인증서 사용 사례

Transport Layer Security(TLS)

클라이언트가 서버에서 인증서를 받을 때 던져야 할 두 가지 질문

1. 이 인증서는 유효하고 신뢰할 수 있는가? 클라이언트는 인증서가 신뢰할 수 있는 인증 기관(CA)에서 발급되었고 만료되거나 해지되지 않았는지 검증해야 합니다. 여기에는 인증서의 유효 기간을 확인하고, 클라이언트가 신뢰하는 CA가 서명했는지 확인하는 일이 포함됩니다.
2. 이 인증서는 서버의 신원과 일치하는가? 클라이언트는 Common Name(CN)이나 Subject Alternative Name(SAN) 같은 인증서의 세부 정보가 서버의 도메인 이름과 일치하는지 확인해야 합니다. 이를 통해 그 인증서가 정말 클라이언트가 연결하려는 서버를 위한 것임을 확인할 수 있습니다.

클라이언트가 인증서의 신뢰성을 검증하는 방식

1. 인증서 신뢰 체인 확인: 클라이언트는 서버의 인증서, 모든 Intermediate 인증서, 루트 인증서로 이루어진 인증서 체인을 검증합니다. 체인의 각 인증서는 한 단계 위의 기관이 서명해야 하며, 최종적으로 신뢰할 수 있는 루트 인증서로 이어져야 합니다.
2. 인증서의 유효 기간 검증: 클라이언트는 인증서의 유효 기간을 확인하여 만료되었거나 아직 유효해지지 않았는지 살핍니다. 여기에는 인증서의 "Not Before"와 "Not After" 날짜를 확인하는 일이 포함됩니다.
3. 인증서와 서버 신원 대조: 클라이언트는 인증서의 Common Name(CN)이나 Subject Alternative Name(SAN)이 서버의 도메인 이름과 일치하는지 확인합니다. 이로써 인증서가 클라이언트가 연결하려는 서버를 위한 것임이 확인됩니다.
4. 해지 여부 확인: 클라이언트는 인증서 해지 목록(CRL)을 조회하거나 Online Certificate Status Protocol(OCSP)을 사용하여 인증서가 해지되었는지 확인합니다. 해지된 인증서는 더 이상 신뢰되지 않습니다.
5. 디지털 서명 검증: 클라이언트는 인증서의 디지털 서명을 검증하여 변조되지 않았음을 확인합니다. 여기에는 발급 CA의 공개 키로 암호학적 서명을 대조하는 일이 포함됩니다.

클라이언트가 서버를 인증서의 진짜 소유자로 검증하는 방식

1. 인증서 체인 검증: 클라이언트는 체인의 각 인증서가 신뢰할 수 있는 인증 기관(CA)의 서명을 받았는지 확인하며 인증서 체인을 검증합니다. 이 체인은 서버의 인증서에서 시작해 신뢰할 수 있는 루트 인증서에서 끝납니다.
2. 도메인 이름 대조: 클라이언트는 인증서의 Common Name(CN)이나 Subject Alternative Name(SAN)이 서버의 도메인 이름과 일치하는지 확인합니다. 이로써 인증서가 클라이언트가 연결하려는 서버를 위한 것임이 보장됩니다.
3. 디지털 서명 검증: 클라이언트는 발급 CA의 공개 키로 인증서의 디지털 서명을 검증합니다. 이로써 인증서가 변조되지 않았으며 실제로 신뢰할 수 있는 CA가 발급했음이 보장됩니다.
4. 인증서 유효 기간: 클라이언트는 인증서의 유효 기간을 확인하여 현재 유효하며 만료되지 않았는지 살핍니다.
5. 해지 상태 확인: 클라이언트는 인증서 해지 목록(CRL)을 조회하거나 Online Certificate Status Protocol(OCSP)을 사용하여 인증서가 해지되었는지 확인합니다. 해지된 인증서는 더 이상 신뢰되지 않습니다.

인증서의 신뢰성을 이미 확인했는데도 소유 여부가 중요한 이유

인증서의 유효성과 신뢰: 이 단계는 인증서가 신뢰할 수 있는 인증 기관(CA)에서 발급되었고, 유효 기간 안에 있으며, 해지되지 않았음을 확인합니다. 인증서가 정당하며 변조되지 않았음을 확인하는 것입니다.

