EC2에서 Let's Encrypt와 Nginx로 HTTPS 설정하는 방법 (Certbot 완전 가이드)

브라우저 주소창에 '주의 요함' 또는 'Not Secure' 경고가 뜨는 순간, 사용자 이탈은 시작된다. EC2 위에서 Nginx로 서비스를 운영 중인데 아직 HTTP만 열려 있다면, Let's Encrypt의 무료 SSL 인증서와 Certbot을 이용해 30분 안에 HTTPS를 완성할 수 있다. 이 글은 실제 운영 환경에서 겪는 함정 — 보안 그룹 누락, 도메인 검증 실패, 자동 갱신 설정 오류 — 까지 포함해 처음부터 끝까지 다룬다.

TL;DR — EC2 HTTPS 설정 핵심 요약

단계작업주요 확인 포인트
1보안 그룹에서 443 포트 개방인바운드 규칙 HTTPS(443) 추가
2도메인 A 레코드를 EC2 퍼블릭 IP로 연결DNS 전파 확인 필수
3Nginx 설치 및 서버 블록 구성server_name에 실제 도메인 입력
4Certbot 설치 및 인증서 발급--nginx 플러그인 사용
5자동 갱신 크론 또는 systemd 타이머 확인certbot renew --dry-run 통과 여부

HTTPS 인증서 발급이 작동하는 방식

Let's Encrypt는 ACME(Automated Certificate Management Environment) 프로토콜로 도메인 소유권을 검증한다. Certbot의 --nginx 플러그인은 HTTP-01 챌린지를 사용하는데, 이 과정에서 Let's Encrypt 서버가 외부에서 http://<your-domain>/.well-known/acme-challenge/ 경로에 접근할 수 있어야 한다. 즉, EC2 보안 그룹의 80번 포트가 열려 있지 않으면 챌린지 자체가 실패한다 — 이게 가장 흔한 첫 번째 함정이다.

sequenceDiagram participant CB as Certbot (EC2) participant NG as Nginx (EC2) participant LE as Let's Encrypt CA participant BR as 브라우저 (클라이언트) CB->>LE: 인증서 발급 요청 (도메인 포함) LE-->>CB: HTTP-01 챌린지 토큰 발급 CB->>NG: 챌린지 파일 임시 배포 LE->>NG: GET /.well-known/acme-challenge/{token} (HTTP:80) NG-->>LE: 토큰 응답 LE-->>CB: 검증 성공 — 인증서 발급 CB->>NG: Nginx 설정 자동 수정 (443 블록 추가) BR->>NG: HTTPS 요청 (TCP:443) NG-->>BR: TLS 핸드셰이크 + 응답
  1. 클라이언트(Certbot)가 Let's Encrypt CA에 인증서 발급을 요청한다.
  2. Let's Encrypt CA가 HTTP-01 챌린지 토큰을 발급한다.
  3. Certbot이 Nginx를 통해 챌린지 파일을 /.well-known/acme-challenge/ 경로에 임시 노출한다.
  4. Let's Encrypt CA가 외부에서 해당 URL을 HTTP(80)로 직접 조회해 토큰을 검증한다.
  5. 검증 성공 시 인증서(cert.pem, privkey.pem 등)를 발급하고, Certbot이 Nginx 설정을 자동으로 수정한다.
  6. 이후 클라이언트는 443 포트로 TLS 핸드셰이크를 수행한다.

사전 조건 확인 — 시작 전 체크리스트

인증서 발급 전에 아래 세 가지가 반드시 충족되어야 한다. 하나라도 빠지면 Certbot이 중간에 멈춘다.

  • 도메인 소유: EC2 퍼블릭 IP 또는 Elastic IP를 가리키는 A 레코드가 DNS에 등록되어 있어야 한다. Route 53이든 외부 레지스트라든 상관없다.
  • 보안 그룹 인바운드 규칙: TCP 80(HTTP)과 TCP 443(HTTPS) 모두 0.0.0.0/0 또는 필요한 CIDR에서 허용되어야 한다.
  • EC2 인스턴스 OS: 이 가이드는 Amazon Linux 2023 및 Ubuntu 22.04/24.04 기준이다. OS에 따라 패키지 관리자 명령이 다르다.

