Certificats SSL/TLS

En bref — Un certificat SSL/TLS est le fichier installé sur votre serveur qui rend possibles le cadenas et https://. Il existe des offres bon marché et coûteuses, mais elles se valent pour le SEO : Google vérifie que l’URL commence par https://, pas le certificat acheté. Un certificat Let’s Encrypt gratuit se classe comme un certificat onéreux. Le véritable risque est un certificat défectueux : s’il expire ou est mal configuré, le navigateur affiche un avertissement inquiétant et les visiteurs repartent.

Ce qu’est réellement un certificat SSL

Le HTTPS moderne utilise des certificats TLS pour authentifier un domaine et établir une connexion chiffrée. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 8446: TLS 1.3 Google recommande HTTPS et l’emploie comme signal de canonicalisation, mais ni le prix ni le niveau de validation du certificat ne procurent d’avantage de classement documenté. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: HTTPS

Touchez pour agrandir

The chart groups observed certificate issuance by duration, from three days or less through more than 200 days. The 47-to-100-day bucket dominates this captured period.

Lorsque vous ouvrez un site sécurisé, le navigateur et le serveur effectuent une brève négociation pour établir le chiffrement. Le certificat est remis par le serveur pendant cet échange. Il atteste, à un certain degré, l’identité du propriétaire du site et contient la clé qui chiffre la connexion.

On parle couramment de « certificat SSL », mais le protocole moderne est TLS. Le nom SSL est simplement resté. Le dossier HTTPS explique cette terminologie et la question de l’effet de HTTPS sur le classement ; cette page examine le certificat lui-même.

Un certificat plus cher améliore-t-il le SEO ?

Non. C’est le mythe le plus répandu. Google ne documente aucune différence de classement selon le type, l’émetteur ou le prix du certificat, dès lors que HTTPS est valide. Pour le moteur, une offre à 300 dollars par an ne vaut pas mieux qu’une offre gratuite. John Mueller l’a dit sans détour : “this does not ‘Boost your website’s SEO’, sorry.” (traduction) : « cela n’améliore pas le SEO de votre site, désolé ».

Un certificat Let’s Encrypt gratuit se classe donc exactement comme l’offre la plus chère d’un vendeur. Le supplément finance des signaux de confiance destinés aux humains, détaillés dans l’onglet Avancé, et non un avantage de classement.

Les formes de certificats

Deux dimensions varient et doivent rester distinctes :

• Le niveau de vérification. Un certificat élémentaire prouve uniquement le contrôle du domaine. Les offres plus coûteuses vérifient l’identité juridique de l’entreprise. Cela ne change rien pour Google.
• Le périmètre couvert. Un certificat peut viser un seul nom d’hôte, un ensemble de sous-domaines grâce à un wildcard, ou une liste précise de noms avec un certificat SAN.

Ce qui compte réellement pour le SEO

Un certificat fonctionnel passe inaperçu. Un certificat défectueux pose problème :

• Un certificat expiré déclenche un avertissement plein écran. Les visiteurs repartent avant d’avoir vu la page ; cela peut ressembler à une chute de classement, alors qu’ils restent simplement à la porte.
• Une défaillance grave peut aussi conduire Google à préférer la version HTTP à la version HTTPS. Google privilégie normalement HTTPS, mais sa documentation précise qu’un mauvais certificat l’emporte sur cette préférence, même avec HSTS.
• Si les erreurs s’accumulent, Google peut cesser entièrement d’explorer les pages HTTPS, qui finissent alors par disparaître des résultats.

La règle pratique est simple : choisissez l’offre peu coûteuse ou gratuite et ne la laissez jamais expirer. Activez le renouvellement automatique, puis n’y pensez plus.

Pour aller plus loin — DV, OV et EV, wildcard et SAN, chaînes de certificats, réduction des durées et comportement exact des robots en cas d’échec — passez à l’onglet Avancé.

En bref — Google ne documente aucune différence de classement entre les niveaux DV, OV et EV, ni entre émission gratuite et payante : un certificat plus cher achète de la confiance humaine ou organisationnelle, pas des positions. Le niveau de validation et le périmètre de couverture sont deux décisions indépendantes. Let’s Encrypt et l’émission ACME automatisée ne constituent pas un compromis. Les certificats affectent le SEO lorsqu’ils échouent : expiration, auto-signature, nom d’hôte incorrect ou chaîne incomplète peuvent casser la page, faire préférer HTTP à HTTPS par Google malgré HSTS et même conduire Google à cesser d’explorer les pages HTTPS. Avec une validité maximale appelée à tomber à 47 jours en 2029, le renouvellement automatisé est obligatoire.

Le dossier HTTPS explique que HTTPS n’est au mieux qu’un critère de départage, que Google examine le schéma plutôt que le certificat et qu’un certificat DV gratuit reçoit le même signal qu’un OV ou EV coûteux. Ici, nous descendons d’un niveau : signification de DV, OV et EV, périmètre de couverture, certificats gratuits automatisés, chaînes qui échouent discrètement et conséquences réelles d’une défaillance sur l’exploration.

Un « certificat SSL » est en réalité un certificat TLS

SSL est une appellation obsolète dans les déploiements TLS modernes. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 8446: TLS 1.3 Les consignes de recherche portent sur un HTTPS valide et accessible, non sur le niveau commercial du certificat. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: HTTPS

SSL, pour Secure Sockets Layer, est l’ancien protocole ; les certificats actuels utilisent TLS (Transport Layer Security). L’expression « certificat SSL » est restée dans l’usage et apparaît encore dans les messages de Search Console. La suite emploie simplement « certificat ».

