CSR 디코더

CSR(인증서 서명 요청)을 붙여넣으면 주체·키 정보를 해석합니다.

CSR 디코더는 인증서 서명 요청(CSR, Certificate Signing Request) PEM의 형식 유효성을 빠르게 확인하는 도구입니다. -----BEGIN CERTIFICATE REQUEST----- 블록이 올바른지, 내부 base64가 깨지지 않았는지, DER 바이너리로 정상 디코드되는지를 점검합니다. 인증기관(CA)에 CSR을 제출하기 전에 복사·붙여넣기 과정에서 줄바꿈이나 공백이 끼어 손상되지 않았는지 확인하기 좋습니다.

입력한 CSR은 서버에서 형식 검증과 SHA-256 지문 계산에만 쓰이며 저장되지 않습니다. 주체(CN)·SAN 같은 상세 필드까지 완전히 해석하려면 로컬에서 openssl req -in csr.pem -noout -text 명령을 쓰는 것이 가장 정확합니다. 이 도구는 제출 직전 "형식이 맞는가"를 가볍게 확인하는 용도에 초점을 둡니다. 발급받은 인증서를 풀어 보려면 SSL 인증서 디코더를, 서버에 설치한 뒤 라이브 점검은 SSL 인증서 검사기를 사용하세요.

CSR (PEM)-----BEGIN CERTIFICATE REQUEST----- 로 시작하는 PEM 텍스트를 붙여넣으세요.

CSR이란 무엇인가

CSR은 SSL/TLS 인증서를 발급받기 위해 인증기관에 제출하는 요청 데이터입니다. 공개키와 주체 정보(도메인, 조직 등)를 담고 개인키로 서명되어 있으며, 보통 Base64로 인코딩된 PEM 텍스트 형태입니다. 개인키 자체는 CSR에 포함되지 않으므로 안전하게 공유할 수 있습니다.

openssl로 CSR 만들고 확인하기

새 키 + CSR 생성: openssl req -new -newkey rsa:2048 -nodes -keyout domain.key -out domain.csr
CSR 내용 확인: openssl req -in domain.csr -noout -text
CSR 서명 검증: openssl req -in domain.csr -noout -verify
주체(Subject)만 보기: openssl req -in domain.csr -noout -subject

제출 전 체크리스트

BEGIN/END 줄을 포함한 PEM 전체를 빠짐없이 붙여넣었는지
중간에 공백·줄바꿈이 끼어 base64가 깨지지 않았는지
키 길이는 2048비트 이상(RSA) 또는 ECDSA P-256 이상인지
Common Name과 SAN에 발급받을 도메인이 정확히 들어갔는지

CSR 주체(DN) 필드 빠른 참조

CSR의 주체(Subject)는 여러 RDN 항목으로 구성되며, openssl req -text 출력의 Subject 줄에 축약자(약어)로 나타납니다. 공개 신뢰 인증서에서는 도메인 검증(DV) 위주로 발급되기 때문에 실제로 의미가 있는 항목은 CN과 SAN 정도이고, 나머지는 무시되거나(EV/OV 외) CA가 제출 폼에서 직접 받습니다.

약어	필드	예시 / 비고
`CN`	Common Name	`www.example.com` — 주 도메인. 와일드카드는 `*.example.com`
`O`	Organization	조직 법인명. OV/EV에서만 검증됨
`OU`	Organizational Unit	부서명. CA/B 포럼 정책상 신규 발급에선 사실상 폐지됨
`L` / `ST`	Locality / State	시·도. `ST`는 약어가 아닌 정식 명칭(`Seoul`)으로
`C`	Country	2글자 ISO 코드 — 한국은 `KR` (`Korea` 아님)
SAN	subjectAltName 확장	실제 인증 도메인 목록. 최신 브라우저는 CN을 무시하고 SAN만 봄

해석 예시: openssl 출력 읽기

이 도구가 "유효"라고 판정한 CSR을 로컬에서 openssl req -in domain.csr -noout -text로 열면 대략 아래처럼 보입니다. 이 도구는 1~2행의 구조(헤더+공개키 존재 여부)와 base64/DER 정합성을 확인할 뿐, 아래 필드 값까지 보여주지는 않습니다.

Subject: C=KR, O=Example Corp, CN=www.example.com → 발급 도메인은 CN의 www.example.com
Public Key Algorithm: rsaEncryption / Public-Key: (2048 bit) → RSA 2048비트, 정책 통과
Requested Extensions → X509v3 Subject Alternative Name: DNS:www.example.com, DNS:example.com → 두 도메인 모두 커버
Signature Algorithm: sha256WithRSAEncryption → SHA-1이면 거의 모든 CA가 거부

여기서 SAN에 루트 도메인(example.com)이 빠져 있는데 그걸로 접속한다면, 형식은 유효해도 발급 후 이름 불일치가 납니다. 이때 SSL 인증서 검사기로 설치 후 SAN을 다시 확인하세요.

흔한 실수 / 함정

CSR 대신 개인키를 붙여넣기: -----BEGIN PRIVATE KEY-----나 RSA PRIVATE KEY 헤더는 CSR이 아닙니다. CSR은 반드시 CERTIFICATE REQUEST 헤더여야 합니다. 개인키는 절대 어디에도 붙여넣지 마세요.
NEW CERTIFICATE REQUEST 헤더 혼동: 일부 Windows/IIS 도구는 -----BEGIN NEW CERTIFICATE REQUEST-----를 내보내는데, 이는 같은 PKCS#10이지만 헤더 문자열이 달라 엄격한 파서가 거부할 수 있습니다. 헤더를 BEGIN CERTIFICATE REQUEST로 바꾸면 동일하게 동작합니다.
'유효=발급 가능'으로 오해: 형식이 맞아도 CN/SAN 도메인 소유 검증(DCV)을 통과해야 발급됩니다. 이 도구의 통과는 "깨지지 않았다"는 의미일 뿐입니다.

자주 묻는 질문

이 도구가 CN이나 SAN 같은 필드도 보여주나요?

아니요. 이 도구는 형식 유효성(PEM 헤더, base64, DER 디코드)과 SHA-256 지문만 확인합니다. 주체·SAN·서명 알고리즘 등 상세 필드는 로컬에서 openssl req -in csr.pem -noout -text 로 확인하는 것이 가장 정확합니다.

입력한 CSR이 서버에 저장되나요?

아니요. 형식 검증과 지문 계산에만 사용되며 디스크에 저장하지 않습니다. 결과는 잠시 인메모리 캐싱될 뿐 영구 보관되지 않습니다.

'유효'로 나왔는데 CA가 거부했어요.

이 도구의 '유효'는 형식(PEM/base64/DER 구조)이 정상이라는 뜻입니다. 키 길이 정책, 도메인 소유 검증, 잘못된 주체 정보 등 내용상의 문제로 CA가 거부할 수 있습니다. openssl req -text 로 내용을 점검하세요.

CSR에 개인키가 들어있나요?

아니요. CSR에는 공개키와 주체 정보, 서명만 포함됩니다. 개인키는 별도 파일(.key)로 로컬에 보관해야 하며 절대 공유하면 안 됩니다.

어떤 형식의 CSR을 넣어야 하나요?

-----BEGIN CERTIFICATE REQUEST----- 로 시작하는 PEM(Base64) 텍스트를 그대로 붙여넣으세요. DER 바이너리는 지원하지 않습니다.