Guides · Site internet · Certificat
« Votre connexion n’est pas privée » : comprendre l’alerte et rétablir l’accès
Lisez le code affiché, comparez avec un autre appareil et un autre réseau, puis corrigez la date, le nom couvert ou la chaîne de confiance. Le prix du certificat vient après ce diagnostic.
La réponse en bref
L’alerte « Votre connexion n’est pas privée » signifie que la validation du certificat présenté pour cette adresse a échoué. Le navigateur protège alors les informations que vous pourriez saisir. Relevez le code exact et gardez la page fermée pour les identifiants, paiements et données sensibles.
Commencez par vérifier la date et l’heure de l’appareil. Ouvrez ensuite le site depuis un autre appareil et un autre réseau, par exemple un téléphone en données mobiles. Une erreur présente sur de nombreux sites désigne souvent l’appareil, le réseau ou un logiciel qui inspecte les connexions. Une erreur limitée au même domaine sur plusieurs appareils désigne plutôt le certificat du site.
Le code oriente la correction : date invalide pour un certificat expiré ou une horloge fausse, nom incorrect pour un certificat qui couvre une autre adresse, autorité inconnue pour une chaîne incomplète, un certificat auto-signé ou une interception. Le propriétaire doit renouveler ou réinstaller le bon certificat avec sa chaîne complète, puis tester chaque nom utilisé.
Un certificat Let’s Encrypt gratuit suffit à la plupart des sites publics lorsqu’il se renouvelle automatiquement. Un certificat payant peut ajouter une identité vérifiée, du support ou des engagements contractuels. Le niveau de chiffrement reste identique à technologie égale.
Gardez les données sensibles hors de la page
Relevez l’adresse complète, le code d’erreur et l’heure. Sur un site public, attendez la correction avant de saisir un mot de passe, un numéro de carte ou un document. Un écran sans option de contournement peut venir de HSTS : le site a demandé au navigateur de refuser toute connexion dont le certificat échoue.
Pour un outil interne, suivez la procédure de l’entreprise. Une autorité privée peut être légitime lorsque sa confiance a été installée sur les appareils gérés ; une exception improvisée dans le navigateur contourne ce contrôle.
Distinguez le site, l’appareil et le réseau
Vérifiez d’abord la date, l’heure et le fuseau horaire. Testez ensuite le même site depuis un autre appareil et un autre réseau. Ouvrez aussi un second site connu depuis l’appareil initial.
| Résultat | Cause à examiner en premier |
|---|---|
| Un seul appareil échoue sur plusieurs sites | Horloge, logiciel de sécurité, proxy ou configuration de l’appareil |
| Tous les appareils d’un même réseau échouent | Portail Wi-Fi, proxy, filtrage ou interception du réseau |
| Le même domaine échoue partout | Certificat, chaîne intermédiaire ou configuration du site |
| Une seule adresse du domaine échoue | Nom absent du certificat ou serveur différent pour ce sous-domaine |
Traduisez l’erreur en correction
Le texte général varie selon le navigateur, mais le code donne la famille du problème. Communiquez-le tel quel au prestataire avec l’adresse concernée et le résultat des deux essais.
| Code ou famille | Ce qu’il indique | Correction |
|---|---|---|
| DATE_INVALID / certificat expiré | Un écart existe entre la période de validité et l’horloge | Corriger l’horloge ou renouveler puis installer le certificat |
| COMMON_NAME_INVALID / BAD_CERT_DOMAIN | Le certificat couvre un autre nom | Émettre un certificat pour chaque nom utilisé et configurer le bon serveur |
| AUTHORITY_INVALID / UNKNOWN_ISSUER | La chaîne aboutit à une autorité inconnue | Installer la chaîne intermédiaire complète ou déployer l’autorité privée sur les appareils gérés |
| Erreur sur plusieurs sites à la fois | Un équipement ou logiciel intercepte peut-être les connexions | Contrôler le réseau, le proxy et le logiciel de sécurité |
Installez le certificat complet, puis testez chaque adresse
Renouvelez le certificat auprès de l’autorité choisie, installez-le avec les certificats intermédiaires et associez-le au bon site. Vérifiez le domaine principal, sa version avec ou sans `www` et chaque sous-domaine réellement publié.
Automatisez le renouvellement et surveillez son résultat. Let’s Encrypt émet des certificats de 90 jours : cette durée courte fonctionne précisément avec une émission et un déploiement automatiques. Le guide de diagnostic des pannes détaille aussi la réduction générale de la durée maximale des certificats publics.
À ne pas faire
- Réutiliser un ancien certificat prévu pour un autre nom
- Installer le certificat du site seul, avec la chaîne intermédiaire manquante
- Omettre de vérifier que le serveur charge la version renouvelée
- Conseiller aux visiteurs de contourner l’alerte
Payez pour un besoin précis, pas pour le cadenas
Les certificats DV prouvent le contrôle du domaine. Les catégories IV, OV et EV ajoutent des informations vérifiées sur leur titulaire selon des règles définies par le CA/Browser Forum. Toutes permettent au navigateur d’établir une connexion chiffrée et d’authentifier le serveur pour le nom couvert.
| Besoin | Choix adapté | Point à vérifier |
|---|---|---|
| Site vitrine, blog, boutique ou application publique | DV public gratuit avec renouvellement automatique | Tous les noms couverts, chaîne complète et supervision du renouvellement |
| Identité de l’organisation inscrite dans le certificat | IV, OV ou EV auprès d’une autorité qui propose cette validation | Informations vérifiées et usage réel de cette identité |
| Support contractuel, console de gestion ou engagement fournisseur | Offre payante définie par ces services | Délai de support, automatisation et responsabilités écrites |
| Service interne sur des appareils administrés | Autorité privée gérée par l’organisation | Déploiement de la confiance et procédure de renouvellement sur tous les appareils |
Le prix couvre des services définis, tandis que la fiabilité du site se vérifie séparément. Let’s Encrypt limite la validation de domaine au contrôle du nom : la réputation, l’identité commerciale et l’état de sécurité du titulaire demandent leurs propres vérifications. Le certificat protège la connexion ; le contenu et l’entreprise se vérifient autrement.
Ce qu’il faut demander à l’hébergeur ou au prestataire
Quel code exact reproduisez-vous, sur quelles adresses et depuis quels réseaux ?
Les codes, les noms testés, les appareils et les réseaux, avec l’heure de chaque essai.
Le certificat couvre-t-il le domaine principal, le www et tous les sous-domaines publiés ?
La liste des noms présents dans le certificat et celle des adresses réellement utilisées.
La chaîne intermédiaire complète est-elle envoyée par chaque serveur ?
Un test de la chaîne depuis l’extérieur, sur chaque point d’entrée du site.
Comment le renouvellement est-il déclenché, installé et contrôlé ?
Le mécanisme automatique, sa fréquence, l’alerte d’échec et la preuve du dernier renouvellement.
Quel besoin précis justifie une offre payante pour ce site ?
Une identité vérifiée, un support, un outil de gestion ou un engagement contractuel clairement nommé.
Les sources
- Mozilla Support — Comprendre les erreurs de connexion sécurisée
Les erreurs de date, de nom, d’émetteur inconnu et les causes propres à l’appareil ou au réseau.
- MDN — HTTP Strict Transport Security
Pourquoi HSTS impose HTTPS et retire le contournement d’une erreur de certificat.
- Let’s Encrypt — FAQ officielle
La gratuité, l’automatisation et la durée de 90 jours des certificats Let’s Encrypt.
- Let’s Encrypt — Certification Practice Statement, version 4.0
La portée et les limites de la validation du domaine pour le titulaire et le site.
- CA/Browser Forum — Baseline Requirements
Les catégories DV, IV, OV et EV et les informations vérifiées pour chacune.