Comment corriger l’erreur “Ce site ne peut pas fournir une connexion sécurisée”

L’erreur "This site can't provide a secure connection" signifie que votre navigateur n’a pas réussi à effectuer une négociation TLS avec le serveur cible. La tentative de connexion a été interrompue avant qu’un canal chiffré puisse être établi, empêchant le navigateur de vérifier l’identité du serveur ou de négocier une suite de chiffrement.

Cette erreur apparaît dans Chrome, Firefox, Edge et Safari et est presque toujours accompagnée d’un code d’erreur spécifique — le plus souvent ERR_SSL_PROTOCOL_ERROR, ERR_SSL_VERSION_OR_CIPHER_MISMATCH ou SSL_ERROR_HANDSHAKE_FAILURE_ALERT. Chaque code pointe vers une couche de défaillance distincte : la configuration du certificat du serveur, la pile TLS du client ou le chemin réseau entre les deux. Identifier quelle couche est responsable avant de modifier les paramètres vous fera gagner un temps considérable.

Ce qui se passe réellement lors d’une négociation TLS

Avant de passer aux solutions, il est important de comprendre le mécanisme de défaillance. Lorsque votre navigateur se connecte à un site HTTPS, il effectue une négociation TLS en quelques millisecondes :

1. Le navigateur envoie un message ClientHello indiquant les versions TLS et les suites de chiffrement prises en charge.
2. Le serveur répond avec un ServerHello, sélectionne une version de protocole et un chiffrement, puis présente sa chaîne de certificats.
3. Le navigateur valide le certificat auprès des autorités de certification (CA) racines de confiance, vérifie la date d’expiration, s’assure que le domaine correspond au Subject Alternative Name (SAN) et confirme que le certificat n’a pas été révoqué (via OCSP ou CRL).
4. Les deux parties dérivent des clés de session et commencent la communication chiffrée.

Un échec à l’une de ces quatre étapes produit le message "can't provide a secure connection". Le code d’erreur dans le panneau de détails du navigateur vous indique exactement quelle étape a échoué.

Causes principales associées aux codes d’erreur

Si le code d’erreur indique que la responsabilité incombe à l’administrateur du serveur et que vous ne contrôlez pas le serveur, vos options se limitent à contacter le propriétaire du site. Les sections suivantes se concentrent sur les erreurs que vous pouvez résoudre côté client, puis sur la remédiation côté serveur pour les administrateurs.

Corrections côté client

1. Vérifier le certificat avant de modifier quoi que ce soit

Cliquez sur le cadenas (ou l’icône d’avertissement) dans la barre d’adresse et sélectionnez La connexion est sécurisée > Le certificat est valide. Vérifiez :

• Période de validité : La date « Not After » doit être dans le futur.
• Émis pour : Le domaine dans le champ SAN du certificat doit correspondre exactement à l’URL, y compris les sous-domaines.
• Émis par : La chaîne CA doit se terminer par une CA racine approuvée par votre système d’exploitation.

Si le certificat est expiré ou ne correspond pas et que vous ne possédez pas le serveur, arrêtez-vous ici et contactez le propriétaire du site. Si vous gérez le serveur, passez à la section côté serveur ci-dessous.

2. Synchroniser la date et l’heure du système

La validation des certificats est sensible au temps. Une horloge système décalée de quelques minutes peut amener le navigateur à conclure qu’un certificat valide est expiré, ou qu’un certificat pas encore valide est utilisé prématurément.

Windows :

w32tm /resync /force

Vous pouvez également faire un clic droit sur l’horloge système, sélectionner Régler la date/l’heure et activer Définir l’heure automatiquement avec le service Windows Time.

Linux (systemd) :

timedatectl set-ntp true
timedatectl status

macOS : Ouvrez Réglages système > Général > Date et heure et activez Régler la date et l’heure automatiquement.

Après la synchronisation, redémarrez le navigateur et retestez.

3. Effacer l’état SSL et le cache du navigateur

Les navigateurs mettent en cache les résultats de validation des certificats et les politiques HSTS (HTTP Strict Transport Security). Une entrée de cache obsolète peut bloquer l’accès même après la résolution d’un problème de certificat côté serveur.

Chrome — effacer les données de navigation :

Accédez à chrome://settings/clearBrowserData, sélectionnez Toute la période, cochez Cookies et autres données des sites et Images et fichiers en cache, puis cliquez sur Effacer les données.

Chrome — effacer l’entrée HSTS pour un domaine spécifique :

Accédez à chrome://net-internals/#hsts, saisissez le domaine sous Supprimer les politiques de sécurité du domaine et cliquez sur Supprimer. Cela est particulièrement utile lorsqu’un domaine était auparavant uniquement HTTPS et est maintenant mal configuré.

Windows — effacer l’état SSL au niveau du système d’exploitation :

