프록시 사용 중 인증서 오류가 날 때 확인할 곳
인증서 설정을 바꾸기 전에 프록시 자체의 TLS 연결과 목적지 웹사이트 중 어느 쪽에서 검증이 실패했는지 구분하세요.
CA 번들을 바꾸기 전에 어느 TLS 핸드셰이크가 실패했는지 찾으세요. 프록시 인증서와 웹사이트 인증서는 서로 다른 연결에서 검증될 수 있습니다.
| 프록시와 목적지 | TLS 검증 |
|---|---|
| HTTP 프록시를 통해 HTTPS 목적지 접속 | CONNECT 이후 터널을 통해 목적지 인증서를 검증합니다. |
| HTTPS 프록시를 통해 HTTPS 목적지 접속 | 먼저 프록시로의 TLS를 검증하고, 터널이 열린 뒤 별도의 목적지 TLS 세션을 검증합니다. |
상세 추적 출력으로 요청한 호스트 이름과 마지막으로 완료한 핸드셰이크를 파악하세요. HTTPS 프록시 인증서 오류는 웹사이트에 접촉하기 전에 발생할 수 있습니다. 해당 연결에서 의도한 이름, 인증서 유효 기간, 로컬 시계, 예상 인증서 체인, 승인된 신뢰 저장소를 확인하세요. 의도적으로 설정한 TLS 가로채기나 추가한 루트 인증서도 조사에 포함하세요.
curl은 두 연결에 각각 별도의 CA 옵션을 제공합니다.
curl --proxy https://proxy.example:8443 --proxy-cacert proxy-ca.pem --cacert site-ca.pem https://example.com/--proxy-cacert는 프록시에 대한 신뢰를, --cacert는 목적지에 대한 신뢰를 지정합니다. 예제의 엔드포인트와 파일을 의도한 신뢰 구성에 맞는 값으로 바꾸세요. 시스템 신뢰 설정으로 충분하다면 사용자 지정 번들은 필요 없습니다.
호스트 이름을 임의의 IP로 바꾸면 인증서 일치 조건이 달라집니다. 검증을 건너뛰면 오류를 감출 수 있지만 상대의 신원은 확인되지 않습니다. 잘 모르는 프록시가 자신의 루트 CA를 설치하라고 요구한다는 사실만으로 그 프록시를 신뢰할 수는 없습니다.
포트 연결 거부나 CONNECT 거부는 더 앞 단계의 문제이므로 인증서를 바꿔도 해결되지 않습니다. 반대로 목적지 TLS 검증이 끝난 뒤 웹사이트가 보내는 HTTP 오류는 수신한 응답을 살펴볼 문제이며 CA를 더 조정할 문제가 아닙니다.