인증서 파일 교체 뒤 실제 HTTPS 응답 확인하기

인증서 파일을 바꿨다는 기록은 모든 HTTPS 종단이 새 인증서를 제공한다는 증명이 아닙니다. SNI와 연결 대상별로 실제 응답의 인증서 이름·지문·유효기간·체인을 확인해야 합니다.

OpenSSL s_client -showcerts는 서버가 보낸 인증서 목록을 보여 주지만 검증된 체인이라는 뜻은 아닙니다. 이름·신뢰 검증이 성공했는지 별도 확인하고, OpenSSL master 문서의 옵션을 설치된 버전에 일반화하지 않습니다.

파일이 바뀐 것과 외부 응답이 바뀐 것은 다릅니다

TLS 종료 지점은 웹 서버, 로드밸런서, ingress 또는 중간 프록시일 수 있습니다. 인증서 파일을 특정 호스트에 복사해도 해당 listener가 새 파일을 다시 읽었는지, 트래픽이 그 호스트에 도착하는지, 같은 이름의 다른 종단이 있는지는 자동으로 확인되지 않습니다. NGINX 공식 HTTPS 문서는 certificate와 private key 설정, chain bundle 순서, 이름 기반 server와 SNI의 관계를 설명합니다.

OpenSSL s_client 문서에서 -servername은 ClientHello의 SNI 이름을 지정합니다. -showcerts는 서버가 전송한 목록을 보여 주는 옵션이며 신뢰 검증된 인증서 체인이 아닙니다. 문서는 master 버전이라 실제 설치본의 도움말과 버전을 대조해야 합니다. 또한 s_client는 검증 오류가 있어도 계속 연결할 수 있는 진단 도구이므로 화면에 인증서가 출력됐다는 사실만을 성공 판정으로 쓰지 않습니다.

두 종단의 가상 응답을 비교합니다

두 endpoint가 서로 다른 지문을 반환하면 한 노드의 성공을 전체 배포 완료로 확대하지 않습니다. DNS나 로드밸런서 뒤에 여러 종단이 있으면 동일한 이름이 요청을 다른 listener로 보낼 수 있으므로, 승인된 주소 목록을 하나씩 확인해야 합니다. 종단 B에서는 구 인증서가 제공되고 중간 체인도 전달되지 않았으므로, 해당 listener가 다른 설정을 사용하는지, 인증서 bundle을 재적재했는지 확인합니다. 반대로 인증서가 한 장만 보여도 브라우저에 저장된 중간 인증서 때문에 일부 클라이언트에서 성공할 수 있습니다. 제공 목록과 클라이언트의 신뢰 체인 검증 결과는 서로 다른 관측입니다.

SNI와 endpoint별로 나눠 확인합니다

1. 승인된 endpoint 목록, IP·포트·DNS 이름, TLS 종료 위치와 SNI 이름을 준비합니다.
2. 각 주소에 같은 SNI 이름을 보내 같은 이름 기반 HTTPS virtual host가 선택되도록 합니다.
3. 응답 leaf의 SAN, subject, serial·지문, notBefore·notAfter가 교체 목표와 일치하는지 비교합니다.
4. 서버가 보낸 intermediate 목록을 확인하고 신뢰 저장소를 사용한 chain 및 hostname 검증 결과를 별도로 기록합니다.
5. 오래된 인증서를 제공한 종단에서는 설정 경로, process reload·listener 상태, 배포 대상과 트래픽 분산을 운영 담당자가 확인합니다.
6. 모든 승인된 종단이 확인되기 전에는 부분 성공을 전체 완료라고 보고하지 않습니다.

체인 출력과 신뢰 검증을 혼동하지 않습니다

서버가 인증서 목록을 전달했다는 뜻은 해당 이름과 날짜가 유효하거나 브라우저가 신뢰한다는 뜻이 아닙니다. 호스트명 불일치, 만료, 신뢰 anchor 누락, 폐기 상태 확인은 별도 기준으로 판단합니다. 점검 결과에는 SNI·연결 주소·검증 옵션과 신뢰 저장소가 무엇인지 남기고, 시험하지 않은 종단·클라이언트는 미확인으로 표시합니다.

복습: 인증서가 출력되면 검증된 건가요?

문제: TLS 응답에서 새 leaf 인증서가 보였고 -showcerts 결과에는 인증서 두 장이 있습니다. 이 사실만으로 이름과 신뢰 체인이 통과했다고 말할 수 있나요?

정답: 아닙니다. 서버가 인증서를 전송했다는 관측입니다. SAN·유효기간, hostname 검증, 신뢰 저장소 기준 chain 검증 결과를 별도로 확인해야 합니다.