Un proxy HTTPS doit aussi envoyer sa chaîne de certificats
Diagnostiquez les certificats intermédiaires manquants sur l'écouteur TLS du client vers Squid, indépendamment du certificat du site de destination.
Si les clients rejettent le proxy HTTPS avant d'atteindre un site, examinez la chaîne envoyée par l'écouteur du proxy. Un certificat feuille valide seul peut ne pas fournir les certificats intermédiaires dont le client a besoin.
- Identifiez le point de terminaison vérifié. Lisez le nom d'hôte dans l'URL du proxy configurée et l'erreur de cette connexion. Le certificat de l'écouteur doit couvrir ce nom. Un certificat de site web ou un certificat pour un autre alias IP ne peut pas le remplacer.
- Vérifiez la configuration de la chaîne de l'écouteur. La configuration OpenSSL prise en charge par Squid peut inclure des intermédiaires dans le fichier de certificat. Confirmez la disposition dans la référence de l'écouteur pour la version de Squid installée et le backend TLS ; le comportement des paquets n'est pas uniforme. L’exemple d’écouteur TLS de Squid 6.13 maintient la confiance de l'écouteur séparée du TLS de destination.
- Vérifiez séparément la confiance du client. Envoyer les intermédiaires aide à construire la chaîne, mais le client a toujours besoin de l'ancre de confiance racine prévue. Importer toute la chaîne du serveur dans un magasin racine sans discernement est un changement différent de la correction de ce que le serveur envoie.
Laissez la vérification activée. Elle identifie le proxy HTTPS que le client comptait utiliser. Une fois cette connexion vérifiée, une erreur de certificat de site ultérieure relève de la session TLS de destination via le proxy, avec sa propre enquête sur le nom d'hôte et la confiance.