CSR 뷰어
FreePEM으로 인코딩된 인증서 서명 요청(PKCS#10)을 디코딩합니다: Subject, 공개 키, 서명 알고리즘, Subject Alternative Names를 확인하고, 자체 서명이 실제로 유효한지 검증합니다.
전적으로 브라우저 내에서 실행됩니다. 서명 확인을 위해서도 CSR이 어디에도 업로드되지 않습니다.
최근 활동
모든 사람에게 공개됩니다. 모든 방문자의 최근 20회 사용 내역, 최신순으로 표시됩니다.
Parsed a CSR and checked its self-signature.
2시간 전
Parsed a CSR and checked its self-signature.
2시간 전
Parsed a CSR and checked its self-signature.
2시간 전
Parsed a CSR and checked its self-signature.
2시간 전
Parsed a CSR and checked its self-signature.
2시간 전
이 도구의 기능
CSR 뷰어는 PEM으로 인코딩된 인증서 서명 요청(PKCS#10)을 디코딩하여 Subject 필드, 공개 키 세부 정보, 서명 알고리즘, Subject Alternative Names를 일반 텍스트로 표시한 다음, CSR의 자체 서명이 포함된 공개 키에 대해 실제로 유효한지 확인합니다.
작동 방식
CSR는 PEM base64로 감싸진 DER 인코딩 ASN.1 구조입니다. 이 도구는 해당 구조를 바이트 단위로 디코딩합니다. 중첩된 각 TLV(태그-길이-값) 요소를 읽어 Subject 식별 이름, SubjectPublicKeyInfo 블록(RSA 모듈러스와 지수, 또는 EC 곡선과 점), Subject Alternative Names를 담는 선택적 extensionRequest 속성, 그리고 외부 서명 알고리즘과 서명 바이트까지 단계적으로 도달합니다 -- 모두 서버 측 ASN.1 라이브러리 없이 클라이언트 측에서만 수행됩니다.
자체 서명을 확인하기 위해 이 도구는 브라우저의 Web Crypto API를 사용하여 CSR 자체의 공개 키를 다시 가져와 서명이 실제로 포함하는 CertificationRequestInfo 블록의 정확한 바이트에 대해 검증하도록 요청합니다. ECDSA 서명의 경우 DER로 인코딩된 r/s 값이 먼저 Web Crypto가 요구하는 고정 길이 원시 형식으로 변환됩니다. 일치하면 개인 키를 가진 사람이 실제로 이 정확한 CSR을 생성했다는 의미이고, 불일치하면 서명 후 변경되었거나 잘못 조립되었다는 의미입니다.
해결하는 문제
- 로컬에 OpenSSL을 설치할 필요 없이, 인증 기관에 보내기 전에 CSR의 Subject 필드와 Subject Alternative Names를 다시 확인합니다.
- 동료, 클라이언트 또는 자동화된 시스템으로부터 받은 CSR이 올바른 형식이며 실제로 자체 서명되었는지 추가 처리 전에 확인합니다.
- CA의 최소 요구 사항을 충족하는지 확인하기 위해 CSR이 생성될 때 사용된 키 종류와 크기(RSA 2048/4096비트, 또는 EC P-256/P-384/P-521)를 확인합니다.
- 인증서 파이프라인을 디버깅하거나 PKCS#10이 실제로 어떻게 인코딩되는지 배우기 위해 CSR의 원시 ASN.1 구조를 살펴봅니다.
자주 묻는 질문
›이 도구가 제 개인 키를 보나요?
아닙니다. CSR에는 개인 키가 절대 포함되지 않습니다 -- 공개 키, 신원 정보, 그리고 개인 키로 만든 서명만 포함됩니다. 이 도구는 붙여넣은 내용만 읽으며 전적으로 브라우저 내에서 실행되고 서버로 아무것도 전송하지 않으므로, 실수로 CSR을 붙여넣더라도 유출될 민감한 정보가 전혀 없습니다.
›"자체 서명 유효" 검사는 실제로 무엇을 증명하나요?
이는 CSR이 내부 공개 키와 일치하는 개인 키를 가진 사람에 의해 서명되었음을 증명합니다 -- 즉, 생성된 이후 CSR이 변조되거나 손상되지 않았다는 뜻입니다. Subject 필드(회사명, 도메인 등)가 사실임을 증명하지는 않습니다 -- 신원 확인은 발급 시 인증 기관의 역할이며, CSR 자체가 증명할 수 있는 것이 아닙니다.
›일부 CSR에서 "확인할 수 없음(이 브라우저에서 지원하지 않는 알고리즘)"이 표시되는 이유는 무엇인가요?
브라우저는 특정 알고리즘 집합만 지원하는 Web Crypto API를 사용하여 서명을 검증합니다. 이 도구는 일반적인 알고리즘(SHA-1/256/384/512를 사용하는 RSA 및 ECDSA)을 지원하지만, 이 범위를 벗어난 특이하거나 오래된 알고리즘으로 서명된 CSR은 클라이언트 측에서 검증할 수 없습니다. 다른 필드는 그래도 정상적으로 디코딩됩니다.
›제 CSR에 Subject Alternative Names가 없는 이유는 무엇인가요?
SAN은 CSR에서 선택 사항이며 CSR 생성 시 명시적으로 요청된 경우에만 나타납니다(예: openssl의 -addext "subjectAltName=..." 옵션이나 설정 파일의 [alt_names] 섹션). 특히 오래되었거나 수동으로 생성된 많은 CSR은 애초에 SAN이 요청된 적이 없습니다.
›CSR과 인증서의 차이는 무엇인가요?
CSR는 생성하여 인증 기관(CA)에 보내는 요청으로, 그 자체가 서버에 설치되는 일은 없습니다. 인증서는 CA가 신원을 확인한 후 돌려주는 것으로, CSR과 동일한 공개 키와 Subject 정보에 더해 CA 자체의 서명, 유효 기간, 일련번호를 포함합니다.
댓글 (0)
이 도구가 유용했나요? 댓글을 남기거나 팁을 공유하거나 개선할 점을 알려주세요.
아직 댓글이 없습니다. 첫 번째로 의견을 남겨보세요!