[Infra Ops] Let's Encrypt 인증서 발급과 Nginx SSL 설정

HTTPS의 자물쇠 아이콘은 단순히 "암호화됐다"는 표시가 아닙니다. "이 서버가 주장하는 도메인의 진짜 소유자임을 제3자가 서명했다"는 의미입니다. 이 서명 체계가 없다면 공격자가 example.com을 사칭하는 서버를 만들어도 브라우저는 알아채지 못합니다. CA(인증기관)와 인증서 체인은 브라우저가 신뢰할 서버와 그렇지 않은 서버를 구분하는 공개키 기반 신뢰 인프라의 핵심입니다.

확대

HTTPS가 단순히 "암호화된 HTTP"라고 생각하면 절반만 맞습니다. 암호화만으로는 내가 통신하는 상대가 진짜 그 서버인지 알 수 없습니다. 그래서 인증서가 필요합니다. 인증서는 "이 서버가 정말 example.com이다"라는 제3자의 서명입니다.

이 제3자를 **CA(Certificate Authority, 인증기관)**라고 부릅니다. 브라우저와 OS에는 신뢰할 수 있는 CA 목록이 내장되어 있습니다. 서버 인증서가 신뢰할 수 있는 CA의 서명을 받았다면 브라우저는 초록 자물쇠를 표시합니다.

