인증서, CSR 또는 키
X.509 인증서, 인증서 서명 요청(CSR), 키 또는 PEM 형식의 전체 체인을 붙여넣거나 .crt, .cer, .der, .p7b, .pfx, .p12 파일을 불러오세요. 주체, SAN, 유효 기간, 확장, 지문은 물론 체인이 올바른 순서로 서명되어 있는지, 개인 키가 인증서와 일치하는지 확인할 수 있습니다. 어떤 데이터도 브라우저 밖으로 전송되지 않습니다.
여러 블록(인증서, 중간 인증서, 키)을 함께 붙여넣거나 파일을 여기로 끌어다 놓을 수 있습니다

작동 방식

X.509 인증서는 공개 키를 도메인, 개인, 조직과 같은 이름에 연결하는 서명된 문서입니다. 서버 간이나 파일로 전달되는 것은 바이너리 형식(DER)이고, 복사해서 붙여넣는 것은 동일한 구조를 BEGIN CERTIFICATE 줄과 END CERTIFICATE 줄 사이에 Base64로 담은 PEM 형식입니다. 그 안에는 주체, 발급자, 유효 기간, 공개 키, 그리고 용도와 해지 여부를 확인할 위치를 알려 주는 확장이 들어 있습니다.

이 도구는 인증서, PKCS#10 인증서 서명 요청(CSR), PKCS#8·PKCS#1·SEC1 개인 키, 공개 키, PKCS#7 패키지(.p7b), PKCS#12 파일(.pfx, .p12)을 인식합니다. 여러 블록을 함께 붙여넣으면 최종 인증서부터 루트까지 체인을 정렬하고, 각 서명을 발급자의 키로 검증하며, 개인 키를 각 인증서 및 CSR과 비교해 어느 것이 어느 것에 해당하는지 알려 줍니다.

또한 형식 간 변환, 인증서와 키로 IIS와 Azure에서 요구하는 .pfx 만들기, 새 CSR과 개인 키 또는 테스트용 자체 서명 인증서 생성도 지원합니다. 모든 처리는 브라우저의 암호화 API로 이루어지므로 인증서와 키가 서버로 전송되지 않습니다.

예시

ISRG Root X1 · SHA-25696:BC:EC:06:26:49:76:F3:74:60:77:9A:CF:28:C5:A7:CF:E8:A3:C0:AA:E1:1A:8F:FC:EE:05:C0:BD:DF:08:C6Let's Encrypt 루트 인증서의 SHA-256 지문입니다. 인증 기관과 신뢰 저장소가 공개하는 값으로, 가지고 있는 파일의 지문과 일치하면 바로 그 인증서입니다.
ISRG Root X1 · pin SPKIC5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=공개 키의 SHA-256을 Base64로 표현한 값입니다. Android 네트워크 보안 구성의 pin-sha256이나 앱의 certificate pinning에 쓰이는 값이며, 키를 재사용하면 인증서를 갱신해도 바뀌지 않습니다.
root.crt + intermediate.crt + server.crtserver.crt + intermediate.crt + root.crtnginx와 HAProxy는 파일의 첫 번째 인증서를 서버 인증서로 사용합니다. 체인 순서가 뒤바뀌면 nginx는 개인 키를 루트 인증서와 비교하게 되어 key values mismatch 오류로 실패합니다.
openssl pkcs12 -in viejo.pfx -legacy -nodes | openssl pkcs12 -export -out nuevo.pfxPBES2 · AES-256-CBC · MAC SHA-256오래된 Windows나 OpenSSL 1.x에서 내보낸 .pfx는 브라우저가 구현하지 않는 RC2와 3DES로 암호화되어 있습니다. 이 명령은 OpenSSL 3의 기본 형식인 AES로 다시 암호화합니다.

