Nginx SSL/TLS 적용하기

2025-12-11

SSL/TLS란?

SSL (Secure Sockets Layer) 과 TLS (Transport Layer Security) 는 인터넷 통신을 암호화하는 프로토콜입니다. 1994년 넷스케이프에서 SSL 1.0을 개발한 이후, SSL은 웹 보안의 표준으로 자리잡았습니다. 그러나 여러 보안 취약점이 발견되면서 1999년 IETF(Internet Engineering Task Force)는 SSL 3.0을 기반으로 한 TLS 1.0을 발표했습니다.

현재 SSL 3.0과 TLS 1.0, 1.1은 보안상의 이유로 폐기되었으며, TLS 1.2(2008년 발표)와 TLS 1.3(2018년 발표)만 사용해야 합니다. 그럼에도 불구하고 역사적 이유와 관례상 “SSL 인증서” 또는 “SSL/TLS”라는 용어를 계속 사용하고 있습니다.

SSL/TLS의 작동 원리

SSL/TLS는 비대칭 암호화와 대칭 암호화를 조합하여 안전한 통신을 제공합니다:

핸드셰이크 단계: 클라이언트와 서버가 비대칭 암호화(공개키/개인키)를 사용하여 안전하게 세션키를 교환합니다.
데이터 전송 단계: 교환된 세션키를 사용하여 대칭 암호화로 빠르게 데이터를 암호화/복호화합니다.
검증 단계: 인증서를 통해 서버의 신원을 확인하고, 메시지 인증 코드(MAC)로 데이터 무결성을 보장합니다.

이러한 구조 덕분에 SSL/TLS는 높은 보안성과 효율성을 동시에 제공할 수 있습니다.

왜 SSL/TLS가 필수인가?

1. 데이터 암호화 - 도청 방지

HTTP는 모든 데이터를 평문으로 전송하기 때문에, 중간자 공격(Man-in-the-Middle Attack)을 통해 누구나 패킷을 가로채서 내용을 읽을 수 있습니다. 로그인 정보, 개인정보, 결제 정보 등 민감한 데이터가 노출될 위험이 있습니다. HTTPS는 AES, ChaCha20 같은 강력한 암호화 알고리즘을 사용하여 데이터를 암호화하므로, 가로채더라도 내용을 해독할 수 없습니다.

2. 서버 인증 - 피싱 방지

SSL 인증서는 신뢰할 수 있는 인증 기관(CA, Certificate Authority)에서 발급합니다. 브라우저는 인증서를 검증하여 현재 접속한 사이트가 정말 원하는 사이트인지 확인할 수 있습니다. 이를 통해 악의적인 사이트가 정상적인 사이트를 사칭하는 피싱 공격을 방지할 수 있습니다.

3. 데이터 무결성 - 변조 방지

SSL/TLS는 HMAC(Hash-based Message Authentication Code)를 사용하여 전송 중인 데이터가 변조되지 않았음을 보장합니다. 공격자가 패킷을 가로채서 내용을 수정하더라도, 수신자는 이를 감지하고 거부할 수 있습니다.

4. SEO 및 검색 순위

2014년부터 Google은 HTTPS를 검색 순위 결정 요소로 사용하기 시작했습니다. 동일한 품질의 콘텐츠라면 HTTPS 사이트가 HTTP 사이트보다 높은 순위를 받게 됩니다. 또한 Google Search Console에서는 HTTPS 사이트에 대한 더 많은 분석 데이터를 제공합니다.

5. 브라우저 요구사항 및 사용자 신뢰

Chrome, Firefox, Safari 등 주요 브라우저는 HTTP 사이트에 “안전하지 않음” 경고를 표시합니다. 특히 로그인 폼이나 결제 페이지가 있는 HTTP 사이트는 더욱 강력한 경고를 보여줍니다. 사용자들은 이러한 경고를 보고 사이트를 이탈할 가능성이 높아, 비즈니스에 직접적인 영향을 미칩니다.

6. 최신 웹 기능 활용

HTTP/2, HTTP/3, Service Workers, Progressive Web Apps(PWA), Geolocation API 등 많은 최신 웹 기능들은 HTTPS를 필수로 요구합니다. HTTPS 없이는 현대적인 웹 애플리케이션을 구축하는 것이 사실상 불가능합니다.

7. 규제 준수

PCI DSS(Payment Card Industry Data Security Standard), GDPR(General Data Protection Regulation), HIPAA(Health Insurance Portability and Accountability Act) 등 많은 보안 및 개인정보 보호 규정에서 민감한 데이터 전송 시 암호화를 의무화하고 있습니다.

SSL 인증서 종류

SSL 인증서는 검증 수준과 적용 범위에 따라 여러 종류로 나뉩니다. 각 인증서는 서로 다른 보안 수준과 비용, 발급 속도를 가지므로, 웹사이트의 특성과 요구사항에 맞게 선택해야 합니다.

검증 수준별 분류

1. DV (Domain Validation) - 도메인 검증 인증서

DV 인증서는 가장 기본적인 형태의 SSL 인증서로, 신청자가 해당 도메인을 실제로 소유하고 있는지만 확인합니다. 인증 기관은 이메일 인증, DNS 레코드 확인, HTTP 파일 업로드 등의 간단한 방법으로 도메인 소유권을 검증합니다.

특징:

발급 시간: 몇 분 ~ 몇 시간 (자동화된 프로세스)
가격: 무료 ~ 저렴 (Let’s Encrypt는 완전 무료)
검증 수준: 낮음 (도메인 소유권만 확인)
브라우저 표시: 기본 자물쇠 아이콘