DNS 전파 확인

# 도메인이 EC2 IP를 가리키는지 확인
dig +short your-domain.com A

# 또는
nslookup your-domain.com

반환된 IP가 EC2 퍼블릭 IP와 일치해야 한다. 일치하지 않으면 인증서 발급을 시도하지 말 것 — 챌린지가 반드시 실패한다.

보안 그룹 인바운드 규칙 확인 (AWS CLI)

aws ec2 describe-security-groups \
  --group-ids sg-0123456789abcdef0 \
  --query 'SecurityGroups[*].IpPermissions[?FromPort==`80` || FromPort==`443`]' \
  --region us-east-1

80과 443 모두 결과에 나타나야 한다. 없다면 아래 명령으로 추가한다.

# HTTP(80) 허용
aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp \
  --port 80 \
  --cidr 0.0.0.0/0 \
  --region us-east-1

# HTTPS(443) 허용
aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp \
  --port 443 \
  --cidr 0.0.0.0/0 \
  --region us-east-1

Step 1 — Nginx 설치 및 기본 서버 블록 구성

Certbot의 --nginx 플러그인은 기존 Nginx 설정을 파싱해서 HTTPS 블록을 자동으로 추가한다. 그러려면 Certbot이 실행되기 전에 server_name에 실제 도메인이 정확히 입력된 서버 블록이 존재해야 한다. 이 단계를 건너뛰고 Certbot을 먼저 실행하면 플러그인이 어느 블록을 수정해야 할지 찾지 못한다.

Amazon Linux 2023

sudo dnf install -y nginx
sudo systemctl enable --now nginx

Ubuntu 22.04 / 24.04

sudo apt update
sudo apt install -y nginx
sudo systemctl enable --now nginx

서버 블록 생성 (Ubuntu 기준 경로)

🔽 Nginx 서버 블록 설정 파일 보기 (클릭해서 펼치기) 
sudo vim /etc/nginx/sites-available/your-domain.com
server {
    listen 80;
    listen [::]:80;

    server_name your-domain.com www.your-domain.com;

    root /var/www/your-domain.com/html;
    index index.html index.htm;

    location / {
        try_files $uri $uri/ =404;
    }
}
# 심볼릭 링크 생성 (Ubuntu)
sudo ln -s /etc/nginx/sites-available/your-domain.com /etc/nginx/sites-enabled/

# 설정 문법 검사
sudo nginx -t

# Nginx 재시작
sudo systemctl reload nginx

Amazon Linux 2023에서는 /etc/nginx/conf.d/your-domain.conf에 직접 파일을 생성하면 된다. sites-available/sites-enabled 구조는 Ubuntu 계열 기본 설정이다.

Step 2 — Certbot 설치

Certbot 공식 권장 설치 방법은 snap 패키지다. OS 패키지 저장소의 Certbot은 버전이 오래된 경우가 있어 플러그인 호환성 문제가 생길 수 있다.

Amazon Linux 2023 — snap 미지원, pip 사용

sudo dnf install -y python3 augeas-libs
sudo python3 -m venv /opt/certbot/
sudo /opt/certbot/bin/pip install --upgrade pip
sudo /opt/certbot/bin/pip install certbot certbot-nginx
sudo ln -s /opt/certbot/bin/certbot /usr/bin/certbot

Ubuntu 22.04 / 24.04 — snap 사용

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

Step 3 — SSL 인증서 발급 (핵심 단계)

이 명령 하나가 도메인 검증, 인증서 발급, Nginx 설정 수정, HTTP→HTTPS 리다이렉트 추가를 모두 처리한다.

sudo certbot --nginx -d your-domain.com -d www.your-domain.com

실행하면 이메일 주소 입력과 이용약관 동의를 묻는다. 이후 Certbot이 HTTP-01 챌린지를 수행하고, 성공하면 아래와 유사한 메시지가 출력된다.

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/your-domain.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/your-domain.com/privkey.pem
This certificate expires on 2025-10-XX.

Certbot이 자동으로 수정한 Nginx 설정을 확인해보면 443 블록과 HTTP→HTTPS 301 리다이렉트가 추가되어 있다.

sudo nginx -t && sudo systemctl reload nginx

Step 4 — 자동 갱신 설정 확인

