1편에 이어서 작성

---

✨인증서 관리와 운영

🔸인증서 발급 절차와 종류

1️⃣ 클라이언트가 공개키와 개인키로 구성된 Key Pair 생성
2️⃣ 개인키는 로컬 안전한 저장소에 보관
3️⃣ 공개키와 사이트 식별 정보를 포함한 CSR 생성
4️⃣ CSR을 인증 기관인 CA에 제출
5️⃣ CA가 제출된 정보를 검증 후 공개키와 사이트 정보를 포함한 X.509 인증서를 CA의 비공개키로 서명하여 발급
6️⃣ 발급된 인증서를 클라이언트가 수신 및 사용

발급 방식

• Domain Validation [DV]
  • 도메인 소유권만 확인 함(WHOIS 정보, DNS TXT 레코드, HTTP 파일 인증 등)
  • 수 분~수 시간 내 발급 가능, 비용은 무료 또는 저렴함
  • 조직 신원 보장은 불가능함 (피싱 사이트 악용 가능성이 존재하기 때문)
• Organization Validation [OV]
  • 도메인 소유권 + 조직 실체(사업자 등록, 전화 및 주소 확인) 검증
  • 브라우저 인증서 세부 정보에 조직명 확인 가능
  • 발급 소요: 1~3일
• Extended Validation [EV]
  • OV 검즘 + 법적 실체, 경영권, 물리적 주소 심층 확인
  • 과거 주소창에 회사명 표시됨(최근 크롬/엣지에서 시각 표시 축소)
  • 금융 및 결제 서비스에서 주로 사용됨

CSR(Certificate Signing Request) 생성

CSR은 SSL/TLS 인증서를 발급받기 위해 서버가 생성하는 요청 데이터로 서버의 공개키와 식별 정보를 포함하며 이를 CA에 제출하면 CA는 해당 정보를 검증 후 인증서를 발급함

CSR 생성 시 개인키는 서버 외부로 전송 금지

1. 서버에서 키 페어 생성
   • ex: RSA 2048 bit 이상 또는 ECC P-256 이상
2. 개인키 기반 CSR 생성
   • CN, SAN, 조직명, 위치정보, 해시 알고리즘 포함
   • ex: openssl req -new -key server.key -out server.csr
3. CSR을 CA에 제출, CA는 DV/OV/EV 검증 절차 후 인증서 발급

🔸CA 역할과 신뢰체계

CACertificate Authority는 디지털 인증서 발급과 신뢰 원천 역할을 하는 기관으로 네트워크 상에서 서버와 사용자의 신원을 검증하고 발급한 인증서가 변조되지 않았음을 보장함

CA는 신청자가 제출한 CSR의 정보와 도메인 소유권 등을 검증한 뒤, 자신의 비공개 키로 서명하여 인증서를 발급함

또한 발급된 인증서의 유효성을 유지·폐기 관리하며, 이를 위해 CRL(Certificate Revocation List)과 OCSP(Online Certificate Status Protocol)로 실시간 검증 서비스를 제공함

공인CA vs 사설CA

• 공인 CA
  : 브라우저/OS 신뢰 저장소에 Root CA 인증서 사전 탑재
  • ex: DigiCert, Sectigo, GlobalSign
  • 전 세계 사용자 대상 서비스에 필수
• 사설 CA
  : 내부망 전용으로 Root 인증서 신뢰 등록d
  • ex: 조직 내부 VPN, 내부 API 통신
  • 외부 접속 시 클라이언트 단 설치 및 배포 필요

Validation

Root CA의 공개키를 사전에 저장하고 인증서 체인 검증의 시작점임 또한 인증서 발급 유효성 검증의 기준 역할을 함

🔸인증서 갱신·폐지 방식

CRL (Certificate Revocation List)

인증서 폐기 목록으로 현재 사용중인 인증서가 만료된 것인지 정상적으로 사용할 수 있는 것인지를 확인하는 신뢰가능한 목록

CA가 폐지된 인증서의 일련번호를 모아 주기적으로 배포함