적합한 사용처:

개인 블로그
소규모 웹사이트
개발/테스트 환경
비상업적 사이트

대표 사례: Let’s Encrypt, Cloudflare SSL, AWS Certificate Manager

2. OV (Organization Validation) - 조직 검증 인증서

OV 인증서는 도메인 소유권뿐만 아니라 신청 조직의 실체도 검증합니다. 인증 기관은 사업자등록증, 법인등록증 등의 공식 문서를 확인하고, 전화나 이메일로 조직의 실재를 확인합니다.

특징:

발급 시간: 1~3일 (수동 검증 필요)
가격: 연간 50~200달러
검증 수준: 중간 (조직 정보 검증)
브라우저 표시: 자물쇠 아이콘 + 인증서에서 조직 정보 확인 가능

적합한 사용처:

기업 공식 웹사이트
B2B 서비스
고객 정보를 다루는 사이트
신뢰도가 중요한 비즈니스

대표 사례: Sectigo OV, DigiCert OV, GlobalSign OV

3. EV (Extended Validation) - 확장 검증 인증서

EV 인증서는 가장 엄격한 검증 과정을 거치는 인증서입니다. 인증 기관은 조직의 법적 실체, 물리적 위치, 운영 상태 등을 철저히 검증하며, CA/Browser Forum에서 정한 엄격한 가이드라인을 따릅니다.

특징:

발급 시간: 3~7일 (매우 엄격한 검증)
가격: 연간 150~500달러
검증 수준: 최고 (조직의 모든 측면 검증)
브라우저 표시: 과거에는 주소창에 회사명이 녹색으로 표시되었으나, 현재는 자물쇠 클릭 시 조직 정보 표시

적합한 사용처:

은행, 금융 기관
전자상거래 사이트
결제 처리 시스템
고객 신뢰가 매우 중요한 서비스

참고: 2019년 이후 주요 브라우저들이 주소창의 EV 표시를 제거하면서, EV 인증서의 실질적 가치에 대한 논란이 있습니다. 많은 기업들이 비용 대비 효과를 고려하여 OV 인증서로 전환하고 있습니다.

도메인 범위별 분류

1. 단일 도메인 (Single Domain) 인증서

하나의 특정 도메인(예: example.com 또는 www.example.com)만 보호합니다. 가장 기본적이고 저렴한 형태입니다.

예시:

example.com을 위한 인증서는 example.com만 보호
www.example.com과는 별개로 취급됨
대부분의 CA는 www를 자동으로 포함시켜주지만, 항상 확인 필요

비용: 가장 저렴 (Let’s Encrypt는 무료)

2. 와일드카드 (Wildcard) 인증서

특정 도메인의 모든 1단계 서브도메인을 보호합니다. *.example.com 형태로 발급되며, 서브도메인을 자주 추가하는 경우 매우 유용합니다.

보호 범위:

✅ api.example.com
✅ blog.example.com
✅ shop.example.com
❌ example.com (루트 도메인은 별도로 추가해야 함)
❌ sub.api.example.com (2단계 서브도메인은 보호 안 됨)

발급 방법:

DV 인증서로만 발급 가능 (DNS 인증 필수)
Let’s Encrypt에서 무료 발급 가능하나, DNS API 연동 필요

비용: 단일 도메인보다 2~3배 비쌈

사용 사례:

마이크로서비스 아키텍처 (각 서비스마다 서브도메인 사용)
멀티테넌트 SaaS (고객사마다 서브도메인 할당)
개발/스테이징/프로덕션 환경 (dev.example.com, staging.example.com 등)

3. 멀티 도메인 (SAN/UCC) 인증서

SAN(Subject Alternative Name) 또는 UCC(Unified Communications Certificate)라고 불리며, 완전히 다른 여러 도메인을 하나의 인증서로 보호할 수 있습니다.

보호 범위 예시:

example.com
example.net
example.org
www.example.com
shop.anotherdomain.com

특징:

일반적으로 3~100개의 도메인 지원
도메인 추가/제거 시 인증서 재발급 필요
관리 포인트가 하나로 통합됨

비용: 도메인 개수에 따라 증가

사용 사례:

여러 브랜드를 운영하는 기업
레거시 시스템 통합
Microsoft Exchange, Office 365 환경

방법 1: Let’s Encrypt (무료)

Let’s Encrypt는 2016년에 시작된 비영리 인증 기관(CA)으로, 누구나 무료로 SSL/TLS 인증서를 발급받을 수 있도록 하는 것을 목표로 합니다. Mozilla, Cisco, Facebook, Google 등 주요 기업들의 후원으로 운영되며, 전 세계 수억 개의 웹사이트에서 사용되고 있습니다.

Let’s Encrypt의 특징

장점:

완전 무료: 발급, 갱신, 관리 비용이 전혀 없습니다
자동화: ACME(Automatic Certificate Management Environment) 프로토콜을 통한 자동 발급 및 갱신
신뢰성: 모든 주요 브라우저에서 신뢰하는 인증서
간편함: Certbot 같은 도구로 몇 분 안에 설정 가능
DV 인증서: 도메인 검증 인증서를 빠르게 발급

제한사항:

90일 유효기간: 보안을 위해 짧게 설정 (자동 갱신으로 해결)
DV만 지원: OV, EV 인증서는 발급 불가
Rate Limiting: 같은 도메인에 대해 주당 50개까지만 발급 가능
와일드카드 제한: DNS 챌린지만 가능 (HTTP 챌린지 불가)

