Quen envía o certificado de cliente a través dun proxy?
Manteña as credenciais mTLS de destino separadas das credenciais do proxy e dos certificados que Apache usa cando crea a súa propia sesión TLS ascendente.
No HTTPS a través de CONNECT habitual, a aplicación envía o certificado de cliente do sitio web durante a súa propia negociación TLS co destino. O proxy só reenvía bytes; non se converte automaticamente no cliente TLS do sitio web.
| Credencial | Propietario/conexión |
|---|---|
| Usuario/contrasinal do proxy | Acceso do cliente ao proxy. |
| Certificado de cliente e clave privada do sitio web | Sesión TLS da aplicación co destino. |
| Certificado de cliente ascendente do servidor proxy | Unha sesión TLS que inicia o propio proxy. |
Estes papeis poden coexistir. Non fai falta subir a clave privada do sitio web a un proxy de túnel simple para que funcione o mTLS de destino. Despois da entrega CONNECT, use a configuración habitual de certificado de cliente de destino da aplicación e continúe verificando o certificado do servidor do sitio web.
SSLProxyMachineCertificateFile de Apache fornece credenciais cando Apache crea a súa propia sesión TLS ascendente. Un consello sobre ese ficheiro non demostra que todo cliente que use un túnel de reenvío opaco deba configuralo.
A interceptación TLS remata unha sesión nun intermediario e cambia esta propiedade. Determine se a identidade de cliente requirida pode pasar por esa disposición en vez de supor que copiar un certificado conserva a autenticación de extremo a extremo.
Ante un fallo, anote se a solicitude parou no inicio de sesión do proxy, na TLS de destino ou no intercambio posterior da aplicación. Poña a credencial na conexión que realmente a solicita.