Pannes de site HTTPS sur un WAF : versions TLS, certificats et échecs de négociation

Trois catégories, pas un grand mystère

Les pannes de site HTTPS sur un WAF semblent mystérieuses jusqu'à ce qu'on remarque qu'elles ne viennent jamais que de trois endroits.

Un site protégé injoignable en HTTPS se répartit presque toujours en trois catégories : un problème de configuration (le déchiffrement n'est même pas activé, ou le mauvais fichier de certificat a été mis au mauvais endroit), un problème de protocole/algorithme SSL (le client et le WAF ne s'accordent pas sur une version de protocole ou une suite de chiffrement), ou un problème de certificat (la clé publique, la clé privée ou la chaîne téléchargée ne correspond pas réellement à ce que présente le serveur). Classer d'abord le symptôme dans l'une de ces trois catégories évite l'essentiel des allers-retours.

Voici l'ordre de vérification pour chaque catégorie, les commandes de capture de paquets et OpenSSL qui montrent exactement où la négociation échoue, les pièges qui expliquent la plupart de ces tickets, et 5 réponses de FAQ tirées de déploiements réels.

À quel moment de la négociation la panne se produit-elle ?

Le WAF se trouve au milieu de deux négociations TLS indépendantes — client-vers-WAF et WAF-vers-serveur — et la panne ne se situe presque jamais dans les deux à la fois.

Placer d'abord la panne sur ce schéma indique s'il faut continuer à lire la configuration, ou passer directement à une capture de paquets.

Les légendes du schéma restent en anglais pour la clarté technique.

Une fois qu'on sait que le site échoue pendant la négociation SSL plutôt qu'après, les cases de gauche — déchiffrement non configuré, version de protocole, suite de chiffrement, incompatibilité certificat/clé — couvrent presque tout ce qui ne va vraiment pas. Les deux de droite montrent à quoi ressemble une panne de négociation vue de l'extérieur, ou une limitation structurelle plutôt qu'une erreur de configuration.

Parcourir chaque catégorie

Configuration, négociation de protocole et certificats laissent chacun une signature différente — voici où regarder pour chacun, et les commandes exactes.

Catégorie 1 — Confirmer que le déchiffrement HTTPS est bien configuré

Avant tout, confirmez que le site protégé est bien configuré pour terminer le TLS.

1. Vérifiez la configuration du site protégé et confirmez que « Déchiffrement HTTPS/SSL » est activé. Si ce n'est pas le cas, le WAF ne termine pas du tout le TLS pour ce site, et aucune des vérifications ci-dessous ne s'applique tant que ce n'est pas activé.
2. Confirmez que la clé publique, la clé privée et la chaîne de certificats ont bien toutes été téléchargées — pas seulement la clé publique seule.
3. Ouvrez le fichier de certificat lui-même et vérifiez son sujet : si le propre nom de domaine du site apparaît, c'est la clé publique/feuille ; si le sujet ne porte qu'un nom d'AC ou d'organisation sans domaine du site, c'est en fait un certificat d'AC/intermédiaire téléchargé au mauvais endroit — cette confusion est assez fréquente pour mériter sa propre FAQ ci-dessous.

$ openssl x509 -in leaf.crt -noout -subject -issuer
subject=CN=www.example.com
issuer=CN=ExampleCA-Intermediate
// a CN with the site's own domain in "subject" -> this is the public/leaf certificate

$ openssl x509 -in maybe-ca.crt -noout -subject -issuer
subject=CN=ExampleCA-Intermediate, O=Example CA
issuer=CN=ExampleCA-Root
// subject carries only a CA/organization name, no site domain -> this is a CA/intermediate cert,
// it belongs in the certificate-chain slot, not the "public key" slot

Catégorie 2 — Confirmer que la version de protocole et la suite de chiffrement se recoupent réellement

Si la configuration est correcte, capturez le Client Hello et comparez-le à ce que le WAF acceptera.

1. Capturez les paquets côté client et lisez le Client Hello — quelles versions TLS et quelles suites de chiffrement le client a-t-il réellement proposées.
2. Comparez cela à l'ensemble pris en charge par le WAF. Par défaut, pour des raisons de sécurité, le WAF n'accepte que TLS 1.1 et TLS 1.2 — SSLv2, SSLv3 et TLS 1.0 sont rejetés d'emblée, et un client ancien (ou une ancienne intégration, un scanner, une sonde de vérification de santé) qui ne parle que ces versions échoue la négociation avant même que les certificats soient échangés.
3. Si la liste des suites de chiffrement du client est entièrement composée de chiffrements faibles ou obsolètes que le WAF n'accepte pas, la seule façon de débloquer le site est d'assouplir la liste des suites acceptées par le WAF dans sa console — en sachant que cela sacrifie précisément la marge de sécurité que l'activation du HTTPS était censée apporter.

$ openssl s_client -connect waf-vip:443 -tls1
...
40736:error:...:tlsv1 alert protocol version:...
// the test only offered TLS1.0 -> the WAF's minimum accepted version is TLS1.1

$ openssl s_client -connect waf-vip:443 -tls1_2 -cipher 'ECDHE-RSA-AES128-GCM-SHA256'
...
Cipher    : ECDHE-RSA-AES128-GCM-SHA256
// re-run with the cipher list read from the real Client Hello capture to confirm
// which of the client's offered suites the WAF actually accepts

Catégorie 3 — Confirmer que la chaîne de certificats correspond réellement

La négociation dépasse l'étape de la version et du chiffrement mais échoue encore autour du message Certificate — la clé privée et la chaîne ne correspondent presque jamais par accident.

1. Confirmez que la clé privée téléchargée est bien celle générée avec ce certificat précis — pas un reliquat d'un renouvellement précédent, ni une clé pour un domaine totalement différent.
2. Confirmez que la chaîne inclut tous les certificats intermédiaires que le client ne fait pas déjà confiance nativement, dans le bon ordre — pas seulement le certificat feuille seul.
3. Si le client présente son propre certificat client (un Ukey ou une authentification mutuelle par jeton matériel similaire), arrêtez-vous ici : le WAF termine et rétablit le TLS en tant que proxy, et un site qui exige que le serveur vérifie directement le certificat propre du client ne peut absolument pas être protégé par le WAF dans cette configuration.

$ openssl x509 -noout -modulus -in server.crt | openssl md5
(stdin)= 3f2504e04f8964ba649...
$ openssl rsa -noout -modulus -in server.key | openssl md5
(stdin)= 3f2504e04f8964ba649...
// the two hashes must match -- if they don't, this private key was not generated for this certificate

5 pièges qui reviennent sans cesse

Une fois que les catégories ci-dessus ont indiqué où se situe le problème, ces cinq causes expliquent l'essentiel de ce qui ne va vraiment pas.

Conceptions de solutions associées

Cinq questions qui reviennent constamment

Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.

Limites honnêtes de cette note

Lectures connexes