Profondeur de validation : DV, OV, IV et EV

Les certificats sont émis selon différents niveaux de validation, qui indiquent l’étendue des vérifications effectuées par l’autorité de certification avant de répondre de votre identité. D’après SSL.com :

• DV (Domain Validation) est “the lowest level of validation, and verifies that whoever requests the certificate controls the domain that the certificate protects.” (traduction) : « le niveau de validation le plus faible ; il vérifie que le demandeur contrôle le domaine protégé ». Rapide et souvent automatisé, il repose sur un enregistrement DNS ou un fichier accessible à l’autorité.
• OV (Organization Validation) “verifies the identity of the organization (e.g. a business, nonprofit, or government organization) of the Subject listed in the certificate, along with the location where the organization operates.” (traduction) : « vérifie l’identité et le lieu d’activité de l’organisation mentionnée dans le certificat ».
• IV (Individual Validation) “verifies the identity of the individual person listed as the Subject of the certificate.” (traduction) : « vérifie l’identité de la personne physique mentionnée comme sujet ».
• EV (Extended Validation), “like OV, verifies the identity of an organization. However, EV represents a higher standard of trust than OV and requires more rigorous validation checks.” (traduction) : « vérifie l’organisation comme OV, mais impose un niveau de confiance et des contrôles plus rigoureux ».

Point essentiel pour le SEO : Google ne documente aucune différence de classement entre ces niveaux. Son signal porte sur le schéma de l’URL. Tant que HTTPS fonctionne, DV, OV et EV reçoivent le même traitement. La différence de prix reflète le travail de vérification et la responsabilité de l’autorité. web.dev résume : “different CAs charge different amounts of money for the service of vouching for your public key.” (traduction) : « les autorités facturent des montants différents pour garantir votre clé publique ». Le supplément achète de la confiance humaine et organisationnelle.

Le dernier argument visuel en faveur d’EV a largement disparu : les navigateurs n’affichent plus le traitement spécial d’EV dans la barre d’adresse. Chrome l’a retiré avec Chrome 77 en 2019, puis Firefox 70 la même année. Vérifiez le comportement actuel avant un achat, mais ce signal visuel n’existe plus dans les principaux navigateurs.

Périmètre de couverture : domaine unique, wildcard ou SAN

Le niveau de validation est un axe ; le périmètre de couverture, c’est-à-dire les noms d’hôte sécurisés, en est un autre. Chaque périmètre peut généralement être émis en DV ou OV, tandis que les wildcards ne sont habituellement pas proposés en EV selon les règles CA/B :

• Domaine unique — couvre exactement un nom d’hôte, par exemple www.example.com.
• Wildcard — couvre un motif sur une seule étiquette DNS. web.dev précise : “In wildcard certificates, the wildcard applies to only one DNS label. A certificate good for *.example.com works for foo.example.com and bar.example.com, but not for foo.bar.example.com.” (traduction) : « le wildcard ne s’applique qu’à une étiquette DNS ; il couvre foo et bar sous example.com, mais pas foo.bar.example.com ». Il ne couvre donc pas les sous-domaines de deuxième niveau.
• SAN / multidomaine (UCC) — énumère explicitement les noms d’hôte dans Subject Alternative Names. web.dev mentionne des “options for mapping your key to more than one DNS name, including several distinct names (e.g. all of example.com, www.example.com, example.net, and www.example.net).” (traduction) : « options permettant d’associer une clé à plusieurs noms DNS distincts, comme les quatre noms cités ». Un SAN peut même réunir plusieurs domaines.

Le piège pratique vient de la limite du wildcard. Avec *.example.com, staging.blog.example.com se trouve deux niveaux plus bas et reste hors couverture. Il renverra une erreur ou un certificat dont le nom ne correspond pas, alors que vous pensiez l’avoir protégé.

Autre piège : un test réussi sur le domaine racine ne prouve pas la couverture de tous les hôtes. Avec SNI, un CDN, un équilibreur de charge ou un hébergement mutualisé peut servir des certificats différents selon l’hôte, la région ou l’origine. Testez chaque nom public séparément ; un résultat propre sur example.com ne garantit rien pour www., un point de présence régional ou un sous-domaine servi ailleurs.

Let’s Encrypt et émission gratuite automatisée

Let’s Encrypt et d’autres autorités gratuites émettent des certificats DV via ACME, une boucle automatisée de demande, défi et émission exécutée par des clients comme Certbot. Deux idées reçues doivent être corrigées :

1. Gratuit ne signifie pas plus faible. Let’s Encrypt fournit la même robustesse de chiffrement et le même traitement de classement qu’une offre payante. Les seules différences réelles sont la validation DV uniquement et une durée courte.
2. Une courte durée devient un avantage quand tout est automatisé. Elle réduit la période d’exposition d’une clé compromise et supprime la dépendance à un rappel humain.

Ce deuxième point concernera bientôt tout le monde, pas seulement Let’s Encrypt.

Réduction de la durée des certificats (2026–2029) : automatisez maintenant

Le secteur réduit les durées selon un calendrier fixe. Le CA/Browser Forum a adopté le Ballot SC-081v3, dont le vote s’est achevé le 11 avril 2025 :

• 398 jours actuellement
• 200 jours à compter du 15 mars 2026
• 100 jours à compter du 15 mars 2027
• 47 jours à compter du 15 mars 2029

