Vérifier un site web : expiration SSL, DNS, e-mail et accessibilité en une seule passe

Ce que l'on regarde pour vérifier un site web

Quand un site « a l'air bizarre », je me pose quatre questions avant de toucher à un serveur : le nom se résout-il ? quel certificat le couvre, et jusqu'à quand ? son courrier sera-t-il accepté ? et répond-il à l'instant ? Pour vérifier un site web, le vérificateur pose ces quatre mêmes questions, chacune à la source qui connaît la réponse, et affiche les résultats côte à côte.

Ce qu'un navigateur ne peut pas voir

Les navigateurs cachent à une page web la réponse d'un autre site : la requête d'accessibilité revient « opaque » et indique seulement à la page que le site a répondu en HTTPS et à quelle vitesse. Voici les angles morts :

• Statut et en-têtes HTTP : une erreur 500 compte quand même comme « a répondu » ; HSTS, CSP et le logiciel serveur restent cachés.
• Chaîne de redirections : vous voyez le temps de la réponse finale, pas les étapes.
• Versions TLS, chiffrements et chaîne exacte servie : le certificat affiché est le dernier journalisé pour l'hôte. Si le serveur web n'a jamais été rechargé après un renouvellement, il peut encore présenter un ancien certificat.
• Listes noires, réputation Safe Browsing, WHOIS et âge du domaine : rien de tout cela n'est accessible à une page de navigateur.
• Autres pays : le temps est mesuré depuis votre réseau uniquement.

Pour cela, j'ouvre un terminal : curl -sI https://example.com/ pour le statut et les en-têtes, et openssl s_client -connect example.com:443 -servername example.com pour le certificat que le serveur présente réellement. Le guide pour vérifier un certificat SSL explique les deux.

Lire les couleurs et la liste « à corriger d'abord »

Chaque constat est vert, orange ou rouge, toujours avec une icône et un mot en plus de la couleur. Le récapitulatif les compte et classe une courte liste « à corriger d'abord », les rouges avant les oranges. Il n'y a pas de note sur 100, volontairement : un enregistrement DMARC absent et une page d'accueil rapide ne font pas une moyenne qui ait un sens. Quand un contrôle ne peut pas s'exécuter, par exemple parce que le journal des certificats est hors service, sa carte le dit au lieu de deviner. « Copier le rapport » et « Télécharger .txt » donnent les mêmes constats en texte avec des heures UTC, et les huit derniers hôtes restent dans votre navigateur jusqu'à ce que vous cliquiez sur « Effacer l'historique ».

Un orange typique, calculé pas à pas. Une boutique sur shop.example a un certificat de 90 jours : notBefore 2026-07-20T08:00:00Z, notAfter 2026-10-18T07:59:59Z, et vous lancez le contrôle à 2026-10-08T00:00Z :

Dix jours, c'est orange (plus de 7, au plus 30). Ma lecture : un certificat de 90 jours aussi près de l'expiration signifie presque toujours que le renouvellement automatique s'est arrêté, car les clients ACME renouvellent normalement environ un mois avant. Je regarde d'abord le journal de la tâche de renouvellement, puis l'enregistrement CAA, car un ensemble CAA qui ne nomme plus l'AC émettrice bloque le renouvellement sans aucune erreur visible sur le site.

Expiration des certificats : durées plus courtes, plus d'e-mails de rappel

Les certificats TLS publics voient leur durée raccourcir selon le vote SC-081v3 du CA/Browser Forum : la limite de 200 jours actuellement en vigueur, qui passera à 100 puis à 47 jours. Les certificats émis avant la première étape gardent leur validité plus longue jusqu'à leur terme (résumé du calendrier par DNSimple).

Dans le même temps, Let's Encrypt a cessé d'envoyer ses e-mails de rappel d'expiration, qui arrivaient dans les semaines précédant la fin (avis de Let's Encrypt). Plus personne ne vous prévient, jetez donc un œil au décompte après chaque changement d'hébergement. Un certificat dont la durée dépasse le maximum de sa date d'émission est signalé en orange (avec un jour de tolérance), et un certificat émis dans les sept derniers jours reçoit une note d'information. Quand plusieurs certificats couvrent l'hôte, la carte montre le plus récemment émis et compte ceux en cours.

