X.509 인증서 디코더 (SSL 인증서 분석)

PEM 형식의 SSL/TLS 인증서를 붙여넣기만 하면 발급자, 유효기간, SAN, 일련번호, 공개키 알고리즘, SHA-1/SHA-256 지문을 즉시 분석합니다. 자체 서명 인증서와 내부 CA 인증서도 오프라인으로 확인할 수 있는 무료 도구입니다.

X.509 인증서 디코더란

X.509 인증서 디코더는 PEM 형식의 SSL/TLS 인증서를 붙여넣기만 하면 Subject(주체), Issuer(발급자), 유효기간, SAN 항목, 일련번호, 공개키 알고리즘, 서명 알고리즘, 지문 등의 정보를 한눈에 보여주는 무료 도구입니다. ASN.1의 DER 이진 구조를 해석하는 작업은 서버 측에서 수행되므로, OpenSSL 명령줄 도구 없이도 누구나 인증서 내용을 간단히 확인할 수 있습니다.

실시간 SSL 검사 도구(공개 도메인에 직접 접속해 실제 TLS 핸드셰이크로 인증서를 가져오는 방식)와 달리, 이 도구는 붙여넣은 PEM 텍스트를 그대로 분석하는 방식입니다. 그래서 아직 운영 환경에 배포되지 않은 인증서, 사내 CA·자체 서명 인증서, 이미 다운로드해 둔 인증서 파일처럼 실시간 조회로는 확인할 수 없는 인증서도 분석할 수 있습니다.

X.509 인증서 디코더 사용 방법

  1. PEM 인증서 붙여넣기 "-----BEGIN CERTIFICATE-----"로 시작하는 텍스트를 입력란에 그대로 붙여넣습니다.
  2. 여러 인증서도 한 번에 붙여넣기 가능 서버 인증서와 중간 CA 인증서를 함께 붙여넣으면 블록별로 자동 감지됩니다.
  3. "분석하기" 버튼 클릭 감지된 인증서 개수를 확인한 후 버튼을 눌러 서버 측에서 분석합니다.
  4. 결과 확인하기 Subject, Issuer, 유효기간, SAN, 지문 등이 목록으로 표시됩니다.

더 잘 활용하기 위한 팁

  • 인증서 체인(서버 인증서+중간 CA 인증서)을 한꺼번에 붙여넣어도 블록별로 자동 분리되어 개별적으로 분석됩니다.
  • 발급 기관이 공개한 SHA-256 지문과 일치하는지 대조하면 인증서가 바뀌었거나 변조되지 않았는지 확인할 수 있습니다.
  • Subject와 Issuer가 완전히 동일한 인증서는 자체 서명 인증서이며, 결과 화면에 전용 배지로 표시됩니다.
  • 자신의 인증서를 붙여넣기 전에 "샘플 인증서 삽입" 버튼으로 출력 형식을 미리 확인해 두면 안심할 수 있습니다.
  • SAN(주체 대체 이름)에 필요한 도메인이 모두 포함되어 있는지, 운영 환경 전환 전에 반드시 확인하세요.

이런 상황에서 활용해 보세요

인증서 만료 원인 조사

브라우저에 "인증서가 만료되었습니다"라고 표시될 때, 실제 validTo 시각을 직접 확인할 수 있습니다.

운영 환경 전환 전 SAN 확인

다중 도메인 인증서를 전환하기 전에 필요한 모든 호스트 이름이 SAN에 포함되어 있는지 확인할 수 있습니다.

키 강도 감사

보안 검토 시 RSA 2048비트 이상인지, 어떤 EC 곡선을 사용하는지 등 공개키 알고리즘과 길이를 확인할 수 있습니다.

사내 CA·자체 서명 인증서 확인

외부에서 접근할 수 없는 사내 시스템의 인증서나 아직 정식 발급하지 않은 인증서 파일도 그대로 분석할 수 있습니다.

용어집

