Comment éviter l’expiration d’un certificat SSL

Chaque certificat SSL/TLS a une date de fin. Une fois cette date passée, les navigateurs cessent de faire confiance au site et affichent une page d’avertissement aux visiteurs. Le site lui-même continue de fonctionner : les vérifications de disponibilité qui se contentent de demander un code d’état peuvent donc ne rien remarquer. L’expiration d’un certificat est l’une des causes de panne les plus évitables, et ce guide montre comment la prévenir.

Ce que fait un certificat SSL/TLS

Un certificat remplit deux fonctions quand un navigateur ouvre une adresse https:// :

• Il prouve l’identité. Il atteste que ce serveur est autorisé à répondre pour ce nom de domaine, avec la garantie d’une autorité de certification à laquelle le navigateur fait confiance.
• Il permet le chiffrement. Il contient la clé publique que le navigateur et le serveur utilisent pour établir une connexion chiffrée.

Le terme SSL est ancien. Les connexions modernes utilisent TLS, mais on dit toujours « certificat SSL », et ce guide aussi.

Un certificat contient une date de début (notBefore) et une date de fin (notAfter). En dehors de cette période, il n’est pas valide. Cela est défini par la norme X.509, la RFC 5280.

Pourquoi l’expiration compte

Quand un certificat expire :

• Les navigateurs affichent un avertissement plein écran et rendent difficile de continuer.
• Les robots d’exploration, les prestataires de paiement et les clients d’API peuvent refuser la connexion.
• Les applications mobiles et les intégrations qui communiquent avec votre serveur peuvent échouer sans aucun message visible.
• Les visiteurs pensent souvent que le site a été piraté.

Le serveur n’a aucun problème. C’est pourquoi l’incident passe facilement inaperçu et peut vite causer de vrais dégâts.

Comment vérifier la période de validité d’un certificat

Vous pouvez vérifier n’importe quel site public vous-même, sans outil particulier.

Dans un navigateur

Les noms exacts des menus varient selon les navigateurs et les versions. Dans la plupart des navigateurs de bureau :

1. Ouvrez le site web.
2. Cliquez sur l’icône à gauche de la barre d’adresse (un cadenas ou une icône de connexion).
3. Choisissez l’entrée relative à la connexion ou au certificat, puis ouvrez les détails du certificat.
4. Lisez les dates « Valid from » et « Valid to ».

Avec OpenSSL

Sous Linux et macOS, OpenSSL est généralement installé. Cette commande se connecte au site et affiche les dates :

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  </dev/null 2>/dev/null |
openssl x509 -noout -dates

Remplacez example.com par votre domaine. Le résultat ressemble à ceci (les dates sont des exemples) :

notBefore=Sep 26 22:49:11 2026 GMT
notAfter=Dec 25 22:56:35 2026 GMT

Rôle de chaque partie :

• openssl s_client -connect example.com:443 ouvre une connexion TLS vers le port 443 et affiche ce que le serveur envoie.
• -servername example.com envoie le nom d’hôte pendant la négociation (SNI, Server Name Indication). De nombreux serveurs hébergent plusieurs sites à la même adresse et se servent du nom pour choisir le certificat à présenter. Sans lui, on peut vous montrer le certificat d’un autre site.
• </dev/null ferme l’entrée aussitôt, de sorte que la commande se termine au lieu d’attendre.
• 2>/dev/null masque les détails de la connexion, qui passent par le flux d’erreurs.
• openssl x509 -noout -dates lit le certificat depuis le tube et n’affiche que ses dates de début et de fin.

Pour poser plutôt une question à réponse oui ou non, utilisez -checkend avec un nombre de secondes. Celle-ci demande si le certificat sera encore valide dans 30 jours (2 592 000 secondes) :

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null |
openssl x509 -noout -checkend 2592000

Elle affiche Certificate will not expire et se termine avec le code 0 si le certificat sera encore valide à cette date. S’il aura expiré d’ici là, elle se termine avec un code différent de zéro. C’est pratique à utiliser dans un script.

Comment fonctionne le renouvellement d’un certificat

Un certificat ne peut pas être prolongé. Renouveler, c’est obtenir de l’autorité de certification un nouveau certificat pour les mêmes noms, avec de nouvelles dates, puis l’installer là où le serveur peut l’utiliser.

Deux étapes comptent, et on ne se souvient souvent que de la première :