Let’s Encrypt suit aussi une trajectoire plus rapide. Selon sa mise à jour de février 2026, la durée par défaut doit diminuer en deux étapes au cours des deux années suivantes, “from 90 days to 64 days, and then 45 days” (traduction) : « de 90 à 64 jours, puis à 45 jours ». Le renouvellement passera d’environ le 60e jour à environ le 30e. Les dates exactes ne sont pas verrouillées ; consultez le journal de Let’s Encrypt avant de vous appuyer sur une échéance précise.

Conclusion opérationnelle : si le renouvellement n’est pas automatisé, corrigez-le avant 2027. Une cadence manuelle supportable à 398 jours provoquera presque inévitablement une panne à 47 ou 100 jours. DigiCert indique que la revalidation manuelle restera possible, mais que “doing so would be a recipe for failure and outages.” (traduction) : « ce serait une recette pour les échecs et les pannes ». L’automatisation devient la seule option raisonnable.

Défaillances de chaîne et de certificat intermédiaire

Ce mécanisme est rarement expliqué et la documentation Google ne le décrit pas en détail.

Un navigateur ne fait confiance qu’à un petit ensemble de certificats racines intégrés à son magasin. Le certificat de votre serveur, dit final ou leaf, est presque toujours signé par un ou plusieurs certificats intermédiaires, eux-mêmes reliés à une racine. Le serveur doit transmettre le certificat final et les intermédiaires pour que le client construise ce chemin de confiance.

La mauvaise configuration classique consiste à n’envoyer que le certificat final. Le problème est trompeur : Chrome sur ordinateur peut encore fonctionner, car il met en cache des intermédiaires rencontrés ailleurs et comble le manque. Le testeur voit donc un cadenas vert, alors que les navigateurs mobiles, de nombreux clients API/HTTP et les outils sans cet intermédiaire échouent complètement lors de la négociation. C’est un défaut TLS qui « fonctionne sur ma machine ».

Ne vous contentez pas d’un test ponctuel avec Chrome. Utilisez un outil qui reconstruit la chaîne :

• SSL Labs Server Test signale explicitement les téléchargements supplémentaires et les chaînes incomplètes.
• openssl s_client -connect example.com:443 -showcerts affiche chaque certificat réellement envoyé par le serveur afin de confirmer la présence de l’intermédiaire.

Effet d’un certificat invalide, expiré ou auto-signé

C’est la partie la plus importante. Les utilisateurs et les robots ne subissent pas la défaillance de la même manière.

Utilisateurs et navigateurs. Une expiration, une auto-signature, un nom d’hôte incorrect ou une autorité non reconnue déclenche un interstitiel plein écran, bien plus sévère que la mention HTTP « Non sécurisé ». Les visiteurs repartent. Dans l’étude A Wolf in Panda’s Clothing de Glenn Gabe, le trafic d’un site e-commerce s’est effondré le jour d’une mise à jour Panda. La cause réelle était un certificat expiré. Une panne technique qui coïncide avec une mise à jour d’algorithme peut prêter à confusion. Après renouvellement, le trafic est revenu en huit jours environ. Les certificats auto-signés conviennent à l’interne, jamais à un site public.

Comportement de Google. Sa documentation de canonicalisation précise : “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals,” (traduction) : « Google préfère les pages HTTPS équivalentes comme canoniques, sauf problème ou signal contradictoire ». Elle cite directement les mauvais certificats : “Avoid bad TLS/SSL certificates and HTTPS-to-HTTP redirects because they cause Google to prefer HTTP very strongly. Implementing HSTS cannot override this strong preference.” (traduction) : « Évitez les mauvais certificats et les redirections HTTPS vers HTTP, qui font fortement préférer HTTP ; HSTS ne peut pas annuler cette préférence ». Une défaillance peut donc ramener la canonique vers HTTP.

La documentation Search Console ajoute une conséquence d’exploration : un certificat invalide “typically affects an entire site,” (traduction) : « touche généralement le site entier », et “if a site has a lot of HTTPS issues, it can prompt Google to stop crawling your HTTPS pages.” (traduction) : « si un site comporte beaucoup de problèmes HTTPS, Google peut cesser d’explorer ses pages HTTPS ». Les autres URL portent alors l’état « HTTPS non évalué ». Le basculement de la canonique et l’arrêt de l’exploration sont deux mécanismes distincts, capables tous deux de retirer des pages de l’index sans changer le signal de classement associé à https://.

La liste d’erreurs de Google reprend la même taxonomie : “The host name of your site does not match any of the Subject Names in your SSL certificate” (traduction) : « le nom d’hôte ne correspond à aucun nom de sujet du certificat », ainsi que les certificats “not recognized by major web browsers” (traduction) : « non reconnus par les principaux navigateurs », notamment lorsqu’ils sont auto-signés, corrompus, émis par une autorité non fiable, expirés ou pas encore valides.

Surveillance de l’expiration et renouvellement automatique

L’expiration est la défaillance la plus fréquente et la plus évitable. Son rayon d’impact est asymétrique : elle casse généralement tout le site à la fois. Google dit “Typically this affects an entire site” (traduction) : « cela touche généralement le site entier ». N’utilisez jamais un simple rappel de calendrier ; automatisez réellement :

• ACME / Certbot sur votre serveur, ou l’équivalent fourni par la plateforme.
• Certificats gérés par l’hébergeur ou le CDN, par exemple Cloudflare, qui les émet et les renouvelle automatiquement.
• Surveillance tierce du certificat et de la disponibilité, qui alerte avant l’expiration et lors d’un échec de négociation, même si le renouvellement est automatisé.