La couverture compte autant que les dates. Un wildcard *.example.com couvre exactement un libellé de plus : www.example.com oui, a.b.example.com non, et le domaine sans www example.com non. Si la liste SAN ne contient que le wildcard, les visiteurs de https://example.com reçoivent une erreur de nom même si le certificat est parfaitement valide.

Les enregistrements DNS en un coup d'œil

Deux autres signaux entourent les enregistrements. NXDOMAIN signifie que le nom n'existe pas du tout, donc le vérificateur s'arrête là et n'interroge ni crt.sh ni le site. La ligne DNSSEC rapporte l'indicateur AD de Cloudflare : « signé et validé » ou « non signé ». Le TTL est le nombre de secondes pendant lequel les résolveurs peuvent garder l'ancienne réponse, c'est pourquoi je le baisse à quelques minutes la veille d'une migration prévue. L'ensemble CAA peut se trouver sur un domaine parent : le vérificateur remonte les domaines parents jusqu'à en trouver un, indique où il l'a trouvé et compare l'AC qu'il nomme à l'émetteur du dernier certificat (RFC 8659). La lecture ligne par ligne de chaque type d'enregistrement se trouve dans vérifier les enregistrements DNS pas à pas.

Santé du domaine de messagerie : SPF, DMARC et MX

Quand les factures finissent en spam, la cause se trouve généralement dans le DNS plutôt que dans le serveur de messagerie. Le vérificateur lit ces enregistrements pour le domaine de messagerie, c'est-à-dire l'hôte sans le préfixe www..

SPF. Un seul enregistrement v=spf1 est autorisé ; deux (souvent un par fournisseur) donnent un permerror, fusionnez-les donc. Chaque include, a, mx, ptr, exists et redirect coûte une requête DNS, et plus de 10 dans une même évaluation donnent un permerror ; ip4, ip6 et all sont gratuits (RFC 7208, section 4.6.4). Prenons v=spf1 include:_spf.google.com include:mailgun.org a mx ip4:203.0.113.5 ~all:

Quatre, c'est confortable, mais chaque include déclenche ses propres requêtes, je garde donc le niveau supérieur bien en dessous de la limite ; dix ou plus au niveau supérieur, c'est déjà rouge. Un enregistrement qui se termine par +all laisse n'importe quel serveur d'internet envoyer en votre nom : rouge. S'il se termine par ?all, ou s'il n'a ni all ni redirect, c'est orange.

DMARC. Un enregistrement TXT sur _dmarc. plus le domaine, qui commence par v=DMARC1. p=none ne fait que collecter des rapports et n'arrête jamais un message falsifié, c'est pourquoi le vérificateur le marque en orange. Ma routine : lire les rapports, corriger chaque expéditeur légitime, passer à quarantine, puis à reject. pct vaut 100 par défaut et sp reprend la politique principale ; deux enregistrements DMARC signifient qu'aucun n'est appliqué (RFC 7489). Un sous-domaine sans enregistrement DMARC propre hérite de celui de son domaine parent, et le vérificateur l'indique quand il le lit de là.

MX. Triés par priorité. Un MX nul (0 .) est une déclaration volontaire que le domaine ne reçoit pas de courrier, ce qui convient à un domaine parqué ou uniquement web.

www et le domaine sans www sont deux noms

Le vérificateur conserve www exactement comme vous le saisissez, interroge aussi le nom jumeau (le domaine sans www si vous avez saisi www, et inversement) et vérifie si le certificat le couvre. C'est voulu : je contrôle www et le domaine sans www séparément à chaque fois, car chacun a besoin de son propre enregistrement DNS et de sa propre place dans la liste SAN du certificat. Un CNAME n'est pas autorisé sur le domaine sans www, donc après un changement de plateforme il est fréquent que www fonctionne alors que le nom sans www pointe encore vers l'ancien hébergeur. Un port ou un chemin que vous ajoutez est ignoré avec une remarque, car les contrôles utilisent le DNS et le port 443.

