Certificats SSL : expiration, chaînes et erreurs de trafic

Un certificat SSL expiré ne ralentit pas simplement un site : il le rend totalement inaccessible derrière un écran d'alerte rouge que la majorité des visiteurs refusent de franchir, et que les robots d'indexation considèrent comme indisponible.

Le chiffre d'affaires tombe instantanément à zéro. Cet incident frappe régulièrement des entreprises de premier plan, car l'échec est silencieux jusqu'au moment précis de la rupture de service.

Voici les causes réelles de défaillance et la méthode pour les anticiper.

L'expiration : l'automatisation qui s'arrête en silence

Les certificats Let's Encrypt sont valables 90 jours et conçus pour se renouveler automatiquement au 60e jour. L'automatisation supprime théoriquement tout risque — jusqu'à ce que la tâche planifiée (cron) échoue sans que personne ne s'en aperçoive pendant un mois.

Le renouvellement s'interrompt souvent pour des motifs banals : modification des règles du pare-feu bloquant le challenge HTTP, déplacement de la racine web lors d'un déploiement, expiration d'un jeton d'API DNS, disque dur saturé ou mise à jour du paquet certbot. Aucune de ces pannes n'envoie de signal d'alerte par défaut. Le certificat cesse simplement de se renouveler, et trente jours plus tard, le site est bloqué par les navigateurs.

La règle de protection absolue : surveillez la date d'expiration du certificat réel de manière indépendante du script de renouvellement. Si votre alerte vérifie uniquement « la commande certbot a-t-elle tourné ? », vous faites confiance au composant qui risque d'échouer. Si elle interroge « le certificat servi en ligne expire-t-il dans moins de 14 jours ? », vous détectez toutes les anomalies sans exception.

Fixez cette alerte à 14 jours avant expiration. Un certificat de 90 jours qui aurait dû se renouveler à 60 jours et auquel il ne reste que 14 jours est en panne avérée, vous laissant deux semaines complètes pour intervenir sereinement.

La couverture des noms d'hôte : le piège du sous-domaine www

Un certificat SSL protège des noms de domaine précis, listés dans son champ SAN (Subject Alternative Name). Un certificat émis pour example.com ne protège pas www.example.com si ce dernier n'y est pas explicitement inscrit.

C'est une faille difficile à détecter en interne, chacun ayant l'habitude de taper le domaine toujours de la même manière. Pendant ce temps, les internautes qui saisissent le www ou cliquent sur d'anciens liens se heurtent à un avertissement de sécurité bloquant.

Vérifiez systématiquement les deux variantes.

Les certificats wildcard ne couvrent qu'un seul niveau. *.example.com protège boutique.example.com mais pas fr.boutique.example.com. De plus, il ne couvre pas le domaine racine example.com nu, qui doit être déclaré en complément.

La chaîne de certification : fonctionnel sur PC, bloqué sur mobile

Votre certificat de site est signé par un certificat intermédiaire, lui-même signé par une autorité racine que le navigateur reconnaît. Votre serveur web a l'obligation de transmettre le certificat intermédiaire. L'autorité racine est déjà mémorisée par le système d'exploitation, mais pas le certificat intermédiaire.

Si votre serveur ne transmet que le certificat final (leaf), la plupart des navigateurs pour ordinateur comblent le manque en téléchargeant l'intermédiaire en tâche de fond. En revanche, de nombreux navigateurs mobiles, applications, appareils Android anciens et outils en ligne de commande ne le font pas et rejettent la connexion.

Voilà pourquoi un site peut s'ouvrir sans anomalie sur l'ordinateur d'un développeur tout en affichant une erreur de sécurité critique sur le smartphone d'un client. Ne vous fiez jamais à la simple présence du cadenas sur votre propre machine.

Notre testeur de certificat SSL gratuit contrôle l'intégrité de la chaîne de certification, la date d'expiration et la couverture exacte des domaines.

Versions du protocole TLS

• TLS 1.3 — la norme actuelle. Finalise la poignée de main cryptographique (handshake) en un seul aller-retour réseau au lieu de deux, accélérant visiblement chaque chargement de page.
• TLS 1.2 — le standard minimal acceptable.
• TLS 1.1 et 1.0 — obsolètes, rejetés par les navigateurs modernes et non conformes aux normes bancaires PCI-DSS.

Si votre hébergement autorise encore TLS 1.0 ou 1.1, exigez une mise à niveau auprès de son support technique.

Certificats gratuits versus certificats payants

Sur le plan cryptographique, la sécurité est strictement identique. Let's Encrypt utilise les mêmes algorithmes, les mêmes longueurs de clés et bénéficie du même niveau de confiance des navigateurs qu'un certificat commercial facturé plusieurs centaines d'euros par an.

Les certificats payants payants apportent une vérification d'organisation (OV ou EV) attestant de l'existence juridique de l'entreprise.

Or, les navigateurs ont supprimé ces distinctions visuelles. La barre d'adresse verte avec le nom de l'entreprise a disparu de Chrome, Firefox et Safari. Un internaute ne peut plus distinguer un certificat EV d'un certificat gratuit sans inspecter les détails techniques du certificat.

Privilégiez les certificats gratuits automatisés, sauf contrainte réglementaire ou contractuelle explicite.

La réduction programmée de la durée de vie des certificats

Les navigateurs refusent désormais les certificats émis pour plus de 398 jours, et les autorités de normalisation avancent vers des durées maximales de 90 jours, voire 45 jours à court terme.

Conséquence directe : la gestion manuelle des certificats est vouée à disparaître. Tout processus nécessitant qu'un collaborateur télécharge manuellement un fichier pour l'importer sur un serveur deviendra intenable. L'automatisation complète de la délivrance et du renouvellement est devenue obligatoire.

Le contenu mixte (Mixed Content)

Un certificat valide ne suffit pas si une page HTTPS charge des ressources via le protocole non sécurisé HTTP (images, scripts, polices). Les navigateurs bloquent automatiquement les scripts non chiffrés et dégradent l'indicateur de sécurité pour les images.

Ce problème survient couramment après une migration vers HTTPS, en raison d'URL en http:// restées figées dans une base de données ou d'anciens articles de blog.

Les contrôles indispensables à mettre en place

Vérification automatisée mensuelle :

• Nombre de jours restants avant expiration (sur le domaine nu et sur www)
• Intégrité de la chaîne de certification intermédiaire
• Version du protocole TLS négociée

Après chaque changement d'hébergeur ou de CDN :

• L'ensemble des points précédents, complété par la détection de contenus mixtes

Une fois pour toutes :

• Déclarez un enregistrement DNS CAA spécifiant les seules autorités autorisées à émettre pour votre domaine. C'est une protection majeure qui s'active en deux minutes.

Consultez notre guide des enregistrements DNS pour configurer vos règles et testez-les avec notre outil de recherche DNS.

En résumé

Les pannes de certificats proviennent de trois sources : une expiration non détectée, un oubli du sous-domaine www ou une chaîne de certification incomplète. Contrôlez régulièrement l'état de votre domaine en conditions réelles pour prémunir votre activité contre ces interruptions de service critiques.