Defaults.Exposed › Corrections › Santé du certificat TLS

Comment corriger Santé du certificat TLS

Votre certificat SSL/TLS est la carte d'identité numérique qui prouve qu'un visiteur parle bien à votre site web — et non à un imposteur — et qui alimente le cadenas dans le navigateur. Ce contrôle examine si ce certificat est valide et reconnu, s'il n'est pas sur le point d'expirer, et s'il est bâti sur une cryptographie robuste et moderne.

En clair, pour votre entreprise : Un certificat cassé ou expiré remplace votre site web par un avertissement rouge plein écran « Votre connexion n'est pas privée » dans tous les navigateurs. La plupart des visiteurs partent aussitôt et ne reviennent pas — les ventes en ligne s'arrêtent, les inscriptions s'arrêtent, et la connexion censée être privée peut être discrètement interceptée.

Ce que cela peut vous coûter

• Votre certificat expire discrètement un week-end ; le lundi, chaque visiteur tombe sur un avertissement de sécurité pleine page, votre commande et vos formulaires de contact sont morts, et vous perdez des ventes chaque heure qu'il faut pour le remarquer et renouveler.
• Un client payant via le Wi-Fi d'un café ou d'un hôtel reçoit un avertissement indiquant que votre certificat ne correspond pas à votre domaine — il suppose que votre site est faux ou piraté, abandonne l'achat, et dit aux autres qu'il « avait l'air louche ».
• L'équipe informatique d'un client plus important effectue un scan de sécurité pré-contrat, voit un certificat auto-signé ou non reconnu, et vous signale comme un risque — l'affaire cale pour quelque chose qui ne coûte rien à corriger.
• Votre certificat utilise une méthode de signature dépassée ou une clé faible ; les navigateurs modernes se mettent à afficher des avertissements le concernant, et un audit de sécurité vous pénalise pour une cryptographie écartée des recommandations depuis des années.
• Vous acceptez les paiements par carte et votre prestataire de paiement vous réaudite ; une clé faible ou un certificat expiré enfreint les règles de sécurité des paiements et votre commande en ligne est gelée jusqu'à correction.

Pourquoi c'est important. Le certificat est l'élément le plus visible de la sécurité de votre site web — quand il est sain, il est invisible, et quand il casse, il met tout votre site à terre avec un avertissement effrayant qui pousse les clients droit chez les concurrents. L'expiration de certificat est la cause numéro un des pannes de site web inattendues, et elle est entièrement évitable. Obtenir un certificat valide est gratuit, et le garder sain consiste surtout à le laisser se renouveler automatiquement.

Ce que c’est, en clair

Quand quelqu’un visite votre site web, deux choses doivent se produire pour qu’il se sente en confiance pour saisir un mot de passe ou un numéro de carte. D’abord, la connexion doit être chiffrée pour que des inconnus ne puissent pas la lire. Ensuite — et c’est la partie qu’on oublie — le navigateur du visiteur doit être sûr que c’est bien votre site à l’autre bout, et non un imposteur ayant monté un faux convaincant. Ce qui assure ces deux rôles, c’est votre certificat TLS (souvent appelé « certificat SSL »).

Voyez-le comme une carte d’identité inviolable pour votre domaine. Une autorité reconnue la délivre, elle est estampillée de votre nom de domaine et d’une date d’expiration, et elle porte la clé cryptographique qui brouille la connexion. Quand tout est en règle, le navigateur affiche le cadenas et votre site se charge normalement. Quand quelque chose cloche avec la carte d’identité, le navigateur fait l’inverse de rassurer votre visiteur — il dresse un avertissement plein écran qui dit, en substance, « ce site n’est peut-être pas sûr ».

Ce contrôle examine la santé de cette carte d’identité sur quatre points qui, chacun, peuvent la casser indépendamment :

• Est-il valide et reconnu ? — délivré par une autorité reconnue, correspondant à votre domaine exact, non auto-signé, et non expiré.
• Est-il sur le point d’expirer ? — car un certificat qui périme met tout votre site à terre.
• Est-il signé avec une méthode robuste ? — les anciens algorithmes de signature peuvent être falsifiés.
• Sa clé est-elle assez forte ? — une clé faible peut, en principe, être cassée.

