본문으로 건너뛰기
AZ Tools

CSR 디코더 (PKCS#10)

PKCS#10 인증서 서명 요청을 브라우저에서 해독해, 지금 인증기관에 보내려는 것이 실제로 무엇인지 보여 줍니다. 식별명 형태의 주체, 주체 대체 이름(SAN), 공개키 알고리즘과 길이, 서명 알고리즘, 챌린지 패스워드, 그리고 CA에 포함해 달라고 요청하는 확장을 표시합니다. 요청 자신의 서명도 검증합니다. CSR은 안에 든 공개키와 짝을 이루는 개인키로 자체 서명되며, 그것이 바로 보낸 사람이 그 키를 갖고 있음을 CA에 증명하는 방식입니다. 그래서 요청 하나만으로 검증이 가능하고, 실패한다면 서명 이후에 바이트가 변경되었거나 키가 맞지 않는다는 뜻입니다. 가장 값진 경고는 주체 대체 이름에 관한 것입니다. 브라우저는 2017년에 호스트명 대조에서 Common Name을 더 이상 인정하지 않게 되었습니다. 따라서 호스트를 CN에만 적은 CSR은 최신 클라이언트 전부에서 실패하는 인증서를 만들어 내는데, 이 실수는 인증서를 설치하기 전까지 보이지 않습니다. 이 도구는 SAN이 아예 없는 요청은 물론, CN은 있는데 SAN 목록에 빠져 있어 의도와 다른 호스트명 집합을 담게 되는 미묘한 경우까지 표시합니다. 2048비트 미만 RSA와 SHA-1 서명도 표시합니다. 지금은 모든 공개 CA가 거부하기 때문입니다. 실수로 개인키를 붙여 넣으면 처리를 거부합니다. 업로드되지 않습니다.

사용법

  1. CSR을 붙여 넣거나 .csr, .pem 파일을 상자에 끌어다 놓습니다. -----BEGIN CERTIFICATE REQUEST----- 로 시작합니다.
  2. SAN 목록을 먼저 확인하십시오. 인증서가 담당해야 할 모든 호스트명이 거기에 있어야 하며, Common Name에 적은 것도 포함입니다.
  3. 자체 서명이 검증되는지 확인하십시오. 검증되지 않으면 보내지 말고 요청을 다시 만드십시오.
  4. 키 길이와 서명 알고리즘을 읽으십시오. 공개 CA는 최소 2048비트 RSA(또는 임의의 EC 곡선)와 SHA-256 이상의 서명을 요구합니다.
  5. 노란색 항목은 제출 전에 해결하십시오. CA에 거부당하면 보통 몇 시간을 왕복하게 됩니다.

자주 묻는 질문

Common Name이 있는데 왜 SAN이 또 필요합니까?
클라이언트가 Common Name을 더 이상 보지 않기 때문입니다. RFC 2818은 2000년에 호스트명 대조에 CN을 쓰는 것을 폐기 예정으로 지정했고, 크롬은 2017년 58 버전에서 지원을 끊었으며 다른 브라우저도 뒤따랐습니다. 지금은 CA/Browser Forum 기본 요구사항이 CA로 하여금 모든 이름을 subjectAltName 확장에 넣도록 의무화합니다. 호스트명이 CN에만 있는 CSR은 CA에 거부되거나, 모든 최신 브라우저가 ERR_CERT_COMMON_NAME_INVALID로 거절하는 인증서를 만들어 냅니다. 그런데도 도구들은 여전히 CN을 보여 주기 때문에 이 실수를 놓치기 쉽습니다.
CSR의 자체 서명은 무엇을 증명합니까?
요청을 만든 쪽이 안에 든 공개키에 대응하는 개인키를 갖고 있다는 사실입니다. 요청은 그 키로 자기 내용에 대해 서명되므로, CA는 요청 하나만으로 검증할 수 있습니다. 누군가 당신의 공개키를 담은 CSR을 제출해 당신 이름의 인증서를 받아 가는 일을 막는 장치가 바로 이것입니다. 도메인 소유권은 증명하지 않으며, 그건 CA가 따로 확인합니다. 서명이 검증되지 않는다면 서명 이후에 파일이 변경된 것이고, 대개 전송 중 손상되었거나 손으로 편집한 경우입니다.
여기에 CSR을 붙여 넣어도 안전합니까?
안전합니다. CSR에는 공개 정보만 들어 있습니다. 요청하는 이름들과 키 쌍의 공개 쪽뿐이고, 어차피 CA에 건네주려고 만든 것입니다. 그래도 이 페이지는 어디로도 보내지 않습니다. ASN.1 파싱과 서명 검증 모두 WebCrypto로 브라우저 안에서 실행되며, 페이지를 연 다음 네트워크를 끊고 요청을 붙여 넣어 확인할 수 있습니다. 개인키는 완전히 다른 이야기입니다. 어디에도 붙여 넣지 마십시오. 여기에 넣으면 도구가 거부합니다.
서명이 확인되지 않는 경우는 왜 생깁니까?
검증하려면 브라우저가 공개키를 가져올 수 있어야 하는데, WebCrypto가 지원하는 알고리즘은 정해져 있기 때문입니다. RSA와 NIST 곡선 위의 ECDSA는 어디서나 되고, Ed25519는 최신 브라우저에서만 되며 오래된 브라우저에서는 건너뜁니다. 키 종류를 가져올 수 없을 때 이 도구는 통과한 것처럼 보이게 하지 않고 확인하지 않았다고 말합니다. 확인하지 않은 서명과 유효한 서명은 전혀 다른 것이며, 그 둘을 뭉뚱그리는 것이야말로 이 도구가 저지를 수 있는 진짜 위험한 일입니다.
인증서도 여기서 해독할 수 있습니까?
안 됩니다. 인증서와 인증서 서명 요청은 서로 다른 구조이고, 이 도구는 PKCS#10 요청만 읽습니다. CSR은 CA에 보내는 것이고 인증서는 돌아오는 것으로, 발급자와 유효 기간, CA의 서명을 담고 있는데 요청에는 그중 무엇도 없습니다. -----BEGIN CERTIFICATE----- 블록은 인증서 디코더에 넣으십시오.
챌린지 패스워드는 무엇에 씁니까?
원래 PKCS#10 규격에 있는 선택 속성으로, 나중에 CA에 인증서 폐기를 요청할 때 쓰는 공유 비밀로 의도된 것입니다. 지금은 공개 CA가 거의 쓰지 않습니다. 폐기는 인증한 계정을 통해 처리하기 때문입니다. 다만 일부 기업 환경과 SCEP 등록 절차는 여전히 요구하고, 마이크로소프트 인증서 서비스는 이 값을 읽습니다. 설정되어 있으면 이 도구가 보여 줍니다. 요청 안에 평문으로 실려 다니므로 알아 둘 가치가 있습니다.

관련 도구