Avec une durée maximale proche de 47 jours, les rappels manuels deviennent intenables : l’automatisation est la seule approche extensible.

Certificats différents selon les sous-domaines

Ce cas diffère du contenu mixte, où une page HTTPS charge des ressources HTTP. Un montage multi-certificats sécurise différentes parties du site avec des certificats, calendriers ou plateformes distincts. Le domaine principal peut être impeccable tandis que blog.example.com expire sur une autre plateforme, qu’un sous-domaine marketing échappe au wildcard ou qu’un hébergement SNI mutualisé rate discrètement un renouvellement.

Leçon : le cadenas valide de la page d’accueil ne prouve rien pour le reste du site. Inventoriez les sous-domaines, confirmez que chacun possède une couverture valide et surveillée — certificat propre, wildcard qui l’atteint ou SAN qui l’énumère — et ne considérez jamais un test SSL Labs sur un seul hôte comme une certification de l’ensemble.

Mythes courants

• « Un certificat payant ou EV se classe mieux qu’un DV gratuit. » Non : le signal porte sur le schéma et Google ne voit pas la profondeur de validation.
• « Un wildcard couvre tous les sous-domaines, même les sous-sous-domaines. » Non : une seule étiquette DNS ; *.example.com ne couvre pas foo.bar.example.com.
• « Un certificat expiré nuit directement au classement. » Pas par le signal de base, mais il peut faire préférer HTTP à HTTPS et, séparément, conduire Google à arrêter l’exploration des pages HTTPS.
• « Let’s Encrypt est de moindre qualité. » Non : même chiffrement et même traitement ; seules diffèrent la validation DV et la courte durée.
• « Si la page d’accueil affiche un cadenas, tous les certificats vont bien. » Non : les sous-domaines peuvent suivre des certificats et calendriers distincts.
• « Les erreurs de chaîne sont rares ou anciennes. » Non : elles apparaissent dès qu’un serveur n’envoie que le certificat final, et le cache de Chrome peut les masquer au testeur.

Cette analyse approfondie complète le dossier HTTPS ; commencez par celui-ci pour le plan de migration, le contenu mixte et HSTS.

Résumé par l’IA

Version condensée de l’onglet Avancé :

• Google ne documente aucune différence de classement entre les niveaux. Avec un HTTPS valide, DV, OV, IV et EV reçoivent le même traitement, tout comme un certificat Let’s Encrypt gratuit et une offre payante. John Mueller : “this does not ‘Boost your website’s SEO’, sorry.” (traduction) : « cela n’améliore pas le SEO de votre site, désolé ».
• Deux axes indépendants : profondeur de validation, de DV à EV, et périmètre de couverture, entre domaine unique, wildcard et SAN. Google ne voit aucun des deux.
• Un wildcard ne couvre qu’une étiquette DNS. *.example.com couvre foo.example.com, mais pas foo.bar.example.com. Un SAN énumère explicitement les hôtes et peut réunir plusieurs domaines.
• L’interface spéciale EV a disparu de Chrome 77 et Firefox 70 en 2019, supprimant son dernier avantage visuel.
• L’émission gratuite automatisée avec ACME ou Certbot n’est pas un compromis : même chiffrement, même classement. Une courte durée devient un avantage lorsqu’elle est automatisée.
• Réduction des durées : le Ballot SC-081v3 du CA/B Forum fait passer le maximum de 398 à 200 jours en mars 2026, 100 en mars 2027, puis 47 jours en mars 2029. Let’s Encrypt prévoit séparément 90, puis 64 et 45 jours. Automatisez maintenant.
• Les erreurs de chaîne peuvent rester invisibles : le serveur omet l’intermédiaire, Chrome sur ordinateur le retrouve en cache, mais les mobiles et clients API échouent. Diagnostiquez avec SSL Labs ou openssl s_client -showcerts.
• Utilisateurs et Google réagissent différemment : les premiers voient un avertissement plein écran ; Google peut préférer HTTP à HTTPS malgré HSTS et, séparément, “stop crawling your HTTPS pages” (traduction) : « cesser d’explorer vos pages HTTPS ».
• L’expiration casse souvent tout le site à la fois. Automatisez et surveillez. Des certificats distincts selon les sous-domaines signifient que le cadenas de la page d’accueil ne prouve rien pour le reste.

Documentation officielle

Sources primaires des moteurs, autorités et organismes de normalisation.

Google

• Rapport HTTPS dans l’aide Search Console — formulations “affects an entire site,” (traduction) : « touche un site entier », et “stop crawling your HTTPS pages” (traduction) : « cesser d’explorer vos pages HTTPS ».
• Problèmes de certificat SSL — erreurs de nom d’hôte, d’auto-signature et d’autorité non reconnue.
• Activer HTTPS sur vos serveurs — autorités, demandes de signature, portée des wildcards et association de plusieurs noms.
• Consolider les URL dupliquées — préférence canonique pour HTTPS, exceptions en cas de problème et impossibilité pour HSTS de surmonter un mauvais certificat.

Autorités et normes

• Certificats DV, OV, IV et EV — définitions des niveaux de validation.
• Let’s Encrypt — autorité DV gratuite et automatisée.
• Protocole ACME et Certbot — client d’automatisation courant pour les serveurs autogérés.
• Durées plus courtes et limites de débit — plan actuel de réduction des durées de Let’s Encrypt.
• CA/Browser Forum — organisme qui fixe les durées maximales, notamment avec le Ballot SC-081v3.

