TLS Certificate Checker

사이트의 TLS/SSL 인증서를 확인하세요: 주체/발급자, 유효 기간, SAN, 체인 완전성, 일반적인 HTTPS 설정 오류. 선택적으로 리디렉션을 따라 최종 목적지가 유효한 인증서를 가진 HTTPS인지 확인합니다. JSON/PDF 보고서를 내보낼 수 있습니다.

Loading…

소개 TLS 인증서 검사기

HTTPS가 작동하지 않으면 사용자에게 경고 메시지가 표시되고 봇이 사이트를 신뢰하지 않게 됩니다. 이 도구는 URL을 가져와 선택적으로 리디렉션을 따라 최종 HTTPS 엔드포인트를 보호하는 TLS 인증서를 검사합니다. 곧 만료되는 인증서, 불완전한 체인, 호스트명/SAN 불일치 및 브라우저 오류와 SEO/가용성 문제를 일으키는 다른 문제들을 발견하는 데 도움을 줍니다.

기능

  • 인증서 주체와 발급자 확인 (누구를 위한 것인지, 누가 발급했는지).
  • 날짜 검증: notBefore / notAfter, 그리고 임박한 만료에 대해 경고.
  • SAN(주체 대체 이름) 및 호스트명 범위 확인 (www vs apex, 서브도메인).
  • 인증서 체인 문제 감지 (누락된 중간 인증서 / 불완전한 체인).
  • 선택적 리디렉션 추적을 통해 최종 URL의 HTTPS 적용 여부 검증.
  • 일반적인 HTTPS 문제 식별 (잘못된 호스트, 잘못된 인증서, 혼합 리디렉션 흐름).
  • 인시던트 티켓을 위한 복사 가능한 결과 및 발견 사항.
  • 문서화 및 회귀 검사를 위한 JSON 및 PDF 보고서 다운로드.

🧭 사용 방법 for tls-certificate-checker

1

테스트할 URL 붙여넣기

대상 URL을 입력하세요. https://example.com을 붙여넣거나, 최종적으로 HTTPS로 업그레이드되는지 확인하려면 http://example.com도 입력할 수 있습니다.

2

실제 동작을 위해 "리디렉션 따라가기" 활성화

사용자와 크롤러가 실제로 도달하는 목적지(http→https, non-www→www)를 검증하려면 리디렉션 따라가기를 활성화 상태로 유지하세요.

3

검사 실행 및 요약 검토

주요 항목을 확인하세요: 유효 기간, 호스트명/SAN 일치 여부, 체인이 완전한지 여부.

4

발견 사항 검토 및 근본 원인 수정

경고(곧 만료, 불일치, 불완전한 체인)가 표시되면 TLS 종료 계층(CDN, 리버스 프록시, 로드 밸런서 또는 웹 서버)에서 수정하세요.

5

추적을 위해 JSON/PDF 내보내기

운영/SEO 티켓에 첨부하거나 이전/이후 스냅샷을 보관하기 위해 보고서를 다운로드하세요.

기술 사양

입력 및 작동

이 도구는 URL을 확인하고 해결된 HTTPS 엔드포인트에 대한 TLS 인증서를 검사합니다.

기능상세 내용
지원되는 URL 형식HTTP 또는 HTTPS URL (리디렉션 추적 활성화 가능).
리디렉션 처리선택 사항; 활성화 시 구성된 최대 리디렉션 횟수까지 추적합니다.
TLS 검사인증서 속성과 일반적인 잘못된 구성을 검사합니다.

기본값 및 제한

예측 가능한 동작을 위해 가져오기 및 안전 기본값이 조정되었습니다.

