SSL 인증서 디코더 및 X.509 뷰어

X.509 / SSL 인증서를 읽는 온라인 도구입니다. 주체, 발급자, 유효 기간, Subject Alternative Names, 키 사용 용도, 확장, Certificate Transparency 증명까지 모든 필드를 해석한 다음, 그중 무엇이 문제인지 설명합니다. PEM, DER, base64, 16진수, 체인 전체, 서명 요청을 모두 받아들이며 무엇을 붙여 넣었는지 스스로 판별합니다.

사용법

붙여 넣거나 끌어다 놓기

인증서 텍스트를 붙여 넣거나 .crt/.cer/.der/.pem 파일을 영역에 끌어다 놓거나 버튼으로 고르세요. 여러 파일을 한 번에 넣으면 하나의 체인으로 읽습니다.

호스트 이름 추가

선택 사항입니다. 인증서가 담당해야 할 도메인을 입력하면 그 이름이 실제로 포함되는지 확인해 줍니다.

먼저 판정을 읽으세요

문제가 세부 내용보다 앞에, 심각한 순서대로 나옵니다. 통과한 검사는 접혀 있어 건강한 인증서는 «문제 없음»으로 읽힙니다.

그다음 필드를 살피세요

판정 아래에 모든 것이 펼쳐집니다: 이름, 주체, 발급자, 키, 지문, 그리고 16진 덤프가 아니라 해석된 각 확장.

인증서를 붙여 넣고 무엇을 포함하는지, 언제 만료되는지, 무엇이 깨질지 정확히 확인하세요

인증서, 체인 또는 CSR

위에 붙여 넣거나 이 영역에 파일을 끌어다 놓거나

또는 사이트에서 인증서를 바로 가져오기

확인할 호스트 이름(선택)

브라우저가 실제로 쓰는 규칙 그대로 확인합니다: SAN만 보고, 와일드카드는 레이블 한 칸까지만.

기능

나열이 아니라 설명

어떤 뷰어든 «Signature Algorithm: sha1WithRSA»는 찍어 줍니다. 이 도구는 브라우저가 2017년부터 SHA-1을 거부한다는 사실과 대신 무엇을 해야 하는지 알려 줍니다. 만료, 키 강도, 이름, 제약, CA 위생까지 마흔 가지 남짓의 검사가 있습니다.

실제로 가지고 있는 형태를 읽습니다

PEM, 날것의 DER, 헤더 없는 base64, 16진 덤프, 쿠버네티스 시크릿(PEM의 base64), \n 이 문자 그대로 들어간 JSON 문자열, 들여쓴 YAML 블록. 어떻게 읽었는지도 알려 주므로 뜻밖의 결과가 스스로 설명됩니다.

브라우저 규칙에 따른 이름 확인

호스트 이름을 넣으면 브라우저가 실제로 적용하는 규칙이 그대로 적용됩니다: SAN만 보고(Chrome은 58부터 Common Name을 무시합니다), 와일드카드는 정확히 레이블 하나만 덮습니다.

체인 전체를 한 번에

fullchain 파일을 붙여 넣으면 인증서를 정렬하고, 모든 서명을 검증하며, 최종·중간·루트를 표시하고, 빠진 것이 있으면 그 발급자를 알려 줍니다.

Certificate Transparency 해석

SCT 증명은 ASN.1이 아니라 TLS 구조여서 다른 디코더는 16진 덩어리로 보여 줍니다. 여기서는 로그 식별자와 타임스탬프가 그대로 보입니다.

갱신을 넘겨 살아남는 지문

SHA-256·SHA-1 지문과 함께 공개 키 핀(pin-sha256)을 계산합니다. 키를 그대로 두고 재발급하면 값이 바뀌지 않으므로 피닝과 HPKP식 점검에 필요한 값입니다.

자주 묻는 질문

Common Name에 도메인이 제대로 있는데 왜 이름이 포함되지 않았다고 하나요?

브라우저가 Common Name을 더는 읽지 않기 때문입니다. Chrome이 58(2017)에서 그 대체 경로를 없앴고 나머지도 뒤따랐습니다. 오늘날 참조되는 것은 Subject Alternative Name 확장뿐입니다. 도메인이 CN에만 있는 인증서는 CN이 아무리 정확해 보여도 NET::ERR_CERT_COMMON_NAME_INVALID로 거부됩니다. 해결책은 이름들을 SAN 확장에 넣어 재발급하는 것입니다.

왜 크롬에서는 되는데 안드로이드나 curl에서는 실패하나요?

거의 항상 중간 인증서가 빠져 있기 때문입니다. 데스크톱 브라우저는 이 문제를 가려 줍니다. 다른 사이트에서 본 중간 인증서를 캐시해 두고, 빠진 것은 AIA로 내려받을 수도 있습니다. 안드로이드, curl, 자바, 대부분의 API 클라이언트는 둘 다 하지 않으므로 신뢰 루트에 닿지 못하는 체인을 보게 됩니다. 전체 체인을 여기에 붙여 넣어 보세요. 체인 항목에서 중간 인증서가 없다고 하면 그것이 원인입니다.

어떤 형식을 붙여 넣을 수 있나요?

PEM(-----BEGIN CERTIFICATE----- 형태), 날것의 DER 바이너리 파일, 헤더 없는 base64, 16진 덤프, 그리고 인증서가 흔히 망가진 채 도착하는 여러 형태: 쿠버네티스 시크릿에서 나온 base64로 감싼 PEM, \n 이 문자 그대로 들어간 JSON·Terraform 문자열, 들여쓴 YAML 블록. 어떤 형태로 인식했는지 도구가 알려 줍니다.

서명 요청이나 개인 키도 읽을 수 있나요?

CSR은 읽습니다. 해석은 물론 자체 서명까지 검증하는데, 대부분의 CSR 디코더는 이 단계를 건너뜁니다. 개인 키는 인식하고 무엇인지 알려 주지만, 이 도구는 알맞은 곳으로 안내합니다. 키와 인증서 대조 도구, 또는 형식 변환기입니다.

공개 키 핀이 무엇이고 언제 필요한가요?

인증서 전체가 아니라 공개 키의 SHA-256 해시입니다. 키만 대상으로 하므로 같은 키로 갱신하면 값이 그대로입니다. 그래서 피닝, Expect-CT식 모니터링, 갱신이 정말 예전 키를 다시 썼는지 확인하는 데 쓸 수 있습니다. 보통의 SHA-256 지문은 재발급할 때마다 바뀝니다.

몇 년짜리 인증서에 왜 경고가 뜨나요?

공개 신뢰 인증서에는 브라우저가 강제하는 최대 유효 기간이 있고 계속 줄고 있습니다. 825일이었다가 2020년 9월부터 398일이 되었고, CA/Browser Forum이 추가 단축을 예정해 두었습니다. 발급 시점의 한도보다 길게 발급된 공개 인증서는 그대로 거부됩니다. 사설·내부 CA에는 이 한도가 적용되지 않으며, 도구는 인증서가 공개 발급된 것으로 보일 때만 이 문제를 제기합니다.

이 도구를 어떻게 평가하시겠습니까?

평가해 주셔서 감사합니다!

평가 변경

댓글을 남기시겠습니까?

더 공유하고 싶으신가요? 댓글을 남겨주세요!

감사합니다! 검토 후 댓글이 표시됩니다.

누구를 위한 도구인가요?

게시일 04 8월 2026 업데이트 05 8월 2026 제작자: 수장