테마

인기 도구

CSR 디코더 · CSR 확인

인증서 서명 요청을 붙여 넣으면 담긴 필드를 모두 읽어 줍니다. 주체, 키, 모든 대체 이름, 모든 확장이 대상입니다. 공인 CA가 적용하는 규칙으로 요청을 검사하고, 개인 키가 일치하는지도 알려 드립니다. SSL 인증서도 여기서 디코딩할 수 있습니다.

Web Crypto로 브라우저에서 디코딩 · 업로드도 저장도 없음 · CA/Browser Forum Baseline Requirements v2.3.1

브라우저에서 디코딩합니다. 업로드도 저장도 하지 않습니다.
파일을 이 페이지 아무 곳에나 놓으세요 PEM, DER, .csr, .cer, .crt, .pem, .req, .txt

예시 선택

이 페이지의 모든 작업은 브라우저 안에서 이루어집니다. 네트워크 패널을 열어 직접 확인해 보세요. 데이터를 담은 요청은 없습니다.

CSR이란?

인증서 서명 요청(CSR)은 인증 기관에 인증서를 요청하는 작은 서명 파일입니다. 공개 키, 인증서에 넣고 싶은 이름, 개인 키로 만든 서명이 들어 있습니다.

형식은 PKCS#10이며 RFC 2986에 정의되어 있습니다. 서명 대상 부분에는 버전 번호, 주체 이름, 공개 키를 담은 SubjectPublicKeyInfo, 속성 집합의 네 가지뿐입니다. 이 전체를 그 안의 공개 키와 짝인 개인 키로 서명하므로 CSR은 자체 서명입니다. 이 서명이 키 소유 증명입니다. 공개 키는 누구나 읽을 수 있지만, 그 키로 검증되는 요청에 서명할 수 있는 쪽은 개인 키를 가진 쪽뿐입니다.

개인 키는 파일에 들어 있지 않으며, 들어 있어서도 안 됩니다. CSR은 이메일로 보내도, CA의 웹 양식에 붙여 넣어도, 여기서 디코딩해도 안전합니다. 그래서 이 페이지는 아무것도 외부로 보내지 않고 모든 작업을 브라우저에서 처리할 수 있습니다.

요청 하나를 바이트 단위로RFC 2986 · PKCS#10

파일 전체

  • 래퍼4바이트
  • 서명 대상 부분469바이트
  • 서명 알고리즘15바이트
  • 서명 자체261바이트

서명 대상 부분의 내부

  1. 버전3바이트항상 0입니다. 형식이 정의한 유일한 버전입니다
  2. 주체 이름108바이트양식에 입력한 고유 이름(DN)
  3. 내 공개 키294바이트알고리즘, 크기, 키. 인증 기관이 확실히 사용하는 단 하나의 필드
  4. 속성60바이트요청한 대체 이름이 실려 가는 곳

내 개인 키위 부분에 서명합니다짝이 되는 개인 키를 가지고 있다는 증명 · 서명은 파일 전체가 아니라 그 부분만 덮습니다

이 페이지가 제공하는 예시 요청이며 전체 크기는 749바이트입니다. 서명 대상 부분에는 네 가지가 들어가고, 그 안의 공개 키와 짝인 개인 키가 정확히 그 부분에 서명하며, 그 결과가 맨 끝의 서명 261바이트입니다.
CSR 디코더 결과: 디코딩된 인증서 서명 요청의 주체, 키, 대체 이름과 CA 규칙 검사 결과CSR 디코더 결과: 디코딩된 인증서 서명 요청의 주체, 키, 대체 이름과 CA 규칙 검사 결과붙여 넣기 또는 놓기CSR, 인증서, 공개 키를 PEM, base64, 16진수 덤프, 파일로 넣을 수 있습니다. 여러 개를 한 번에 넣어도 됩니다.판정공인 CA가 이 요청을 어떻게 처리하는지 보여 줍니다. 발급, 변경 후 발급, 거부 중 하나이며 각각 이유가 붙습니다.이름인증서가 포함하게 될 모든 이름과, 이에 대조한 일반 이름의 검사 결과입니다.키와 서명알고리즘, 크기, 곡선, 지수와 함께 요청 자체의 서명이 유효한지 보여 줍니다.키 일치개인 키나 발급된 인증서를 추가하면 이 요청에 속하는지 확인할 수 있습니다. 어느 쪽도 브라우저 밖으로 나가지 않습니다.
분해한 인증서 서명 요청입니다. 판정, 요청한 이름, 그 뒤의 키, 그리고 내 키를 맞춰 볼 자리를 보여 줍니다. 번호를 선택하면 각 부분이 무엇을 보여 주는지 확인할 수 있습니다.

CSR을 보내기 전에 확인하는 방법

확인할 것은 세 가지입니다. 이름이 의도한 대로인지, 서명이 유효한지, 그리고 CA가 적용하는 규칙을 어기는 내용이 없는지입니다.