Citations des sources

Déclarations publiques. Chaque lien mène directement au passage cité.

Google — erreurs de certificat dans Search Console

• “The HTTPS URL has an invalid SSL certificate. Typically this affects an entire site.” (traduction) : « L’URL HTTPS possède un certificat SSL invalide. Cela touche généralement un site entier. » — Aide Google Search Console, rapport HTTPS. Accéder à la citation
• “If a site has a lot of HTTPS issues, it can prompt Google to stop crawling your HTTPS pages.” (traduction) : « Si un site comporte beaucoup de problèmes HTTPS, Google peut cesser d’explorer vos pages HTTPS. » — Aide Google Search Console, rapport HTTPS. La phrase essentielle de ce sujet : la conséquence réelle d’un certificat défectueux sur l’exploration. Accéder à la citation
• “The host name of your site does not match any of the Subject Names in your SSL certificate.” (traduction) : « Le nom d’hôte de votre site ne correspond à aucun nom de sujet de votre certificat SSL. » — Aide Google Search Console consacrée aux problèmes de certificat SSL. Accéder à la citation
• “Your site uses an SSL certificate which is not recognized by major web browsers.” (traduction) : « Votre site utilise un certificat SSL non reconnu par les principaux navigateurs. » — Aide Google Search Console, problèmes de certificat SSL. Accéder à la citation

Google — préférence canonique et mauvais certificats

• “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals.” (traduction) : « Google préfère les pages HTTPS équivalentes comme canoniques, sauf problème ou signal contradictoire. » / “Avoid bad TLS/SSL certificates and HTTPS-to-HTTP redirects because they cause Google to prefer HTTP very strongly. Implementing HSTS cannot override this strong preference.” (traduction) : « Évitez les mauvais certificats TLS/SSL et les redirections HTTPS vers HTTP, qui font fortement préférer HTTP. HSTS ne peut pas annuler cette préférence. » — Google Search Central, consolidation des URL dupliquées. Lire la source

Google / web.dev — périmètre et coût des certificats

• “In wildcard certificates, the wildcard applies to only one DNS label. A certificate good for *.example.com works for foo.example.com and bar.example.com, but not for foo.bar.example.com.” (traduction) : « Dans un certificat wildcard, le joker ne s’applique qu’à une étiquette DNS ; il couvre foo et bar sous example.com, mais pas foo.bar.example.com. » — web.dev, activation de HTTPS sur les serveurs. Accéder à la citation
• “Different CAs charge different amounts of money for the service of vouching for your public key.” (traduction) : « Les autorités facturent des montants différents pour garantir votre clé publique. » — web.dev, activation de HTTPS sur les serveurs. Accéder à la citation

SSL.com — niveaux de validation

• “Domain Validation (DV) is the lowest level of validation, and verifies that whoever requests the certificate controls the domain that the certificate protects.” (traduction) : « DV est le niveau le plus faible et vérifie que le demandeur contrôle le domaine protégé. » Accéder à la citation
• “Extended Validation (EV), like OV, verifies the identity of an organization. However, EV represents a higher standard of trust than OV and requires more rigorous validation checks.” (traduction) : « EV vérifie l’organisation comme OV, mais impose un niveau de confiance et des contrôles plus rigoureux. » Accéder à la citation

John Mueller, Google Search Relations (réponse sur les réseaux sociaux reprise par Search Engine Journal en mai 2023)

• “@EncryptedFence this does not ‘Boost your website’s SEO’, sorry.”(traduction) : « Cela n’améliore pas le SEO de votre site, désolé. » “Quoted from Mueller’s Mastodon reply via Search Engine Journal — INDUSTRY-tier corroboration of the OFFICIAL scheme-based framing, not a Google-owned page. Confirm against the original post if quoting directly.” (traduction) : « Citation de la réponse Mastodon de Mueller via Search Engine Journal : corroboration sectorielle du cadre officiel fondé sur le schéma, et non page détenue par Google. Vérifiez la publication originale avant toute citation directe. » Lire l’article

Glenn Gabe, GSQi (étude de cas sur un certificat expiré, septembre 2013)

• “There are times that SEO problems aren’t really SEO problems. Technical issues that appear at the same time algorithm updates hit can be confusing.”(traduction) : « Certains problèmes apparemment SEO n’en sont pas ; une panne technique qui coïncide avec une mise à jour d’algorithme peut prêter à confusion. » “Industry case study; 2013 browser-UI details are dated but the diagnostic lesson is evergreen.” (traduction) : « Étude sectorielle : l’interface des navigateurs de 2013 est datée, mais la leçon de diagnostic reste valable. » Lire l’étude de cas

Quel certificat choisir ?

Suivez les questions dans l’ordre. Les deux premières règlent l’essentiel ; la suite concerne le périmètre.

1. Le site doit-il être classé par Google ? Ce besoin est déjà couvert par https:// : tout certificat valide procure le même signal. Cette question ne justifie donc jamais une offre plus chère.

2. Devez-vous présenter aux humains une identité organisationnelle vérifiée, notamment pour une obligation juridique ou de conformité ?

• Non, cas de la grande majorité des blogs, sites éditoriaux et boutiques → certificat DV, gratuit avec Let’s Encrypt et automatisé.
• Oui, notamment banque ou environnement réglementé imposant OV/EV → OV, ou EV si l’exigence le nomme. EV n’affiche plus d’indicateur spécial dans Chrome 77+ ni Firefox 70+ : vous payez la vérification, pas un badge.

