도입
브라우저 자물쇠만으로는 서버가 어떤 인증서 체인을 제공하고 어떤 호스트 이름을 포함하는지 기록하기 어렵다. OpenSSL은 TLS 연결, 인증서 체인, 유효기간과 Subject Alternative Name을 텍스트로 확인할 수 있다.
OpenSSL 3.x 기준으로 공개 테스트 도메인을 읽기 전용으로 검사한다. 개인키 파일은 사용하거나 출력하지 않는다.
검사 항목
- SNI로 요청한 호스트와 반환 인증서의 SAN 일치
- leaf에서 중간 인증서로 이어지는 체인
Verify return codenotBefore와notAfter- 클라이언트 신뢰 저장소 차이
s_client 연결 성공과 애플리케이션의 호스트 이름 검증 성공은 같은 의미가 아니다. 호스트 검증 옵션을 별도로 사용해야 한다.
SNI와 호스트 검증을 포함해 접속하기
SNI를 포함해 연결하기
openssl version
openssl s_client \
-connect example.com:443 \
-servername example.com \
-showcerts \
-verify_hostname example.com < /dev/null
출력 마지막의 verify code와 인증서 수를 확인한다. 진단 대상이 CDN이나 로드밸런서라면 DNS가 반환한 여러 주소에서 결과가 같은지도 검사할 수 있다.
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null |
openssl x509 -noout -subject -issuer -dates -ext subjectAltName

SNI 누락 결과 비교
openssl s_client -connect example.com:443 < /dev/null 2>/dev/null |
openssl x509 -noout -subject -issuer -ext subjectAltName
같은 인증서가 나오면 그 결과를 그대로 기록하고 선택 이미지를 제거한다. 차이가 있다면 가상 호스트의 기본 인증서가 선택됐는지 확인한다.

운영 점검 기준
만료 임계치는 인증서 자동 갱신 주기보다 충분히 길게 잡고 외부에서 확인한다. 서버 파일의 인증서만 검사하면 실제 프록시나 CDN이 제공하는 인증서와 다를 수 있다.
검증 오류를 체인과 호스트로 나눠 읽기
Unable to get local issuer certificate
증상
서버 접속은 되지만 체인 검증 오류가 난다.
원인
중간 인증서 누락 또는 클라이언트 신뢰 저장소 문제다.
확인 방법
-showcerts로 제공 체인을 확인하고 다른 신뢰 저장소와 비교한다.
해결
서버에 올바른 full chain을 배포하거나 클라이언트 CA 구성을 바로잡는다.
예방
갱신 후 외부 TLS 검사를 자동화한다.
인증서는 유효하지만 호스트가 맞지 않는다
증상
날짜는 정상인데 hostname mismatch가 난다.
원인
SAN에 요청 호스트가 없거나 SNI가 잘못됐다.
확인 방법
-verify_hostname과 SAN 출력을 함께 본다.
해결
올바른 호스트가 포함된 인증서를 배포하고 SNI 라우팅을 점검한다.
예방
체인·기간·호스트 검증을 하나의 점검으로 묶는다.
TLS 배포 점검표
- 외부 주소에서 SNI를 포함해 연결했는가?
- SAN과 제공 체인이 검증되는가?
- 유효기간과 자동 갱신 시점을 확인했는가?
- CDN 또는 프록시가 실제 제공하는 인증서를 검사했는가?
참고 자료
한 줄 요약
TLS 점검은 SNI와 호스트 검증을 포함한 외부 연결에서 체인, SAN, 유효기간과 verify 결과를 함께 확인해야 한다.
댓글 0