SSL 인증서 디코더
PEM·Base64를 붙여넣거나 DER·PKCS #7 파일을 열어 SSL 인증서 내용을 확인합니다. SAN, 유효 기간, 공개 키, 확장, SCT를 보여 주고 중간 인증서 순서와 서명도 검사합니다.
- 브라우저에서 처리
- 데이터가 브라우저 밖으로 나가지 않습니다
- 무료 · 회원가입 불필요
WeChat으로 스캔하여 공유
예시·자세한 설명·자주 묻는 질문 실제 출력이 있는 예시, 다른 도구와의 차이, 자주 묻는 질문.
실제 예: www.kakao.com 인증서 체인
예시를 누르면 2026-10-01에 openssl s_client -showcerts로 www.kakao.com에서 받은 인증서 3개를 불러옵니다.
| # | 주체 CN | 역할 | 다음 인증서의 서명 |
|---|---|---|---|
| 1 | kakao.com | 서버 인증서 | 서명 검증됨 |
| 2 | Thawte TLS RSA CA G1 | 중간 CA | 서명 검증됨 |
| 3 | DigiCert Global Root G2 | 루트 CA (자체 서명) | 자체 서명 검증됨 |
카카오 서버는 루트 인증서까지 보냅니다. 도구는 “체인이 자체 서명 루트 인증서로 끝납니다”라고 알려 줍니다. 클라이언트는 루트를 이미 갖고 있으므로 보내지 않아도 되고(RFC 8446 §4.4.2), 보내도 오류는 아닙니다.
서버 인증서에서 볼 만한 값:
- 유효 기간
2026-09-01 00:00:00 UTC~2027-03-18 23:59:59 UTC, 길이 199일. 2026년 3월 15일부터 발급되는 공개 신뢰 TLS 인증서는 최대 200일입니다(CA/B 포럼 BR §6.3.2, SC-081 투표). 2027년 3월 15일부터는 100일, 2029년 3월 15일부터는 47일로 줄어듭니다. - SAN 2개.
www.kakao.com을 입력하면 SAN 항목과 일치한다고 나옵니다. - 인증서 투명성 SCT 3개와 각 로그 ID, 타임스탬프.
중간 인증서가 빠진 서버
같은 날 www.kisa.or.kr은 서버 인증서 1개만 보냈습니다. 이 인증서를 붙여넣으면 도구는 발급자 GeoTrust TLS RSA CA G1이 입력에 없다고 알리고, AIA에 적힌 http://cacerts.geotrust.com/GeoTrustTLSRSACAG1.crt를 보여 줍니다.
브라우저는 이 주소로 중간 인증서를 받아 와 화면이 정상으로 보이는 경우가 많습니다. 하지만 Java는 이 기능이 기본으로 꺼져 있고, Go의 TLS도 받아 오지 않습니다(golang/go#31773). API 서버나 앱에서만 연결 오류가 나면 먼저 중간 인증서 누락을 의심하세요. nginx는 서버 인증서 뒤에 중간 인증서를 이어 붙인 파일을 쓰도록 안내합니다(Configuring HTTPS servers).
체인을 거꾸로 붙여넣으면 “순서가 틀렸거나 다른 체인이 섞였습니다. 서버 인증서부터의 경로: #3 → #2 → #1.”처럼 올바른 순서를 알려 주고, 올바른 순서로 복사로 바로잡은 파일을 얻을 수 있습니다.
검사 항목
- 바깥 서명 알고리즘과 tbsCertificate 안의 알고리즘 일치(RFC 5280 §4.1.1.2), 일련번호가 양수이고 20옥텟 이하인지(§4.1.2.2), 시각에 초와
Z가 있는지(§4.1.2.5). - 인식할 수 없는 중요 확장, 중복 확장(§4.2).
- SAN이 없는 인증서: Chrome은 58 버전부터 CN으로 호스트 이름을 비교하지 않습니다.
- SHA-1·MD5 서명, 2048비트 미만 RSA 키, 발급자가 CA가 아니거나 keyCertSign이 없거나 경로 길이를 넘는 경우.
공개 키 길이는 키 자체에서 계산합니다(P-521은 521비트). 지문 카드에는 DER의 SHA-256·SHA-1·MD5와 공개 키(SPKI)의 SHA-256 Base64 값이 있습니다. RFC 7469의 pin-sha256 형식으로, Android 네트워크 보안 구성과 OkHttp 인증서 고정에 그대로 쓸 수 있습니다.
입력 형식
- PEM
CERTIFICATE, 예전 표기X509 CERTIFICATE, OpenSSL의TRUSTED CERTIFICATE(RFC 7468). 앞뒤 문장, CRLF, 여분의 공백은 무시합니다. - BEGIN / END 줄 없는 Base64.
- 바이너리 DER 파일과 PKCS #7(
.p7b). 불러오면 PEM으로 바꿔 입력란에 보여 줍니다. - CSR, 공개 키, CRL은 종류만 알려 주고 분석하지 않습니다. CSR은 CSR 디코더를 쓰세요.
오류는 위치를 알려 줍니다. 위 서버 인증서를 복사하다 Base64 한 줄이 빠지면 “0번째 바이트의 Certificate는 1618바이트가 필요하지만 1570바이트만 남았습니다”라고 나옵니다.
다른 도구와 비교
2026-10-01에 같은 인증서로 확인한 결과:
| 도구 | 분석 위치 | 인증서 4개 체인 | 확인한 점 |
|---|---|---|---|
| SecureSign 인증서 CRT 디코더 | 폼을 서버로 전송(/tools/X509Certificate2) | 첫 번째만 표시 | 22:49:11 UTC를 “오전 7:49:11”로 표시(시간대 표기 없이 한국 시간). 공개 키 길이 미표시 |
| SSL Shopper | 서버로 전송 | ”We were unable to decode this certificate” | 시각 없이 날짜만 표시 |
| 이 도구 | 페이지 안 | 4개 모두, 순서와 서명 검사 | — |
제한 사항
- 신뢰 저장소가 없고, OCSP / CRL 폐기 확인과 서버 연결도 하지 않습니다. 체인은
openssl s_client -connect 도메인:443 -showcerts로 받고, DNS는 DNS Lookup, 응답 헤더는 HTTP Header 분석기로 확인하세요. - 서명 검증은 Web Crypto로 합니다. RSA(PKCS #1 v1.5, PSS), P-256 / P-384 / P-521 ECDSA, 브라우저가 지원하면 Ed25519까지입니다. ML-DSA, Ed448, DSA, SM2는 분석하지만 “미검증”으로 표시합니다.
- 이름 제약은 표시만 하고 서버 인증서 이름에 적용하지 않습니다.
- 파일은 1MB까지, 한 번에 인증서 200개까지 처리합니다.
FAQ
인증서가 서버로 전송되나요?
아니요. 페이지 안의 JavaScript DER 파서가 분석하고, 지문과 서명 검증에는 브라우저의 Web Crypto를 씁니다. 페이지 자체는 다른 ZeroTool 페이지처럼 Google Analytics와 AdSense를 불러오지만, 붙여넣은 내용은 그쪽으로 가지 않습니다.
중간 인증서가 포함된 체인을 한 번에 붙여넣어도 되나요?
됩니다. 입력의 모든 인증서를 분석하고, 각 인증서 다음에 그 인증서를 발급한 인증서가 오는지, 다음 인증서의 공개 키로 서명이 검증되는지 확인합니다. 순서가 틀리면 올바른 순서로 복사할 수 있습니다.
파일에 개인 키도 들어 있으면 어떻게 되나요?
PRIVATE KEY, RSA PRIVATE KEY, EC PRIVATE KEY 같은 블록은 분석하지 않고 건너뛰며, 개인 키가 든 입력은 브라우저에 저장하지 않습니다. .pfx / .p12(PKCS #12) 파일은 열지 않습니다. openssl pkcs12 -nokeys로 인증서만 꺼내세요.
표시되는 시각은 한국 시간인가요?
아니요. 모든 시각은 UTC로 표시하고, 옆에 인증서 안의 원래 값(예: 270318235959Z)을 함께 보여 줍니다. 한국 시간은 9시간을 더하면 됩니다.
브라우저가 이 인증서를 신뢰하는지도 알 수 있나요?
알 수 없습니다. 신뢰 저장소가 없고 폐기 여부도 확인하지 않습니다. 붙여넣은 체인이 빠짐없고 순서가 맞으며 서명이 맞는지만 판단합니다. 신뢰 여부는 openssl verify나 운영체제 인증서 저장소로 확인하세요.