CSR(인증서 서명 요청) 디코더
PEM 형식의 CSR(인증서 서명 요청)을 붙여넣기만 하면 신청 예정인 CN·SAN·조직명·공개 키 알고리즘을 CA 제출 전에 확인할 수 있습니다. 입력 실수를 사전에 발견하는 데 도움이 되는 무료 도구입니다.
CSR 디코더란
CSR 디코더는 PEM 형식의 CSR(Certificate Signing Request, 인증서 서명 요청)을 붙여넣기만 하면 신청 예정인 Subject(CN·조직명 등)·SAN(주체 대체 이름)·공개 키 알고리즘·서명 알고리즘을 한눈에 확인할 수 있는 무료 도구입니다. CA(인증 기관)에 제출하기 전에 입력한 내용이 의도한 대로인지 그 자리에서 검증할 수 있습니다.
유사한 도구인 "X.509 인증서 디코더"가 이미 발급된 인증서를 분석하는 반면, 이 도구는 CA 심사·발급 이전 단계에 있는 CSR 자체를 대상으로 합니다. 아직 인증서가 발급되지 않았거나 개인 키를 재발급하기 전 최종 확인 용도로 사용할 수 있습니다.
CSR 디코더 사용법
- PEM 형식의 CSR을 붙여넣습니다 "-----BEGIN CERTIFICATE REQUEST-----"로 시작하는 텍스트를 입력란에 그대로 붙여넣습니다.
- 여러 개의 CSR도 한 번에 붙여넣을 수 있습니다 여러 CSR을 한꺼번에 붙여넣으면 블록 단위로 자동 감지됩니다.
- "분석하기" 버튼을 누릅니다 감지된 CSR 건수를 확인한 뒤 버튼을 눌러 서버에서 분석을 진행합니다.
- 결과를 확인합니다 Subject·SAN·공개 키 알고리즘 등이 목록으로 표시됩니다.
더 잘 활용하기 위한 팁
- CN(일반 이름)과 SAN 양쪽 모두에 실제로 발급받고자 하는 모든 호스트 이름이 포함되어 있는지 제출 전에 반드시 확인해 주세요. SAN 누락은 재발급의 번거로움으로 이어집니다.
- 공개 키 알고리즘이 RSA 2048비트 미만이거나 EC의 비권장 곡선을 사용하고 있지는 않은지 이 시점에서 확인해 두면 CA 심사에서 반려되는 상황을 피하는 데 도움이 됩니다.
- 여러 서버에 같은 CSR을 재사용하기 전에, Subject와 SAN에 적힌 조직명·도메인이 실제 신청 대상과 일치하는지 다시 한번 확인하세요.
- 이 도구로 확인할 수 있는 것은 어디까지나 CSR에 기재된 신청 내용뿐입니다. CA가 실제로 어떤 SAN을 발급할지는 심사 결과에 따라 달라질 수 있습니다.
이럴 때 활용해 보세요
CA 제출 전 최종 확인
유료 SSL 인증서를 구매하기 전에 CSR 생성 시 입력한 CN·SAN이 올바른지 확인할 수 있습니다.
사내 시스템의 CSR 생성 절차 검증
openssl req 등으로 생성한 CSR의 내용이 의도한 대로인지, 명령줄 조작에 익숙하지 않은 담당자도 시각적으로 확인할 수 있습니다.
과거에 발급을 의뢰한 CSR 내용 재확인
파일로 보관 중인 CSR의 내용을, 개인 키를 다루지 않고도 안전하게 다시 확인할 수 있습니다.
멀티 도메인 인증서의 SAN 누락 점검
여러 호스트 이름을 하나의 인증서로 한꺼번에 신청할 때, SAN에 빠진 항목이 없는지 신청 전에 점검할 수 있습니다.
용어집
- CSR(인증서 서명 요청)
- Certificate Signing Request의 약자입니다. CA에 인증서 발급을 요청할 때 제출하는, 공개 키와 신청 정보(Subject·SAN 등)를 담은 데이터입니다.
- CA(인증 기관)
- Certificate Authority의 약자입니다. CSR의 내용을 심사하여 실제 SSL/TLS 인증서를 발급하는 제3의 기관입니다.
- CN(일반 이름, Common Name)
- 인증서의 주된 대상이 되는 호스트 이름이나 서비스 이름을 나타내는 Subject의 한 항목입니다. 과거에는 브라우저가 CN만을 보고 검증했지만, 현재는 SAN이 우선시됩니다.
- SAN(주체 대체 이름, Subject Alternative Name)
- 인증서가 유효한 호스트 이름이나 IP 주소를 추가로 나열하는 확장 필드입니다. CSR 단계에서는 "Requested Extensions(요청된 확장)"로 기록됩니다.
- Requested Extensions(요청된 확장)
- CSR 신청자가 "발급 시 이 확장을 포함해 달라"고 요청하는 속성입니다. SAN은 이 안에 포함되지만, CA가 반드시 그대로 반영한다는 보장은 없습니다.
- 공개 키 알고리즘
- CSR에 포함된 공개 키의 생성 방식입니다. RSA·EC(타원 곡선 암호) 등이 있으며, 키 길이와 곡선에 따라 강도가 달라집니다.
자주 묻는 질문
여담 ― CSR은 왜 "서명"을 포함할까요
CSR의 내용을 자세히 살펴보면 Subject·공개 키 정보에 이어 서명 알고리즘과 서명 값이 담겨 있습니다. 이는 언뜻 이상하게 보일 수 있습니다. CA에 "저를 증명해 주세요"라고 요청하는 서류가 왜 자기 자신의 서명을 포함하고 있는 것일까요? 그 답은 "Proof of Possession(개인 키 보유 증명)"이라는 개념에 있습니다. CSR 전체(Subject·공개 키 등)를, CSR에 기재한 공개 키와 한 쌍을 이루는 개인 키로 서명함으로써 "이 공개 키에 대응하는 개인 키를 실제로 보유한 신청자 본인"임을 CA에 증명하는 것입니다. 타인의 공개 키를 임의로 포함한 CSR을 만들더라도 대응하는 개인 키가 없으면 올바른 서명을 만들 수 없기 때문에, 이러한 방식으로 신분 사칭 신청을 방지할 수 있습니다.
CSR이라는 구조는 RSA가 개발한 공개 키 암호 표준군 PKCS(Public-Key Cryptography Standards) 중 PKCS#10으로 1986년에 규정되었습니다. 현재는 IETF가 RFC 2986으로 다시 정의했지만, 실무에서는 지금도 PKCS#10이라는 명칭이 널리 사용되고 있습니다. TLS 인증서의 세계에서는 눈에 띄지 않는 존재이지만, 인증서 발급 과정 전체의 출발점이 되는 없어서는 안 될 구조입니다.
CSR의 Requested Extensions(요청된 확장)에 SAN을 포함하는 구조가 표준화된 것은 사실 그리 오래된 이야기가 아닙니다. 원래 CSR 표준(PKCS#10)에는 Subject와 CN 정도만 상정되어 있었고, 멀티 도메인 인증서와 와일드카드 인증서가 보급되면서 CA마다 독자적인 방식으로 SAN을 받아들이게 되었습니다. 현재는 openssl 등 주요 도구가 RFC 2985의 Extension Request라는 구조를 통해 SAN을 CSR에 포함하는 방법을 표준으로 지원하고 있으며, 이 도구 역시 이 표준적인 위치(Attributes 내의 extensionRequest 속성)에서 SAN을 읽어들이고 있습니다.