프록시를 통해 클라이언트 인증서를 보내는 주체는 누구인가?
대상 mTLS 자격 증명을 프록시 자격 증명과 Apache가 자체 업스트림 TLS 세션을 만들 때 사용하는 인증서와 분리해 두십시오.
일반적인 CONNECT를 통한 HTTPS에서는 애플리케이션이 대상과의 자체 TLS 핸드셰이크 중에 웹사이트의 클라이언트 인증서를 보냅니다. 프록시는 바이트만 중계하며 자동으로 웹사이트의 TLS 클라이언트가 되지는 않습니다.
| 자격 증명 | 소유자/연결 |
|---|---|
| 프록시 사용자 이름/비밀번호 | 클라이언트의 프록시 접속. |
| 웹사이트 클라이언트 인증서와 개인 키 | 대상과의 애플리케이션 TLS 세션. |
| 프록시 서버의 업스트림 클라이언트 인증서 | 프록시 자체가 시작하는 TLS 세션. |
이 역할들은 함께 존재할 수 있습니다. 대상 mTLS가 작동하도록 하기 위해 웹사이트 개인 키를 단순 터널링 프록시에 업로드할 필요는 없습니다. CONNECT 인계 후에는 애플리케이션의 일반적인 대상 클라이언트 인증서 구성을 사용하고 웹사이트 서버 인증서 검증을 계속하십시오.
Apache의 SSLProxyMachineCertificateFile는 Apache가 자체 업스트림 TLS 세션을 만들 때 자격 증명을 제공합니다. 그 파일에 관한 조언은 불투명 포워드 터널을 사용하는 모든 클라이언트가 그것을 구성해야 한다는 것을 입증하지 않습니다.
TLS 가로채기는 중간자에서 세션을 종료하고 이 소유 관계를 바꿉니다. 인증서를 복사하면 종단 간 인증이 유지된다고 가정하는 대신, 필요한 클라이언트 신원이 그 구성를 통과할 수 있는지 확인하십시오.
실패 시 요청이 프록시 로그인, 대상 TLS 또는 이후 애플리케이션 교환 중 어디에서 멈췄는지 기록하십시오. 자격 증명은 실제로 그것을 요구하는 연결에 두십시오.