Vérifier le HTTPS et le certificat SSL d’un site

Comment utiliser l’outil

Saisissez l’adresse d’un site et cliquez sur « Vérifier ». L’outil ouvre une connexion sécurisée sur le port 443, lit le certificat présenté, puis demande la page en http:// et en https:// sans cache. Les constats sont rangés en « À corriger », « À noter » et « OK », suivis du détail du certificat et de la liste des ressources en http:// trouvées dans la page.

Si vous saisissez une page précise, c’est cette page qui est lue pour le contenu mixte. Pour contrôler l’accueil, indiquez seulement le nom du site. Le certificat, lui, est celui de l’hôte.

Ce que l’outil contrôle

D’abord le certificat : la chaîne de confiance, les dates de validité avec le nombre de jours restants, le nom de l’hôte comparé aux noms couverts (champ « Subject Alternative Name »), un éventuel certificat auto-signé et le protocole négocié. L’alerte « à renouveler » se déclenche sous 30 jours : c’est un seuil de l’outil, aucune source ne le fixe.

Ensuite la redirection de http:// vers https://. Google recommande les redirections permanentes côté serveur, de préférence 301 ou 308.² Une page http:// qui répond 200 sans rediriger laisse le site en deux versions. Une redirection qui revient de HTTPS vers HTTP est le pire cas : voir plus bas.

Puis l’en-tête HSTS : sa présence, son max-age, includeSubDomains et preload. Enfin le contenu mixte : chaque ressource en http:// du HTML, classée selon ce que font les navigateurs.

HTTPS et Google

Google préfère la version HTTPS d’une page quand il choisit l’adresse canonique. Il fait des exceptions en cas de problème ou de signaux contradictoires, qu’il énumère : un certificat SSL invalide, des dépendances non images servies en HTTP, une redirection vers une page HTTP ou qui passe par elle.¹ L’outil reprend ces trois cas dans ses constats.

Sur le classement, la documentation de Google range le service sécurisé parmi les aspects de l’expérience sur la page, puis précise qu’il n’existe pas de signal unique et qu’au-delà des Core Web Vitals, ces aspects n’aident pas directement un site à mieux se classer.³ Le HTTPS sert donc surtout à ne pas perdre la version canonique et à protéger les visiteurs.

Le contenu mixte

On parle de contenu mixte quand une page HTTPS charge une ressource en HTTP. MDN explique que ces ressources peuvent être lues, voire modifiées, par un attaquant, les scripts étant les plus dangereux.⁴

Les navigateurs récents distinguent deux cas. Les ressources « mises à niveau » sont réécrites en https automatiquement : images en src, audio, vidéo et leurs sources. Les autres sont bloquées : scripts, feuilles de style, cadres, objets, images en srcset ou dans un élément picture. Une image appelée par adresse IP n’est jamais mise à niveau.⁴ L’outil range chaque ressource dans l’une de ces deux catégories.

Le HSTS

L’en-tête Strict-Transport-Security dit au navigateur qu’un hôte ne se visite qu’en HTTPS. Son max-age donne la durée en secondes ; includeSubDomains étend la règle aux sous-domaines.⁵ La RFC 6797 fixe que le navigateur ignore l’en-tête reçu en HTTP, qu’un hôte ne doit en envoyer qu’un seul et ne doit pas le mettre dans ses réponses HTTP.⁶

Le HSTS ne protège pas la toute première visite, avant que le navigateur ait reçu l’en-tête. La liste de préchargement comble ce trou, à condition d’un max-age d’au moins 31 536 000 secondes, de includeSubDomains et de la directive preload.⁵ Le HSTS reste facultatif : l’outil le signale « à noter » quand il manque, jamais « à corriger ».

Ce que l’outil ne voit pas

L’outil lit le HTML de la page, sans exécuter de JavaScript : une ressource en http:// ajoutée par un script n’apparaît pas. Il ne lit pas les feuilles de style, donc les url() en http:// qu’elles contiennent lui échappent. Il lit 1,5 Mo de HTML au plus.

Il ne contrôle pas la chaîne complète des certificats intermédiaires, ne teste pas les anciennes versions de TLS ni la liste de préchargement elle-même, et affiche le protocole négocié sans le juger. Chaque vérification compte pour une requête sur un quota de 20 par tranche de 10 minutes et par visiteur, partagé avec les autres outils du site. Le serveur ne conserve ni l’adresse ni le résultat.

Après le test

Une fois le HTTPS en place, vérifiez qu’il n’y a qu’un seul saut : le vérificateur de redirections suit toute la chaîne. L’analyseur d’en-têtes HTTP lit les autres en-têtes de sécurité, et le test d’indexabilité dit si la page reste indexable.

Questions fréquentes