인증서는 체인 구조입니다: 브라우저 내장 루트 CA → 중간 CA(Let's Encrypt R11 등) → 서버 인증서(your-domain.com)

Let's Encrypt는 ISRG(Internet Security Research Group)이 운영하는 무료 CA입니다. 2016년 이후 주요 브라우저와 OS 모두에서 신뢰하며, 자동화 도구(Certbot)로 발급과 갱신을 처리할 수 있어 사실상 표준이 됐습니다.

인증서 파일 두 가지:

브라우저가 https://로 보낸 요청은 암호문으로 도착합니다. Nginx는 이 암호문을 받아 복호화하고(TLS 종료), 평문 HTTP로 백엔드에 넘긴 뒤, 백엔드 응답을 다시 암호화해 돌려보냅니다. 이 "복호화 지점" 역할을 단계로 알아야 인증서 만료, SNI 불일치, mixed content, 핸드셰이크 실패가 각각 어느 단계에서 터지는지 짚을 수 있습니다. 핸드셰이크 내부는 다음 개념에서 자세히 보고, 여기서는 요청 하나가 Nginx를 통과하는 전체 경로를 봅니다.

[브라우저]  https://shop.example.com/order   (암호문)
   │
   ① ClientHello        지원 TLS 버전·cipher 목록 + SNI(접속하려는 도메인) 제시
   │
   ② 인증서 제시         SNI에 맞는 server 블록의 ssl_certificate(fullchain) 반환
   │
   ③ 키 교환·세션키       인증서 검증 후 양측이 대칭 세션키 합의            (여기까지가 핸드셰이크)
   │
   ④ 복호화(TLS 종료)     이후 도착하는 암호문을 세션키로 복호화 → 평문 HTTP 요청 확보
   │
   ⑤ 평문으로 백엔드 전달   location 매칭 → proxy_pass 로 평문 HTTP를 WAS에 전달
   │
   ⑥ 응답 암호화          백엔드 평문 응답을 세션키로 다시 암호화해 반환
   ▼
[브라우저]  200 (복호화해서 렌더링)

각 단계에서 무슨 일이 일어나고, 막히면 어떤 증상인가:

즉 HTTPS 문제는 핸드셰이크에서 깨졌나(①③), 복호화·연결에서 깨졌나(④⑤), 콘텐츠에서 깨졌나(⑥ mixed content) 로 갈립니다 — handshake failure·인증서 경고는 ①③(버전·SNI·체인·만료), ERR_SSL_PROTOCOL_ERROR는 ④(listen 443 ssl 확인), mixed content는 ⑤⑥(백엔드가 https를 인지하도록 X-Forwarded-Proto)입니다. 그래서 판정은 브라우저가 아니라 openssl s_client -connect 도메인:443 -servername 도메인으로 서버가 실제 보내는 인증서 체인과 Verify return code를 보고, listen 줄에 ssl이 있는지를 nginx -T로 확인하는 순서로 좁힙니다.

HTTP는 연결하면 바로 데이터를 주고받습니다. HTTPS는 데이터 교환 전에 TLS 핸드셰이크가 먼저 일어납니다. 이 과정을 이해해야 ssl_session_cache 같은 설정이 왜 필요한지 납득이 됩니다.

확대

핸드셰이크는 대략 이렇게 동작합니다:

1. 클라이언트 → 서버: "이런 암호화 방식을 지원해요" (ClientHello)
2. 서버 → 클라이언트: "이 방식을 쓰자, 내 인증서야" (ServerHello + Certificate)
3. 클라이언트: 인증서를 CA 체인으로 검증
4. 클라이언트 ↔ 서버: 세션 키 교환 (대칭키 협상)
5. 이후부터는 협상한 대칭키로 암호화 통신

CPU 비용이 있습니다. 핸드셰이크는 비대칭 암호 연산을 포함하기 때문에 일반 HTTP보다 비쌉니다. 그래서 Nginx에 세션 캐시를 설정해 재연결 시 핸드셰이크를 생략합니다.

# 이 설정이 왜 있는지 이제 납득이 됩니다
ssl_session_cache shared:SSL:10m;   # 워커 공유 캐시 10MB
ssl_session_timeout 10m;            # 캐시 유지 시간

Certbot 플러그인이 자동으로 해주는 것도 좋지만, 실제로 무슨 설정이 들어가는지 알아야 합니다. 직접 관리하는 서버에서는 설정의 각 줄이 무엇을 의미하는지 설명할 수 있어야 합니다.

# /etc/nginx/sites-available/yourdomain.com

# 1. HTTP → HTTPS 리다이렉트
server {
    listen 80;
    listen [::]:80;
    server_name yourdomain.com www.yourdomain.com;

    # 301 영구 리다이렉트 — SEO와 브라우저 캐시 모두 HTTPS로 기억
    return 301 https://$host$request_uri;
}

# 2. HTTPS 메인 블록
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name yourdomain.com www.yourdomain.com;

    # 인증서 파일 경로
    ssl_certificate     /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

    # 권장 TLS 버전 (1.2, 1.3만 허용 — 1.0, 1.1은 취약)
    ssl_protocols TLSv1.2 TLSv1.3;

    # 강력한 암호화 스위트만 허용
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256;
    ssl_prefer_server_ciphers off;  # TLS 1.3에서는 off 권장

    # 세션 캐시 — 재연결 시 핸드셰이크 생략
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;

    # HSTS — 브라우저가 이 도메인은 항상 HTTPS로 접근하도록 기억
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    # 기타 보안 헤더
    add_header X-Content-Type-Options nosniff always;
    add_header X-Frame-Options DENY always;

    root /var/www/yourdomain.com;
    index index.html;

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

HSTS 주의사항: max-age=31536000(1년)으로 설정하면 브라우저가 1년간 이 도메인을 HTTPS로만 접근합니다. HTTPS를 다시 HTTP로 내릴 일이 없다고 확신할 때만 설정하세요. 처음에는 max-age=300으로 시작해 문제 없으면 늘리는 게 안전합니다.

Let's Encrypt 인증서는 90일마다 만료됩니다. 수동으로 갱신하다 깜빡하면 사이트가 "인증서 만료" 경고로 접근 불가가 됩니다. 자동 갱신은 선택이 아닌 필수입니다.

Certbot 설치 시 systemd timer가 자동으로 등록됩니다. Ubuntu 기준으로 확인해봅니다.

# systemd timer 등록 여부 확인
sudo systemctl status certbot.timer
# certbot.timer - Run certbot twice daily
#   Active: active (waiting)
#   Trigger: Wed 2025-01-15 12:00:00 UTC

# 직접 갱신 테스트 (실제로 갱신하지 않고 시뮬레이션만)
sudo certbot renew --dry-run

systemd timer가 없는 환경(CentOS 7, 일부 구버전)이나 직접 통제하고 싶을 때는 cron을 씁니다.

# crontab 편집
sudo crontab -e

# 매일 새벽 2시 30분, 오후 2시 30분 두 번 실행
# certbot은 만료 30일 이내일 때만 실제 갱신 수행
30 2,14 * * * certbot renew --quiet --post-hook "systemctl reload nginx"

# --quiet: 성공 시 출력 없음 (메일 스팸 방지)
# --post-hook: 갱신이 실제로 일어났을 때만 nginx reload

왜 하루 두 번인가? Let's Encrypt 서버 장애나 네트워크 문제로 갱신이 실패할 경우를 대비합니다. 한 번 실패해도 몇 시간 후 재시도 기회가 있습니다.

앞의 핸드셰이크 그림에서 서버가 '내 인증서'를 보낸다고 했습니다. 정확히는 서버가 무엇을 보내고 클라이언트가 무엇으로 검증하는지를 알아야, '브라우저는 되는데 특정 클라이언트만 실패하는' 사고를 이해할 수 있습니다.

• 서버는 leaf + 중간 CA를 함께 보내야 합니다: 서버 인증서(leaf) 하나만 보내는 게 아니라, 그 위의 중간 CA 인증서까지 묶어 보내야 클라이언트가 자기가 가진 루트 CA까지 체인을 이을 수 있습니다(루트는 클라이언트가 이미 보유). 이 묶음이 fullchain.pem입니다.
• 왜 브라우저는 되고 다른 클라이언트는 안 되나: 서버가 leaf만 보내 체인이 불완전해도, 최신 브라우저는 중간 인증서를 캐시해 뒀거나 인증서의 AIA 필드를 보고 중간 인증서를 스스로 내려받아(AIA fetching) 체인을 메꿔 성공합니다. 반면 curl·Java(HttpClient)·Go·모바일 앱·모니터링/웹훅 발신자는 대개 그 보정을 하지 않아, 같은 서버에서 unable to get local issuer certificate 같은 체인 오류를 냅니다. 그래서 '내 브라우저는 되는데 왜 파트너 API만 실패하지?'가 생깁니다.
• 폐기 확인과 OCSP stapling: 클라이언트는 인증서가 중간에 폐기됐는지도 확인합니다. 매 연결마다 CA의 OCSP 서버에 물으면 느리고 프라이버시 문제가 있어, 서버가 CA의 OCSP 응답을 미리 받아 핸드셰이크에 끼워 보내는 OCSP stapling(ssl_stapling on)을 씁니다. 다만 stapling이 잘못 설정돼 응답을 못 받아오면 첫 핸드셰이크가 느려지거나 경고가 남습니다.

정리하면 인증서 '적용됨'은 leaf 하나만으로도 브라우저에선 통과할 수 있어 조용히 넘어갑니다. 하지만 진짜 완결은 '모든 클라이언트가 체인을 검증할 수 있는가'입니다. 그래서 ssl_certificate에는 항상 fullchain.pem을 쓰고, 판정은 브라우저가 아니라 openssl s_client의 체인 출력과 Verify return code로 합니다.