1. Émettre. L’autorité vérifie que vous contrôlez le domaine et vous remet un nouveau certificat.
2. Déployer. Le nouveau certificat et la clé sont placés là où le serveur web les lit, et on indique au serveur de les charger.

Tant que la seconde étape n’est pas faite, le serveur continue de présenter l’ancien certificat, et l’ancienne date de fin reste valable. Un fichier renouvelé sur le disque n’est pas un certificat renouvelé en production.

Renouvellement automatique

La plupart des autorités de certification attendent désormais que le renouvellement soit automatisé. Let’s Encrypt, par exemple, délivre des certificats valables 90 jours par défaut, et son guide d’intégration recommande de renouveler quand il reste environ un tiers de la durée de vie, afin de pouvoir réessayer en cas d’échec.

Les outils habituels, comme Certbot et les clients ACME intégrés à de nombreux panneaux d’hébergement et serveurs web, le font selon un calendrier. Ils tentent le renouvellement régulièrement, remplacent les fichiers du certificat quand l’échéance approche et peuvent exécuter ensuite une commande, comme recharger le serveur web.

Quel que soit l’outil, configurez-le de façon à pouvoir constater qu’il fonctionne :

• Sachez où il s’exécute et à quelle fréquence.
• Sachez qui est prévenu en cas d’échec.
• Faites un essai à blanc, si l’outil le permet. Certbot propose certbot renew --dry-run.

Les certificats sont de plus en plus courts

La durée de vie des certificats est réduite dans toute l’industrie, ce qui rend le renouvellement manuel de moins en moins praticable :

• Le CA/Browser Forum, l’organisme qui fixe les règles des certificats publics, a approuvé un calendrier qui ramène la validité maximale de 398 jours à 47 jours. Les certificats émis à partir du 15 mars 2026 peuvent durer jusqu’à 200 jours, à partir du 15 mars 2027 jusqu’à 100 jours, et à partir du 15 mars 2029 jusqu’à 47 jours.
• Let’s Encrypt a annoncé que son profil par défaut passera à 64 jours en février 2027 et à 45 jours en février 2028.

Si vous renouvelez à la main une fois par an, prévoyez d’automatiser. Vérifiez les règles en vigueur chez votre propre autorité, car les calendriers peuvent changer.

Pourquoi le renouvellement automatique peut échouer

Automatique ne veut pas dire fiable. Voici les raisons courantes pour lesquelles des renouvellements échouent sans que personne ne s’en aperçoive :

• La tâche planifiée s’est arrêtée. Le serveur a été reconstruit, le minuteur a été perdu ou la tâche n’a jamais été activée.
• La vérification du domaine échoue. L’autorité doit atteindre votre site ou vos enregistrements DNS pour confirmer que vous en avez le contrôle. Un pare-feu modifié, une zone DNS déplacée, une redirection qui intercepte désormais le défi ou un CDN placé devant peuvent la bloquer.
• Le nouveau certificat n’est pas chargé. Le fichier est remplacé, mais le serveur web n’est jamais rechargé et garde donc l’ancien en mémoire.
• Un autre serveur détient le certificat. Un répartiteur de charge, un CDN ou un second hôte présente sa propre copie, qu’aucune tâche ne met à jour.
• Un nom a été ajouté ou retiré. Le certificat ne couvre plus tous les noms d’hôte utilisés.
• Le compte ou les identifiants ont expiré. Un jeton d’API pour la validation DNS a été révoqué, ou l’e-mail de contact du compte n’existe plus.
• Limites de fréquence ou changements chez l’autorité. Trop de tentatives, ou un changement des règles de l’émetteur, peuvent faire rejeter une demande.

Les deuxième et troisième cas sont les plus fréquents en pratique, et ni l’un ni l’autre n’apparaît dans les dates du certificat avant qu’il soit trop tard.

Chaînes de certificats et problèmes de déploiement

Un serveur doit envoyer son propre certificat (le certificat feuille) et les certificats intermédiaires qui le relient à une racine de confiance. Si un intermédiaire manque, certains clients arrivent quand même à reconstituer le chemin et d’autres non. Le site paraît alors correct dans votre navigateur et échoue dans une application, un outil en ligne de commande ou un ancien téléphone.

Signes de ce problème :

• Le site fonctionne dans un navigateur de bureau, mais échoue avec curl ou depuis un script.
• openssl s_client se termine par un message indiquant qu’il est impossible de vérifier le premier certificat.
• Seuls certains appareils se plaignent.