3. Combien de noms d’hôte faut-il sécuriser ? Le périmètre reste indépendant de l’étape 2.

• Un nom, comme www.example.com → certificat domaine unique.
• Plusieurs sous-domaines de premier niveau, comme shop., blog. et app. sous example.com → wildcard *.example.com. Vérifiez qu’aucun n’est de deuxième niveau, tel api.staging.example.com.
• Une liste précise, éventuellement sur plusieurs domaines, comme example.com, example.net et brand.io → certificat SAN / multidomaine (UCC) qui énumère chaque nom.
• Des sous-domaines de deuxième niveau hors de portée du wildcard → deuxième wildcard à ce niveau ou ajout explicite dans un SAN.

4. Quel algorithme de clé et combien de points de présence servent réellement l’hôte ? RSA ou ECDSA relève de la sécurité et de la compatibilité client, pas du classement. Certains clients anciens ou embarqués ne gèrent pas ECDSA. Si plusieurs régions, origines, CDN ou équilibreurs répondent, testez chaque chemin : une réussite sur l’un ne valide pas les autres.

5. Le renouvellement sera-t-il automatisé ?

• Oui → parfait ; les courtes durées conviennent et le maximum tombera à 47 jours en 2029.
• Non → corrigez cela d’abord. Utilisez ACME, Certbot ou un certificat géré par l’hébergeur ou le CDN.

Vous diagnostiquez une erreur en production ? Quel symptôme observez-vous ?

• Fonctionne dans Chrome sur ordinateur, échoue sur mobile ou dans les outils → probablement un intermédiaire manquant. Testez avec SSL Labs ou openssl s_client -showcerts, puis installez la chaîne complète.
• Tout le site avertit ou chute soudainement → vérifiez d’abord l’expiration.
• Un seul sous-domaine avertit → trou de couverture ou certificats distincts.
• L’avertissement nomme un autre site → nom d’hôte incorrect, absent des Subject Names.

Liste de contrôle de santé des certificats

Vérifiez que les certificats sont valides, couvrent tous les hôtes et n’expireront pas discrètement :

• Chaque nom d’hôte public — domaine racine, www et chaque sous-domaine — sert un certificat valide et reconnu, pas seulement la page d’accueil.
• La chaîne complète est installée, certificat final et intermédiaire, et vérifiée avec SSL Labs ou openssl s_client -showcerts, pas avec un test Chrome ponctuel.
• Le renouvellement est automatisé par ACME, Certbot, l’hébergeur, le CDN ou la PaaS ; aucun rappel humain ne subsiste.
• Un moniteur de certificat et de disponibilité alerte avant l’expiration et lors d’un échec de négociation.
• Aucun nom d’hôte incorrect : chaque hôte figure dans les Subject Alternative Names ou relève d’un wildcard qui l’atteint.
• Les wildcards respectent la limite d’une étiquette : aucun a.b.example.com ne se trouve hors de *.example.com.
• Aucun certificat auto-signé sur un hôte public de production ; ils restent acceptables en développement.
• La profondeur de validation répond à un besoin humain ou de conformité, pas à une attente SEO.
• Le rapport HTTPS de Search Console ne présente ni « certificat invalide » ni « HTTPS non évalué ».
• Les sous-domaines sur des plateformes ou CDN différents sont inventoriés et disposent chacun d’un renouvellement surveillé.

Modèles mentaux

1. Deux axes, pas un seul. Un certificat possède une profondeur de validation — DV, OV, IV ou EV — et un périmètre de couverture — domaine unique, wildcard ou SAN. Ils sont indépendants. Google ne voit aucun des deux.

2. Le signal de classement ne distingue pas les niveaux. Un https:// valide reçoit le même petit signal quels que soient l’émetteur, le prix et le niveau de validation. Demander quel niveau améliore le SEO constitue donc une erreur de catégorie. Cela ne signifie pas qu’une défaillance est invisible.

3. Une défaillance est une urgence de canonicalisation, d’accès d’exploration et d’expérience utilisateur, jamais une question de niveau de classement. Quand le certificat casse, les utilisateurs repartent devant l’avertissement, Google peut préférer HTTP à HTTPS malgré HSTS et peut cesser d’explorer les pages HTTPS. Corrigez le certificat ; aucun levier de classement ne compensera la panne.

4. L’automatisation devient centrale à mesure que les durées diminuent. Le secteur se dirige vers 47 jours. Une fois le renouvellement automatisé, une courte durée est plus sûre : moindre fenêtre de compromission et aucun oubli humain. Le risque réel est l’absence d’automatisation.

5. Le cadenas de la page d’accueil ne prouve qu’un nom d’hôte. Couverture, échéances et plateformes varient entre sous-domaines. Inventoriez et surveillez chaque hôte.

6. Testez la chaîne, pas votre ordinateur. Chrome sur ordinateur met les intermédiaires en cache et peut masquer une erreur. Validez depuis un constructeur propre, avec SSL Labs ou openssl s_client.

Certificats SSL/TLS : fiche pratique

Profondeur de validation

Périmètre de couverture

Réduction de la durée maximale selon le CA/Browser Forum

Quand un certificat casse

À retenir

• Un DV gratuit de Let’s Encrypt offre le même chiffrement et le même classement qu’un certificat payant.
• Le signal de Google lit le schéma, pas le certificat.
• Une accumulation de problèmes HTTPS peut interrompre l’exploration des pages HTTPS par Google.
• Automatisez avec ACME/Certbot ou un certificat géré par l’hébergeur ou le CDN.