위에 요청을 붙여 넣으세요. 이 페이지는 주체를 속성별로 읽고, 모든 주체 대체 이름을 나열하고, 키의 알고리즘과 크기를 보여 준 다음 요청 자체의 서명을 확인합니다. 서명이 확인되지 않는 요청은 만들어진 뒤에 편집되었거나, 잘렸거나, 손상된 것이므로 그대로 보내지 말고 다시 만드세요.

그다음이 규칙입니다. 인증 기관은 CA/Browser Forum의 Baseline Requirements를 적용하며, 이를 어기는 요청은 거부되거나 조용히 변경됩니다. 이 페이지의 검사 결과는 CA가 요청한 내용을 발급할 수 없으면 반드시 수정, 발급은 하되 필드를 삭제하거나 바꾸면 변경 예정, 알아 두면 좋은 내용이면 참고로 표시합니다.

실행 순서대로 세 가지 검사CA/Browser Forum TLS BR 2.3.1
  1. 이름인증서가 포함하게 될 모든 이름과, 일반 이름이 그 안에 있는지 여부
  2. 서명브라우저 자체의 암호화 기능으로 검증
  3. 인증 기관의 규칙하나씩 적용하며, 각각 출처 문서를 함께 표시
  • 보내세요요청에 규칙을 어기는 내용이 없습니다
  • 거부됩니다파일은 멀쩡하지만, 요청한 내용이 허용되지 않습니다
  • 다시 만드세요서명이 확인되지 않으면 파일이 만들어진 뒤에 편집되었거나, 잘렸거나, 잘못 복사된 것입니다
처음 두 검사는 파일 자체에 대한 것이고 세 번째는 인증 기관이 허용하는 것에 대한 것입니다. 요청이 앞의 두 검사를 통과하고도 거부될 수 있습니다.

CSR에 들어 있는 것과 CA가 실제로 쓰는 것

CSR의 모든 내용 가운데 공인 CA가 확실하게 쓰는 필드는 공개 키 하나입니다. 나머지는 대부분 CA가 직접 검증하거나, 덮어쓰거나, 복사가 금지되어 있습니다.

DigiCert는 자사 문서에서 분명하게 말합니다. "DigiCert uses the public key embedded in the CSR to create your client certificate. All other fields in the CSR are ignored." OV나 EV 인증서에서는 조직, 지역, 국가를 넣기 전에 CA가 직접 검증해야 하며, 입력한 값은 그대로 신뢰하지 않습니다. 유효 기간은 요청에서 가져오지 않으며 Baseline Requirements의 일정을 따릅니다.

주체 필드 두 가지는 단순히 무시되는 데 그치지 않고 금지됩니다. organizationalUnitName(OU)은 공인 TLS 인증서에 들어가면 안 되며(CA/Browser Forum의 투표안 SC047에 따라 2022년 9월 1일 이후 발급된 인증서에는 넣을 수 없습니다), emailAddress는 도메인 검증 인증서에 아예 허용되지 않습니다. 일반 이름은 허용되지만 권장하지 않으며, 있다면 주체 대체 이름 중 하나와 정확히 같아야 합니다. 이 마지막 규칙 때문에 이 페이지는 SAN 목록에 없는 일반 이름을 표시합니다.

인증 기관이 각 필드를 어떻게 처리하는가CA/Browser Forum TLS BR 2.3.1
내 요청의 필드그 결과이유
공개 키SubjectPublicKeyInfo보낸 그대로 사용인증 기관이 확실히 가져가는 단 하나
대체 이름subjectAltName2.5.29.17보낸 그대로 사용CA는 이름을 하나라도 기록하기 전에 각 이름을 내가 관리하는지 확인합니다
일반 이름CN2.5.4.3검증한 뒤 CA가 작성권장하지 않음. 있다면 대체 이름 중 하나와 정확히 같아야 합니다
조직, 지역, 주(도)O, L, ST2.5.4.10검증한 뒤 CA가 작성조직 검증 인증서에서는 입력한 값이 아니라 CA가 검증한 기록에서 가져옵니다
국가C2.5.4.6검증한 뒤 CA가 작성검증 수준과 관계없이 들어갈 수 있습니다
조직 단위OU2.5.4.11아예 허용되지 않음2022년 9월 1일부터 공인 인증서에서 금지
이메일 주소emailAddress1.2.840.113549.1.9.1아예 허용되지 않음도메인 검증 인증서에는 허용되지 않음
유효 시작일, 유효 종료일notBefore, notAfter요청에서 가져오지 않음인증 기관이 따르는 일정으로 정해지며, 내 요청으로는 정해지지 않습니다

“DigiCert uses the public key embedded in the CSR to create your client certificate. All other fields in the CSR are ignored.”

DigiCert, 자사 문서
사람들이 고민하는 필드와 각각의 실제 가치입니다. 키와 이름은 살아남고, 조직 단위는 무엇을 입력하든 아예 들어갈 수 없고, 도메인 검증 인증서에는 이메일 주소도 들어갈 수 없으며, 날짜는 처음부터 내가 정할 수 없었습니다.

CA가 CSR을 거부하는 이유

