TLS 오류가 났을 때 CA 파일 교체부터 시작하면 이름 불일치나 만료 문제를 놓칠 수 있습니다. 서버가 제시한 인증서, 접속에 사용한 호스트 이름, 클라이언트가 신뢰하는 CA, 확인 시각을 나눠 봅니다. HTTP 응답을 받기 전 실패했는지도 기록합니다.
같은 인증서, 서로 다른 실패 조건
SAN에 good.test를 넣은 유효기간 1일의 임시 자체 서명 인증서를 만들었습니다. 이 인증서를 해당 명령의 CAfile로만 지정하고 good.test를 검사하면 종료 코드 0이었습니다. wrong.test를 지정하면 error 62, 신뢰 저장소를 지정하지 않고 기본 저장소도 제외하면 error 18, 검사 시각을 이틀 뒤로 지정하면 error 10이었습니다. 운영 시스템 시각과 신뢰 저장소는 바꾸지 않았습니다.
openssl verify -CAfile cert.pem -verify_hostname good.test cert.pem
openssl verify -CAfile cert.pem -verify_hostname wrong.test cert.pem위 명령은 자신의 테스트용 cert.pem이 있을 때 사용하는 오프라인 비교입니다. 신뢰·이름·시각 조건은 OpenSSL 검증 옵션에서 독립적으로 다룹니다. 실서버의 중간 인증서 누락과 자체 서명 인증서 미신뢰는 같은 오류 상황으로 단정할 수 없습니다.
실서버에서는 접속 이름과 SNI도 맞추기
IP로 접속한 결과와 도메인으로 접속한 결과가 다르면 가상 호스트 선택도 확인합니다. 인증서를 올바른 도메인으로 재발급해야 할 상황을 verify=False나 curl -k로 숨기지 마세요. 체인은 맞는데 특정 Python 환경만 실패하면 그 인터프리터의 CA 경로와 라이브러리 설정을 비교합니다. SSL 기본 경로 출력은 Requests 같은 라이브러리가 실제로 같은 번들을 쓴다는 증거가 아닙니다.
수정 뒤에는 원래 실패한 클라이언트·호스트 이름·네트워크에서 검증을 켠 채 재시도합니다. TLS 통과와 HTTP 권한 오류를 분리해 기록하세요. 이번 자체 서명 실험은 외부 사이트의 인증서 배포나 전체 체인 복구를 검증한 결과가 아닙니다.