Let’s Encrypt가 적합한 경우:

개인 웹사이트, 블로그
스타트업 및 중소기업 웹사이트
API 서버
개발/스테이징 환경
비영리 조직 웹사이트
예산이 제한적인 프로젝트

Certbot 설치

Ubuntu/Debian

sudo apt update
sudo apt install certbot python3-certbot-nginx

CentOS/RHEL 8

sudo dnf install epel-release
sudo dnf install certbot python3-certbot-nginx

macOS

brew install certbot

인증서 발급 (자동 설정)

Certbot이 Nginx 설정을 자동으로 수정합니다.

# 단일 도메인
sudo certbot --nginx -d example.com

# 여러 도메인 (www 포함)
sudo certbot --nginx -d example.com -d www.example.com

# 와일드카드 인증서 (DNS 인증 필요)
sudo certbot certonly --manual --preferred-challenges dns -d "*.example.com" -d example.com

자동 설정 과정에서 선택 사항

이메일 입력 (인증서 만료 알림용)
서비스 약관 동의
HTTP 트래픽 처리 방법 선택:
- HTTP와 HTTPS 모두 허용
- HTTP를 HTTPS로 자동 리다이렉트 (권장)

인증서 발급 (수동 설정)

설정 파일을 직접 수정하려면:

# 인증서만 발급 (설정은 수동으로)
sudo certbot certonly --nginx -d example.com -d www.example.com

발급된 인증서 위치:

/etc/letsencrypt/live/example.com/fullchain.pem   # 인증서
/etc/letsencrypt/live/example.com/privkey.pem     # 개인키
/etc/letsencrypt/live/example.com/chain.pem       # 체인 인증서
/etc/letsencrypt/live/example.com/cert.pem        # 서버 인증서

Nginx 수동 설정

server {
    listen 80;
    server_name example.com www.example.com;

    # ACME 챌린지용 (인증서 갱신에 필요)
    location ^~ /.well-known/acme-challenge/ {
        root /var/www/html;
    }

    # 나머지 요청은 HTTPS로 리다이렉트
    location / {
        return 301 https://$server_name$request_uri;
    }
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com www.example.com;

    # SSL 인증서 설정
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # SSL 프로토콜 설정
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;

    # SSL 암호화 스위트
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';

    # SSL 세션 캐시
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_session_tickets off;

    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;

    # DNS 리졸버
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;

    # 보안 헤더
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-XSS-Protection "1; mode=block" always;

    root /var/www/example.com;
    index index.html index.htm;

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

자동 갱신 설정

Let’s Encrypt 인증서는 90일마다 갱신이 필요합니다.

갱신 테스트

sudo certbot renew --dry-run

Cron 작업 추가 (자동 갱신)

Certbot 설치 시 자동으로 systemd timer가 설정되지만, 확인:

# systemd timer 확인
systemctl status certbot.timer

# 수동 실행
sudo certbot renew

# 갱신 후 Nginx 리로드를 위한 hook
sudo certbot renew --deploy-hook "systemctl reload nginx"

수동으로 cron 설정하려면:

sudo crontab -e

다음 줄 추가:

# 매일 새벽 3시에 인증서 갱신 확인
0 3 * * * certbot renew --quiet --deploy-hook "systemctl reload nginx"

와일드카드 인증서 발급

와일드카드 인증서는 DNS 인증이 필요합니다.

sudo certbot certonly \
  --manual \
  --preferred-challenges dns \
  -d "*.example.com" \
  -d example.com

과정:

Certbot이 TXT 레코드 값을 제공
DNS 설정에서 _acme-challenge.example.com TXT 레코드 추가
DNS 전파 확인 후 Enter

DNS 전파 확인:

dig _acme-challenge.example.com TXT

방법 2: 유료 인증서

1. 인증서 구매

인증서를 구매할 수 있는 곳:

Comodo/Sectigo
DigiCert
GlobalSign
GoDaddy
Namecheap

2. CSR (Certificate Signing Request) 생성

# 개인키 생성
sudo openssl genrsa -out /etc/ssl/private/example.com.key 2048

# CSR 생성
sudo openssl req -new -key /etc/ssl/private/example.com.key \
  -out /etc/ssl/csr/example.com.csr

# 입력 정보
Country Name (2 letter code) [AU]: KR
State or Province Name (full name) [Some-State]: Seoul
Locality Name (eg, city) []: Seoul
Organization Name (eg, company) []: Example Inc
Organizational Unit Name (eg, section) []: IT
Common Name (e.g. server FQDN or YOUR name) []: example.com
Email Address []: admin@example.com

3. CSR 제출 및 인증서 받기

CSR 파일 내용을 인증 기관에 제출
cat /etc/ssl/csr/example.com.csr
도메인 검증 완료 (이메일 또는 DNS)
인증서 파일 다운로드:
- example.com.crt (서버 인증서)
- intermediate.crt (중간 인증서)

4. 인증서 설치

# 인증서 파일 저장
sudo cp example.com.crt /etc/ssl/certs/
sudo cp intermediate.crt /etc/ssl/certs/

# 권한 설정
sudo chmod 644 /etc/ssl/certs/example.com.crt
sudo chmod 644 /etc/ssl/certs/intermediate.crt
sudo chmod 600 /etc/ssl/private/example.com.key

# 인증서 체인 생성 (옵션)
sudo cat /etc/ssl/certs/example.com.crt \
         /etc/ssl/certs/intermediate.crt \
         > /etc/ssl/certs/example.com-chain.crt

5. Nginx 설정

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/ssl/certs/example.com-chain.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    # 나머지 SSL 설정은 위와 동일
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
    ssl_prefer_server_ciphers off;

    # ...
}