설정
리디렉션 추적활성화됨
최대 리디렉션 횟수10
시간 초과15000 ms
사용자 에이전트Encode64Bot/1.0 (+https://encode64.com)
사설 네트워크허용되지 않음

검사 항목

검사는 실제 운영에서 가장 자주 발생하는 문제(만료, 호스트명 불일치(SAN 범위), 체인 완전성)를 중심으로 설계되었습니다. 리디렉션 추적은 HTTPS가 최종 표준 호스트에서만 유효한 경우를 포착하는 데 도움이 됩니다.

유효한 인증서는 강력한 보안에 필요하지만 충분하지는 않습니다. 강화된 배포를 위해 HSTS 및 보안 헤더 감사와 함께 사용하세요.

명령줄

OpenSSL과 curl을 사용하여 터미널에서 인증서 세부 정보를 확인하고 도구가 보고하는 내용과 비교하세요.

macOS / Linux

호스트에 대한 인증서 체인(SNI) 표시

echo | openssl s_client -servername example.com -connect example.com:443 -showcerts 2>/dev/null

제공된 리프 인증서와 중간 체인을 검사하는 데 유용합니다.

만료 날짜 빠르게 추출

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

notBefore / notAfter를 출력합니다.

SAN 목록 표시

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

인증서가 포함하는 호스트명을 보여줍니다.

HTTP에서 HTTPS로의 리디렉션 확인

curl -I http://example.com

Location 헤더와 최종 스킴을 확인합니다.

리디렉션을 추적하고 최종 URL 표시

curl -IL http://example.com | sed -n '1,120p'

리디렉션 체인과 비정식 엔드포인트를 감지하는 데 도움을 줍니다.

가상 호스팅 서버/CDN에서 openssl s_client를 사용할 때는 항상 -servername 옵션을 사용하세요. SNI 없이는 잘못된 인증서를 받을 수 있습니다.

사용 사례

인증서 만료로 인한 장애 방지

만료가 임박한 인증서를 식별하여 사용자와 봇이 브라우저 오류를 경험하기 전에 갱신할 수 있습니다.

  • 주간 인증서 상태 점검
  • DNS 또는 CDN 변경 후 도메인 감사

불완전한 인증서 체인 문제 해결

오래된 클라이언트와 일부 크롤러를 중단시키는 누락된 중간 인증서(사용자 정의 서버 설정에서 흔함)를 감지합니다.

  • 잘못 구성된 Nginx/Apache 체인 번들
  • 중간 인증서가 누락된 로드 밸런서

호스트명/SAN 불일치 디버깅 (www vs apex)

인증서가 www/비-www 및 서브도메인을 포함하여 사용자가 접근하는 정확한 호스트를 포함하는지 확인합니다.

  • Apex 도메인은 작동하지만 www는 중단됨
  • SAN 목록에서 누락된 API 서브도메인

리디렉션을 통한 HTTPS 적용 확인

http URL이 유효한 인증서를 가진 정식 https 엔드포인트로 리디렉션되는지 확인합니다.

  • http→https 301 리디렉션
  • 비-www→www 정식화

❓ Frequently Asked Questions

HTTPS가 활성화되어 있어도 브라우저가 "신뢰할 수 없는 인증서"라고 표시하는 이유는 무엇인가요?

일반적인 원인은 만료된 인증서, 불완전한 체인(중간 인증서 누락), 호스트명 불일치(SAN에 호스트가 포함되지 않음), 또는 SNI/가상 호스팅 구성 오류로 인해 잘못된 인증서를 제공하는 경우입니다.

SAN이란 무엇이며 왜 중요한가요?

SAN(주체 대체 이름)은 인증서가 유효한 호스트명입니다. 사이트가 example.com과 www.example.com 모두를 통해 접근된다면, 인증서는 둘 다 포함해야 합니다(또는 포함된 호스트로 일관되게 리디렉션해야 합니다).

http가 https로 리디렉션되는 것이 괜찮나요?

네—그것이 권장됩니다. 최종 HTTPS 목적지가 유효한 인증서를 제공하고 리디렉션 체인이 짧고 일관된지(정식 리디렉션에는 301을 선호) 확인하기만 하면 됩니다.

이 도구는 TLS 버전/암호를 확인하나요?

이 도구는 인증서 검사와 일반적인 구성 오류에 중점을 둡니다. 프로토콜/암호 강화(TLS 1.2/1.3, 약한 암호)를 위해서는 전용 TLS 구성 스캐너를 사용하세요.

리프, 중간, 루트 인증서의 차이는 무엇인가요?

리프 인증서는 사이트의 인증서입니다. 중간 인증서는 이를 신뢰할 수 있는 루트 CA에 연결합니다. 브라우저는 루트를 신뢰하므로, 중간 인증서가 누락되면 유효한 신뢰 체인을 구축하지 못할 수 있습니다.

Pro Tips

Best Practice

가능한 한 인증서를 일찍 갱신하고 갱신을 자동화(ACME)하세요.

Best Practice

SAN이 제공하는 모든 공개 호스트명(www, 최상위 도메인, API 서브도메인)을 포함하도록 하거나, 리디렉션을 통해 단일 표준 호스트를 적용하세요.

Best Practice

항상 전체 체인(리프 + 중간 인증서)을 제공하세요. 마이그레이션 후 불완전한 체인 번들로 인한 장애가 많습니다.

Best Practice

리디렉션을 활성화할 경우 최소화하세요: 표준 https URL로의 한 단계 이동이 이상적입니다.

Best Practice

유효한 TLS와 HSTS 및 보안 헤더를 함께 사용하여 현실에서 더 강력한 보호를 제공하세요.

Additional Resources

Other Tools