Qui envoie le certificat client à travers un proxy ?
Séparez les identifiants mTLS du site cible des identifiants du proxy et des certificats utilisés par Apache pour sa propre session TLS amont.
Avec un HTTPS ordinaire via CONNECT, l’application envoie le certificat client du site pendant sa propre négociation TLS avec la destination. Le proxy relaie les octets ; il ne devient pas automatiquement le client TLS du site.
| Identifiant | Propriétaire/connexion |
|---|---|
| Nom d’utilisateur/mot de passe du proxy | Accès du client au proxy. |
| Certificat client et clé privée du site | Session TLS de l’application avec la destination. |
| Certificat client amont du serveur proxy | Session TLS initiée par le proxy lui-même. |
Ces rôles peuvent coexister. Il n’est pas nécessaire de téléverser la clé privée du site vers un proxy de tunnel simple pour faire fonctionner le mTLS de destination. Après le passage CONNECT, utilisez la configuration habituelle du certificat client de destination dans l’application et continuez à vérifier le certificat du serveur du site.
SSLProxyMachineCertificateFile fournit les identifiants quand Apache crée sa propre session TLS amont. Les conseils sur ce fichier ne signifient pas que tout client utilisant un tunnel direct opaque doit le configurer.
L’interception TLS termine une session chez un intermédiaire et modifie cette propriété. Vérifiez si l’identité client requise peut traverser cette architecture au lieu de supposer que copier un certificat conserve l’authentification de bout en bout.
En cas d’échec, notez si la requête s’est arrêtée à la connexion au proxy, au TLS de destination ou lors de l’échange applicatif suivant. Placez l’identifiant sur la connexion qui le demande réellement.