Control Panel > Network and Internet > Internet Options > Content tab > Clear SSL State

Cela efface le cache de certificats utilisé par Internet Explorer, Edge (hérité) et certaines applications Windows.

Firefox : Accédez à about:preferences#privacy, faites défiler jusqu’à Cookies et données de sites et cliquez sur Effacer les données.

4. Désactiver l’inspection HTTPS de l’antivirus

Les produits de sécurité des éditeurs tels qu’Avast, AVG, Kaspersky, ESET et Bitdefender effectuent une interception SSL/TLS — ils agissent comme un proxy man-in-the-middle local, re-signant les certificats avec leur propre CA racine. Lorsque leur CA racine n’est pas correctement installée dans le magasin de confiance du navigateur, ou lorsque le module d’interception est défaillant, toutes les connexions HTTPS échouent.

Pour tester si c’est la cause :

1. Désactivez temporairement la fonctionnalité Web Shield, Analyse HTTPS ou Filtrage SSL dans les paramètres de votre antivirus.
2. Rechargez la page défaillante.
3. Si l’erreur disparaît, l’antivirus est le coupable.

La solution permanente consiste à ajouter le domaine concerné à la liste d’exclusions de l’antivirus plutôt que de désactiver l’analyse HTTPS globalement, ce qui réduirait votre niveau de sécurité.

5. Mettre à jour le navigateur

Le TLS moderne nécessite la prise en charge de TLS 1.2 au minimum par le navigateur, et TLS 1.3 pour une sécurité optimale. Les navigateurs antérieurs à environ Chrome 70, Firefox 63 ou Edge 79 peuvent ne pas prendre en charge TLS 1.3 ou présenter des bugs de négociation connus.

Chrome :

Accédez à chrome://settings/help. Chrome vérifie automatiquement les mises à jour et les installe au redémarrage.

Firefox :

Accédez à about:support, puis Rechercher des mises à jour dans le menu Aide.

Maintenir le navigateur à jour garantit également que le magasin de CA racines intégré au navigateur est à jour, ce qui est important pour les certificats émis par de nouvelles CA.

6. Vérifier les paramètres de protocole TLS dans le navigateur

Chrome et Edge (basés sur Chromium) :

Ces navigateurs n’exposent pas les bascules de version TLS dans l’interface depuis Chrome 84. TLS 1.0 et 1.1 sont définitivement désactivés. Si un site nécessite TLS 1.0 ou 1.1, le site doit être mis à jour — il n’existe pas de solution de contournement côté client, et il ne devrait pas en exister.

Pour vérifier les indicateurs TLS expérimentaux, accédez à chrome://flags et recherchez TLS. Dans la plupart des versions de production, aucun indicateur exploitable n’apparaîtra.

Firefox :

Accédez à about:config et recherchez security.tls.version.min. La valeur doit être 3 (correspondant à TLS 1.2). Définir la valeur à 1 ou 2 pour accommoder un serveur défaillant est un risque de sécurité et ne doit être fait que dans des environnements de test isolés.

Internet Explorer / Edge hérité :

Accédez à Options Internet > Avancé > Sécurité et assurez-vous que Utiliser TLS 1.2 et Utiliser TLS 1.3 sont cochés. Décochez Utiliser SSL 3.0, Utiliser TLS 1.0 et Utiliser TLS 1.1.

7. Désactiver ou vérifier les extensions du navigateur

Les extensions ayant accès au réseau — notamment les VPN, bloqueurs de publicités, outils de confidentialité et commutateurs de proxy — peuvent intercepter ou modifier les connexions TLS. Pour isoler un conflit d’extension :

Accédez à chrome://extensions/ et désactivez toutes les extensions. Rechargez la page défaillante. Si l’erreur se résout, réactivez les extensions une par une, en rechargeant après chacune, jusqu’à identifier l’extension fautive.

8. Changer le résolveur DNS

Le DNS n’affecte pas directement TLS, mais un résolveur DNS renvoyant des adresses IP incorrectes (en raison d’un empoisonnement, d’un filtrage ou d’une interférence du FAI) peut diriger votre navigateur vers un serveur présentant un certificat pour le mauvais domaine, provoquant une erreur ERR_CERT_COMMON_NAME_INVALID.

Passer à un résolveur public élimine la manipulation DNS au niveau du FAI :

Windows — changer le DNS via PowerShell :

Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("1.1.1.1","1.0.0.1")

Remplacez "Ethernet" par le nom réel de votre interface (utilisez Get-NetAdapter pour lister les interfaces).

Linux :

sudo nano /etc/resolv.conf

Ajoutez :

nameserver 1.1.1.1
nameserver 8.8.8.8

Résolveurs publics recommandés :

9. Réinitialiser la pile réseau (Windows)

