인증서 및 키 매처

인증서, 개인 키, CSR의 어떤 조합이든 — PEM이든 DER이든 — 넣으면, 이 워크벤치는 어떤 키가 어떤 인증서와 맞는지 증명하고, 인증서를 체인으로 정렬하고, 형식을 변환하고, CSR을 생성합니다. 개인 키는 브라우저를 절대 떠나지 않습니다: 모든 것은 이 탭 안에서 로컬로 파싱되고, 키는 메모리에만 보관되며, 업로드, 기록, 저장되는 일이 절대 없고, 이 페이지는 네트워크 요청을 하지 않습니다. 인증서 하나를 깊이 디코딩하려면 SSL 인증서 파서를, 빠른 자체 서명 인증서가 필요하면 자체 서명 인증서 생성기를 사용하세요.

인증서, 키, CSR 추가

매칭 판정

인증서와 개인 키를 추가하면 판정이 여기에 표시됩니다: 어떤 키가 어떤 인증서와 맞는지 — 동일한 공개 키로 증명되며, 파일 이름으로 추측하는 일은 절대 없습니다.

체인 빌더

인증서가 두 개 이상 로드되면, 빌더는 발급자 이름과 주체 이름을 맞추어 리프를 먼저, 그다음 중간 인증서(들), 마지막으로 루트를 정렬합니다 — 그리고 브라우저의 암호화가 허용하는 곳에서는 이름에 의존하지 않고 각 링크의 실제 서명을 검증합니다.

CSR 생성

여기, 브라우저에서 생성되는 키를 위한 인증서 서명 요청: 주체를 입력하고, 키 유형을 선택하고, CSR을 다운로드하여 CA에 보내세요 — 그리고 개인 키도 함께 제공되니 직접 안전하게 보관해야 합니다. 키는 여기에만 표시됩니다; 이 페이지는 키를 보관하지 않습니다.

매칭은 실제로 어떻게 작동하나

인증서와 개인 키는 하나의 파일의 두 절반이 아닙니다; 하나의 수학적 객체를 공유하는 두 파일입니다. 키 쌍이 생성되면 공개 절반은 인증서 안에 (그리고 그 키로 만든 모든 CSR 안에) 들어가고, 개인 절반은 키 파일에 남습니다. 두 항목이 정확히 일치하는 경우는 같은 공개 키를 지니고 있을 때입니다 — RSA에서는 같은 모듈러스와 지수, EC에서는 같은 곡선 위의 같은 점입니다. 이 페이지는 그 공개 키를 표준 래퍼(SubjectPublicKeyInfo)로 인코딩하고, 인코딩에 SHA-256을 적용하여, 로드된 모든 항목을 그 해시로 그룹화합니다. 따라서 각 카드에 표시되는 해시는 요약이 아니라 증거입니다: 동일한 해시는 우연히 생길 수 없고, 불일치도 마찬가지로 확실하므로 판정을 단도직입적으로 말할 수 있습니다 — 이 키는 이 인증서와 맞거나, 로드된 키 중 맞는 것이 없습니다. 이 검사가 잡아내는 전형적인 장애는 키가 인증서와 맞지 않을 때에 적혀 있습니다: 새벽 2시의 재로드에서 디스크에 갱신된 인증서가 서버가 로드한 키와 다른 키에 속해 있던 경우입니다.

파일 이름은 아무것도 증명하지 못합니다. server.crt, server.key, final-v2.pem, 그리고 작년 갱신 시도의 CSR로 가득한 디렉터리는 물려받은 인프라의 정상적인 상태이며, 이름은 문서가 아니라 고고학입니다. 일치하는 파일 확장자나 일치하는 날짜도 아무것도 증명하지 못합니다. 그렇다면 전통적인 openssl 검사는 어떨까요 — 인증서의 모듈러스 해시와 키의 모듈러스 해시를 비교하는 것? 그것은 정확히 이 페이지의 검사이며, RSA로 제한되고 한 번에 한 쌍씩만 검사하며, EC 키에는 모듈러스가 없기 때문에 EC 키를 완전히 놓칩니다. 공개 키 지문은 모든 알고리즘을 균일하게 다루므로, 여기서 그룹화 키로 쓰입니다.

체인, 순서, 그리고 "검증됨"의 의미

서버는 리프 인증서를 먼저 제시하고, 그다음 각 중간 인증서를 순서대로 제시해야 합니다. 그래야 클라이언트가 발급자에서 주체로 이어지는 링크를 따라 이미 신뢰하는 루트까지 올라갈 수 있습니다. 같은 인증서를 잘못된 순서로 제시하거나 — 중간 인증서가 빠져 있으면 — 빠진 링크를 스스로 가져올 수 없는 클라이언트에서 전형적인 "unable to get local issuer certificate" 계열 오류가 발생합니다. 위의 빌더는 이름만으로 순서를 재구성하는데, 이는 항상 가능합니다. 그리고 한 걸음 더 나아갑니다: RSA와 ECDSA 서명에 대해서는 발급자의 공개 키를 임포트하고 인증서의 서명된 바이트에 대한 서명을 검사합니다. 서명 검증됨이라고 표시된 링크는 암호학적으로 증명된 것입니다. 이름 일치만이라고 표시된 링크는 그렇지 않습니다 — 이름은 이어지지만 서명은 이 플랫폼이 검사하지 않는 알고리즘(RSA-PSS가 일반적인 경우)을 사용하며, 페이지는 이름 일치를 증명으로 꾸미지 않고 그렇게 말합니다. 서명 검사가 실패하면, 이름은 우연이나 위조였으며, 빌더는 조용히 번들을 만드는 대신 실패를 빨간색으로 표시합니다.