활용 사례

  • 인증 기관에서 받은 인증서를 설치하기 전에 모든 도메인(SAN)이 포함되어 있고 만료일이 예상과 같은지 확인합니다.
  • 서버에 남아 있는 개인 키 중 어느 것이 각 인증서에 해당하는지 OpenSSL로 모듈러스를 비교하지 않고도 알아냅니다.
  • 클라이언트가 사이트를 신뢰하지 않는 원인을 찾습니다. 누락된 중간 인증서, 순서가 뒤섞인 체인, SHA-1로 서명된 인증서 등이 원인일 수 있습니다.
  • 인증서 구매나 갱신에 필요한 CSR을 내 컴퓨터에서 만든 키로 생성하고, 서버에서 직접 하고 싶을 때를 위해 동일한 OpenSSL 명령도 확인합니다.
  • .crt와 .key를 IIS, Azure App Service 또는 Java 키 저장소용 .pfx로 변환하거나, .pfx에서 nginx용 인증서와 키를 추출합니다.
  • 모바일 앱에서 certificate pinning을 설정하거나 클라이언트 인증서를 검증하기 위해 인증서의 지문 또는 SPKI 핀을 확인합니다.

자주 묻는 질문

여기에 개인 키를 붙여넣어도 안전한가요?

키는 브라우저 안에서 Web Crypto API로 처리되며 어떤 서버로도 전송되지 않습니다. 개발자 도구의 네트워크 탭에서 직접 확인할 수 있습니다. 그래도 운영 환경의 키는 모두 비밀 정보로 취급하는 것이 좋습니다. 신뢰할 수 있는 도구에만 붙여넣고 작업이 끝나면 탭을 닫으세요.

PEM, DER, CRT, CER, P7B, PFX의 차이점은 무엇인가요?

DER은 바이너리 형식의 인증서이고, PEM은 같은 바이너리를 BEGIN 줄과 END 줄 사이에 Base64로 담은 것입니다. .crt와 .cer 확장자는 형식을 나타내지 않으며 두 형식 중 어느 것이든 담을 수 있습니다. .p7b는 여러 인증서를 담고 키는 포함하지 않는 PKCS#7 패키지입니다. .pfx 또는 .p12는 PKCS#12로, 인증서, 중간 인증서, 개인 키를 함께 비밀번호로 암호화하여 저장합니다.

서버에 중간 인증서가 빠져 있는지 어떻게 알 수 있나요?

서버에 설정된 내용을 붙여넣으세요. 체인이 자체 서명이 아닌 인증서로 끝나면 연결 고리 하나가 빠진 것입니다. 해당 인증서의 Authority Information Access 확장에는 보통 CA Issuers 항목에 발급자를 다운로드할 주소가 들어 있습니다. 데스크톱 브라우저는 때때로 이를 자동으로 가져오지만 Android, curl, 대부분의 라이브러리는 그렇지 않기 때문에 일부 클라이언트에서만 오류가 발생합니다.

공개 TLS 인증서의 유효 기간은 최대 얼마인가요?

2020년 9월부터 브라우저는 398일을 초과하는 인증서를 거부합니다. CA/Browser Forum은 2025년에 최대 기간을 단계적으로 줄이는 안을 승인했습니다. 2026년 3월 15일부터 발급되는 인증서는 200일, 2027년 3월부터는 100일, 2029년 3월부터는 47일입니다. 따라서 ACME로 갱신을 자동화하는 것이 좋습니다. 기업 내부 CA에는 이 제한이 없습니다.

CSR에는 RSA와 ECDSA 중 무엇을 써야 하나요?

ECDSA P-256은 훨씬 작은 키와 서명으로 3072비트 RSA에 필적하는 보안을 제공하며, 서버의 핸드셰이크도 더 빠릅니다. 현재의 모든 브라우저와 시스템에서 지원됩니다. 매우 오래된 클라이언트, 임베디드 장비 또는 RSA만 허용하는 시스템이 있다면 RSA 2048이 여전히 안전한 선택입니다.

일반 이름(CN)에 도메인만 넣으면 충분한가요?

아니요. 2017년 Chrome 58부터 브라우저는 주체 대체 이름(SAN)만 확인하고 CN은 무시합니다. CN에 넣은 도메인을 포함해 인증서를 사용할 모든 도메인이 SAN 목록에 있어야 합니다. *.example.com 같은 와일드카드는 한 단계만 포함하므로 www.example.com에는 쓸 수 있지만 example.com이나 a.b.example.com에는 쓸 수 없습니다.

관련 항목