Let's Encrypt 인증서 유효기간은 90일이다. Certbot은 설치 시 자동으로 갱신 작업을 등록하지만, 실제로 작동하는지 반드시 직접 확인해야 한다. 갱신에 실패해도 즉각적인 알림이 없고, 90일 후 인증서가 만료되어서야 문제를 발견하는 경우가 흔하다.

dry-run으로 갱신 시뮬레이션

sudo certbot renew --dry-run

Congratulations, all simulated renewals succeeded 메시지가 나와야 정상이다.

systemd 타이머 확인 (Ubuntu snap 설치 기준)

sudo systemctl status snap.certbot.renew.timer

크론 확인 (Amazon Linux 2023 pip 설치 기준)

sudo crontab -l

자동으로 등록되지 않았다면 수동으로 추가한다.

echo '0 0,12 * * * root /opt/certbot/bin/python -c "import random; import time; time.sleep(random.random() * 3600)" && sudo certbot renew -q' | sudo tee -a /etc/crontab

실제 운영에서 마주친 실패 패턴 — 오진에서 실제 원인까지

처음에는 Certbot 오류 메시지를 보고 Nginx 설정 문제라고 판단했다. nginx -t는 통과하고, 서버 블록도 정상이었다. 그런데 계속 챌린지 실패가 떴다.

증상: certbot --nginx 실행 시 아래 오류 반복

Challenge failed for domain your-domain.com
http-01 challenge for your-domain.com
Cleaning up challenges
Some challenges have failed.

오진: Nginx server_name 설정이 잘못됐거나 Certbot 버전 문제라고 추정했다.

실제 원인: EC2 보안 그룹에서 TCP 80이 막혀 있었다. Let's Encrypt CA가 외부에서 챌린지 URL을 조회할 수 없었던 것이다. Nginx는 인스턴스 내부에서 정상 동작하고 있었기 때문에 로컬 테스트로는 문제를 발견할 수 없었다.

확인 방법: EC2 외부에서 curl로 직접 챌린지 경로 접근을 테스트한다.

# 외부 머신 또는 Cloud Shell에서 실행
curl -v http://your-domain.com/.well-known/acme-challenge/test

연결 자체가 타임아웃되면 보안 그룹 문제다. 404가 반환되면 Nginx는 정상이고 챌린지 파일 경로 문제다.

보안 그룹은 인스턴스 외부의 방화벽이다. Nginx가 내부에서 잘 돌아간다고 해서 외부 트래픽이 도달한다는 보장이 없다. Let's Encrypt는 항상 인터넷에서 직접 접근한다.

최종 Nginx 설정 확인 — Certbot 수정 후 결과

Certbot이 자동으로 수정한 설정이 의도한 대로 되어 있는지 검토하는 것이 좋다. 특히 리버스 프록시(Node.js, Gunicorn 등)를 사용하는 경우 proxy_pass 블록이 443 서버 블록 안에 있어야 한다.