형식: PEM, DER, 그리고 .pfx 문제

PEM은 레이블이 붙은 헤더로 DER 바이트를 Base64로 감싼 것이고, DER은 원시 인코딩입니다. 둘 사이의 변환은 아무것도 잃지 않고 아무것도 증명하지 않습니다 — 다른 봉투에 든 같은 객체입니다 — 그래서 모든 카드가 두 가지 다운로드를 모두 제공합니다. Windows와 일부 Java 도구는 DER이나 PKCS#12를 선호하고, 대부분의 Unix 도구는 PEM을 원합니다. PKCS#12(.pfx/.p12)는 다른 문제입니다: 자체 무결성 MAC을 가진 암호화된 컨테이너이며, 모든 소비자가 받아들이고 그 이름에 걸맞은 보호를 갖춘 것을 만드는 일은 웹 페이지에서 손으로 만들 일이 아닙니다. 이 도구는 의도적으로 그것을 제공하지 않습니다. 매칭된 쌍을 직접 패키징하려면 파일이 있는 곳에서 openssl을 실행하세요: openssl pkcs12 -export -inkey key.pem -in cert.pem -certfile chain.pem -out bundle.pfx — 이 페이지가 어떤 키, 인증서, 체인이 실제로 함께 속하는지 알려준 뒤에 말입니다.

파싱과 체인화는 이 사이트를 위해 손으로 작성한 DER 코드입니다(BSD 스타일, 타사 파서 없음); 해싱, 서명 검증, 키 생성은 브라우저의 WebCrypto를 사용합니다. 이 도구의 어떤 부분도 네트워크 요청을 하지 않습니다.

자주 묻는 질문

매처는 키와 인증서가 함께 속한다는 것을 어떻게 증명하나요?

파일이 아니라 공개 키를 비교함으로써입니다. 모든 인증서, CSR, 개인 키는 동일한 인코딩된 공개 키(SubjectPublicKeyInfo)를 산출합니다; 이 페이지는 그것에 SHA-256을 적용하고 해시가 일치하는 항목들을 그룹화합니다. 동일한 공개 키는 그 개인 키가 수학적으로 그 인증서가 발급된 바로 그 키라는 뜻입니다 — openssl이 모듈러스 비교로 수행하는 바로 그 검사를, 모든 파일에 대해 한 번에, 그리고 RSA뿐 아니라 EC 키에 대해서도 수행하는 것입니다.

실제 개인 키를 웹 페이지에 로드해도 안전한가요?

이 페이지에서는, 만들어진 방식 덕분에 안전합니다: 모든 것은 브라우저 안에서 로컬로 파싱되고, 키는 이 탭의 메모리에만 보관되며, 아무것도 업로드, 기록, 어떤 저장소에도 쓰이지 않고, 페이지는 네트워크 요청을 하지 않습니다. 지켜야 할 습관은 키를 붙여넣기 전에 어떤 도구에서든 그 주장을 확인하는 것 — 그리고 개인 키를 채팅, 티켓, 또는 원격으로 처리하는 서버 측 "검사기"에 절대 붙여넣지 않는 것입니다.

체인 빌더에서 "이름 일치만"은 무슨 뜻인가요?

체인 빌더는 각 인증서의 발급자 이름을 다음 인증서의 주체 이름과 맞추어 인증서를 정렬한 뒤, 발급자의 공개 키로 실제 서명을 검증하려고 시도합니다. 서명 알고리즘이 브라우저의 WebCrypto가 검사할 수 있는 것(실제로는 RSA와 ECDSA)인 경우, 링크는 "서명 검증됨"으로, 검사가 실패하면 "서명 실패"로 표시됩니다. 그 외의 모든 것 — RSA-PSS가 일반적인 경우입니다 — 은 정직하게 "이름 일치만"으로 표시됩니다: 이름은 맞물리지만, 이 페이지는 그 링크를 암호학적으로 증명하지 않았습니다.

PKCS#12(.pfx) 내보내기가 없는 이유는 무엇인가요?

PKCS#12 파일은 키와 인증서를 MAC 무결성을 갖춘 비밀번호 기반 암호화로 감쌉니다 — 신중하고 충분히 테스트된 인코딩이 필요한 형식입니다. 다른 소프트웨어가 거부할 수 있는 파일(또는 더 나쁘게는 약하게 보호된 키)을 만들 수 있는 손으로 만든 버전을 제공하기보다, 이 페이지는 PEM과 DER 사이에서 변환하고 .pfx 패키징은 openssl에 맡깁니다: 명령이 페이지에 표시되어 있어 키가 이미 있는 곳에서 실행할 수 있습니다.

이 페이지가 암호화된 개인 키를 읽을 수 있나요?

하나를 식별하고 그렇게 말할 수는 있지만, 사용할 수는 없습니다: 암호화된(비밀번호로 보호된) 키는 복호화되기 전까지 공개 키를 드러내지 않으며, 매칭은 공개 키로 이루어집니다. openssl로 로컬에서 사본을 복호화하고(pkcs8 -topk8 -nocrypt, 또는 rsa/ec) 복호화된 사본을 로드하세요 — 신뢰하는 컴퓨터에서 수행하고, 사본은 나중에 삭제하세요.