La bonne nouvelle d’emblée : obtenir un certificat sain est gratuit, et le garder sain consiste surtout à le laisser se renouveler tout seul pour qu’aucun humain n’ait à y penser.

Ce que cela peut vous coûter

• La panne du week-end. Un certificat atteint discrètement sa date d’expiration tard un vendredi. Le renouvellement censé tourner ne s’est pas exécuté (un serveur a bougé, un script a cassé, personne n’a remarqué). Le samedi matin, chaque visiteur — et chaque robot Google — voit un avertissement rouge pleine page au lieu de votre page d’accueil. Votre boutique est fermée et vous ne le savez même pas. La correction technique prend quelques minutes ; le week-end de ventes perdu et les clients qui ont décidé que vous aviez « mis la clé sous la porte » ne reviennent pas.

• La commande abandonnée. Un client achète depuis son téléphone sur le Wi-Fi d’un hôtel. Votre certificat ne correspond pas tout à fait au domaine qu’il a tapé (mettons qu’il couvre boutique.votreentreprise.com mais pas le votreentreprise.com nu qu’il a utilisé). Le navigateur l’avertit que le site « usurpe peut-être » le vôtre. Pour un acheteur non technique, cela se lit comme arnaque — il ferme l’onglet, et vous ne saurez jamais que la vente a existé.

• Le contrat enlisé. L’équipe sécurité d’un prospect plus important effectue un scan de routine avant de signer. Le verdict révèle un certificat auto-signé ou non reconnu sur l’un de vos sous-domaines. Même si tout le reste va bien, ce seul signal rouge transforme une approbation rapide en allers-retours qui retardent l’affaire — pour un problème qui ne coûte rien à corriger.

• L’avertissement au ralenti. Votre certificat est techniquement valide mais signé avec SHA-1, une vieille méthode que les navigateurs abandonnent progressivement. Une mise à jour de navigateur plus tard, une part de vos visiteurs se met à voir des avertissements que vous ne pouvez pas reproduire sur votre propre machine à jour. Des tickets d’assistance arrivent au compte-gouttes disant que le site « a l’air cassé » et vous ne comprenez pas pourquoi.

• L’échec de conformité. Vous acceptez les paiements par carte. Lors d’un réaudit, les contrôles de votre prestataire signalent une clé faible ou un certificat périmé. Les règles de sécurité des cartes exigent un chiffrement robuste et à jour — vos paiements en ligne sont donc suspendus jusqu’à réémission, gelant le chiffre d’affaires au pire moment possible.

Ce que c’est réellement (les quatre volets)

Un certificat peut être malsain de quatre façons distinctes, et cette page les couvre toutes. Chacune est un contrôle séparé sous le capot, mais pour vous, c’est toujours « mon certificat va-t-il bien ? »

1. Valide et reconnu

C’est le gros morceau — et la seule partie de la santé du certificat qui soit un contrôle critique et pesant au maximum. Un certificat est « valide et reconnu » uniquement quand toutes ces conditions sont vraies :

• Il a été délivré par une autorité de certification reconnue à laquelle les navigateurs font déjà confiance (Let’s Encrypt, DigiCert, Sectigo, Google, Amazon, etc.).
• Il correspond au domaine exact que le visiteur utilise — sous-domaines compris. Un certificat pour www.votreentreprise.com qui ne couvre pas aussi votreentreprise.com déclenchera un avertissement sur le domaine nu.
• Il n’est pas auto-signé — c’est-à-dire pas un certificat que vous vous êtes délivré, qui chiffre mais ne prouve rien de votre identité.
• Il est actuellement dans sa fenêtre de validité — non expiré, et pas (curieusement, mais cela arrive) daté pour commencer dans le futur.
• Sa chaîne de confiance est intacte — l’autorité qui l’a signé est elle-même reconnue, jusqu’au sommet.

Si l’une de ces conditions échoue, les navigateurs affichent la redoutée page « Votre connexion n’est pas privée », et ce contrôle échoue durement. Le bon réglage ressemble à : un certificat d’une autorité reconnue, couvrant chaque domaine et sous-domaine que vous utilisez réellement, confortablement dans ses dates.