PEM
Base64로 인코딩한 DER 데이터를 "-----BEGIN CERTIFICATE-----" 등의 행으로 감싼 텍스트 형식입니다. 인증서 교환에 가장 흔히 사용됩니다.
X.509
공개키 인증서의 구조를 정의한 국제 표준 규격입니다. TLS/SSL뿐 아니라 S/MIME, 코드 서명에도 사용됩니다.
ASN.1 / DER
인증서 내부 구조를 엄밀하게 정의하는 이진 표현 규칙입니다. PEM은 이 DER 데이터를 단순히 Base64로 변환한 것입니다.
SAN(주체 대체 이름)
인증서가 유효한 호스트 이름이나 IP 주소를 추가로 나열하는 확장 필드입니다. 다중 도메인 인증서에서는 필수입니다.
지문
인증서 전체를 해시화한 값으로, 인증서가 바뀌었거나 변조되지 않았는지 대조할 때 사용합니다.
자체 서명 인증서
Issuer와 Subject가 동일한 인증서로, 제3자 인증 기관(CA)의 검증을 받지 않았습니다.

자주 묻는 질문

분석을 위해 서버로 한 번 전송되지만 저장되거나 영구적으로 기록되지 않습니다. 다만 공개하고 싶지 않은 민감한 정보가 포함된 인증서는 붙여넣지 않는 것이 좋습니다.

아니요. 이 도구는 "-----BEGIN CERTIFICATE-----"로 시작하는 공개 인증서만 지원합니다. 개인키는 어떤 온라인 도구에도 절대 붙여넣지 마세요.

BEGIN/END 행이 누락되었거나, Base64 내용이 손상되었거나, 인증서가 아닌 개인키나 CSR(인증서 서명 요청) 파일을 붙여넣은 경우 등이 주요 원인입니다.

기존 검사 도구는 도메인 이름을 지정해 실제 TLS 통신으로 인증서를 가져오지만, 이 도구는 임의의 PEM 텍스트를 직접 분석하므로 자체 서명 인증서나 사내 CA 인증서처럼 실시간 조회로는 확인할 수 없는 경우에도 대응할 수 있습니다.
툴군

여담 ― PEM은 왜 읽기 어려운 문자열인가

인증서 파일을 열어보면 "-----BEGIN CERTIFICATE-----"로 시작하는 읽기 어려운 문자열이 잔뜩 나열되어 당황했던 경험이 있는 분도 많을 것입니다. 이 형식은 PEM(Privacy-Enhanced Mail)이라고 불리며, 실제로는 ASN.1이라는 규격으로 이진 표현된 DER 형식 데이터를 이메일이나 텍스트 파일로도 안전하게 주고받을 수 있도록 Base64로 인코딩한 것입니다. 즉 PEM은 DER의 "겉옷"에 불과하며, 인증서의 실제 내용은 ASN.1의 TLV(태그·길이·값) 구조로 엄밀하게 정의되어 있습니다. 이 도구는 바로 이 DER 이진 데이터를 해석해 사람이 읽을 수 있는 형태로 변환해 줍니다.

X.509라는 규격 이름을 의외라고 생각하는 분도 있을 것입니다. 원래는 1988년 ITU-T(국제전기통신연합)가 X.500 디렉터리 서비스의 일부로 제정한 것으로, 인터넷이 보급되기 훨씬 이전의 이야기입니다. 이후 1999년 IETF가 인터넷용으로 RFC 2459로 재정의했고, 현재는 RFC 5280이 최신 규격입니다. 버전에는 v1, v2, v3가 있으며 SAN(주체 대체 이름) 같은 확장 필드는 v3부터 사용할 수 있게 되었습니다. 오늘날 발급되는 TLS 인증서는 거의 전부 v3이며, 이 도구도 v3의 확장 필드를 전제로 분석합니다.

인증서의 "지문"은 SHA-1과 SHA-256 두 종류가 나란히 표시되는 경우가 많습니다. SHA-1은 실제 충돌 공격 사례가 보고된 이후 서명 알고리즘으로는 더 이상 권장되지 않지만, 인증서 전체를 해시화해 고유하게 식별하는 용도로는 여전히 참조되는 경우가 있어 오래된 도구와의 호환성을 위해 이 도구도 두 값을 모두 표시합니다. 새로운 대조 작업에서는 SHA-256 값을 우선적으로 사용하는 것을 권장합니다.