인증서 장애는 클라이언트 검증 실패와 서버 배포 실패를 두 경로로 나눈다

파일을 먼저 보지 말고 SNI를 포함해 외부 endpoint가 실제로 내보내는 leaf·chain·기간을 관찰한 뒤 검증 gate를 좁힌다.

클라이언트 검증 경로

서비스 이름SAN의 DNS-ID/IP-ID가 접속 이름과 일치하는지 본다. CN fallback에 기대지 않는다.

유효 기간notBefore·notAfter와 client/server 시계를 함께 확인한다.

인증 경로leaf에서 신뢰 anchor까지 서명·제약·용도 정책이 유효한지 검증한다.

상태·알고리즘구성된 revocation 정책과 허용 signature algorithm을 확인한다.

서버 배포 경로

chain 구성leaf와 필요한 intermediate를 올바른 순서로 제공한다. root는 보통 보내지 않는다.

key 일치leaf의 공개키와 실제 private key가 같은 key pair인지 알고리즘에 맞게 비교한다.

SNI·종단 선택LB·CDN·reverse proxy가 해당 이름에 새 인증서를 선택하는지 본다.

reload·배포 확산파일 갱신 뒤 process reload와 모든 region/edge의 외부 응답을 재검증한다.

1. 외부 관찰SNI·포트·실제 chain 저장

2. 이름접속 host와 SAN 비교

3. 시간인증서 기간과 시계 비교

4. pathintermediate·trust·제약 검증

5. 배포key·SNI·reload·edge 확인

경고 우회 금지 인증서 오류를 무시하면 TLS의 서버 신원 검증을 포기한다. 갱신 자동화는 발급 성공이 아니라 외부 endpoint 검증까지 닫힌 루프로 만든다.