TLS에서의 인증서 검증

인증서 검증이 없다면 서버인 척하는 공격자와 TLS 연결이 수립될 수 있습니다(중간자 공격). 인증서 검증을 통해 개인 키를 보유한 정당한 서버와 통신하고 있음을 확인할 수 있습니다.

주요 필드는 다음과 같습니다. Subject(인증서 소유자), SubjectAltName(DNS 이름/IP 주소), Issuer(서명한 CA), Validity(notBefore/notAfter), 공개 키, Signature입니다. 브라우저는 이 모든 항목을 확인합니다.

서버 인증서 → 중간 CA 인증서 → 루트 CA 인증서의 순서입니다. 루트 CA는 자체 서명되며 OS/브라우저 신뢰 저장소에 사전 설치되어 있습니다. 서버는 TLS 핸드셰이크의 Certificate 메시지에서 자신의 인증서와 중간 인증서를 전송합니다.

각 인증서는 바로 위에 있는 발급자에 의해 서명됩니다. 클라이언트는 public_key(cert_{n+1})을 사용해 signature(cert_n)을 검증합니다. 서명 하나라도 유효하지 않으면 체인이 거부됩니다. 루트는 서명을 통해 신뢰되는 것이 아니라 사전 설치를 통해 신뢰됩니다.

클라이언트는 서버의 호스트 이름이 인증서의 Subject 또는 SubjectAltName(DNS 항목)과 일치하는지 확인합니다. 와일드카드(*.example.com)는 하나의 레이블과 일치합니다. 2000년 이후로는 호스트 이름 일치 여부를 확인할 때 SAN이 CN보다 우선합니다.

클라이언트는 체인의 모든 인증서에 대해 notBefore ≤ now ≤ notAfter인지 확인합니다. 서명이 유효하더라도 만료된 인증서는 거부됩니다. 인증서의 유효 기간은 계속 짧아져 현재 브라우저는 약 398일로 제한합니다.

CA는 폐기된 인증서의 일련 번호를 서명한 목록인 인증서 폐기 목록(CRL)을 게시합니다. 클라이언트는 인증서의 CRL 배포 지점 확장에 있는 CRL URL을 다운로드하고 해당 일련 번호가 포함되어 있는지 확인합니다.

온라인 인증서 상태 프로토콜(OCSP)을 사용하면 클라이언트가 CA의 OCSP 응답자에게 특정 인증서 하나의 상태를 조회할 수 있습니다. CRL보다 빠르지만 지연 시간이 추가됩니다. OCSP 스테이플링을 사용하면 서버가 TLS 핸드셰이크에 서명된 OCSP 응답을 포함합니다.

CT(RFC 6962)는 CA가 발급한 모든 인증서를 공개된 추가 전용 로그에 기록하도록 요구합니다. 브라우저는 인증서 또는 TLS 확장에 포함된 서명된 인증서 타임스탬프(SCT)를 확인합니다. 이를 통해 잘못 발급된 인증서가 발견되지 않은 채 남는 것을 방지합니다.

HTTP 공개 키 고정(HPKP, 폐기됨)과 모바일 앱의 인증서 고정은 특정 공개 키 또는 인증서 해시를 고정합니다. 서버가 다른 인증서를 제시하면 그 인증서가 유효하더라도 연결이 거부됩니다. 이를 통해 CA 손상 공격을 방지할 수 있습니다.

ERR_CERT_AUTHORITY_INVALID: 루트를 신뢰할 수 없습니다. ERR_CERT_DATE_INVALID: 인증서가 만료되었습니다. ERR_CERT_COMMON_NAME_INVALID: 호스트 이름이 일치하지 않습니다. NET::ERR_CERT_REVOKED: OCSP/CRL에서 폐기된 것으로 표시했습니다. 각 오류는 특정 검증 단계의 실패에 대응합니다.

OCSP 스테이플링은 어떤 문제를 해결합니까?

TLS의 인증서 검증에는 체인 검증, 서명 확인, 이름 일치 여부 확인, 유효 기간 확인 및 폐기 확인이 포함됩니다. 다음으로는 과거의 TLS 공격과 TLS 1.3이 이를 어떻게 완화하는지 살펴봅니다.