X.509 인증서

이 형식은 오래되었고 그 점이 드러납니다. X.509는 디렉터리 표준의 일부로 1988년에 등장했으며, 여전히 사용되는 인터넷 프로파일인 RFC 5280은 2008년 5월에 제정되었습니다. 인증서는 발급자가 서명한 구조화된 기록이지 비밀이 아니므로 외부에 건네도 안전합니다. 그것이 증명하는 범위는 좁습니다. 누군가가 자신이 어떤 이름을 통제한다고 인증 기관을 설득했다는 것뿐입니다.

작동 방식

인증서는 필드의 목록과 그 모든 필드를 포괄하는 서명으로 이루어집니다.

독자에게 중요한 필드는 몇 개 되지 않습니다. 일련번호는 발급자에게 해당 인증서를 식별시킵니다. 발급자 필드는 누가 서명했는지를, 주체 필드는 누구에 관한 것인지를 나타내며, 두 개의 타임스탬프가 인증서가 유효한 기간을 표시합니다. 주체 공개 키 정보 블록에는 키 자체가 담깁니다. 나머지는 확장 필드가 담당하며, 그중 하나가 대부분의 역할을 합니다. subjectAltName은 인증서가 포괄하는 도메인 이름을 나열합니다.

일반 이름(common name) 필드는 전형적인 함정입니다. 도메인이 저장되는 곳처럼 보이고 수년간 실제로 그랬지만, RFC 6125는 2011년 3월에 이를 읽는 것을 사용 중단 대상으로 지정했으며 브라우저는 이제 이를 무시합니다. subjectAltName에 방문 중인 사이트가 나열되지 않은 인증서는 일반 이름이 무엇을 말하든 검증에 실패합니다.

유효 기간은 지난 10년간 급격히 짧아졌습니다. 2020년 9월 1일부터 발급되는 공개적으로 신뢰되는 TLS 인증서는 유효 기간이 398일을 넘을 수 없으며, 이는 이전의 3년, 그다음 2년에서 줄어든 것입니다. Let's Encrypt는 갱신이 자동화되어 있으므로 90일짜리 인증서를 당연하게 발급합니다. 짧은 유효 기간은 폐기(revocation)를 대신하는 수단이며, 폐기는 지금까지 신뢰성 있게 작동한 적이 없습니다.

누구나 하나를 만들 수 있습니다. 자신의 키로 인증서에 서명하면 발급자와 주체가 동일한 자체 서명 인증서가 만들어지며, 이는 어떤 신뢰 저장소도 인식하지 못하는 완벽하게 유효한 파일입니다. 인증서를 신뢰할 수 있게 만드는 것은 서명이 아니라 서명자의 신원입니다.

어디에서 볼 수 있는가

어떤 브라우저에서든 자물쇠를 클릭하면 X.509 인증서를 보게 됩니다.

같은 파일 형식은 소프트웨어가 어떤 것이 특정 공급업체에서 왔는지 확인해야 하는 곳이면 어디든 나타납니다. 서명된 애플리케이션 바이너리, 서명된 펌웨어 업데이트, 그리고 일부 하드웨어 지갑이 탑재하여 공급업체의 앱이 정품 기기와 복제품을 구별할 수 있게 하는 증명(attestation) 인증서가 그 예입니다. BIP70은 인증서를 비트코인 결제 요청에 직접 내장했으며, 이 형식이 비트코인 프로토콜의 일부가 된 유일한 사례입니다.

여기서 구매자를 보호하는 두 가지 습관이 있습니다. 자금을 보관하는 사이트에서 인증서 경고를 절대 무시하고 넘어가지 마십시오. 브라우저는 이름과 키가 일치하지 않는다고 알리는 것이며, 거래소 도메인에서 그것이 무해한 경우란 없습니다. 그리고 사기 사이트에서 유효한 인증서가 있는 것은 모순이 아니라 정상이라는 점을 기억하십시오. 검증은 이름을 대상으로 하므로, 이름이 실제 이름과 거의 비슷하기만 하면 인증서는 제 역할을 다하는 동안 사용자는 자금을 잃게 됩니다.

X.509 인증서 vs 리프 인증서

X.509는 형식이고, 리프(leaf)는 위치를 설명합니다. 체인의 모든 인증서는 중간 인증서와 자체 서명 루트를 포함해 X.509 인증서이며, 그중 하나를 리프라고 부르는 것은 그것이 추가 발급을 승인하지 않고 실제 서버를 식별하며 체인의 끝에 있다는 것만을 말합니다. 차이는 확장 필드 하나에서 드러납니다. basicConstraints가 자신을 인증 기관으로 표시한 인증서는 다른 인증서에 서명할 수 있지만 리프 인증서는 그럴 수 없습니다.