Un catalogue Winsock corrompu ou une pile TCP/IP défaillante peut provoquer des échecs TLS intermittents qui semblent sans rapport avec les certificats. Exécutez les commandes suivantes en tant qu’administrateur :

netsh int ip reset
netsh winsock reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

Redémarrez la machine après avoir exécuté les cinq commandes. Ne sautez pas le redémarrage — netsh winsock reset en particulier nécessite un redémarrage pour prendre effet.

Corrections côté serveur pour les administrateurs

Si vous gérez le serveur web présentant le certificat, voici les causes les plus courantes côté serveur et leur remédiation.

Certificat SSL expiré ou mal configuré

Un certificat expiré est la cause la plus fréquente de cette erreur au niveau du serveur. Si vous exploitez un site dans un environnement VPS Hosting, le renouvellement des certificats doit être automatisé.

Vérifier l’expiration du certificat depuis la ligne de commande :

echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates

Automatiser le renouvellement avec Certbot (Let's Encrypt) :

sudo certbot renew --dry-run

Ajoutez une tâche cron ou un timer systemd pour exécuter certbot renew deux fois par jour — les certificats Let's Encrypt expirent tous les 90 jours, et Certbot ne renouvelle que lorsqu’il reste moins de 30 jours.

0 0,12 * * * root certbot renew --quiet

Si vous avez besoin d’un certificat validé commercialement avec validation étendue ou couverture wildcard, les Certificats SSL d’une CA de confiance fournissent la chaîne de confiance requise par tous les principaux navigateurs.

Chaîne de certificats incomplète

Une mauvaise configuration très courante : le serveur présente uniquement le certificat d’entité finale sans les certificats CA intermédiaires. Le navigateur ne peut pas construire un chemin de confiance vers une CA racine qu’il reconnaît, ce qui entraîne ERR_CERT_AUTHORITY_INVALID.

Diagnostiquer avec SSL Labs :

Exécutez votre domaine via le test de serveur SSL Labs (outil externe). Un problème de chaîne sera signalé immédiatement.

Correction sur Nginx :

La directive ssl_certificate doit pointer vers un fichier contenant la chaîne complète — votre certificat suivi de tous les certificats intermédiaires :

cat your_domain.crt intermediate.crt > fullchain.crt

ssl_certificate /etc/nginx/ssl/fullchain.crt;
ssl_certificate_key /etc/nginx/ssl/your_domain.key;

Correction sur Apache :

SSLCertificateFile /etc/apache2/ssl/your_domain.crt
SSLCertificateKeyFile /etc/apache2/ssl/your_domain.key
SSLCertificateChainFile /etc/apache2/ssl/intermediate.crt

Versions TLS obsolètes et suites de chiffrement faibles

Les navigateurs ont supprimé la prise en charge de TLS 1.0 et TLS 1.1. Si votre serveur ne propose que ces versions de protocole, les navigateurs modernes refuseront entièrement la connexion.

Configuration TLS Nginx recommandée :

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:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_stapling on;
ssl_stapling_verify on;

Configuration TLS Apache recommandée :

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder off
SSLSessionTickets off

Après avoir modifié la configuration du serveur, testez avec :

openssl s_client -connect yourdomain.com:443 -tls1_2
openssl s_client -connect yourdomain.com:443 -tls1_3

Incompatibilité de domaine du certificat

Si votre certificat couvre www.example.com mais que les utilisateurs accèdent à example.com (ou vice versa), le navigateur signalera une incompatibilité de domaine. La correction appropriée consiste à émettre un certificat avec les deux noms dans le champ SAN, ou à utiliser un certificat wildcard (*.example.com).

Lors de la configuration d’un nouveau domaine dans un environnement Serveurs dédiés, vérifiez toujours que le champ SAN couvre toutes les variantes de nom d’hôte auxquelles le serveur répondra avant la mise en production.

Blocage du contenu mixte

Une page chargée via HTTPS qui référence des ressources HTTP (images, scripts, feuilles de style) déclenche des avertissements de contenu mixte. Bien que cela ne produise pas directement l’erreur « can’t provide a secure connection », cela peut provoquer des échecs partiels de page qui sont mal diagnostiqués comme des erreurs TLS.

Auditez le contenu mixte avec :

curl -s https://yourdomain.com | grep -Eo 'src="http://[^"]*"|href="http://[^"]*"'

Comparaison des causes côté client et côté serveur

Considérations relatives à l’environnement d’hébergement

L’environnement d’hébergement que vous utilisez influence directement la facilité avec laquelle vous pouvez résoudre les problèmes TLS côté serveur.

Sur l’Hébergement Web Mutualisé, la gestion des certificats est généralement effectuée via le panneau de contrôle. La plupart des plateformes d’hébergement mutualisé modernes incluent l’intégration gratuite de Let's Encrypt, mais vous avez un contrôle limité sur les paramètres de protocole TLS à l’échelle du serveur.

Sur un VPS avec cPanel, vous avez accès à AutoSSL pour la provision automatisée de certificats et pouvez configurer directement les paramètres TLS d’Apache ou Nginx. C’est l’environnement recommandé pour les sites où la précision de la configuration TLS est importante.

Sur les Serveurs dédiés bare-metal, vous avez un contrôle total sur l’ensemble de la pile TLS — version OpenSSL, sélection des suites de chiffrement, agrafage OCSP, préchargement HSTS et épinglage de certificats — mais vous êtes également entièrement responsable de maintenir la configuration à jour.

Liste de contrôle pratique pour la prise de décision

Utilisez cette liste de contrôle pour trier l’erreur de manière systématique plutôt qu’en appliquant des correctifs au hasard :

• L’erreur apparaît-elle sur tous les sites HTTPS ou sur un seul ?
• Tous les sites : concentrez-vous sur l’horloge système, l’analyse HTTPS de l’antivirus, la mise à jour du navigateur, le magasin de CA racines du système d’exploitation.
• Un seul site : le problème est presque certainement côté serveur.

• Que dit le code d’erreur spécifique ?
• ERR_CERT_DATE_INVALID : vérifiez d’abord l’horloge système, puis l’expiration du certificat.
• ERR_CERT_AUTHORITY_INVALID : vérifiez la complétude de la chaîne de certificats.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH : le serveur utilise un TLS obsolète ou des chiffrements non pris en charge.
• ERR_CERT_COMMON_NAME_INVALID : le SAN du certificat ne correspond pas au domaine.

• L’erreur disparaît-elle sur un réseau différent ?
• Oui : un pare-feu, un proxy ou une inspection TLS au niveau du FAI est la cause.

• L’erreur disparaît-elle avec l’antivirus désactivé ?
• Oui : configurez une exclusion pour le domaine dans les paramètres d’analyse HTTPS de l’antivirus.

• Êtes-vous l’administrateur du serveur ?
• Exécutez les diagnostics openssl s_client et le test SSL Labs avant de toucher à tout fichier de configuration.
• Automatisez le renouvellement des certificats immédiatement après avoir résolu le problème immédiat.

FAQ

Pourquoi « This site can't provide a secure connection » apparaît-il uniquement sur un site web ?

Lorsque l’erreur est isolée à un seul domaine, la cause principale est presque toujours côté serveur : un certificat expiré, une chaîne de certificats incomplète, une incompatibilité de nom de domaine dans le champ SAN du certificat, ou le serveur configuré pour utiliser uniquement des versions TLS obsolètes (1.0 ou 1.1) que les navigateurs modernes n’acceptent plus.

Un VPN peut-il provoquer cette erreur ?

Oui. Certains clients VPN acheminent les requêtes DNS via leurs propres résolveurs ou effectuent une inspection du trafic qui interfère avec les négociations TLS. Si l’erreur apparaît uniquement lorsque le VPN est actif, désactivez la fonctionnalité « split tunneling » ou « SSL inspection » du VPN, ou ajoutez le domaine concerné comme exclusion.

Effacer le cache résout-il toujours les erreurs SSL ?

Non. Effacer le cache résout les erreurs causées par des politiques HSTS obsolètes ou des réponses de certificats invalides en cache. Cela n’a aucun effet sur les problèmes de certificats côté serveur, les problèmes d’horloge système ou l’interception antivirus. Utilisez l’effacement du cache comme première étape, pas comme solution universelle.

Comment vérifier si le certificat SSL de mon serveur est correctement configuré sans navigateur ?

Utilisez OpenSSL depuis n’importe quelle machine ayant accès au réseau :

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

La sortie affiche la chaîne de certificats complète, la version TLS négociée, la suite de chiffrement sélectionnée et toute erreur de vérification. C’est la méthode de diagnostic la plus fiable pour les problèmes TLS côté serveur.

Quelle est la différence entre ERR_SSL_PROTOCOL_ERROR et ERR_SSL_VERSION_OR_CIPHER_MISMATCH ?

ERR_SSL_PROTOCOL_ERROR indique que le serveur a envoyé une réponse qui ne correspond à aucun format d’enregistrement TLS reconnu — souvent causé par un serveur envoyant une réponse HTTP sur le port 443, un équilibreur de charge mal configuré ou un pare-feu interrompant la connexion en pleine négociation. ERR_SSL_VERSION_OR_CIPHER_MISMATCH signifie que la négociation a démarré correctement mais que le client et le serveur n’ont pas pu s’entendre sur une version TLS ou une suite de chiffrement mutuellement prise en charge, généralement parce que le serveur ne prend en charge que des protocoles obsolètes.