검사 프록시의 어느 쪽이 인증서를 거부했는가?

클라이언트는 승인된 검사 프록시를 신뢰합니다. 그래도 요청은 인증서 오류로 실패합니다. 두 사실 모두 참일 수 있습니다. 그 프록시에는 검증할 또 다른 TLS 관계가 있습니다.

client -- TLS to approved intermediary -- proxy -- TLS to website -- destination

가로채기 구성에서는 중간자가 클라이언트의 TLS를 종료하고 앞쪽으로 자체 연결을 만듭니다. 클라이언트는 자기 쪽에서 제시된 인증서를 받아들일 수 있지만, 프록시는 웹사이트에서 받은 인증서를 거부합니다.

검증자 측의 오류를 읽으십시오

실패한 체인이나 호스트 이름을 어느 프로세스가 보고했는지 확인하십시오. 프록시가 생성한 오류 페이지는 유효한 연결을 통해 클라이언트에 정상적으로 도달할 수 있습니다. 클라이언트의 CA 파일을 다시 바꾸는 것으로는 프록시의 업스트림 신뢰 구성이 갱신되지 않습니다.

예를 들어 Mitmproxy는 ssl_verify_upstream_trusted_ca을 포함한 별도의 업스트림 신뢰 옵션을 문서화합니다. 적절한 관리자는 검증을 유지하면서 업스트림 서비스에 승인된 신뢰를 구성할 수 있습니다. 다른 프록시 제품에는 그에 대응하는 인터페이스가 필요합니다.

실제 목적지 이름과 체인도 확인하십시오. 중간 인증서가 없는 사설 서비스, 만료된 인증서, 알려지지 않은 사설 발급자는 각각 다른 복구가 필요합니다. 한 사설 서비스를 위한 의도된 예외가 조용히 모든 인증서의 전면 수용이 되어서는 안 됩니다.

일반 CONNECT 터널은 다릅니다

불투명 전달 터널은 이런 방식으로 목적지 TLS를 분리하지 않습니다. 애플리케이션은 보통 그 종단 간 TLS 세션을 스스로 협상하고 검증합니다. 검사 프록시 설정을 아무 중간자에나 적용하는 대신, 가로채기가 실제로 경로의 일부인지 먼저 확인하십시오.

두 검증 결과를 따로 기록하십시오. “프록시 인증서는 신뢰할 수 있다”는 클라이언트 측 질문에 답할 뿐, 프록시가 업스트림에 연결할 때 무엇을 보았는지를 증명하지는 않습니다.