🔽 Certbot 적용 후 Nginx 설정 예시 보기 (클릭해서 펼치기) 
server {
    listen 80;
    server_name your-domain.com www.your-domain.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name your-domain.com www.your-domain.com;

    ssl_certificate /etc/letsencrypt/live/your-domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    root /var/www/your-domain.com/html;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

HTTPS 동작 최종 검증

설정이 완료되면 아래 세 가지로 실제 동작을 확인한다.

# 1. HTTPS 응답 확인
curl -I https://your-domain.com

# 2. HTTP → HTTPS 리다이렉트 확인
curl -I http://your-domain.com
# Location: https://your-domain.com/ 가 반환되어야 함

# 3. 인증서 만료일 확인
sudo certbot certificates
graph LR Client["브라우저"] -->|"HTTP :80"| NGX80["Nginx :80
301 Redirect"] NGX80 -->|"HTTPS :443"| NGX443["Nginx :443
TLS 종료"] NGX443 -->|"인증서 검증"| CERT["Let's Encrypt
인증서"] NGX443 -->|"정적 파일 또는 프록시"| APP["애플리케이션
백엔드"] CRON["Certbot 자동 갱신
(systemd/cron)"] -->|"90일마다"| CERT
  1. 클라이언트가 HTTP(80)로 접속하면 Nginx가 301 리다이렉트로 HTTPS(443)로 보낸다.
  2. HTTPS 요청에서 TLS 핸드셰이크가 발생하고, Let's Encrypt 인증서로 신뢰가 검증된다.
  3. Nginx가 요청을 처리하거나 백엔드 애플리케이션으로 프록시한다.
  4. 90일마다 Certbot이 자동으로 인증서를 갱신하고 Nginx를 재로드한다.

EC2 HTTPS 설정 마무리 및 다음 단계

이제 브라우저 주소창에 자물쇠 아이콘이 표시되고, HTTP 접속은 자동으로 HTTPS로 리다이렉트된다. 여기서 멈추지 말고 아래 항목을 추가로 검토하면 보안과 성능이 한 단계 더 올라간다.

  • Elastic IP 사용: EC2를 재시작하면 퍼블릭 IP가 바뀐다. Elastic IP를 할당하지 않으면 DNS A 레코드를 다시 수정해야 하고, 인증서 갱신도 실패할 수 있다.
  • HSTS 헤더 추가: Nginx 443 블록에 add_header Strict-Transport-Security "max-age=31536000" always;를 추가하면 브라우저가 HTTP 접속 자체를 차단한다.
  • ALB + ACM 전환 검토: 트래픽이 늘어나면 Application Load Balancer와 AWS Certificate Manager(ACM)를 조합하는 것이 운영 부담이 적다. ACM 인증서는 자동 갱신되고 EC2 인스턴스에 직접 설치할 필요가 없다.

공식 Certbot 문서: https://certbot.eff.org/

핵심 용어 정리

용어설명
Let's Encrypt무료 SSL/TLS 인증서를 발급하는 비영리 CA(Certificate Authority)
CertbotLet's Encrypt 인증서 발급 및 갱신을 자동화하는 EFF 공식 클라이언트 도구
HTTP-01 챌린지도메인 소유권을 검증하는 ACME 프로토콜 방식. 80번 포트로 특정 URL에 접근 가능해야 함
ACMEAutomated Certificate Management Environment. 인증서 발급 자동화 프로토콜 (RFC 8555)
Elastic IPAWS에서 제공하는 고정 퍼블릭 IPv4 주소. EC2 재시작 후에도 IP가 유지됨

Related Posts

댓글

댓글 쓰기

이 블로그의 인기 게시물

EC2 SSH 연결 타임아웃 완전 해결 가이드: Security Group 인바운드 규칙부터 라우팅까지

새로 생성한 EC2 인스턴스에 SSH로 접속하려는데 'Connection timed out' 에러가 뜨는 상황은, AWS를 처음 쓰는 엔지니어뿐 아니라 경험 있는 운영자도 종종 마주친다. 문제는 단순히 Security Group 포트 하나가 아니라, Security Group → Network ACL → 라우팅 테이블 → 인스턴스 상태 까지 여러 레이어가 겹쳐 있다는 점이다. 이 글에서는 EC2 SSH 연결 타임아웃의 실제 원인을 레이어별로 진단하고, CLI 기반으로 빠르게 수정하는 방법을 다룬다. TL;DR — EC2 SSH 연결 타임아웃 빠른 진단표 진단 레이어 확인 항목 가장 흔한 원인 Security Group (인바운드) TCP 22 허용 여부, 소스 IP 포트 22 규칙 누락 또는 소스 0.0.0.0/0 미설정 Network ACL 인바운드 22 허용, 아웃바운드 임시 포트 허용 아웃바운드 임시 포트(1024-65535) 차단 라우팅 테이블 Internet Gateway 연결 여부 Public Subnet에 IGW 라우트 없음 퍼블릭 IP / EIP 인스턴스에 퍼블릭 IP 할당 여부 퍼블릭 IP 없이 직접 접속 시도 인스턴스 상태 Status Check 통과 여부 System/Instance reachability 실패 EC2 SSH 연결이 어떻게 동작하는가 SSH 연결 요청이 EC2에 도달하기까지 거치는 경로를 이해하지 않으면, 어느 레이어에서 막혔는지 추측에 의존하게 된다. 패킷은 인터넷 → IGW → 서브넷 → Network ACL → Security Group → 인스턴스 순서로 흐른다. 각 레이어는 독립적으로 동작하며, 하나라도 막히면 클라이언트 입장에서는 동일하게 타임아웃으로 보인다. graph LR Client["클라이언트"] ...
자세한 내용 보기

S3 정적 웹사이트 호스팅 완전 가이드: HTML/CSS 사이트를 무료로 배포하는 법

간단한 HTML/CSS 포트폴리오나 랜딩 페이지를 만들었는데, 서버 없이 배포할 방법을 찾고 있다면 S3 정적 웹사이트 호스팅이 가장 현실적인 선택이다. EC2 인스턴스를 띄울 필요도 없고, Nginx 설정을 건드릴 필요도 없다. S3 버킷 하나로 수백만 요청을 처리할 수 있다. TL;DR — S3 정적 웹사이트 호스팅 핵심 요약 단계 작업 주의사항 1 S3 버킷 생성 (퍼블릭 액세스 차단 해제) 버킷 이름은 변경 불가 2 정적 웹사이트 호스팅 활성화 인덱스/에러 문서 지정 필수 3 버킷 정책으로 퍼블릭 읽기 허용 ACL 방식은 권장하지 않음 4 파일 업로드 Content-Type 자동 감지 확인 5 S3 웹사이트 엔드포인트로 접근 HTTPS는 CloudFront 필요 S3 정적 웹사이트 호스팅의 동작 원리 S3에는 두 가지 엔드포인트가 존재한다. 하나는 REST API 엔드포인트( s3.amazonaws.com ), 다른 하나는 웹사이트 엔드포인트( s3-website-{region}.amazonaws.com )다. 정적 웹사이트 호스팅을 활성화하면 웹사이트 엔드포인트가 활성화되고, 이 엔드포인트는 HTTP GET 요청에 대해 인덱스 문서를 반환하거나 404 시 커스텀 에러 페이지를 반환하는 웹 서버처럼 동작한다. REST 엔드포인트와 웹사이트 엔드포인트의 결정적 차이는 루트 경로 처리 방식이다. REST 엔드포인트에서 / 를 요청하면 버킷 목록 XML이 반환되거나 403이 뜬다. 웹사이트 엔드포인트는 설정된 인덱스 문서( index.html )를 자동으로 반환한다. 중요한 제약이 하나 있다. S3 웹사이트 엔드포인트는 HTTP만 지원한다. HTTPS가 필요하다면 CloudFront를 앞단에 배치해야 한다. 이 포스트에서는 S3 단독 설정에 집중하고, CloudFront 연동은 별도로 다룬...
자세한 내용 보기

EC2 인스턴스 중지(Stop) vs 종료(Terminate): EBS 데이터는 살아남는가

EC2 인스턴스를 중지했는데 재시작하니 데이터가 사라졌다는 제보가 팀 슬랙에 올라오는 순간, 모두가 멈춘다. 실제로 EC2 인스턴스 중지와 종료의 차이 를 정확히 이해하지 못한 채 비용 절감을 위해 인스턴스를 껐다가 데이터를 잃는 사고는 생각보다 자주 발생한다. Stop과 Terminate는 콘솔에서 불과 몇 픽셀 차이지만, 결과는 완전히 다르다. TL;DR — EC2 중지 vs 종료 핵심 비교 항목 Stop (중지) Terminate (종료) 인스턴스 상태 stopped → 재시작 가능 shutting-down → terminated (영구) 루트 EBS 볼륨 기본 유지 기본 삭제 (DeleteOnTermination=true) 추가 EBS 볼륨 유지 기본 유지 (DeleteOnTermination=false) 인스턴스 스토어 데이터 소멸 데이터 소멸 퍼블릭 IP (동적) 중지 시 반환, 재시작 시 새 IP 할당 즉시 반환 Elastic IP 유지 (연결 상태 유지) 연결 해제 (IP 자체는 계정에 남음) 과금 인스턴스 요금 없음, EBS 요금 발생 인스턴스 요금 없음, 잔존 EBS 요금 발생 복구 가능성 가능 불가능 EC2 인스턴스 중지와 종료의 동작 원리 Stop과 Terminate를 단순히 '켜고 끄는 것'으로 이해하면 반드시 사고가 난...
자세한 내용 보기