Pourquoi votre HTTPS ne suffit pas toujours
Activer SSL/TLS, c'est bien. Le configurer correctement, c'est autre chose.
Des milliers de sites affichent le petit cadenas vert et restent vulnérables. Un certificat installé à la va-vite, des protocoles obsolètes tolérés, des headers absents. Le cadenas rassure les visiteurs. Il ne protège pas automatiquement votre serveur.
Ce que les professionnels font, et que la plupart ignorent.
Les fondations : choisir les bons protocoles
Bannir TLS 1.0 et TLS 1.1 sans exception
Ces protocoles sont morts. Officiellement dépréciés par l'IETF depuis 2021, ils exposent vos utilisateurs à des attaques connues comme POODLE ou BEAST.
Activez uniquement TLS 1.2 et TLS 1.3. TLS 1.3 doit être votre priorité : il supprime les algorithmes faibles, réduit la latence de handshake et offre la confidentialité persistante par défaut.
Testez votre configuration sur SSL Labs. Un score en dessous de A, c'est un signal d'alarme.
Sélectionner des suites cryptographiques modernes
Votre serveur propose des dizaines d'algorithmes. Les clients en choisissent un. Sans tri, les plus faibles restent disponibles.
Privilégiez les suites avec ECDHE pour l'échange de clés et AES-GCM pour le chiffrement symétrique. Éliminez RC4, DES, et toute suite sans Perfect Forward Secrecy. Si la clé de session est compromise demain, les échanges passés doivent rester illisibles.
La gestion des certificats : l'erreur qui coûte cher
Automatiser le renouvellement
Un certificat expiré coupe l'accès à votre site pour tous vos visiteurs. Les navigateurs affichent une page d'erreur rouge. Personne ne passe outre.
Utilisez Let's Encrypt avec Certbot ou un équivalent. Configurez le renouvellement automatique 30 jours avant expiration. Testez le script dès l'installation, pas la veille de l'expiration.
Vérifier la chaîne de certificats
Un certificat intermédiaire manquant, et certains appareils refusent la connexion silencieusement. Ça ne se voit pas dans Chrome. Ça se voit sur les vieux Android ou les systèmes d'entreprise.
Servez toujours la chaîne complète : votre certificat suivi des intermédiaires. Vérifiez avec openssl s_client -connect votredomaine.com:443 -showcerts.
Les headers HTTP : le niveau ignoré par 80 % des sites
HSTS : forcer HTTPS une fois pour toutes
HTTP Strict Transport Security indique aux navigateurs de ne jamais tenter une connexion HTTP vers votre domaine. Même si quelqu'un tape http:// dans la barre d'adresse, la redirection se fait côté client, avant tout échange réseau.
Configurez une durée minimale de 31 536 000 secondes (un an). Activez includeSubDomains uniquement si tous vos sous-domaines sont prêts. Soumettez votre domaine à la liste HSTS preload pour aller plus loin.
Certificate Transparency et HPKP : ce qu'il faut savoir
HPKP (Public Key Pinning) est déprécié. Ne l'utilisez pas. Le risque de vous bloquer vous-même dépasse largement le bénéfice.
Surveillez plutôt Certificate Transparency. Les logs CT publics enregistrent chaque certificat émis pour votre domaine. Des outils comme crt.sh ou des alertes automatiques vous préviennent si un certificat non autorisé apparaît : c'est votre filet contre les émissions frauduleuses.
Configuration serveur : les détails qui changent tout
Désactiver la renégociation non sécurisée
La renégociation TLS renouvelle les paramètres de session sans couper la connexion. Mal configurée, elle ouvre la porte à des attaques par injection.
Désactivez la renégociation initiée par le client (ssl_client_renegotiation off sur Nginx). Activez uniquement la renégociation sécurisée définie par la RFC 5746. Consultez la documentation de votre serveur pour les options exactes.
Optimiser OCSP Stapling
Quand un navigateur vérifie la validité d'un certificat, il contacte le serveur OCSP de l'autorité de certification. Cela ajoute de la latence et révèle à l'AC quel site vos utilisateurs visitent.
OCSP Stapling règle les deux problèmes. Votre serveur récupère et met en cache la réponse OCSP, puis la colle au handshake TLS. Activez-le avec ssl_stapling on sur Nginx ou SSLUseStapling On sur Apache.
Surveiller, tester, itérer
Les outils à connaître
Ne configurez pas SSL/TLS une fois et oubliez. Les recommandations évoluent, les vulnérabilités émergent.
- SSL Labs (ssllabs.com/ssltest) : audit complet, score détaillé
- testssl.sh : outil en ligne de commande, utilisable en local ou en CI/CD
- Mozilla SSL Configuration Generator : génère les configs Nginx, Apache et HAProxy à jour
- crt.sh : surveillance des certificats émis pour votre domaine
Intégrer les tests dans votre pipeline
Une bonne configuration aujourd'hui peut devenir vulnérable après une mise à jour système. Apache 2.4.x, OpenSSL, votre distribution Linux : chaque composant peut modifier le comportement TLS.
Intégrez testssl.sh dans votre pipeline CI/CD et définissez des seuils d'alerte. Une régression TLS, c'est une fuite de données potentielle. Traitez-la comme telle.
Ce que tout cela signifie concrètement
La sécurité TLS n'est pas un état figé. C'est une pratique qui demande de la rigueur dans la durée.
Le cadenas rassure. La configuration protège. La surveillance prévient. Les trois fonctionnent ensemble ou pas du tout.
Faites l'audit SSL Labs maintenant. Notez les trois premiers points à corriger. Réglez-les cette semaine.