• CRL의 동작
  1. HTTP, LDAP를 이용해서 인증서를 통해서 받은 URL을 통해 CRL을 요청함
  2. CA를 요청 받은 후에 CRL List를 보내주게 됨
  3. 브라우저에서 CRL 정보를 피싱하고 현재 인증서가 CRL에 포함되어있는지 확인
     
     
• 장점: 네트워크 연결이 불안정한 환경에서도 검증 가능
• 단점: 파일의 크기가 커져 전송이 지연되며 폐지 후 반영까지 시간차가 발생함

OCSP (Online Certificate Status Protocol)

클라이언트가 CA OCSP 서버에 실시간 요청하여 특정 인증서 상태를 확인하는 Protocol

CRL과 달리 불필요한 목록을 받을 필요가 없기 때문에 속도가 빠름

• 요청 시 응답

  • 일반적인 경우 : good,revoked,inknown
  • 유효하지 못한 경우 : error code

• OCSP Stapling: 웹사이트에 과부하를 방지하기 위해 서버가 미리 받아와 OCSP 응답을 SSL/TLS Handshake에 포함하여 응답 지연 및 프라이버시 문제를 완화 함

폐지 사유

• 개인키 유출
• 인증서 정보 변경(도메인, 조직명 등)
• CA 검증 오류 또는 발급 취소
• 계약 종료 및 서비스 폐기

🔸자동화 발급

자동화 시 만료로 인한 서비스 중단을 방지할 수 있고 인적 실수를 최소화 할 수 있음
단, 보안적으로 자동화 스크립트의 키 파일 접근 권한을 제한하고, ACME API 토큰의 유출 방지와 발급 속도 제한을 관리해야함

ACME Protocol

RFC 8555 표준으로 CA와 클라이언트 간 인증서 발급 및 갱신 절차를 자동화함

• 인증 방법
  • HTTP-01 : 웹 서버 경로에 토큰 파일 배치
  • DNS-01 : 특정 TXT 레코드 생성
    
    
• 장점 : 발급·갱신 자동화, 운영 부담 감소
  
  
• 고려사항
  • ACME 클라이언트 인증서·키 파일 권한 관리
  • DNS 인증 시 API 키 보안

Let's Encrypt 사례

무료 DV 인증서를 발급하며 90일의 유효 기간을 가지고 대표 클라이언트로는 Certbot이 존재함

cerbtot certonly --standalone -d example.com
certbot renew --quiet

---

✨SSL/TLS 버전과 암호 Sutie

🔸SSL-TLS까지의 변화

• SSL 2.0, 3.0 폐기
  : 설계 상 취약점 존재

  • 메시지 위조, 암호화 취약 등

• TLS 1.0, 1.1 Deprecation
  : SHA-1, CBC 기반 취약점, PCI 등 규제에서 비권장

• TLS 1.2 주요 개선점
  : AEAD 모드 지원, CBC 취약점 대응, 선택적 Forward Secrecy 지원

• TLS 1.3 주요 개선점
  : 불필요한 알고리즘 제거, 핸드셰이크 간소화, 기본 Forward Secrecy 적용

🔸각 버전의 특징

버전	특징	주요 개선점
TLS 1.2	기존 CBC 모드와 RSA 키 교환 지원	AEAD, SHA-2 계열 MAC, 선택적 Forward Secrecy
TLS 1.3	핸드셰이크 단순화, 암호 스위트 축소	불필요한 알고리즘 제거, 기본 Forward Secrecy, 0-RTT 가능

🔸암호 Suite 구조와 선택 기준

Cipher Suite란
: 연결에서 사용될 암호화 알고리즘과 인증/무결성 방법을 지정하는 조합

[TLS Cipher Suite예시]

구성 요소

• 키 교환 알고리즘 [Key Exchange]
  : 세션 키 안전 공유
  ex ) RSA, DH, ECDH
  
  
• 인증 알고리즘 [Authentication]
  : 서버/클라이언트 신원 검증
  ex ) RSA, ECDSA
  
  
• 대칭 키 암호 [Symmetric Encyption]
  : 데이터 전송 암호화
  ex ) AES, ChaCha20, 3DES
  
  