방법 3: 자체 서명 인증서 (개발/테스트용)

프로덕션 환경에는 사용하지 마세요!

인증서 생성

# 개인키와 인증서를 한 번에 생성 (유효기간 365일)
sudo openssl req -x509 -nodes -days 365 \
  -newkey rsa:2048 \
  -keyout /etc/ssl/private/selfsigned.key \
  -out /etc/ssl/certs/selfsigned.crt

# 입력 정보
Country Name: KR
State: Seoul
Locality: Seoul
Organization: Dev
Common Name: localhost (또는 개발 도메인)

Nginx 설정

server {
    listen 443 ssl http2;
    server_name localhost;

    ssl_certificate /etc/ssl/certs/selfsigned.crt;
    ssl_certificate_key /etc/ssl/private/selfsigned.key;

    ssl_protocols TLSv1.2 TLSv1.3;

    root /var/www/html;
    index index.html;
}

SSL 최적화 설정

1. Mozilla SSL Configuration Generator

Mozilla SSL Configuration Generator를 사용하면 최신 권장 설정을 얻을 수 있습니다.

2. 최신 보안 설정 (2025년 기준)

# /etc/nginx/conf.d/ssl.conf
# 모든 SSL 사이트에서 공유

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';
ssl_prefer_server_ciphers off;

# Diffie-Hellman 파라미터
ssl_dhparam /etc/nginx/dhparam.pem;

# 세션 캐시
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;

# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

# 보안 헤더
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

3. DH 파라미터 생성

sudo openssl dhparam -out /etc/nginx/dhparam.pem 2048

더 강력한 보안을 원하면 4096 사용 (시간이 오래 걸림):

sudo openssl dhparam -out /etc/nginx/dhparam.pem 4096

4. 서버별 설정에서 include

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;

    # 공통 SSL 설정 포함
    include /etc/nginx/conf.d/ssl.conf;

    # 사이트별 설정
    root /var/www/example.com;
    index index.html;
}

HSTS (HTTP Strict Transport Security)

HSTS란?

HSTS(HTTP Strict Transport Security)는 웹사이트가 브라우저에게 “앞으로는 무조건 HTTPS로만 접속하라”고 지시하는 보안 메커니즘입니다. 2012년 RFC 6797로 표준화되었으며, 현재 모든 주요 브라우저에서 지원됩니다.

HSTS의 작동 원리

최초 HTTPS 접속: 사용자가 처음 HTTPS로 사이트에 접속합니다.
HSTS 헤더 수신: 서버는 Strict-Transport-Security 헤더를 응답에 포함시킵니다.
브라우저 저장: 브라우저는 이 정책을 저장하고 지정된 기간 동안 기억합니다.
자동 HTTPS 전환: 이후 사용자가 HTTP로 접속을 시도하면, 브라우저가 자동으로 HTTPS로 리다이렉트합니다 (서버 왕복 없이!).

HSTS가 해결하는 보안 문제

1. SSL Stripping 공격 방지

공격 시나리오 (HSTS 없이):

1. 사용자가 http://bank.com 입력
2. 공격자가 중간에서 가로채고 HTTP로 응답
3. 사용자는 HTTP로 통신하게 되어 정보 유출

HSTS로 방어:

1. 사용자가 http://bank.com 입력
2. 브라우저가 자동으로 https://bank.com으로 변경
3. 공격자가 개입할 기회가 없음

2. 중간자 공격 (Man-in-the-Middle) 방지

사용자가 실수로 HTTP 링크를 클릭하거나, 북마크에 HTTP로 저장했더라도 브라우저가 자동으로 HTTPS로 전환하여 보호합니다.

3. Mixed Content 문제 완화

HTTPS 페이지에서 HTTP 리소스를 로드할 때 발생하는 보안 경고를 줄입니다.

HSTS 헤더 구성 요소

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

파라미터 설명:

max-age (필수)
- 브라우저가 HSTS 정책을 기억할 시간 (초 단위)
- max-age=31536000: 1년 (365일)
- max-age=63072000: 2년 (권장)
- 0으로 설정하면 HSTS 비활성화
includeSubDomains (선택)
- 모든 서브도메인에도 HSTS 적용
- example.com뿐만 아니라 api.example.com, blog.example.com 등도 포함
- ⚠️ 주의: 모든 서브도메인이 HTTPS를 지원해야 함
preload (선택)
- 브라우저의 HSTS Preload List에 등록 신청
- 사용자가 한 번도 방문하지 않았어도 보호
- ⚠️ 주의: 되돌릴 수 없으므로 신중하게 결정

HSTS의 한계와 주의사항

첫 방문 취약점 (Trust-On-First-Use, TOFU)

HSTS는 사용자가 처음 HTTPS로 사이트를 방문한 이후에만 효과가 있습니다. 첫 방문 시에는 여전히 공격에 노출될 수 있습니다.

해결책: HSTS Preload List 등록

Preload의 영구성

Preload에 등록하면 제거하는 데 몇 달이 걸릴 수 있으며, 모든 브라우저에서 완전히 제거되려면 더 오래 걸립니다.

주의사항:

모든 서브도메인이 영구히 HTTPS만 지원해야 함
HTTP로 돌아갈 계획이 없어야 함
레거시 서브도메인이 없는지 확인 필요