2. Pas sur le point d’expirer

Chaque certificat a une date de fin ferme. Les gratuits durent généralement 90 jours ; les payants souvent un an. Passé la date, la confiance s’évapore instantanément — il n’y a pas de période de grâce. Ce contrôle mesure combien de jours restent et comment cela interagit avec qui l’a délivré :

• S’il est déjà expiré, ou expire dans moins de 7 jours, c’est traité comme critique — un signe que le renouvellement a échoué.
• S’il expire dans les 30 jours et n’est pas géré automatiquement, c’est un avertissement à renouveler dès maintenant.
• S’il provient d’un fournisseur à renouvellement automatique (Let’s Encrypt, Cloudflare, Google, Amazon, ZeroSSL et similaires) avec au moins une semaine restante, il réussit — car il est censé se renouveler avant l’échéance.
• Une marge confortable (90 jours et plus, ou géré automatiquement) est une réussite propre.

Le bon réglage ressemble à : un certificat géré automatiquement qui se renouvelle sans que personne n’y touche. Le moyen le plus fiable de ne jamais subir de panne d’expiration est de rendre une machine, et non une personne, responsable du renouvellement.

3. Algorithme de signature robuste

Chaque certificat est « signé » à l’aide d’un algorithme cryptographique qui permet aux navigateurs de détecter toute falsification. Les anciens algorithmes — MD5 et SHA-1 — se sont révélés falsifiables, ce qui signifie qu’un attaquant pourrait en principe fabriquer un certificat frauduleux qui paraît légitimement vôtre. Ce contrôle réussit quand le certificat utilise une signature robuste et moderne : SHA-256 ou plus fort (SHA-384, SHA-512), un ECDSA moderne, ou Ed25519/Ed448. MD5 et SHA-1 échouent. Le bon réglage ressemble à : SHA-256 ou mieux — ce qui est le défaut sur tout certificat gratuit et moderne, donc c’est rarement un problème sur quoi que ce soit émis ces dernières années.

4. Clé robuste

Le certificat porte une clé cryptographique qui fait le brouillage réel. Si cette clé est trop courte, la puissance de calcul moderne peut — avec assez de ressources — la casser, permettant à un attaquant d’usurper votre site ou de déchiffrer le trafic. Les minimums admis sont RSA 2048 bits ou courbe elliptique (EC) 256 bits. Ce contrôle réussit à ces tailles ou au-dessus et échoue en dessous. Le bon réglage ressemble à : RSA 2048 bits (ou 4096 bits), ou une clé EC 256 bits comme P-256 — là encore, le défaut sur les certificats gratuits modernes.

Une note sur les trois derniers : valide-et-reconnu est le critère critique qui déclenche la page d’avertissement. La robustesse de la signature et de la clé concerne la pérennité et les audits — un certificat gratuit récent les réussit presque toujours automatiquement, mais ce sont les points qu’une revue de sécurité vérifiera, donc ils valent la peine d’être réglés.

Comment corriger (gratuit, ~15 minutes)

Transmettez cette section à la personne qui gère votre site web ou votre hébergement — la correction est gratuite. Un certificat valide, robuste et à renouvellement automatique ne coûte rien via Let’s Encrypt ou tout hébergeur moderne. Nous facturons uniquement la surveillance du maintien de sa santé dans le temps, pas la correction. Si vous n’avez pas d’informaticien, les notes par plateforme ci-dessous mèneront la plupart des propriétaires à bon port.

Étape 1 — Obtenez (ou remplacez) le certificat par un certificat gratuit et reconnu. Cette seule étape corrige d’un coup la validité, la signature et la robustesse de la clé, car les certificats gratuits modernes utilisent SHA-256 et des clés robustes par défaut.

