SSL/TLS 인증서 이해

발행: (2026년 1월 15일 오후 02:47 GMT+9)
6 min read
원문: Dev.to

I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (excluding the source line you already provided) here? Once I have it, I’ll translate it into Korean while preserving the original formatting and markdown.

이름 게임: SSL vs TLS

SSL (Secure Sockets Layer)와 TLS (Transport Layer Security)는 종종 같은 의미로 사용되지만, SSL은 사실상 사라졌습니다. 1996년 이후로 업데이트되지 않았으며 보안 취약점이 많이 존재합니다. 오늘날 우리가 사용하는 모든 것은 실제로 TLS입니다.

왜 아직도 “SSL”이라는 말을 많이 듣는 걸까요? 사람들에게 처음 알려진 이름이었기 때문에 마케팅 상으로 업계가 계속 사용해 왔습니다. 오늘날 “SSL 인증서”를 구매하면 실제로는 TLS를 활성화하는 인증서를 얻는 것입니다.

TLS를 두 컴퓨터 사이의 보안 터널이라고 생각하면 됩니다. 웹사이트에서 Proceed to Payment을 클릭하면 TLS가 암호화된 터널을 만들어 결제 정보를 결제 처리업체(예: Visa 또는 Stripe)로 전송합니다. TLS가 없으면 누구든지 데이터를 가로채어 읽을 수 있습니다.

Certificate Authorities (CAs)

TLS 세계에서 인증서의 적법성을 검증하는 “이민 심사관”은 Certificate Authorities(인증 기관)이라고 부릅니다. 대표적인 CA는 다음과 같습니다:

  • Let’s Encrypt
  • Google Trust Services
  • Cloudflare
  • DigiCert
  • GoDaddy

개인 키와 CSR 생성

# Generate a private key
openssl genrsa -out private.key 2048

# Generate a CSR using the private key
openssl req -new -key private.key -out certificate.csr
  • private.key – 서버에 이 파일을 비밀로 보관하고 절대 공유하지 마세요.
  • certificate.csr – 이를 CA에 보내세요.

CSR 제출 및 검증

CSR을 인증 기관(Certificate Authority)에 제출합니다. 인증 기관은 다음을 확인합니다:

  • 이 회사가 정당한 기업인가?
  • 해당 도메인을 실제로 소유/관리하고 있는가?
  • 정보가 정확한가?

도메인 검증을 위해 인증 기관이 다음을 요청할 수 있습니다:

  • DNS 레코드 추가
  • 웹사이트에 특정 파일 업로드
  • 도메인으로 전송된 이메일에 응답

서명된 인증서 수신

검증이 완료되면, CA는 자체 암호 서명이 포함된 서명된 인증서를 반환합니다—여러분의 “도장이 찍힌 여권”과 같습니다.

certificate.crt   # Your signed certificate
ca-bundle.crt     # The CA's chain of trust

서버 구성

Nginx

server {
    listen 443 ssl;
    server_name yourdomain.com;

    ssl_certificate /path/to/certificate.crt;
    ssl_certificate_key /path/to/private.key;

    # Modern TLS configuration
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
}

Apache

ServerName yourdomain.com

SSLEngine on
SSLCertificateFile /path/to/certificate.crt
SSLCertificateKeyFile /path/to/private.key
SSLCertificateChainFile /path/to/ca-bundle.crt

TLS 핸드쉐이크 개요

  1. Client Hello – 브라우저가 “안전하게 연결하고 싶어요.” 라고 말합니다.
  2. Server Hello – 서버가 자신의 인증서(CA에 의해 서명된)를 응답합니다.
  3. Certificate Verification – 브라우저가 인증서가 신뢰할 수 있는 CA에 의해 서명되었는지 확인합니다.
  4. Key Exchange – 양측이 세션을 위한 암호화 키에 합의합니다.
  5. Encrypted Communication – 모든 데이터가 안전한 터널을 통해 전송됩니다.

예시 HTTPS 요청 (JavaScript)

fetch('https://api.example.com/payment', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    cardNumber: '4242424242424242',
    amount: 99.99
  })
});

TLS는 해당 요청 본문의 모든 내용을 자동으로 암호화합니다. TLS가 없으면 네트워크상의 누구든지 카드 번호를 읽을 수 있습니다.

TLS vs. 비 TLS

  • ❌ 평문으로 전송되는 비밀번호

  • ❌ 공격자에게 노출되는 신용카드

  • ❌ 세션 토큰이 도난당할 수 있음

  • ❌ 전송 중 데이터가 변조될 수 있음

  • ✅ 모든 것이 종단 간 암호화됨

  • ✅ 인증서는 CA에 의해 검증됨

  • ✅ 중간자 공격으로부터 보호됨

  • ✅ 브라우저에 표시되는 안심 자물쇠

Certbot 설치

# Install Certbot
sudo apt install certbot python3-certbot-nginx

# Get a certificate and auto‑configure Nginx
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

# Auto‑renewal is set up automatically (certificates are valid for 90 days)

그게 전부입니다. 이제 TLS가 설정되고 실행 중이며, 사용자는 안전한 터널을 통해 안전하게 탐색할 수 있습니다.

Back to Blog

관련 글

더 보기 »

[iOS] SSL 핸드쉐이크 실패 디버깅

문제: 예상치 못한 Configuration Conflict 최근에 우리 monitoring dashboard가 간헐적인 network error logs로 가득 차기 시작했습니다. 그것들은 당신이...