인증서 / PEM 디코더

이 도구가 하는 일

인증서는 붙임표 두 줄 사이의 Base64 덩어리로 도착하고, 보아서는 그것에 대해 아무것도 알 수 없습니다. 이 도구는 그것을 디코딩합니다: 누구에게 누가 발급했는지, 언제 만료되는지, 어느 호스트 이름을 덮는지, 어떤 종류의 키를 지니는지, 그리고 나르는 모든 확장입니다. 체인 전체를 붙여넣으면 각 인증서가 다음 것에 대해 확인됩니다.

전적으로 브라우저 안에서 돕니다. 여기서는 대부분의 도구보다 그것이 더 중요합니다 — 대안은 대개 운영 인증서를 남의 서버에 붙여넣거나 openssl 호출을 기억하는 것인데, 거의 아무도 하지 않습니다.

PEM은 포장일 뿐

붙임표와 Base64는 포장입니다. 안에는 DER, ASN.1이라 불리는 구조의 이진 인코딩이 있고, 붙임표 사이의 레이블이 어느 구조를 기대할지 말합니다:

CERTIFICATE           발급된 X.509 인증서
CERTIFICATE REQUEST   CSR: CA에 요청한 것
PUBLIC KEY            신원이 붙지 않은 맨 키
PRIVATE KEY           비밀 절반, 여기서 거부됨

같은 인증서가 붙임표도 Base64도 없이 .cer나 .crt 파일 안의 맨 DER로도 도착할 수 있습니다. 파일이 텍스트가 아니라 이진 잡음으로 열리면 그것이 그것입니다. 먼저 Base64로 만들거나 PEM으로 내보내세요.

인증서에 실제로 들어 있는 것

핵심 필드는 지금까지 발급된 모든 인증서에서 같습니다:

• 주체 — 인증서가 누구에 관한 것인지. 웹사이트에는 이제 대개 공통 이름뿐이고, 흔히 그 이상 아무것도 없습니다.
• 발급자 — 그것에 서명한 인증 기관. 그 주체 이름이 그것이 서명하는 모든 것의 발급자로 그대로 나타나고, 그것이 체인 확인을 가능하게 합니다.
• 유효 기간 — 두 절대 순간으로, 늘 UTC입니다. 이 도구는 둘 다 보이고 남은 기간을 브라우저 안에서 계산합니다. 이 페이지를 생성한 빌드 머신은 당신이 언제 읽는지 모르기 때문입니다.
• 일련번호 — 발급자마다 고유하고, 인증서가 폐기될 때 쓰이는 식별자입니다.
• 서명 알고리즘 — 발급자가 무엇으로 서명했는지, 예를 들어 SHA-256 with ECDSA입니다.
• 공개 키 — 종류와 크기. RSA에는 모듈러스의 비트 길이, EC에는 이름 붙은 곡선의 성질이라 P-256은 늘 256비트입니다.

사람이 기대하고 더는 찾지 못하는 필드 하나: 주체 공통 이름은 브라우저가 확인하는 것이 아닙니다. 호스트 이름 대조에서 여러 해 무시되어 왔습니다. 중요한 것은 아래의 주체 대체 이름 확장입니다.

작동할지를 정하는 확장

인증서는 얼마든지 확장을 나를 수 있습니다. 그중 다섯이 실제로 받아들여질지를 정하고, 이 도구는 그것들을 온전히 디코딩합니다:

• 주체 대체 이름 — 인증서가 유효한 호스트 이름, IP 주소, 이메일 주소. 이것이 브라우저가 확인하는 필드이고, SAN이 당신이 입력한 이름을 나열하지 않는 인증서는 그 밖의 모든 것이 아무리 옳아도 거부됩니다.
• 기본 제약 — 이것이 인증 기관인지, 그리고 그 아래에 몇 개의 중간 인증서가 앉을 수 있는지. CA로 표시된 말단 인증서, 또는 그 반대는 체인을 깨뜨립니다.
• 키 용도 — 키가 대체 무엇에 쓰일 수 있는지: 서명, 키 암호화, 인증서 서명. 거의 늘 크리티컬로 표시되고, 이는 소프트웨어가 이해하지 못하는 용도를 무시하는 대신 인증서를 거부해야 함을 뜻합니다.
• 확장 키 용도 — 목적: TLS 서버, TLS 클라이언트, 코드 서명, 이메일. TLS 서버 인증이 없는 인증서는 웹사이트를 서비스하지 못하고, 이는 다른 것을 위해 발급된 인증서에서 흔한 놀람입니다.
• 주체와 기관 키 식별자 — 여럿이 이름을 공유할 때 소프트웨어가 인증서를 그 발급자에 빠르게 맞추게 하는 짧은 해시.