• 메시지 인증 코드 [MAC] / 해시 [Hash]
  : 데이터 변조 확인
  ex ) SHA256, SHA384
  
  
• 옵션: AEAD 알고리즘
  : 암호화와 무결성 동시 처리
  ex ) AES-GCM, ChaCha20-Poly1305

선택 기준 및 주의 사항

• 보안성
  : RC4, 3DES, MD5, SHA-1 같은 취약 알고리즘은 제외하고, AES-128 이상과 SHA-256 이상 같은 안전하고 알고리즘 사용

• Forward Secrecy 지원
  : ECDHE/DHE 기반 키 교환으로 세션 키가 노출되더라고 예전 세션 보호해야 함

• 성능과 호환성
  : 서버·클라이언트 환경 고려하고, 모바일·IoT 환경에서는 ChaCha20-Poly1305와 같은 경량 암호가 적합함 또한 TLS 버전 및 클라이언트 지원 확인

• 최신 버전 사용 권장
  : TLS 1.2 이상을 사용하고, 가능하면 TLS 1.3

• 호환성 테스트 필수
  : 주요 브라우저·OS 환경에서 정상 동작 여부를 검증해야함

---

✨보안 위협과 대응 방안

🔸공격 사례

• POODLE
  SSL 3.0의 패딩 취약점을 이용해 암호문 일부를 평문으로 복원하는 공격
  SSL 3.0은 사용 중단 권고됨

• BEAST
  TLS 1.0 CBC 모드 취약점을 악용하여 세션 쿠키 같은 민감 데이터를 탈취하는 공격
  TLS 1.1 이상에서 개선됨

• Heartbleed
  OpenSSL Heartbeat 확장 구현 버그로 인해 메모리 정보가 노출되는 취약점
  비밀키, 세션 토큰 등이 유출될 수 있어 즉시 패치가 필요함

• DROWN
  SSLv2를 지원하는 서버를 대상으로 TLS 연결까지 복호화할 수 있는 공격
  SSLv2 완전 차단이 필요함

• Logjam
  Diffie-Hellman 키 교환 시 약한 512비트 파라미터를 강제로 사용하게 하여 세션 키를 복호화하는 공격
  강력한 DH 그룹(2048비트 이상)을 사용해야 함

🔹 원인 : 프로토콜 설계 결함, 구현 취약점, 구식 암호 사용.
🔹 영향 : 세션 탈취, 민감 정보 유출, 암호화 통신 무력화.

🔸취약 암호 Sutie

주요 브라우저와 TLS 표준에서 이미 폐기(Deprecation)되었으며, 최신 환경에서는 사용 불가능함

• RC4
  : 편향된 출력으로 인해 평문 일부 예측 가능. 대부분의 브라우저에서 비활성화됨

• 3DES
  : 짧은 블록 길이(64비트)로 인한 Sweet32 공격 가능성. 단계적 폐기 진행 중

• NULL cipher
  : 암호화를 수행하지 않는 Suite로, 데이터가 평문 그대로 노출됨

• Deprecation 현황
  : 주요 브라우저와 표준 단체에서 RC4, SSL 3.0, TLS 1.0/1.1, 3DES 등을 더 이상 지원하지 않음

🔸잘못된 인증서 검증

• CN/SAN 불일치
  : 서버 인증서의 Common Name 또는 Subject Alternative Name이 접속하려는 도메인과 다르면 신뢰할 수 없음
  Common Name (CN) : 인증서 주체 필드에 있는 대표 도메인 이름
  Subject Alternative Name (SAN) : 여러 도메인·서브도메인·IP를 동시에 지정할 수 있는 인증서 확장 필드
  

• Self-signed 인증서
  : 공인 CA가 서명하지 않은 인증서로, 중간자 공격(MITM)에 취약함

• 영향
  : 브라우저 경고를 무시하고 접속할 경우, 공격자가 위조 인증서로 세션을 탈취하거나 암호화된 통신을 가로챌 수 있음

올바른 CA 서명 인증서 사용하고, CN과 SAN 정보 정확히 설정해야하며 만료·폐기 관리 철저히 해야함