인증서 파서

X.509 인증서는 TLS/SSL에서 사용되는 공개 키 인증서의 표준 형식입니다. 이 도구는 PEM 인코딩된 인증서를 파싱하여 주체, 발급자, 유효 기간, 공개 키 세부 정보 및 확장을 표시합니다. HTTPS 연결 문제 디버깅에 필수적입니다.

사양

주요 사용 사례

SSL/TLS 연결 오류 디버깅 ("certificate has expired")
인증서가 올바른 도메인 이름을 포함하는지 확인
갱신 계획을 위한 인증서 만료일 확인
체인의 중간 및 루트 인증서 검사
인증서 속성이 규정 요구사항을 충족하는지 확인

기능

PEM 인코딩된 인증서 파싱 (-----BEGIN CERTIFICATE-----)
주체 및 발급자 고유 이름 표시
유효 기간 표시 (Not Before / Not After)
공개 키 알고리즘 및 크기 추출
주체 대체 이름(SAN) 표시
인증서 확장 표시 (Key Usage, Extended Key Usage, Basic Constraints)
기관/주체 키 식별자 표시
CRL 배포 지점 및 기관 정보 액세스 URL

예제

자체 서명 인증서

사용해 보기 →

주체 대체 이름을 포함하는 example.com용 X.509 인증서.

개인 키

사용해 보기 →

PKCS#8 형식의 대응하는 RSA 개인 키.

팁

브라우저에서 인증서 내보내기: 자물쇠 클릭 > 인증서 > 세부 정보 > 내보내기.
사이트 인증서 가져오기: openssl s_client -connect example.com:443
SAN(주체 대체 이름)은 모든 유효한 도메인 이름을 나열합니다.
루트 인증서는 자체 서명됩니다 (발급자 = 주체).
인증서 체인 확인: openssl verify -CAfile ca.pem cert.pem

이해하기 인증서 파서

X.509 인증서는 인터넷 신뢰의 기반으로, HTTPS 연결을 위한 TLS/SSL 암호화, 코드 서명, 이메일 보안(S/MIME), VPN 인증을 가능하게 합니다. 인증서는 공개 키를 신원(도메인 이름, 조직 또는 개인)에 바인딩하며, 인증 기관(CA)이 인증서에 디지털 서명하여 이 바인딩을 보증합니다.

인증서는 일반적으로 PEM 형식으로 저장됩니다. -----BEGIN CERTIFICATE----- 와 -----END CERTIFICATE----- 마커 사이에 Base64로 인코딩된 DER 데이터입니다. 인증서에는 주체(인증서가 식별하는 대상), 발급자(서명한 주체), 유효 기간(Not Before 및 Not After 날짜), 주체의 공개 키, 사용을 제어하는 확장이 포함됩니다. 주체 대체 이름(SAN) 확장은 인증서가 포함하는 모든 도메인 이름을 나열합니다.

인증서 체인은 하나 이상의 중간 CA를 통해 최종 엔터티 인증서를 신뢰할 수 있는 루트 CA에 연결하여 신뢰를 구축합니다. 브라우저가 웹사이트에 연결할 때, 체인을 검증합니다: 서버의 인증서가 중간 CA에 의해 서명되었고, 중간 CA는 브라우저가 신뢰하는 루트 CA에 의해 서명되었습니다. 중간 인증서가 누락되거나 알 수 없는 루트인 경우 익숙한 "연결이 비공개가 아닙니다" 오류가 발생합니다.

인증서 관리는 장애의 흔한 원인입니다. 만료된 인증서는 즉시 서비스 중단을 야기합니다. 도메인 이름 불일치는 브라우저 경고를 트리거합니다. 중간 인증서 누락은 일부 브라우저(캐시하거나 가져올 수 있음)에서는 작동하지만 다른 브라우저와 API 클라이언트에서는 실패합니다. Let's Encrypt와 certbot 같은 도구로 인증서 만료를 모니터링하고 갱신을 자동화하는 것이 안정적인 운영에 필수적입니다.

인증서 만료일을 확인하려면 PEM 내용을 이 도구에 붙여넣고 Not After 날짜를 확인하세요. 명령줄에서는 로컬 파일의 경우 openssl x509 -enddate -noout -in cert.pem을, 원격 서버의 경우 openssl s_client -connect example.com:443을 openssl x509 -noout -enddate로 파이프하세요. certbot, cert-manager 또는 전용 모니터링 서비스를 통한 자동화된 모니터링은 장애를 방지하기 위해 만료 전에 알림을 보낼 수 있습니다.

루트 인증서는 자체 서명(발급자가 주체와 동일)되며, 브라우저와 운영 체제에 신뢰 앵커로 사전 설치됩니다. 중간 인증서는 루트 CA에 의해 서명되며 최종 엔터티 인증서에 서명하는 데 사용됩니다. 이 신뢰 체인은 루트 키를 보호합니다. 중간 인증서가 손상되면 루트가 아닌 해당 중간 인증서만 폐기합니다. 서버는 전체 체인(최종 엔터티와 모든 중간 인증서)을 보내야 하지만 루트 인증서 자체는 포함하지 않아야 합니다.

주체 대체 이름(SAN)은 인증서가 유효한 모든 도메인 이름과 IP 주소를 나열합니다. 단일 인증서로 SAN을 사용하여 example.com, www.example.com, api.example.com 등 여러 도메인을 보호할 수 있습니다. 최신 브라우저는 도메인 검증에 일반 이름(CN) 필드 대신 SAN을 사용합니다. 와일드카드 인증서(*.example.com)는 한 수준의 하위 도메인을 포함하지만 최상위 도메인 자체는 포함하지 않습니다.

브라우저에서는 작동하지만 API 클라이언트에서 실패하는 인증서는 불완전한 인증서 체인으로 인한 흔한 문제입니다. 브라우저는 더 관대합니다. 일부는 AIA(기관 정보 액세스) 가져오기를 통해 누락된 중간 인증서를 자동으로 가져오거나 이전에 캐시한 중간 인증서를 사용합니다. curl, Node.js, Python의 requests 라이브러리 같은 API 클라이언트는 일반적으로 서버가 완전한 체인을 보내야 합니다. 서버가 최종 엔터티 인증서와 모든 중간 인증서를 보내도록 구성하고, curl -v 또는 openssl s_client로 체인이 완전한지 테스트하세요.

← 전체 도구로 돌아가기