Inspecter un certificat et sa chaîne complète

La commande la plus utile pour diagnostiquer un certificat. -showcerts affiche chaque certificat réellement envoyé par le serveur, ce qui révèle rapidement un intermédiaire manquant.

macOS / Linux

# Show the full chain the server sends (leaf + intermediates)
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

# Just the expiry dates (notBefore / notAfter)
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates

# The hostnames the cert actually covers (Subject Alternative Names)
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

L’option -servername définit SNI. Elle est essentielle sur un hébergement mutualisé ou un CDN où une même adresse IP sert plusieurs certificats.

Windows (PowerShell) — vérifier l’expiration et les noms couverts

# Pull the served certificate and read its expiry + Subject Alternative Names
$req = [Net.HttpWebRequest]::Create("https://example.com")
$req.GetResponse().Dispose()
$cert = $req.ServicePoint.Certificate
$cert2 = [System.Security.Cryptography.X509Certificates.X509Certificate2]$cert
"Expires: " + $cert2.NotAfter
$cert2.Extensions | Where-Object { $_.Oid.FriendlyName -eq "Subject Alternative Name" } |
  ForEach-Object { $_.Format($true) }

Console Chrome DevTools : repérer les sous-ressources non sécurisées

Collez ce code dans la console pour lister les ressources http:// encore référencées dans le HTML, utile comme contrôle rapide de contenu mixte pendant l’audit :

[...document.querySelectorAll('[src],[href]')]
  .map(el => el.getAttribute('src') || el.getAttribute('href'))
  .filter(u => u && u.startsWith('http://'))
  .forEach(u => console.warn('insecure:', u));

Pour contrôler tous les noms d’hôte, un validateur externe comme SSL Labs est plus efficace qu’un script lancé hôte par hôte. Ces commandes restent les vérifications rapides du serveur devant vous.

Anti-modèles liés aux certificats

Défaillances récurrentes :

Acheter EV ou OV « pour le SEO ». Google ne voit pas la profondeur de validation. Ne payez davantage que pour un besoin réel de confiance humaine ou de conformité.

Vérifier uniquement dans Chrome sur ordinateur. Chrome met les intermédiaires en cache et peut afficher un cadenas sur une chaîne qui échoue ailleurs. Validez avec SSL Labs ou openssl s_client -showcerts.

Renouveler avec des rappels manuels. Une entrée de calendrier n’est pas un système. Une expiration casse souvent tout le site et le risque augmente avec la réduction à 47 jours. Automatisez.

Supposer qu’un wildcard couvre tout le domaine. *.example.com s’arrête après une étiquette DNS. staging.api.example.com reste hors couverture.

Tester uniquement la page d’accueil. Les sous-domaines sur d’autres plateformes ou CDN ont leurs propres certificats et échéances. Le cadenas du domaine racine ne dit rien sur blog. ou un hôte marketing.

Employer un certificat auto-signé en production publique. Il déclenche un interstitiel sévère et échoue dans la plupart des validateurs et robots. Réservez-le à l’interne, au développement ou à la préproduction.

Traiter une panne comme un problème de niveau de classement, ou comme un détail inoffensif. Ce n’est pas un levier de niveau, mais la panne peut ramener la canonique vers HTTP, réduire l’accès d’exploration et détruire les conversions. Corrigez le certificat sans chercher un autre facteur de classement.

Procédure de renouvellement et de déploiement

1. Tenez un inventaire des noms d’hôte. Notez domaine racine, www, sous-domaines, niveaux plus profonds, points de terminaison CDN ou équilibreurs, émetteur, périmètre, responsable et voie d’automatisation.
2. Surveillez l’expiration indépendamment de l’émetteur. Alertez assez tôt pour diagnostiquer un échec et adaptez le délai à la durée réelle ; un rappel de calendrier ne suffit pas.
3. Exercez le renouvellement automatique. Confirmez que le flux ACME, hébergeur ou CDN peut demander, valider, installer, activer et recharger chaque processus serveur sans intervention.
4. Validez le candidat. Contrôlez hôtes et SAN demandés, profondeur du wildcard, émetteur, période de validité et chaîne intermédiaire complète.
5. Déployez sur chaque couche. Mettez à jour tous les points de présence, proxies, équilibreurs et origines qui terminent TLS.
6. Testez depuis l’extérieur. Utilisez un validateur propre et openssl s_client avec SNI sur des hôtes représentatifs, y compris des clients sans cache partagé.
7. Bouclez le processus. Confirmez la nouvelle expiration dans la surveillance, consignez le déploiement et examinez tout point qui sert encore l’ancien certificat.

Traitez tout échec de renouvellement comme un incident de disponibilité. Sur un hôte HSTS, le visiteur ne peut pas contourner l’erreur en sécurité.

Boîte à outils d’inspection

• SSL Labs Server Test — validation externe du certificat servi, de la chaîne, des noms couverts, des protocoles et des différences entre points de terminaison.
• openssl s_client — inspecte avec SNI ce que sert précisément un hôte et affiche la chaîne complète ; associez-le à openssl x509 pour les dates et SAN.
• Visionneuse de certificat et DevTools du navigateur — reproduit sur le client concerné les erreurs de nom, de confiance et d’expiration.
• Surveillance indépendante — alerte sur chaque nom inventorié, même si l’émetteur ou le CDN affirme que le renouvellement est automatique.
• Rapport HTTPS de Google Search Console — révèle les problèmes généraux de service HTTPS ; utilisez des outils de certificat pour diagnostiquer le point précis.