서버 신원 확인: 인증서가 유효하고 신뢰할 수 있더라도, 그것이 지금 연결하려는 서버의 것인지도 확인해야 합니다. 여기에는 인증서의 Common Name(CN)이나 Subject Alternative Name(SAN)이 서버의 도메인 이름과 일치하는지 확인하는 일이 포함됩니다. 이 단계는 인증서가 바로 그 서버를 위한 것임을 보장하여, 공격자가 다른 도메인의 유효한 인증서를 제시하는 중간자 공격을 막아 줍니다.

클라이언트가 이 질문에 답하는 두 가지 방법과 각 방법에서 나오는 두 가지 결과

1. Domain Name System(DNS) 검증: 클라이언트는 인증서의 Common Name(CN)이나 Subject Alternative Name(SAN)이 서버의 도메인 이름과 일치하는지 확인합니다.
   결과:
   • 일치: 이름이 일치하면 클라이언트는 인증서가 해당 서버를 위한 것이라고 확신하고 연결을 이어 갈 수 있습니다.
   • 불일치: 이름이 일치하지 않으면 클라이언트는 대개 연결을 끊거나 보안 위험 가능성을 알리는 경고를 표시합니다.
2. 공개 키 기반 구조(PKI) 검증: 클라이언트는 발급 인증 기관(CA)의 공개 키로 인증서의 디지털 서명을 검증합니다.
   결과:
   • 유효한 서명: 서명이 유효하면 인증서가 변조되지 않았으며 신뢰할 수 있는 CA가 발급했음이 확인됩니다.
   • 유효하지 않은 서명: 서명이 유효하지 않으면 클라이언트는 연결을 끊거나, 인증서가 손상되었거나 위조되었을 수 있음을 알리는 경고를 표시합니다.

사용할 방법을 결정하는 요인

Domain Name System(DNS) 검증

• 사용 시점: 이 방법은 TLS 핸드셰이크의 일부로 언제나 사용됩니다. 클라이언트는 인증서의 Common Name(CN)이나 Subject Alternative Name(SAN)을 서버의 도메인 이름과 대조하여 일치하는지 확인합니다.
• 결정 요인: 이는 TLS 프로토콜의 표준 절차이며, 안전한 연결을 수립할 때 클라이언트가 자동으로 수행합니다.

공개 키 기반 구조(PKI) 검증

• 사용 시점: 이 방법도 TLS 핸드셰이크 중에 언제나 사용됩니다. 클라이언트는 발급 인증 기관(CA)의 공개 키로 인증서의 디지털 서명을 검증합니다.
• 결정 요인: 이 역시 TLS 프로토콜의 또 다른 표준 절차입니다. 클라이언트는 인증서가 유효하며 변조되지 않았는지 확인하기 위해 이 검사를 자동으로 수행합니다.

서버가 클라이언트에 보내야 할 인증서

TLS 핸드셰이크 중에 서버는 다음 인증서를 클라이언트에 보내야 합니다.

• 최종 개체 인증서: 서버 자신의 인증서로, 클라이언트에게 자신의 신원을 증명합니다.
• Intermediate 인증서: 최종 개체 인증서를 신뢰할 수 있는 루트 인증서에 연결하는 인증서입니다. 서버의 인증서에서 신뢰할 수 있는 루트 인증서까지 이어지는 신뢰 체인을 형성하는 데 쓰입니다.

Domain Validation 인증서와 Extended Validation 인증서

Domain Validation(DV) 인증서는 인증 기관(CA)이 신청자가 해당 도메인을 통제하고 있는지 확인하는 유형의 TLS 인증서입니다. 확인은 보통 다음과 같은 방법으로 이루어집니다.

• 도메인의 관리 연락처로 보낸 이메일에 회신하기.
• DNS TXT 레코드 추가하기.
• 웹 서버에 파일 업로드하기.

주요 특징

• 빠른 발급: 최소한의 검증만 필요하므로 대개 몇 분 안에 빠르게 발급할 수 있습니다.
• 기본적인 보안: 암호화를 제공하고, 인증서를 요청한 주체가 도메인을 통제하고 있다는 기본적인 보증을 제공합니다.
• 비용 효율: 흔히 더 저렴하거나 무료여서 소규모 웹 사이트와 개인 프로젝트에서도 쉽게 쓸 수 있습니다.