• Cloudflare : dans SSL/TLS → Overview, réglez le mode sur Full (Strict). Cloudflare émet et renouvelle automatiquement un certificat de périphérie reconnu pour vous ; assurez-vous que votre serveur d’origine a aussi un certificat valide pour que « Strict » fonctionne.
• Hébergement Google Workspace / Microsoft 365 ou tout hôte cPanel : cherchez SSL/TLS Status et lancez AutoSSL. Il provisionne et renouvelle des certificats gratuits automatiquement.
• Créateurs de sites (Squarespace, Wix, Shopify, hébergeurs WordPress modernes) : le SSL est généralement actif par défaut — confirmez qu’il est activé dans vos réglages de domaine/sécurité, et qu’il couvre à la fois votreentreprise.com et www.votreentreprise.com.
• Votre propre serveur Linux (Nginx/Apache) : installez Let’s Encrypt avec Certbot — sudo certbot --nginx -d votreentreprise.com -d www.votreentreprise.com (ou --apache). Pour une clé EC moderne, ajoutez --key-type ecdsa. Listez chaque nom d’hôte que vous servez avec -d pour que le certificat les couvre tous.

Étape 2 — Rendez le renouvellement automatique pour qu’il n’expire plus jamais. C’est l’étape qui empêche le scénario de la panne du week-end.

• Sur un serveur Let’s Encrypt, confirmez que la minuterie de renouvellement est active et testez-la : sudo certbot renew --dry-run. Certbot installe normalement une minuterie automatique ; sinon, ajoutez une tâche cron quotidienne : 0 3 * * * certbot renew --quiet.
• Sur Cloudflare, cPanel AutoSSL, et les hébergements managés / créateurs de sites, le renouvellement est géré pour vous — il n’y a rien à programmer.

Étape 3 — Assurez-vous qu’il couvre les bons noms. La cause la plus fréquente de « valide mais avertissement » est une non-correspondance de nom. Le certificat doit couvrir chaque nom d’hôte que les clients utilisent réellement — le domaine nu, www, et tout sous-domaine comme boutique. ou app.. Lors de la génération d’un certificat, incluez chacun d’eux (un joker comme *.votreentreprise.com couvre tous les sous-domaines d’un coup).

Étape 4 — Si seule la signature ou la robustesse de la clé est signalée, réémettez simplement. Vous n’avez rien à acheter : générez un nouveau certificat (Étape 1) et le nouveau utilisera SHA-256 et une clé robuste automatiquement. Sur votre propre serveur, vous pouvez fixer explicitement une clé moderne — par ex. openssl ecparam -genkey -name prime256v1 -out server.key pour l’EC, ou openssl genrsa -out server.key 4096 pour le RSA — puis réémettre.

Étape 5 — Vérifiez, puis recontrôlez ici. Confirmez les dates, l’émetteur et la clé avec une commande rapide — echo | openssl s_client -servername votreentreprise.com -connect votreentreprise.com:443 2>/dev/null | openssl x509 -noout -dates -issuer -subject — puis relancez ce contrôle.

Erreurs fréquentes

• Considérer « nous avons installé le SSL une fois » comme terminé. Les certificats expirent au chronomètre. Sans renouvellement automatique, la question n’est pas si il périme mais quand — généralement au moment le moins opportun.
• Couvrir www mais pas le domaine nu (ou l’inverse). Les deux doivent être sur le certificat, sinon l’un déclenche un avertissement de non-correspondance de nom. Le même piège attrape les nouveaux sous-domaines ajoutés plus tard.
• Laisser un certificat auto-signé sur un sous-domaine « de test » en réalité public. Il chiffre, donc il donne une impression de sécurité — mais les navigateurs (et les scanners de sécurité) le traitent comme non reconnu, et c’est un classique signal rouge d’audit.
• Croire que payant rime avec plus sûr. Un certificat Let’s Encrypt gratuit est exactement aussi reconnu et chiffré qu’un certificat coûteux. Payer plus ne fabrique pas un cadenas plus solide.
• Renouveler le certificat mais oublier de recharger le serveur. Un nouveau certificat posé sur le disque ne fait rien tant que le serveur web n’est pas rechargé pour le prendre en compte — une cause étonnamment fréquente de « je l’ai renouvelé mais il affiche toujours expiré ».
• Un renouvellement automatique qui a échoué en silence. Une tâche de renouvellement peut casser (un fichier déplacé, un changement DNS, un port bloqué) et continuer de « réussir » sans bruit. Surveiller la date d’expiration — et pas seulement la tâche de renouvellement — est ce qui détecte réellement cela avant que ça morde.

FAQ