설정 단계

1단계: 테스트 설정 (짧은 기간)

add_header Strict-Transport-Security "max-age=300" always;

2단계: 1주일 테스트

add_header Strict-Transport-Security "max-age=604800" always;

3단계: 1년 + 서브도메인 포함

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

4단계: Preload 리스트 등록

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

hstspreload.org에서 도메인 등록

⚠️ 주의: preload는 되돌릴 수 없으므로 신중하게!

SSL 인증서 확인

인증서 정보 확인

# 인증서 내용 확인
sudo openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -text -noout

# 만료 날짜 확인
sudo openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -noout -dates

# 도메인 확인
sudo openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -noout -subject

# 발급자 확인
sudo openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -noout -issuer

서버 SSL 테스트

# OpenSSL로 연결 테스트
openssl s_client -connect example.com:443 -servername example.com

# 인증서 체인 확인
openssl s_client -connect example.com:443 -showcerts

온라인 SSL 테스트 도구

SSL Labs Server Test (가장 권장)
- https://www.ssllabs.com/ssltest/
- A+ 등급을 목표로!
SSL Checker
- https://www.sslshopper.com/ssl-checker.html
Why No Padlock
- https://www.whynopadlock.com/

멀티 도메인 SSL 설정

방법 1: 각 도메인별 인증서

# example.com
server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;

    include /etc/nginx/conf.d/ssl.conf;
    root /var/www/example.com;
}

# another-site.com
server {
    listen 443 ssl http2;
    server_name another-site.com www.another-site.com;

    ssl_certificate /etc/letsencrypt/live/another-site.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/another-site.com/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/another-site.com/chain.pem;

    include /etc/nginx/conf.d/ssl.conf;
    root /var/www/another-site.com;
}

방법 2: 와일드카드 인증서

server {
    listen 443 ssl http2;
    server_name app1.example.com;

    # 같은 와일드카드 인증서 사용
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    include /etc/nginx/conf.d/ssl.conf;
    root /var/www/app1;
}

server {
    listen 443 ssl http2;
    server_name app2.example.com;

    # 같은 와일드카드 인증서 사용
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    include /etc/nginx/conf.d/ssl.conf;
    root /var/www/app2;
}

리버스 프록시에서 SSL

리버스 프록시 환경에서 SSL/TLS를 구성하는 방법은 크게 두 가지입니다. 각 방법은 서로 다른 보안 수준과 성능 특성을 가지므로, 요구사항에 맞게 선택해야 합니다.

1. SSL Termination (SSL 종료) - 권장 방식

개념:
SSL Termination은 Nginx에서 SSL/TLS 연결을 종료하고, 백엔드 서버와는 암호화되지 않은 HTTP로 통신하는 방식입니다. 이는 가장 일반적이고 효율적인 구성입니다.

통신 흐름:

클라이언트 ↔ Nginx (HTTPS) → 백엔드 서버 (HTTP)

장점:

성능 향상
- SSL/TLS 암호화/복호화를 Nginx에서만 처리하므로 백엔드 서버의 CPU 부담 감소
- 백엔드 서버는 애플리케이션 로직에만 집중 가능
- 내부 네트워크는 암호화 오버헤드 없이 빠른 통신
중앙화된 인증서 관리
- 인증서를 Nginx 한 곳에서만 관리
- 인증서 갱신이 간단함
- 여러 백엔드 서버가 있어도 인증서는 하나만 필요
간편한 백엔드 설정
- 백엔드 서버에 SSL 설정이 불필요
- 백엔드 애플리케이션 코드 수정 불필요
- 다양한 백엔드 기술 스택 지원 용이
로드 밸런싱과 통합 용이
- SSL Offloading과 로드 밸런싱을 동시에 처리
- 헬스 체크가 간단함

단점:

내부 네트워크 보안
- Nginx와 백엔드 사이의 트래픽이 평문으로 전송됨
- 같은 네트워크 내의 공격자가 트래픽을 가로챌 수 있음
- 해결책: 내부 네트워크를 격리하거나 VPN 사용
규제 준수 문제
- PCI DSS, HIPAA 등 특정 규정에서는 end-to-end 암호화를 요구할 수 있음
- 해결책: 규제 요구사항 확인 후 필요시 End-to-End SSL 사용

적합한 사용 사례:

신뢰할 수 있는 내부 네트워크 환경
클라우드 VPC 내부 통신
동일 데이터센터 내의 서버 간 통신
성능이 중요한 고트래픽 사이트
마이크로서비스 아키텍처 (서비스 메시 없이)

server {
    listen 443 ssl http2;
    server_name api.example.com;

    ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;
    include /etc/nginx/conf.d/ssl.conf;

    location / {
        proxy_pass http://localhost:3000;

        # 백엔드에 원본 정보 전달
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Port $server_port;
    }
}

2. End-to-End SSL (종단 간 암호화)

개념:
End-to-End SSL은 클라이언트부터 백엔드 서버까지 전 구간을 암호화하는 방식입니다. Nginx는 클라이언트의 SSL 연결을 종료하지만, 백엔드 서버와도 새로운 SSL 연결을 맺습니다.

통신 흐름:

클라이언트 ↔ Nginx (HTTPS) → 백엔드 서버 (HTTPS)

장점:

최고 수준의 보안
- 전 구간 암호화로 중간자 공격 방지
- 내부 네트워크가 침해되어도 트래픽 내용 보호
- Zero Trust 네트워크 모델에 적합
규제 준수
- PCI DSS, HIPAA, SOC 2 등 엄격한 보안 규정 충족
- 감사 추적(Audit Trail)에 유리
- 컴플라이언스 요구사항 만족
마이크로서비스 보안
- 서비스 간 통신도 암호화
- 서비스 메시(Service Mesh)와 통합 가능
- mTLS(mutual TLS)로 확장 가능

단점:

성능 오버헤드
- 이중 SSL 핸드셰이크로 지연 시간 증가
- Nginx와 백엔드 모두 암호화/복호화 처리
- CPU 사용량 증가 (특히 백엔드 서버)
복잡한 인증서 관리
- Nginx와 백엔드 모두 인증서 필요
- 백엔드 인증서는 자체 서명 또는 내부 CA 사용
- 인증서 갱신이 두 배로 필요
디버깅 어려움
- 암호화된 트래픽 분석이 어려움
- 문제 추적 시 복잡도 증가
- 로깅 및 모니터링이 제한적
설정 복잡성
- 백엔드 애플리케이션에 SSL 설정 필요
- 인증서 검증 설정 필요
- 잘못 설정 시 연결 실패 위험

적합한 사용 사례:

금융, 의료, 정부 시스템
규제 준수가 필수인 환경
신뢰할 수 없는 네트워크 환경 (예: 멀티 클라우드)
고도의 보안이 필요한 API
Zero Trust 아키텍처
내부 네트워크 격리가 불가능한 환경