Extended Validation(EV) 인증서는 더 엄격한 검증 절차를 요구하는 상위 등급의 TLS 인증서입니다. CA는 인증서를 요청한 주체의 법적, 물리적, 운영상 실체를 확인합니다. 여기에는 다음이 포함됩니다.

• 해당 주체의 법적 신원과 지위 확인.
• 해당 주체의 물리적, 운영상 실재 확인.
• 해당 주체가 그 도메인을 사용할 배타적 권리를 가지고 있는지 확인.

주요 특징

• 높은 보증 수준: 철저한 심사를 거치므로 사용자에게 가장 높은 수준의 신뢰와 보증을 제공합니다.
• 눈에 보이는 표시: 일부 브라우저에서는 EV 인증서가 주소 표시줄에 조직 이름을 표시하곤 했으나, 지금은 흔하지 않습니다.
• 한층 높은 신뢰: 금융 기관이나 전자 상거래 사이트처럼 민감한 정보를 다루는 웹 사이트에 적합합니다.

안전성 비교

Extended Validation(EV) 인증서는 거치는 검증 절차가 엄격하기 때문에 일반적으로 Domain Validation(DV) 인증서보다 안전하다고 봅니다. 비교하면 다음과 같습니다.

Domain Validation(DV) 인증서

• 검증 수준: 도메인 통제 여부만 확인합니다.
• 보안: 기본적인 암호화와 보증을 제공합니다.
• 사용 사례: 개인 웹 사이트, 블로그, 소규모 사업체에 적합합니다.

Extended Validation(EV) 인증서

• 검증 수준: 해당 주체의 법적, 물리적, 운영상 실체를 확인합니다.
• 보안: 철저한 심사를 거치므로 더 높은 수준의 신뢰와 보증을 제공합니다.
• 사용 사례: 금융 기관, 전자 상거래 사이트를 비롯해 민감한 정보를 다루는 모든 웹 사이트에 적합합니다.

EV 인증서가 더 안전한 이유

• 철저한 심사: EV 인증서는 광범위한 검증을 요구하므로 악의적인 주체가 발급받기가 더 어렵습니다.
• 신뢰 표시: 지금은 흔하지 않지만, EV 인증서는 브라우저 주소 표시줄에 조직 이름을 표시하여 사용자에게 눈에 보이는 보증을 제공하곤 했습니다.
• 높은 보증 수준: 상세한 확인 절차를 통해 인증서 뒤에 있는 주체가 정당함을 보장하므로, 피싱을 비롯한 공격의 위험이 줄어듭니다.

OCSP Stapling을 사용한 해지 확인 절차

OCSP Stapling은 지연을 줄이고 프라이버시를 개선하여 표준 OCSP 절차를 보완합니다. 작동 방식은 다음과 같습니다.

1. 서버가 OCSP 응답을 요청: 웹 서버가 인증 기관(CA)이 운영하는 OCSP 응답자에게 자기 인증서의 해지 상태를 주기적으로 요청합니다. 이 요청은 클라이언트가 연결할 때마다가 아니라 백그라운드에서 이루어집니다.
2. OCSP 응답자가 응답을 제공: OCSP 응답자는 인증서의 상태, 예를 들어 "good", "revoked", "unknown"을 나타내는 서명되고 타임스탬프가 찍힌 OCSP 응답을 돌려보냅니다. 서버는 이 응답을 캐시에 저장합니다.
3. 응답을 첨부한 TLS 핸드셰이크: 웹 브라우저 같은 클라이언트가 서버에 연결을 시작하면, 서버는 캐시에 저장해 둔 OCSP 응답을 TLS 핸드셰이크에 포함합니다. 이를 핸드셰이크에 응답을 "스테이플링"한다고 합니다.
4. 클라이언트가 OCSP 응답을 검증: 클라이언트는 첨부된 OCSP 응답을 검증합니다. 응답은 CA가 서명했으므로 클라이언트는 그 유효성을 신뢰할 수 있습니다. 응답이 인증서가 해지되었음을 나타내면 클라이언트는 안전한 연결을 수립하지 않습니다.
5. 주기적인 갱신: 서버는 TLS 핸드셰이크에서 언제나 최신 상태를 제공할 수 있도록 캐시에 저장한 OCSP 응답을 계속 주기적으로 갱신합니다.

이 절차는 클라이언트가 별도로 OCSP 요청을 보낼 필요를 줄여 주므로 성능과 프라이버시가 개선됩니다.