그 밖의 모든 확장은 아는 이름이 있으면 그 이름, OID, 그리고 크리티컬로 표시됐는지와 함께 나열됩니다. 아무것도 조용히 떨궈지지 않습니다: 이 도구가 디코딩하지 않는 확장도 나타나므로 그것이 거기 있음을 볼 수 있습니다.

체인, 그리고 여기서 "이어짐"의 뜻

서버는 거의 결코 인증서 하나를 보내지 않습니다. 자신의 것에 더해 클라이언트가 이미 신뢰하는 루트에 닿는 데 필요한 중간 인증서를 보냅니다. 순서가 중요하고 파일은 대개 fullchain.pem이라 불립니다:

블록 1   말단      주체: example.com     발급자: Example CA R3
블록 2   중간      주체: Example CA R3   발급자: Example Root
블록 3   루트      흔히 생략됨, 클라이언트가 이미 가지므로

각 인증서는 발급자를 이름 붙이고, 그 아래 다음 인증서는 바로 그 이름을 주체로 가져야 합니다. 이 도구는 그 두 이름을 바이트마다 비교해 맞는지 말합니다. 그것이 오프라인에서 확인할 수 있는 유일한 관계이고, 대부분의 체인 문제를 차지하는 두 실패를 잡습니다: 빠진 중간 인증서와, 잘못된 순서로 붙여넣은 블록입니다.

그 실패에는 특징적인 증상이 있습니다. 데스크톱 브라우저는 흔히 빠진 중간 인증서를 스스로 가져와 덮어 가리므로, 사이트가 노트북에서는 괜찮아 보이고 전화, 모바일 앱, curl에서는 실패합니다. 그것이 당신이 디버깅하는 것을 말한다면, 먼저 전체 체인을 여기 붙여넣으세요.

이 도구가 말해 주지 않는 것

서명을 검증하지 않고, 할 수 없습니다. 인증서가 정말 발급자에게 서명됐는지 확인하려면 발급자의 공개 키가 필요하고, 그 발급자를 믿어야 할지 정하려면 신뢰 저장소가 필요합니다. 붙여넣은 파일은 어느 것도 공급하지 않습니다. 폐기도 확인할 수 없는데, 그것은 CA로의 네트워크 요청이 필요합니다.

그래서 여기서 "체인이 이어져 있다"는 이름이 맞음을 뜻하지 체인이 유효함이 아닙니다. 위조된 인증서의 체인도 완벽히 이어질 것입니다. 이 확인이 좋은 것은 자신의 설정에서 구조적 실수를 찾는 것이고, 그것이 사람이 체인을 디코더에 붙여넣을 때 실제로 보는 것입니다.

지문, 그리고 개인 키

SHA-256 지문은 인증서 전체의 해시이고, 누군가 당신에게 인용한 값이나 핀과 비교하는 것입니다. 그것이 무엇을 식별하는지에 유의하세요: 그 안의 키가 아니라 인증서입니다. 같은 키로 인증서를 갱신하면 다른 지문이 나오고, 그것이 갱신에서 핀이 깨지는 흔한 이유입니다. SHA-1 지문도 보이는데 오래된 도구와 콘솔이 아직 표시하기 때문입니다 — 식별을 위해서만입니다. SHA-1에 무언가에 서명할 일은 없습니다.

개인 키는 인식되어 거부됩니다. 여기 붙여넣은 것은 브라우저를 떠나지 않으므로 거부는 이 페이지에 관한 것이 아닙니다: 개인 키를 웹 폼에 붙여넣는 것은 들이지 않는 편이 좋은 습관이고, 다음에 청하는 사이트는 로컬에서 돌지 않을 수 있다는 것입니다. 키와 인증서가 짝인지 확인해야 한다면, 인증서에서 나온 공개 키를 키에서 이끌어 낸 것과 로컬에서 비교하세요.