server {
    listen 443 ssl http2;
    server_name api.example.com;

    ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;

    location / {
        proxy_pass https://backend-server:8443;

        # 백엔드 SSL 검증
        proxy_ssl_verify on;
        proxy_ssl_trusted_certificate /etc/ssl/certs/backend-ca.crt;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

트러블슈팅

SSL/TLS 설정 중 발생할 수 있는 일반적인 문제와 해결 방법을 소개합니다.

1. ERR_SSL_PROTOCOL_ERROR

증상

브라우저에서 “ERR_SSL_PROTOCOL_ERROR” 또는 “이 사이트에 안전하게 연결할 수 없습니다” 메시지가 표시됩니다.

원인

Nginx SSL 설정 오류
- 잘못된 SSL 인증서 경로
- 문법 오류가 있는 설정 파일
- 충돌하는 server 블록
포트 443이 차단됨
- 방화벽이 HTTPS 트래픽을 차단
- Nginx가 포트 443에서 리스닝하지 않음
- 다른 프로세스가 포트 443을 사용 중
SSL 프로토콜 불일치
- 오래된 TLS 버전만 지원
- 클라이언트와 서버 간 암호화 스위트 불일치

해결 방법

# 1. Nginx 설정 문법 검사
sudo nginx -t

# 2. 포트 443 사용 확인
sudo netstat -tlnp | grep :443
# 또는
sudo ss -tlnp | grep :443

# 3. 방화벽 설정 확인
sudo ufw status
sudo ufw allow 443/tcp

# iptables 사용 시
sudo iptables -L -n | grep 443
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# 4. Nginx 프로세스 확인
sudo systemctl status nginx

# 5. SSL 설정 확인
sudo nginx -T | grep -A 10 "ssl_certificate"

# 6. 에러 로그 확인
sudo tail -f /var/log/nginx/error.log

설정 예시:

server {
    listen 443 ssl http2;  # http2 빼먹지 않기
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # TLS 1.2 이상만 허용
    ssl_protocols TLSv1.2 TLSv1.3;
}

2. NET::ERR_CERT_AUTHORITY_INVALID

증상

브라우저에서 “인증서가 신뢰할 수 없습니다” 또는 “보안 인증서 오류” 경고가 표시됩니다.

원인

자체 서명 인증서 사용
- 브라우저가 인증 기관을 신뢰하지 않음
- 프로덕션 환경에서 개발용 인증서 사용
인증서 체인 누락
- 중간 인증서가 포함되지 않음
- cert.pem 대신 fullchain.pem을 사용해야 함
만료된 인증서
- 인증서 유효기간이 지남
- Let’s Encrypt 자동 갱신 실패
도메인 불일치
- 인증서가 다른 도메인용
- www 포함 여부 차이

해결 방법

# 1. 인증서 정보 확인
openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -text -noout

# 2. 만료일 확인
openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -noout -dates

# 3. 도메인 확인
openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -noout -subject -ext subjectAltName

# 4. 인증서 체인 확인
openssl s_client -connect example.com:443 -showcerts

설정 수정:

# ❌ 잘못된 설정
ssl_certificate /etc/letsencrypt/live/example.com/cert.pem;

# ✅ 올바른 설정 (체인 포함)
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

# 추가 설정 (OCSP Stapling)
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
ssl_stapling on;
ssl_stapling_verify on;

3. Mixed Content Warning

증상

HTTPS 사이트가 로드되지만, 브라우저 콘솔에 “Mixed Content” 경고가 표시되고 일부 리소스(이미지, CSS, JS)가 로드되지 않습니다.

원인

HTTPS 페이지에서 HTTP 프로토콜로 리소스(이미지, 스크립트, 스타일시트)를 로드하려고 시도합니다.

<!-- HTTPS 페이지에서 -->
<script src="http://example.com/script.js"></script>  <!-- ❌ Mixed Content -->
<img src="http://cdn.example.com/image.jpg">  <!-- ❌ Mixed Content -->

해결 방법

방법 1: Content Security Policy 헤더 (자동 업그레이드)

server {
    listen 443 ssl http2;
    server_name example.com;

    # HTTP 리소스를 자동으로 HTTPS로 업그레이드
    add_header Content-Security-Policy "upgrade-insecure-requests" always;
}

방법 2: HTML 코드 수정

<!-- 프로토콜 생략 (상대 프로토콜) -->
<script src="//example.com/script.js"></script>

<!-- 또는 HTTPS로 명시 -->
<script src="https://example.com/script.js"></script>

방법 3: 리버스 프록시로 외부 리소스 프록시

server {
    listen 443 ssl http2;
    server_name example.com;

    # 외부 HTTP 리소스를 프록시
    location /external/ {
        proxy_pass http://external-site.com/;
        proxy_set_header Host external-site.com;
    }
}

4. 인증서 갱신 실패

증상

Let’s Encrypt 인증서 자동 갱신이 실패하고, certbot renew 명령이 오류를 반환합니다.

원인

포트 80이 차단됨
- ACME HTTP-01 챌린지를 위해 포트 80 필요
- 방화벽이나 보안 그룹이 포트 80 차단
웹 루트 접근 불가
- .well-known/acme-challenge 경로 접근 불가
- Nginx 설정에서 해당 경로를 차단
도메인 DNS 문제
- DNS가 올바른 IP를 가리키지 않음
- DNS 전파 지연
Rate Limiting
- Let’s Encrypt의 발급 제한 초과
- 같은 도메인에 너무 많은 요청

해결 방법

# 1. 포트 80 확인 및 개방
sudo ufw allow 80/tcp

# 2. ACME 챌린지 경로 테스트
curl -I http://example.com/.well-known/acme-challenge/test

# 3. 수동 갱신 시도 (상세 로그)
sudo certbot renew --dry-run --verbose

# 4. 강제 갱신
sudo certbot renew --force-renewal

# 5. DNS 확인
dig example.com
nslookup example.com

# 6. Certbot 로그 확인
sudo tail -f /var/log/letsencrypt/letsencrypt.log

Nginx 설정 확인:

server {
    listen 80;
    server_name example.com;

    # ACME 챌린지 경로는 반드시 허용
    location ^~ /.well-known/acme-challenge/ {
        root /var/www/html;
        allow all;
    }

    # 나머지는 HTTPS로 리다이렉트
    location / {
        return 301 https://$server_name$request_uri;
    }
}

5. Too Many Redirects (무한 리다이렉트)

증상

브라우저에서 “ERR_TOO_MANY_REDIRECTS” 또는 “리다이렉트가 너무 많습니다” 오류가 발생합니다.

원인

리버스 프록시 리다이렉트 루프
- 로드 밸런서/CDN이 HTTPS를 HTTP로 변환
- Nginx가 HTTP를 감지하고 다시 HTTPS로 리다이렉트
- 무한 루프 발생
잘못된 리다이렉트 로직
- HTTP와 HTTPS server 블록이 서로를 리다이렉트

해결 방법

X-Forwarded-Proto 헤더 확인:

server {
    listen 80;
    server_name example.com;

    # X-Forwarded-Proto가 https면 리다이렉트 안 함
    if ($http_x_forwarded_proto = "https") {
        # 이미 HTTPS이므로 정상 처리
        # (실제로는 443 포트에서 처리되어야 하지만 예외 처리)
    }

    # HTTP인 경우에만 리다이렉트
    if ($http_x_forwarded_proto != "https") {
        return 301 https://$server_name$request_uri;
    }
}

CloudFlare/AWS ELB 사용 시:

server {
    listen 80;
    server_name example.com;

    # CloudFlare의 경우
    set $redirect 0;
    if ($http_cf_visitor ~* "https") {
        set $redirect 0;
    }
    if ($http_cf_visitor !~* "https") {
        set $redirect 1;
    }
    if ($redirect = 1) {
        return 301 https://$server_name$request_uri;
    }
}

더 간단한 해결책 (리버스 프록시 환경):

# 80 포트에서는 리다이렉트 로직 제거
server {
    listen 80;
    server_name example.com;

    # 로드 밸런서가 이미 HTTPS 처리
    # 추가 리다이렉트 불필요
    root /var/www/example.com;
    index index.html;
}

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    root /var/www/example.com;
    index index.html;
}

6. SSL Handshake Failed

증상

curl 또는 브라우저에서 “SSL handshake failed” 오류가 발생합니다.

원인

TLS 버전 불일치
암호화 스위트 불일치
SNI(Server Name Indication) 문제

해결 방법

# 1. SSL 연결 테스트
openssl s_client -connect example.com:443 -servername example.com

# 2. 특정 TLS 버전 테스트
openssl s_client -connect example.com:443 -tls1_2
openssl s_client -connect example.com:443 -tls1_3

# 3. 암호화 스위트 확인
nmap --script ssl-enum-ciphers -p 443 example.com

설정 개선:

server {
    listen 443 ssl http2;
    server_name example.com;

    # 최신 TLS만 허용
    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';
    ssl_prefer_server_ciphers off;

    # DH 파라미터 (2048비트 이상)
    ssl_dhparam /etc/nginx/dhparam.pem;
}

Docker 환경에서 SSL

docker-compose.yml

version: '3.8'

services:
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./conf.d:/etc/nginx/conf.d:ro
      - ./ssl:/etc/nginx/ssl:ro
      - /etc/letsencrypt:/etc/letsencrypt:ro
      - ./html:/usr/share/nginx/html:ro
    restart: unless-stopped

  certbot:
    image: certbot/certbot
    volumes:
      - /etc/letsencrypt:/etc/letsencrypt
      - ./html:/usr/share/nginx/html
    entrypoint: "/bin/sh -c 'trap exit TERM; while :; do certbot renew; sleep 12h & wait $${!}; done;'"

초기 인증서 발급

# Certbot 컨테이너로 인증서 발급
docker-compose run --rm certbot certonly --webroot \
  --webroot-path=/usr/share/nginx/html \
  -d example.com \
  -d www.example.com \
  --email admin@example.com \
  --agree-tos \
  --no-eff-email

성능 벤치마크

SSL/TLS 성능 테스트

# 초당 연결 수 테스트
openssl s_time -connect example.com:443 -www / -new -time 30

# Apache Bench로 HTTPS 부하 테스트
ab -n 1000 -c 100 https://example.com/

성능 비교

설정	TPS (Transactions Per Second)
HTTP (no SSL)	~5,000
HTTPS (TLS 1.2)	~3,500
HTTPS (TLS 1.3)	~4,200
HTTPS + 세션 재사용	~4,800

보안 체크리스트

TLS 1.2 이상만 사용
강력한 암호화 스위트 설정
HSTS 헤더 설정
OCSP Stapling 활성화
Perfect Forward Secrecy (PFS) 지원
인증서 자동 갱신 설정
보안 헤더 설정 (X-Frame-Options, CSP 등)
SSL Labs에서 A+ 등급 획득
HTTP에서 HTTPS로 리다이렉트
인증서 만료 모니터링

인증서 모니터링

만료 알림 스크립트

#!/bin/bash
# check-ssl-expiry.sh

DOMAIN="example.com"
DAYS_WARN=30

# 만료일 확인
EXPIRY_DATE=$(echo | openssl s_client -servername $DOMAIN -connect $DOMAIN:443 2>/dev/null | openssl x509 -noout -enddate | cut -d= -f2)

# 남은 일수 계산
EXPIRY_EPOCH=$(date -d "$EXPIRY_DATE" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( ($EXPIRY_EPOCH - $NOW_EPOCH) / 86400 ))

if [ $DAYS_LEFT -lt $DAYS_WARN ]; then
    echo "Warning: SSL certificate for $DOMAIN expires in $DAYS_LEFT days!"
    # 이메일 또는 Slack 알림 전송
fi

Cron으로 매일 실행:

0 9 * * * /path/to/check-ssl-expiry.sh

Infra

SSL/TLS란?

SSL/TLS의 작동 원리

왜 SSL/TLS가 필수인가?

1. 데이터 암호화 - 도청 방지

2. 서버 인증 - 피싱 방지

3. 데이터 무결성 - 변조 방지

4. SEO 및 검색 순위

5. 브라우저 요구사항 및 사용자 신뢰

6. 최신 웹 기능 활용

7. 규제 준수

SSL 인증서 종류

검증 수준별 분류

1. DV (Domain Validation) - 도메인 검증 인증서

2. OV (Organization Validation) - 조직 검증 인증서

3. EV (Extended Validation) - 확장 검증 인증서

도메인 범위별 분류

1. 단일 도메인 (Single Domain) 인증서

2. 와일드카드 (Wildcard) 인증서

3. 멀티 도메인 (SAN/UCC) 인증서

방법 1: Let’s Encrypt (무료)

Let’s Encrypt의 특징

Certbot 설치

Ubuntu/Debian

CentOS/RHEL 8

macOS

인증서 발급 (자동 설정)

자동 설정 과정에서 선택 사항

인증서 발급 (수동 설정)

Nginx 수동 설정

자동 갱신 설정

갱신 테스트

Cron 작업 추가 (자동 갱신)

와일드카드 인증서 발급

방법 2: 유료 인증서

1. 인증서 구매

2. CSR (Certificate Signing Request) 생성

3. CSR 제출 및 인증서 받기

4. 인증서 설치

5. Nginx 설정

방법 3: 자체 서명 인증서 (개발/테스트용)

인증서 생성

Nginx 설정

SSL 최적화 설정

1. Mozilla SSL Configuration Generator

2. 최신 보안 설정 (2025년 기준)

3. DH 파라미터 생성

4. 서버별 설정에서 include

HSTS (HTTP Strict Transport Security)

HSTS란?

HSTS의 작동 원리

HSTS가 해결하는 보안 문제

1. SSL Stripping 공격 방지

2. 중간자 공격 (Man-in-the-Middle) 방지

3. Mixed Content 문제 완화

HSTS 헤더 구성 요소

HSTS의 한계와 주의사항

첫 방문 취약점 (Trust-On-First-Use, TOFU)

Preload의 영구성

설정 단계

1단계: 테스트 설정 (짧은 기간)

2단계: 1주일 테스트

3단계: 1년 + 서브도메인 포함

4단계: Preload 리스트 등록

SSL 인증서 확인

인증서 정보 확인

서버 SSL 테스트

온라인 SSL 테스트 도구

멀티 도메인 SSL 설정

방법 1: 각 도메인별 인증서

방법 2: 와일드카드 인증서

리버스 프록시에서 SSL

1. SSL Termination (SSL 종료) - 권장 방식

2. End-to-End SSL (종단 간 암호화)

트러블슈팅

1. ERR_SSL_PROTOCOL_ERROR

증상

원인

해결 방법

2. NET::ERR_CERT_AUTHORITY_INVALID