거부 사유는 거의 모두 다음 중 하나로 귀결됩니다. CA가 인증할 수 없는 이름, 너무 넓은 와일드카드, 예약된 IP 주소, 너무 작은 키, 너무 오래된 서명 해시, 서명이 확인되지 않는 요청입니다.

인증 기관은 내부 이름, 즉 "does not end with a Top-Level Domain registered in IANA's Root Zone Database"인 이름에는 발급할 수 없습니다. server.local, intranet, 점이 전혀 없는 단일 레이블 이름, 임의로 만든 접미사가 모두 여기에 해당합니다. 레이블은 영문자, 숫자, 하이픈만 쓸 수 있으므로 호스트 이름의 밑줄은 거부되고, 이름 끝에 마침표를 써서도 안 됩니다. 와일드카드는 맨 왼쪽 레이블 전체만 대신할 수 있고 공개 접미사는 안 됩니다. *.example.com은 되고 *.co.uk는 안 됩니다. IP 주소는 넣을 수 있지만 예약된 주소는 안 됩니다. 10.0.0.0/8, 192.168.0.0/16, 127.0.0.1, fc00::/7은 모두 불가합니다.

키에 대한 Baseline Requirements의 기준은 정확합니다. RSA 모듈러스는 2048비트 이상이면서 8로 나누어떨어져야 하고, 아니면 P-256, P-384, P-521 곡선의 점이어야 하며 "no other algorithms or key sizes are permitted"입니다. CA는 소인수분해할 수 있는 키, 즉 "which can be factored within 100 rounds using Fermat's factorization method"인 키도 거부해야 하며, 이 페이지는 요청에 든 키에 그 검사를 실제로 수행합니다. 또한 CSR 자체의 서명 해시는 인증서의 해시와 다르지만, Let's Encrypt는 2022년에 SHA-1 자체 서명을 받지 않게 되었으므로, 아직 SHA-1로 서명하는 오래된 도구로 만든 요청은 거부됩니다.

인증 기관이 인증하지 않는 이름CA/Browser Forum TLS BR 2.3.1
  • server.local
    내부 이름공개 루트 영역에 있는 최상위 도메인으로 끝나지 않으므로, 아무도 그 이름이 내 것임을 증명할 수 없습니다
    거부
  • intranet
    단일 레이블점이 전혀 없는 이름도 같은 정의에 해당합니다
    거부
  • my_host.example.com
    밑줄레이블에는 영문자, 숫자, 하이픈만 쓸 수 있습니다
    거부
  • *.co.uk
    레지스트리 전체에 걸친 와일드카드와일드카드는 맨 왼쪽 레이블만 대신할 수 있고 공개 접미사는 안 됩니다
    거부
  • 192.168.1.10
    예약된 주소공인 주소는 인증할 수 있지만 사설 또는 특수 용도 대역의 주소는 절대 안 됩니다
    거부
  • example.com.
    끝의 마침표비어 있는 루트 레이블은 써서는 안 됩니다
    거부
여섯 개의 이름이 각각 다른 규칙을 어기며, 모두 요청을 보내기 전에 미리 볼 수 있었던 거부 사유입니다.

개인 키가 CSR과 일치하는지 어떻게 알 수 있나요?

개인 키 파일에는 이미 공개 키가 들어 있으므로, 일치 여부 확인은 공개 키 두 개의 비교입니다. 비밀은 필요 없고 어디로 보낼 것도 없습니다.

