Les erreurs de configuration SSL/TLS qui mettent votre site en danger

Pour la plupart des visiteurs, HTTPS est binaire : le cadenas est là ou non. Pour un attaquant, TLS est un spectre. Un certificat peut être valide et de confiance alors que la configuration derrière autorise encore des attaques par rétrogradation, des fuites entre sous-domaines, ou casse en silence le mois prochain à l’expiration. Voici ce qu’une analyse recherche au-delà de « est-ce du HTTPS ».

Des certificats sur le point d’expirer

L’expiration est l’incident TLS le plus courant et le plus évitable. Avec des durées de vie de certificat qui raccourcissent, le renouvellement manuel n’est plus réaliste. Automatisez l’émission et le renouvellement (ACME / Let's Encrypt ou les certificats gérés de votre plateforme) et alertez bien avant la date d’expiration, pas le jour même. Une analyse indique les jours restants pour qu’un certificat de courte durée ne vous surprenne pas.

Des chaînes de certificat incomplètes

Un serveur qui envoie son certificat feuille mais omet l’intermédiaire fonctionnera dans votre navigateur — car il a déjà l’intermédiaire en cache — et échouera chez quelqu’un d’autre. C’est le classique bug TLS « ça marche chez moi ». Servez toujours la chaîne complète :

openssl s_client -connect example.com:443 -servername example.com -showcerts

Si la sortie ne montre qu’un seul certificat, votre chaîne est incomplète.

Protocoles et chiffrements faibles toujours activés

TLS 1.0 et 1.1 sont obsolètes et doivent être désactivés ; de même pour les chiffrements de qualité export et RC4. Recommandations modernes :

• Ne prenez en charge que TLS 1.2 et TLS 1.3.
• Privilégiez les suites à confidentialité persistante (ECDHE).
• Désactivez RC4, 3DES et tout ce qui est étiqueté EXPORT.
• Activez l’agrafage OCSP pour accélérer les vérifications de révocation.

Contenu mixte sur les pages HTTPS

Une page HTTPS qui charge un script, une feuille de style ou une image en http:// offre à un attaquant un point d’appui sur une page censée être sûre — et le navigateur bloquera de toute façon les parties actives, cassant votre interface. Trouvez et corrigez chaque référence absolue http://, ou laissez le navigateur les mettre à niveau :

Content-Security-Policy: upgrade-insecure-requests

Pas de redirection HTTP vers HTTPS

Si http://yoursite.com sert du contenu au lieu de rediriger, chaque première visite est une requête en clair. Redirigez tout le HTTP vers HTTPS avec un 301/308, puis imposez-le avec HSTS pour que le navigateur ne réessaie jamais HTTP (voir l’erreur n° 1 dans le guide des en-têtes de sécurité).

Des certificats génériques trop étendus

Un certificat *.example.com sur des services sans rapport signifie qu’une clé privée volée les compromet tous. Pratique, mais cela élargit le rayon d’impact. Limitez la portée des certificats aux services qui ont réellement besoin de les partager.

Vérifiez en continu, pas une seule fois

La configuration TLS dérive : un nouveau sous-domaine, un changement d’équilibreur de charge, un renouvellement oublié. Intégrez une vérification TLS au même rythme que pour les en-têtes — Comment lire un rapport d’analyse de sécurité de site web explique comment transformer ces constats en plan hebdomadaire, et la page des tarifs indique les limites d’analyse pour le maintenir planifié.