¿Quién envía el certificado de cliente a través de un proxy?
Separa las credenciales mTLS del destino de las credenciales del proxy y de los certificados que Apache usa al crear su propia sesión TLS ascendente.
En el HTTPS normal mediante CONNECT, la aplicación envía el certificado de cliente del sitio durante su propio handshake TLS con el destino. El proxy retransmite bytes; no se convierte automáticamente en el cliente TLS del sitio.
| Credencial | Propietario/conexión |
|---|---|
| Usuario/contraseña del proxy | Acceso del cliente al proxy. |
| Certificado de cliente y clave privada del sitio | Sesión TLS de la aplicación con el destino. |
| Certificado de cliente ascendente del servidor proxy | Sesión TLS iniciada por el propio proxy. |
Estos papeles pueden coexistir. No hace falta subir la clave privada del sitio a un proxy de túnel simple para que funcione el mTLS del destino. Tras el intercambio CONNECT, usa la configuración normal del certificado de cliente del destino y sigue verificando el certificado del servidor del sitio.
SSLProxyMachineCertificateFile proporciona credenciales cuando Apache crea su propia sesión TLS ascendente. Ese archivo no demuestra que todos los clientes que usan un túnel directo opaco deban configurarlo.
La interceptación TLS termina una sesión en un intermediario y cambia esta propiedad. Comprueba si la identidad de cliente requerida puede atravesar ese diseño, en vez de suponer que copiar un certificado conserva la autenticación de extremo a extremo.
Ante un fallo, registra si la solicitud se detuvo en el inicio de sesión del proxy, el TLS del destino o el intercambio posterior de la aplicación. Coloca la credencial en la conexión que realmente la solicita.