Pour examiner la chaîne envoyée par le serveur, ajoutez -showcerts :

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

À la fin de la sortie, repérez la ligne qui commence par Verify return code. 0 (ok) signifie qu’OpenSSL a pu construire un chemin de confiance.

Autres erreurs de déploiement à rechercher : le certificat et la clé ne correspondent pas, un ancien certificat est présenté sur l’un de plusieurs serveurs, ou le site est atteint par un nom que le certificat ne mentionne pas.

Surveiller l’expiration du certificat

Même avec l’automatisation, surveiller la date de fin est le filet de sécurité. Il détecte tous les échecs ci-dessus, car il regarde ce qui est présenté, et non ce qui devrait l’être.

Une bonne vérification d’expiration :

• Lit le certificat que reçoivent les visiteurs, à l’adresse réelle.
• Prévient assez tôt pour agir, avec des jours de marge et non des heures.
• Prévient la personne qui peut corriger le problème.
• Prévient de nouveau si le problème n’est pas corrigé, ou du moins ne laisse pas l’avertissement se perdre.

Dans UptimeWire

Pour chaque site web dont l’adresse commence par https://, UptimeWire vérifie le certificat séparément de la vérification de disponibilité. Voici son comportement :

• Calendrier propre. Les vérifications de certificat s’exécutent toutes les quelques heures, selon leur propre calendrier et non à l’intervalle de la vérification de disponibilité. Une alerte peut donc arriver plusieurs heures après le franchissement du seuil, et non à l’instant exact.
• Délai d’avertissement. Vous choisissez combien de jours avant l’expiration être prévenu. La valeur par défaut est de 30 jours, et le réglage s’applique à chaque site web. Une alerte est envoyée quand il reste au certificat moins de jours que cette valeur.
• Envoyée une seule fois. L’alerte est envoyée quand la vérification passe à l’état d’avertissement, et non à chaque vérification suivante.
• Certificats non valides. Si le certificat ne peut pas du tout être validé (par exemple, parce qu’il a expiré ou qu’il est établi pour un autre nom), vous êtes prévenu immédiatement, sans attendre le seuil.
• Canaux. Les alertes de certificat sont envoyées par e-mail et, si vous l’avez connecté, par Telegram. Les canaux de messagerie instantanée et de webhook ne les transportent pas.

UptimeWire ne renouvelle ni ne remplace les certificats. Il vous dit que le moment d’agir est venu.

Que faire quand un certificat a expiré

1. Confirmez-le. Vérifiez les dates avec un navigateur ou avec la commande OpenSSL ci-dessus, à l’adresse réelle.
2. Trouvez où le certificat est présenté. Ce peut être votre serveur web, un répartiteur de charge, un CDN ou un panneau d’hébergement.
3. Renouvelez-le. Lancez l’outil de renouvellement ou demandez un nouveau certificat à votre autorité. Si l’automatisation a échoué, lisez son journal pour savoir pourquoi.
4. Déployez-le. Installez le nouveau certificat et rechargez le service qui le présente.
5. Vérifiez de nouveau depuis l’extérieur. Lisez les dates à l’adresse réelle et contrôlez la chaîne.
6. Trouvez la cause. Corrigez la raison de l’échec de l’automatisation, sinon la même chose se produira au prochain renouvellement.
7. Informez les gens, si nécessaire. Si des clients ont vu l’avertissement, un court message sur une page de statut ou par e-mail est utile.

Liste de contrôle de prévention

• Chaque nom d’hôte public est listé, avec le certificat qui le couvre et l’endroit où il est présenté.
• Le renouvellement est automatique et vous savez où il s’exécute.
• Quelqu’un reçoit le message d’échec de la tâche de renouvellement.
• Le serveur web est rechargé après le remplacement du certificat.
• La chaîne est complète (Verify return code: 0 (ok)).
• La date de fin est surveillée depuis l’extérieur, avec un délai d’avertissement d’au moins deux semaines.
• L’e-mail d’alerte arrive dans une boîte aux lettres lue par une personne.
• Vous vérifiez les dates après tout changement de serveur, de CDN ou d’hébergement.
• L’enregistrement du domaine et le DNS sont eux aussi surveillés, car ils tombent en panne de la même façon silencieuse. Consultez le guide complet de la surveillance de la disponibilité d’un site web.

Pour l’autre versant du problème, savoir quand un site est injoignable pour quelque raison que ce soit, lisez Comment surveiller la disponibilité d’un site web.