Noms trompeurs et punycode

Les noms internationaux transitent par le DNS en punycode : münchen.de devient xn--mnchen-3ya.de, пример.рф devient xn--e1afmkfd.xn--p1ai. Le résultat affiche les deux formes côte à côte. Un libellé qui mélange lettres latines et cyrilliques ou grecques reçoit une note orange « risque de nom trompeur », car un « а » cyrillique est identique à un « a » latin. Un libellé écrit entièrement en lettres cyrilliques qui ont toutes un jumeau latin reçoit la même note orange, alors qu'un nom dans une seule écriture, comme пример.рф, n'est pas signalé. Une marque connue suivie de -login, -secure ou -verify, un chiffre à la place d'une lettre et plus de quatre tirets reçoivent seulement un indice informatif. Un certificat de moins de sept jours reçoit aussi une note d'information. Ce sont des indices pour un acheteur prudent, pas un verdict sur l'honnêteté de qui que ce soit : toute boutique neuve et parfaitement honnête commence aussi avec un certificat récent.

Confidentialité et limites des contrôles

Les contrôles s'exécutent dans votre navigateur. Pour récupérer les enregistrements DNS et les journaux de certificats, votre navigateur envoie le nom de domaine à Cloudflare DNS (cloudflare-dns.com) et à crt.sh, et ouvre une fois la page d'accueil du site pour mesurer le temps de réponse. Rien ne nous est envoyé ; vos derniers hôtes restent dans votre propre navigateur.

Les deux services de consultation sont gratuits et partagés, et crt.sh en particulier est souvent surchargé. Quand il ne répond pas, vous obtenez une carte orange qui le dit ; les données du certificat ne sont jamais devinées. Pour rester un bon voisin, la page autorise un nouveau contrôle toutes les 10 secondes et 30 par heure et par navigateur, et répéter un hôte dans les 10 minutes affiche le résultat en cache sans entamer le quota (un résultat sans données de certificat n'est pas mis en cache, et « Vérifier à nouveau » force une exécution fraîche). Lancer un nouveau contrôle annule celui qui est en cours, et chaque requête a un délai maximal : 6 secondes pour chaque réponse DNS, 20 pour le journal des certificats et 8 pour la page d'accueil. Sont refusés d'emblée les adresses IP saisies à la place d'un nom (les adresses privées, de bouclage et link-local ont leur propre message), localhost, les noms se terminant par .local, .internal, .lan ou .home.arpa, ainsi que les noms sans point : vérifier un site web ici ne sert que pour les sites publics. Si un site semble en panne et que vous voulez savoir si le problème vient de chez vous, suivez le diagnostic « en panne pour tout le monde ou seulement pour moi ? ».

L'arithmétique derrière chaque verdict, et les cas sur lesquels je la teste

Les dates de certificat issues des journaux n'ont pas de fuseau horaire, elles sont donc lues en UTC. Les jours restants sont le temps restant divisé par 86 400 000 ms et arrondi à l'inférieur : 7,5 jours s'affichent 7. Sept jours ou moins, c'est rouge (« à renouveler maintenant »), jusqu'à 30 orange, au-delà vert, et une valeur négative se lit « expiré depuis N jours ». La durée de vie est affichée avec deux décimales, et une durée qui dépasse de plus d'un jour le maximum de sa date d'émission (398 jours avant la première étape, puis 200, 100 et 47) est orange. Les termes SPF ne sont comptés qu'au niveau supérieur, après retrait des qualificatifs + - ~ ? ; dix ou plus, c'est rouge. Le temps d'accessibilité est jugé rapide en dessous de 500 ms et correct en dessous de 1500 ms, les deux en vert, plus lent c'est orange ; il inclut la mise en place DNS et TLS depuis votre réseau, et aucune requête n'est faite quand toutes les adresses sont privées. L'outil doit réussir ces cas avec toutes les réponses réseau simulées, vérifiés à la date du 2026-10-08T00:00:00Z :