위의 키 또는 인증서 대조를 열고 요청 옆에 키를 추가하세요. 이 페이지는 파일에서 공개 키 절반만 읽고(PKCS#8, PKCS#1, SEC1 키를 모두 이해합니다), 요청 안의 키와 비교해 답을 보여 줍니다. 업로드하지 않고, 보관하지 않으며, 키는 입력란을 벗어나면 지워집니다. 요청과 CA가 돌려준 인증서 사이에도 같은 검사가 통합니다. 서버가 시작을 거부하기 전에 "the certificate and the private key do not match" 오류를 미리 잡아낼 수 있습니다.

어떤 웹 페이지에도 키를 붙여 넣고 싶지 않다면, 같은 답을 내 컴퓨터에서 명령 두 개로 얻을 수 있습니다. openssl req -in request.csr -pubkey -noout은 요청에서 공개 키를 출력하고, openssl pkey -in private.key -pubout은 키에서 출력합니다. 출력이 같으면 일치합니다. 예전 방식인 -modulus는 RSA 키에서만 되지만 -pubkey는 모든 키 종류에서 됩니다.

파일 둘, 비교 하나RFC 2986 · OpenSSL manual
내 브라우저
  • 개인 키 파일어디에도 보내면 안 되는 파일공개 키 절반만 읽어 냅니다
  • 요청인증 기관에 보내는 파일이미 공개 키가 들어 있습니다

같은 키인가요?

  • 일치합니다돌려받는 인증서를 이 키에 설치할 수 있습니다
  • 일치하지 않습니다웹 서버가 시작을 거부할 때 보고하는 바로 그 불일치입니다

이 선을 넘는 것은 없습니다 · 네트워크를 꺼도 비교가 동작합니다그 밖의 모든 곳

또는 내 컴퓨터에서 직접openssl req -in request.csr -pubkey -nooutopenssl pkey -in private.key -pubout출력이 같으면 일치합니다
개인 키 파일에는 이미 공개 키가 들어 있으므로, 공개 키 두 개를 비교하면 답이 나옵니다. 그러려고 비밀이 움직일 필요는 없으며, 실제로도 움직이지 않습니다.

CSR, 인증서, 개인 키: 무엇이 다른가요?

개인 키는 비밀입니다. CSR은 그 키를 가졌음을 증명하는 요청입니다. 인증서는 CA가 서명해서 돌려주는 답이며, 세 가지 중 처음부터 공개를 전제로 한 것은 인증서뿐입니다.

세 파일은 같은 폴더에 이름까지 비슷하게 놓이는 경우가 많습니다. 개인 키는 -----BEGIN PRIVATE KEY----- 또는 -----BEGIN RSA PRIVATE KEY-----로 시작하며, 인증 기관을 포함해 누구에게도 보내면 안 됩니다. 인증서 서명 요청은 -----BEGIN CERTIFICATE REQUEST-----로 시작하고, 그 키로 서명되며, 보내도 안전합니다. 인증서는 -----BEGIN CERTIFICATE-----로 시작하고, CA가 서명하며, 어차피 사이트의 모든 방문자에게 전달됩니다.

인증서가 발급되고 나면 요청은 더 쓸 데가 없습니다. 설치, 갱신, 폐기 어디에도 필요하지 않습니다. 반드시 지키고 안전하게 보관해야 하는 것은 키입니다. 위에 셋 중 무엇이든 붙여 넣으면 이 페이지가 어느 것인지 알려 줍니다.

파일 셋, 폴더 하나, 헷갈리게 비슷한 이름RFC 7468

  • 개인 키비밀

    첫 줄-----BEGIN PRIVATE KEY-----널리 쓰이는 다른 형태-----BEGIN RSA PRIVATE KEY-----

    서명한 쪽
    없음. 서명을 하는 쪽입니다
    볼 수 있는 사람
    나뿐, 다른 사람은 안 됩니다
    용도
    이 서버가 인증서를 발급받은 서버임을 증명합니다

  • 인증서 서명 요청공개

    첫 줄-----BEGIN CERTIFICATE REQUEST-----널리 쓰이는 다른 형태-----BEGIN NEW CERTIFICATE REQUEST-----

    서명한 쪽
    자기 자신, 개인 키로
    볼 수 있는 사람
    나와 인증 기관
    용도
    인증서를 요청하고, 그 대상 키를 가졌음을 증명합니다

  • 인증서공개

    첫 줄-----BEGIN CERTIFICATE-----

    서명한 쪽
    인증 기관
    볼 수 있는 사람
    사이트의 모든 방문자
    용도
    이 키가 이 이름들의 것임을 브라우저에 알립니다

.csr.pem.req.txt요청에 확장자를 정해 둔 표준은 없습니다. 이 모두가 쓰이며, 이 페이지는 이름이 아니라 내용을 읽습니다

셋 중 비밀인 것은 첫 번째뿐입니다. 마지막 것은 어차피 모든 방문자에게 전달되고, 가운데 것은 인증서가 도착하는 순간 쓸모가 없어집니다.

CSR을 온라인에서 디코딩해도 안전한가요?

CSR에는 비밀이 없으므로 어디서 디코딩해도 해가 없습니다. 문제는 개인 키이고, 사람들이 CSR과 혼동하는 파일이 바로 그것입니다.

이 페이지의 모든 작업은 브라우저에서 실행됩니다. 요청은 페이지와 함께 내려받은 코드가 분석하고, 서명은 브라우저 자체의 Web Crypto가 확인하며, 어떤 서버로도 내 데이터를 담은 요청이 나가지 않습니다. 사용하는 동안 네트워크 패널에서 직접 볼 수 있습니다. 이는 약속이 아니라 페이지가 만들어진 방식입니다.

이것이 중요한 이유는 CSR 옆에 있는 파일 때문입니다. CA/Browser Forum의 정의는 엄격합니다. "A Private Key is said to be compromised if its value has been disclosed to an unauthorized person, or an unauthorized person has had access to it." 악용은 필요 없습니다. 다른 사람의 서버에 닿기만 해도 충분합니다. 2020년에 DigiCert는 고객이 CSR과 함께 붙여 넣은 개인 키 337개를 발견해 관련 인증서를 모두 폐기했고, "by sending the private key to DigiCert along with the CSR, the customer has compromised the private key"라고 밝혔습니다. 이 페이지가 붙여 넣은 개인 키를 읽게 되면, 그 사실을 알리고 디코딩을 거부하며 아무것도 보관하지 않습니다.

파일이 실제로 가는 곳CA/Browser Forum TLS BR 2.3.1

이 페이지

내 브라우저
  1. 파일을 읽습니다
  2. 페이지와 함께 도착한 코드가 분해합니다
  3. 브라우저가 직접 서명을 확인합니다
  4. 결과를 그립니다

내 데이터를 담고 나가는 요청이 없습니다사용하는 동안 네트워크 패널을 열어 직접 확인하세요

업로드하는 페이지

내 브라우저

파일이 업로드됩니다…옆에 함께 붙여 넣은 것이 무엇이든 함께

다른 사람의 서버

그곳에 도착한 개인 키는 그것만으로 유출된 것입니다

“A Private Key is said to be compromised if its value has been disclosed to an unauthorized person, or an unauthorized person has had access to it.”

인증 기관들이 스스로 정한 정의

이미 일어난 일입니다2020년에 한 인증 기관이 요청 옆에 붙여 넣은 개인 키 337개를 발견했습니다관련된 인증서는 모두 폐기되었습니다

요청에는 비밀이 없으므로 어디서 디코딩해도 해가 없습니다. 사람들이 혼동하는 파일은 다릅니다. 악용이 없어도 피해가 생기며, 보이기만 해도 충분합니다.

RSA와 ECDSA: CSR에는 어떤 키를 써야 할까요?

ECDSA P-256 키는 RSA 3072비트 키와 강도가 같으면서 훨씬 작으므로 더 나은 기본값입니다. RSA 2048은 여전히 어디서나 받아들여집니다.

NIST는 P-256과 RSA-3072를 같은 128비트 보안 강도로 보며, 표에는 RSA-4096 행이 아예 없습니다. 다음 행은 RSA-7680으로, 192비트이며 P-384가 도달하는 수준입니다. 따라서 4096비트 RSA 키는 3072비트보다 나은 점이 문서로 확인되지 않는데도 모든 방문자에게 핸드셰이크 부담을 더합니다. Baseline Requirements는 P-521도 허용하지만 Let's Encrypt는 이를 거부하므로, P-521 요청은 규칙상 완전히 합법이어도 쓰려던 CA에서 실패할 수 있습니다.

Ed25519는 알고리즘이 아무리 좋아도 현재 공인 TLS 인증서에는 쓸 수 없습니다. Baseline Requirements는 RSA와 NIST 곡선 세 가지를 열거하고 "no other algorithms or key sizes are permitted"라고 덧붙입니다. 양자 내성 키도 마찬가지입니다. 공인 TLS에서 ML-DSA를 허용하려던 투표안은 2026년 10월에 병합되지 않은 채 종결되었습니다. Ed25519와 ML-DSA는 SSH, 서명, 사설 CA에는 여전히 유용하며, 이 페이지는 그런 키를 쓴 요청도 읽습니다.

같은 강도, 전혀 다른 크기NIST SP 800-57 Part 1 Rev 5, Table 2
강도RSA 키곡선
보안 112비트2,048비트모든 공인 CA이 강도에 해당하는 곡선 가운데 공인 인증 기관이 허용하는 것은 없습니다
보안 128비트3,072비트모든 공인 CAP-256모든 공인 CA
4,096비트모든 공인 CA4,096비트는 표에 아예 없습니다
보안 192비트7,680비트모든 공인 CAP-384모든 공인 CA
보안 256비트15,360비트모든 공인 CAP-521모든 공인 CA
  • RSA 키
  • 곡선
  • 단계가 한 크기에서 다음 크기로 바로 넘어가며 그 사이의 인기 있는 크기를 건너뜁니다. 그래서 모든 방문자에게 드는 추가 핸드셰이크 비용이 아무도 문서로 남기지 않은 이득을 위한 것이 됩니다
  • 허용하는 곳Let's Encrypt

곡선은 같은 강도를 훨씬 적은 바이트로 담습니다

공개된 비교표와, 키를 실제로 쓸 수 있는지 가르는 두 가지입니다. 규칙이 허용하는 것, 그리고 쓰려는 인증 기관이 허용하는 것입니다.

플랫폼별 CSR 만드는 방법

OpenSSL 명령 하나로 Linux, macOS, OpenSSL이 설치된 Windows를 모두 처리할 수 있습니다. IIS에는 certreq가, macOS에는 키체인 접근이 있고, 이 사이트에는 키를 어디로도 보내지 않는 생성기가 있습니다.

OpenSSL에서는 openssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr -subj "/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.com" 한 번으로 키와 요청을 함께 만듭니다. (-nodes는 키를 암호화하지 않고 둡니다. OpenSSL 3에서는 -noenc로도 쓰지만, macOS에 내장된 LibreSSL은 -nodes만 알아봅니다.) 그런 다음 openssl req -in example.com.csr -text -verify -noout으로 내용을 보고 검증합니다. Windows에서는 certreq -new request.inf request.req가 .inf 파일을 읽으며, 대체 이름은 OID 2.5.29.17 아래에 _continue_ 줄로 적습니다. SAN= 키는 없습니다. Microsoft 참조 페이지는 예제가 SHA-1을 쓰고 있어 CA가 이제 거부한다고 경고하므로, 해시는 직접 지정하세요.

Mac에서는 키체인 접근 > 인증서 지원 > 인증 기관에 인증서 요청으로 만들 수 있으며, 키 크기는 "Let me specify key pair information" 체크 상자 뒤에 있습니다. 또는 브라우저의 Web Crypto로 키를 만들고 두 파일을 서버를 거치지 않고 건네주는 CSR 생성기를 사용하세요. CSR에 파일 확장자를 정해 둔 표준은 없습니다. .csr, .pem, .req, .txt가 모두 쓰이며, 이 페이지는 이름을 믿지 않고 내용을 읽습니다.

만드는 방법 네 가지OpenSSL · Microsoft Learn · Apple Support

  1. OpenSSLLinux, macOS, Windows

    명령 하나로 키와 요청을 함께 만듭니다openssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr -subj "/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.com"그런 다음 다시 읽어 요청 자체의 서명을 검증합니다openssl req -in example.com.csr -text -verify -noout

  2. certreqWindows Server와 IIS

    일반 텍스트 파일을 읽으며, 대체 이름은 확장 섹션에 한 줄씩 적습니다certreq -new request.inf request.req[Extensions] 2.5.29.17 = "{text}" _continue_ = "DNS=example.com&" _continue_ = "DNS=www.example.com"Microsoft 자체 예제 페이지는 아직 인증 기관이 거부하는 해시를 기준으로 쓰여 있으므로, 해시는 직접 지정하세요

  3. Keychain AccessmacOS

    Keychain Access › Certificate Assistant › Request a Certificate From a Certificate AuthorityMac은 이 메뉴 이름을 자체 언어로 표시합니다키 종류와 크기는 키 쌍을 직접 지정하는 상자 뒤에 있습니다RSA 키는 2048~4096비트이며, 더 작은 키는 더 이상 제공되지 않습니다

  4. DNS Robot모든 브라우저

    브라우저 자체의 암호화 기능으로 키를 만들고, 두 파일 모두 서버를 거치지 않고 건네줍니다생성기 열기
OpenSSL 명령 하나가 Linux, macOS, Windows 모두에서 동작합니다. 나머지 세 방법은 그 명령이 손에 없는 컴퓨터를 위한 것입니다.

인증서는 얼마나 오래 유효한가요?

지금 발급되는 공인 TLS 인증서의 유효 기간은 200일을 넘을 수 없습니다. 2027년 3월에 100일로, 2029년 3월에 47일로 줄어듭니다.

일정은 2025년 4월에 채택된 CA/Browser Forum 투표안 SC-081v3에서 나왔으며, CSR이 영향을 줄 수 있는 부분이 아닙니다. 유효 기간은 요청에서 정해지지 않습니다. 각 단계에는 숫자가 두 개 있어서, SHOULD NOT은 MUST NOT보다 하루 짧습니다. 지금은 199일과 200일, 2027-03-15부터는 99일과 100일, 2029-03-15부터는 46일과 47일입니다. 일수를 셀 때는 "a day is measured as 86,400 seconds"이며, 더 나아간 하루의 일부도 하루 전체로 셉니다.

실무적으로는 갱신을 자동화해야 한다는 뜻입니다. 아직 해마다 CSR을 손으로 만들고 있다면 이제 ACME로 옮길 때입니다. ACME에서는 클라이언트가 요청을 대신 만들며, Baseline Requirements 자체는 "a certificate request in a form prescribed by the CA"만 요구하지만 ACME에서는 PKCS#10이 실제로 필수입니다.

인증서가 유효할 수 있는 기간CA/Browser Forum TLS BR 2.3.1 §6.3.2
  1. 2026년 3월 15일 이전오늘의 위치397일398일
  2. 2026년 3월 15일부터199일200일
  3. 2027년 3월 15일부터99일100일
  4. 2029년 3월 15일부터46일47일
  • 전체 일정은 2025년 4월 11일에 채택된 투표안 하나, SC-081v3에서 나왔습니다
  • 하루는 정확히 86,400초로 셉니다 더 나아간 하루의 일부도 하루 전체로 셉니다
  • 요청의 어떤 내용도 이를 바꾸지 못합니다
네 단계이며 각각 숫자가 둘입니다. 규칙이 권장하지 않는 값과 금지하는 값입니다. 날짜는 이미 정해져 있으며, 그래서 자동 갱신이 유일하게 현실적인 답입니다.

원본 ASN.1이 보여 주는 것

base64 아래의 CSR은 DER로 인코딩된 트리입니다. 이 디코더는 바이트 오프셋과 함께 트리를 그리고, 아는 모든 객체 식별자의 이름을 붙입니다. openssl asn1parse가 출력하는 내용과 같습니다.

이름이 친숙하지 않은 필드를 정직하게 보여 주는 방법입니다. 디코딩된 항목에서 원본 구조를 열면 CertificationRequestInfo, 주체의 상대 고유 이름(RDN)을 하나씩, SubjectPublicKeyInfo, attributes [0] 집합, 그리고 그 안에서 RFC 5280의 X.509 확장을 담은 extensionRequest 속성을 볼 수 있습니다. 객체 식별자는 1.2.840.113549.1.9.14이며, RFC 2986이 아니라 RFC 2985 §5.4.2에 정의되어 있습니다.

그곳에서 만날 수 있는 다른 속성은 challengePassword(1.2.840.113549.1.9.7)입니다. 나중에 인증서를 폐기할 때 쓰는 공유 비밀로 만들어졌고, SCEP 등록에서는 아직 쓰이지만 일반적인 웹 인증서 주문과는 관계가 없습니다. 이 페이지는 있으면 보여 줍니다. 보이지 않는 필드는 검사할 수 없기 때문입니다.

같은 요청을 바이트로RFC 2986 · RFC 2985 · RFC 5280
바이트 위치구조크기
0SEQUENCE749바이트
4SEQUENCE469바이트
8INTEGER03바이트
11SEQUENCE108바이트
13SET13바이트
15SEQUENCE11바이트
17OBJECT IDENTIFIERC2.5.4.65바이트
22PrintableStringUS4바이트
26SET21바이트
28SEQUENCE19바이트
30OBJECT IDENTIFIERST2.5.4.85바이트
35UTF8StringCalifornia12바이트
47SET24바이트
49SEQUENCE22바이트
51OBJECT IDENTIFIERL2.5.4.75바이트
56UTF8StringSan Francisco15바이트
71SET22바이트
73SEQUENCE20바이트
75OBJECT IDENTIFIERO2.5.4.105바이트
80UTF8StringExample Inc13바이트
93SET26바이트
95SEQUENCE24바이트
97OBJECT IDENTIFIERCN2.5.4.35바이트
102UTF8Stringwww.example.com17바이트
119SEQUENCE294바이트
123SEQUENCE15바이트
125OBJECT IDENTIFIERrsaEncryption1.2.840.113549.1.1.111바이트
136NULL2바이트
138BIT STRING2,160비트30 82 01 0a 02 82 01 01 00 c5 47 47 1d 26 1c bf275바이트
413[0]60바이트
415SEQUENCE58바이트
417OBJECT IDENTIFIERextensionRequest1.2.840.113549.1.9.1411바이트
428SET45바이트
430SEQUENCE43바이트
432SEQUENCE41바이트
434OBJECT IDENTIFIERSubject Alternative Name2.5.29.175바이트
439OCTET STRING32바이트30 1e 82 0f 77 77 77 2e 65 78 61 6d 70 6c 65 2e34바이트
473SEQUENCE15바이트
475OBJECT IDENTIFIERsha256WithRSAEncryption1.2.840.113549.1.1.1111바이트
486NULL2바이트
488BIT STRING2,048비트00 57 41 c5 09 98 14 78 8c ee c3 61 d4 c0 e0 2d261바이트
  • 다른 것을 담음
  • 값을 담음
  • 위치로 이름이 정해짐

  • 확장을 담는 속성

    1.2.840.113549.1.9.14요청 자체를 정의하는 문서와 다른 문서에 정의되어 있으며, 그래서 대체 이름이 주체 옆이 아니라 속성 안에 실려 갑니다

  • 만날 수 있는 다른 속성이 요청에는 없음

    1.2.840.113549.1.9.7나중에 인증서 폐기를 요청할 때 쓰려던 공유 비밀로, 장치가 네트워크에 스스로 등록할 때는 아직 쓰입니다
예시 요청의 모든 바이트와 각 객체 식별자의 이름입니다. 명령줄 디코더가 출력하는 내용을 출력하는 대신 그려서, 한 필드가 어디서 끝나고 다음 필드가 어디서 시작하는지 볼 수 있습니다.

CSR 디코더: 질문과 답변

CSR은 어떻게 디코딩하나요?

-----BEGIN CERTIFICATE REQUEST-----와 -----END CERTIFICATE REQUEST----- 줄을 포함한 요청 전체를 위의 입력란에 붙여 넣거나, 파일을 페이지에 놓으세요. 붙여 넣는 즉시 디코딩합니다. 주체, 공개 키, 모든 주체 대체 이름, 요청한 모든 확장, 지문이 나옵니다. base64 본문만, 16진수 덤프, 바이너리 DER 파일 업로드도 가능합니다.

이 CSR 디코더는 사용해도 안전한가요?

네, 이유는 두 가지입니다. 인증서 서명 요청에는 비밀이 없고 처음부터 인증 기관에 보내도록 만들어진 것이므로, 어디서 디코딩해도 해가 없습니다. 그리고 이 페이지는 브라우저에서 작업합니다. 요청은 페이지와 함께 내려받은 코드가 분석하며 어떤 서버로도 전송되지 않습니다. 개인 키를 실수로 붙여 넣으면 페이지가 알려 주고, 디코딩을 거부하며, 아무것도 보관하지 않습니다.

CSR이 유효한지 어떻게 확인하나요?

여기서 디코딩하고 판정을 읽으세요. 이 페이지는 요청 자체의 서명을 확인해 보낸 쪽이 짝이 되는 개인 키를 가졌음을 증명한 다음, 공인 인증 기관이 적용하는 규칙을 적용합니다. 인증할 수 없는 이름, 너무 넓은 와일드카드, 예약된 IP 주소, 너무 작거나 소인수분해할 수 있는 키, 폐지된 주체 필드, 오래된 서명 해시가 대상입니다. 각 항목은 CA가 거부할지(반드시 수정), 변경할지(변경 예정), 참고만 할지(참고) 알려 줍니다.

인증 기관이 CSR을 거부하는 이유는 무엇인가요?

흔한 원인은 server.local 같은 내부 이름이나 단일 레이블 호스트 이름, 호스트 이름의 밑줄, *.co.uk 같은 공개 접미사에 걸친 와일드카드, 대체 이름의 사설 IP 주소, 2048비트 미만의 RSA 키, 아직 SHA-1로 서명된 요청입니다. 위에서 요청을 디코딩하면 이 모두가 어긴 규칙과 함께 명확하게 표시됩니다.

개인 키가 CSR과 일치하는지 어떻게 알 수 있나요?

위의 키 또는 인증서 대조를 사용하세요. 요청 옆에 키를 추가하면 페이지가 키 파일 안의 공개 키를 요청 안의 공개 키와 브라우저에서 비교합니다. 직접 하려면 openssl req -in request.csr -pubkey -noout과 openssl pkey -in private.key -pubout이 일치할 때 같은 공개 키를 출력합니다. 키와 발급된 인증서 사이에도 같은 비교가 통합니다.

SSL 인증서도 디코딩할 수 있나요?

네. 인증서를 붙여 넣으면 인증서로 디코딩합니다. 발급자와 주체, 일련번호, 유효 기간, 모든 대체 이름, 키 용도와 확장 키 용도, 기관 키 식별자와 주체 키 식별자, OCSP와 CA 발급자 URL, 인증서 정책, 포함된 Certificate Transparency 타임스탬프가 나옵니다. 인증서와 그 요청을 함께 붙여 넣으면 같은 키를 쓰는지도 알려 줍니다.

인증 기관은 내 CSR에서 실제로 어떤 필드를 사용하나요?

확실한 것은 공개 키 하나입니다. DigiCert 문서에 따르면 나머지는 무시됩니다. OV나 EV 인증서에서는 조직과 국가를 넣기 전에 CA가 직접 검증해야 하며, 유효 기간은 항상 요청이 아니라 Baseline Requirements의 일정에서 나옵니다. 두 필드는 단순히 무시되는 정도가 아니라 공인 TLS 인증서에서 금지됩니다. OU와, 도메인 검증 인증서에서는 emailAddress입니다.

일반 이름은 아직도 중요한가요?

다른 값의 복사본으로서만 중요합니다. 브라우저는 2017년부터 호스트 이름 일치에 일반 이름을 무시하고 주체 대체 이름만 사용합니다. Baseline Requirements는 일반 이름을 권장하지 않음(NOT RECOMMENDED)으로 규정하고, 있다면 "MUST contain exactly one entry that is one of the values contained in the Certificate's subjectAltName extension"이라고 요구합니다. 대체 이름에 없는 일반 이름은 거부 사유이며, 이 페이지가 표시합니다.

여러 파일을 한 번에 디코딩할 수 있나요?

네. 요청, 그 인증서, 중간 인증서를 함께 붙여 넣으면 각 블록이 붙여 넣은 순서대로 자기 카드에 디코딩됩니다. 손상된 블록 하나가 나머지를 막지 않습니다. 붙여 넣은 내용 중에 개인 키가 있으면 그 사실을 알리고 건너뛰며 디코딩하지 않습니다. 블록은 최대 40개까지 디코딩하고, 그 이상은 조용히 버리지 않고 개수를 세어 알려 줍니다.

CSR의 challenge password란 무엇인가요?

RFC 2985의 선택 속성으로, 원래는 인증서 폐기를 요청할 때 제시하는 공유 비밀이었습니다. 장치가 요청할 자격이 있음을 증명하는 SCEP 등록에서는 아직 역할이 있습니다. 일반 웹 인증서 주문과는 관계가 없으며, 이를 보여 주는 도구가 드물기 때문에 이 페이지는 요청에 있으면 항상 표시합니다.

공인 인증서에 Ed25519 키를 쓸 수 있나요?

지금은 안 됩니다. Baseline Requirements는 RSA와 P-256, P-384, P-521 곡선을 허용한 뒤 "no other algorithms or key sizes are permitted"라고 규정하므로, 어떤 공인 인증 기관도 Ed25519 요청에는 발급하지 않습니다. SSH, 서명, 사설 CA에는 좋은 키이며, 이 디코더는 Ed25519와 Ed448 요청, 양자 내성 ML-DSA 키도 문제없이 읽습니다.

인증서는 이제 얼마나 오래 유효한가요?

지금 발급되는 공인 TLS 인증서는 200일을 넘을 수 없으며, 2026-03-15 이전의 398일에서 줄었습니다. CA/Browser Forum 투표안 SC-081v3에 따라 2027-03-15에 100일로, 2029-03-15에 47일로 줄어듭니다. CSR의 어떤 내용도 이에 영향을 주지 않으며, 유효 기간은 CA가 정합니다. 이 정도 기간이면 갱신을 자동화해야 하고, 실제로는 ACME를 뜻합니다.

부족한 점이 있습니까?기능 또는 새 도구 제안하기

관련 도구