Testez par nom d’hôte, pas seulement par IP ou page d’accueil. Une infrastructure partagée peut servir un certificat différent selon SNI, la région ou le point de présence.

Tests avant mise en production

Test 1 : couverture des noms et de la chaîne

• Objectif : prouver que chaque hôte public reçoit un certificat reconnu qui le nomme réellement.
• Méthode : lancez SSL Labs et openssl s_client -servername sur le domaine racine, www, chaque classe de sous-domaines et les hôtes profonds hors wildcard.
• Résultat attendu : le nom correspond à un SAN, la chaîne est complète et un client propre la valide sans fournir d’intermédiaire en cache.
• Échec : nom incorrect, certificat final auto-signé, intermédiaire manquant ou certificat différent sur un point.
• Action suivante : corrigez la couverture ou la chaîne servie, redéployez et retestez tous les points concernés.

Test 2 : répétition du renouvellement automatisé

• Objectif : vérifier que le renouvellement est un processus réel, pas une hypothèse.
• Méthode : exercez la voie de préproduction ou d’essai à blanc, puis vérifiez l’installation et l’activation sur chaque couche terminant TLS.
• Résultat attendu : validation, émission, déploiement et surveillance se terminent sans sauvetage manuel.
• Échec : validation de domaine refusée, erreur de permission, point de présence obsolète ou surveillance encore liée à l’ancien certificat.
• Action suivante : réparez l’automatisation et répétez avant l’urgence de la fenêtre de production.

Test 3 : contrôle client après déploiement

• Objectif : repérer les différences de point et de client masquées par un seul navigateur.
• Méthode : testez plusieurs réseaux et clients propres, comparez numéros de série et expirations, puis examinez le rapport HTTPS de Search Console.
• Résultat attendu : tous les points servent le certificat prévu et les pages restent explorables en HTTPS.
• Échec : incohérence régionale, avertissement, régression du rapport HTTPS ou échec de crawl.
• Action suivante : mettez à niveau le point oublié ou restaurez le dernier certificat valide pendant la correction du déploiement.

Testez vos connaissances : certificats SSL/TLS

Cinq questions rapides sur le rapport entre certificats et SEO. Choisissez une réponse, puis vérifiez.

Ressources utiles

Mes conférences

• Mieux vaut prévenir que guérir avec HTTPS — SMX East 2016 (SlideShare) — analyse approfondie de TLS, des erreurs courantes et des pièges de migration. J’y signalais aussi le risque de désindexation TLS lié à SNI avec Bing et Baidu. Les statistiques d’adoption datent de 2016 et ne doivent pas être citées comme actuelles.

Mes articles associés

• Guide du débutant en SEO technique — place des certificats et de HTTPS dans l’ensemble du référencement technique.

Sources officielles ou de référence

• Le rapport HTTPS et les problèmes de certificat SSL de Google — liste des erreurs affichées par Search Console et leur signification.
• Activer HTTPS sur vos serveurs — autorités, demandes de signature, wildcards et noms multiples.
• Consolider les URL dupliquées — préférence canonique et mauvais certificats qui font préférer HTTP.
• SSL Labs Server Test — évalue la configuration TLS et signale les chaînes incomplètes.

Autres acteurs du secteur

• Certificats DV, OV, IV et EV (SSL.com) — définitions rédigées par une autorité.
• Un loup déguisé en Panda : effet d’un certificat expiré sur le trafic naturel (Glenn Gabe, GSQi) — étude de cas d’une expiration prise pour une pénalité Panda.
• Google : un certificat SSL n’améliore pas le SEO — réponse directe de John Mueller.
• Durées plus courtes et limites de débit — passage prévu par Let’s Encrypt de 90 à 64 puis 45 jours.
• La durée des certificats TLS tombera officiellement à 47 jours — calendrier du Ballot SC-081v3.
• Erreurs SSL qui affectent le SEO (SISTRIX) — synthèse pratique des erreurs de nom, expiration, protocole et contenu mixte.
• Certbot (EFF) — client ACME courant pour automatiser émission et renouvellement.

Chiffres à citer

• La durée maximale des certificats tombera à 47 jours en 2029. Le Ballot SC-081v3 du CA/Browser Forum, dont le vote s’est achevé le 11 avril 2025, prévoit 398 jours, puis 200 en mars 2026, 100 en mars 2027 et 47 en mars 2029. Ce calendrier rend le renouvellement automatisé indispensable. Source
• Let’s Encrypt fera passer sa durée par défaut de 90 à 64 puis 45 jours. Selon sa mise à jour de février 2026, le changement se déroulera en deux étapes au cours des deux années suivantes, sans dates exactes publiées pour chacune. Source
• Un certificat défectueux “typically affects an entire site.” (traduction) : « touche généralement un site entier ». Google décrit ainsi le rayon d’impact : expiration et erreur de chaîne cassent rarement une seule page. Source
• Une accumulation de problèmes HTTPS peut arrêter l’exploration des pages HTTPS par Google. Cette conséquence sur l’accès au crawl est distincte du signal de classement et du basculement canonique vers HTTP. Source
• Un mauvais certificat peut annuler la préférence canonique de Google pour HTTPS, sans que HSTS puisse l’empêcher. La documentation cite les mauvais certificats TLS/SSL parmi les raisons de préférer très fortement la version HTTP. Source

Journal des modifications