SSL_ERROR_NO_CYPHER_OVERLAP. Firefox affiche ce message d’erreur, sans page de contournement possible, sur un site pourtant équipé d’un certificat TLS valide, non expiré, émis par une autorité reconnue. Le réflexe naturel consiste à vérifier le certificat lui-même, sa date d’expiration, la chaîne de confiance — et à ne rien trouver d’anormal, puisque le problème ne se situe pas là.
Ce que dit vraiment le message
Ce message signifie précisément qu’aucune suite de chiffrement (cipher suite) commune n’a pu être négociée entre le navigateur et le serveur lors de la poignée de main TLS. Le navigateur propose une liste de suites qu’il accepte, le serveur propose la sienne, et la connexion échoue si l’intersection de ces deux listes est vide.
Ce cas se produit typiquement sur un serveur ancien, jamais reconfiguré depuis son installation initiale, qui n’accepte encore que des suites de chiffrement obsolètes (souvent basées sur RC4 ou des versions anciennes de TLS), pendant qu’un navigateur récent, pour des raisons de sécurité, a retiré la prise en charge de ces mêmes suites de ses versions les plus à jour.
Diagnostic
La commande openssl s_client permet de lister précisément les suites acceptées par le serveur, en testant différentes versions de protocole :
openssl s_client -connect exemple-site.fr:443 -tls1_2
openssl s_client -connect exemple-site.fr:443 -cipher 'ECDHE-RSA-AES128-GCM-SHA256'
Un test complémentaire via l’outil en ligne SSL Labs de Qualys confirme rapidement si le serveur propose encore des suites jugées faibles ou obsolètes par les standards actuels, avec une notation explicite de la configuration.
Correctif côté nginx
La correction consiste à définir une liste de suites de chiffrement modernes et à retirer les anciennes, dans le bloc serveur nginx concerné :
server {
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;
}
Un rechargement du service suffit à appliquer le changement, sans interruption du service ni renouvellement du certificat :
sudo nginx -t && sudo systemctl reload nginx
Le compromis à connaître
Retirer les suites les plus anciennes peut couper l’accès à des navigateurs très anciens ou à certains automates internes encore mal maintenus. Sur un site grand public, ce compromis est presque toujours favorable ; sur un site interne à une organisation avec du matériel ancien, une vérification préalable évite une coupure d’accès imprévue.
- Vérifier les suites acceptées avec
openssl s_clientavant toute modification - Tester la nouvelle configuration sur un environnement de recette avant la production
- Revalider avec SSL Labs après application du correctif
Un certificat valide ne garantit jamais à lui seul une connexion possible : la configuration des suites de chiffrement autour de lui compte tout autant, et vieillit bien plus vite qu’on ne le pense.
Le cas d’Apache
Sur un serveur encore basé sur Apache, le même correctif s’applique via les directives équivalentes dans le fichier de configuration du site, avec une syntaxe légèrement différente mais un principe identique :
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
SSLHonorCipherOrder off
Un redémarrage du service Apache, plutôt qu’un simple rechargement, est parfois nécessaire selon la distribution utilisée pour que le changement de suites soit pleinement pris en compte par tous les processus enfants déjà lancés.
Un contrôle à intégrer au cycle de vie du serveur
Plutôt que d’attendre qu’un visiteur signale l’erreur, un contrôle automatisé de la configuration TLS, exécuté mensuellement via un script qui interroge SSL Labs ou reproduit un test openssl s_client minimal, permet d’anticiper ce type de dérive avant qu’elle ne touche un visiteur réel. Ce contrôle coûte peu à mettre en place et évite la surprise désagréable d’un incident découvert par un client plutôt que par l’équipe technique elle-même.
En résumé
SSL_ERROR_NO_CYPHER_OVERLAP ne trahit jamais un problème de certificat, mais une configuration serveur figée depuis trop longtemps face à des navigateurs qui, eux, retirent régulièrement le support des suites de chiffrement jugées faibles. Une revue périodique de la configuration TLS, indépendante du renouvellement du certificat, évite que ce message ne surprenne un jour les visiteurs du site, souvent au pire moment possible.
