HTTPS sur un site autonome : certificat SSL, HSTS et correction du contenu mixte
1. Choix du certificat et renouvellement automatique : n’achetez pas de certificat OV et ne renouvelez pas à la main
Beaucoup de sites autonomes achètent un certificat SSL payant la première année, oublient de le renouveler la deuxième et se retrouvent avec l’avertissement rouge du navigateur. Le constat contre-intuitif est le suivant : pour la grande majorité des sites B2B autonomes, le certificat DV gratuit de Let’s Encrypt suffit amplement, l’OCSP stapling et la note A+ sont accessibles, et le nom d’entreprise affiché en plus avec un certificat OV payant n’a aucun effet mesurable sur le taux de conversion.
Le choix du certificat ne repose que sur deux critères fermes : d’abord l’algorithme de clé, avec ECDSA P-256 plutôt que RSA 2048, qui réduit la taille de la poignée de main de 40 % et accélère le premier chargement mobile d’environ 80 millisecondes ; ensuite la méthode de renouvellement, qui doit passer par certbot ou acme.sh en renouvellement automatique, avec une vérification quotidienne par crontab, et jamais de renouvellement manuel. Dans 90 % des incidents de certificat expiré, la cause est un responsable parti ou un oubli.
| Type de certificat | Coût annuel | Affichage navigateur | Cas d’usage | Ce qu’on recommande |
|---|---|---|---|---|
| Let’s Encrypt DV ECDSA | 0 € | Cadenas de sécurité, sans nom d’entreprise | La grande majorité des sites B2B autonomes | Choix par défaut, renouvellement automatique |
| Let’s Encrypt DV RSA | 0 € | Cadenas de sécurité, sans nom d’entreprise | Besoin de compatibilité avec les anciens appareils | Uniquement en cas de trafic IE11 |
| Certificat OV payant | 2000 à 8000 yuans/an | Nom d’entreprise en vert | Finance, paiement, panier moyen élevé | À éviter sauf nécessité |
| Certificat EV payant | 5000 à 20000 yuans/an | Badge EV (supprimé par la plupart des navigateurs) | Quasiment aucun cas d’usage | Déconseillé |
Exemple concret : un SaaS basé à Hangzhou qui se développe à l’international demande un certificat Let’s Encrypt avec acme.sh et configure dans crontab 0 3 * * 1 /root/.acme.sh/acme.sh –renew -d example.com, soit une vérification et un renouvellement automatiques chaque lundi à 3 h du matin. En parallèle, on ajoute une règle de surveillance : une alerte WeCom est envoyée dès que la validité restante du certificat passe sous 15 jours. Une fois cette configuration en place, on n’y touche plus pendant deux ans.
Comment gérer les domaines multiples et les domaines génériques, à planifier avec Accélération mondiale par CDN la stratégie de certificat des nœuds. Les fournisseurs de CDN incluent généralement un certificat en périphérie : le certificat d’origine et celui de la périphérie se gèrent séparément, et le renouvellement du certificat de périphérie ne doit pas dépendre de l’origine.
2. HSTS : une montée progressive, pas un passage en force
HSTS (HTTP Strict Transport Security) est un en-tête de réponse qui force le navigateur à passer par HTTPS. Son côté contre-intuitif : plus le max-age est long, plus c’est sûr, mais plus c’est risqué. Si vous mettez directement max-age=31536000 dès le départ, votre environnement de test, vos sous-domaines de staging et votre back-office interne seront inaccessibles en HTTP pendant un an, et la moindre panne de certificat met tout le site à terre.
Le bon rythme de montée en charge se fait en trois paliers : la première semaine, max-age=300 (5 minutes), le temps de voir si des utilisateurs remontent des problèmes ou si le business décroche ; de la deuxième à la quatrième semaine, max-age=86400 (1 jour), pour confirmer qu’il n’y a rien d’anormal ; et seulement après un mois, passer à max-age=31536000 (1 an) en ajoutant includeSubDomains. La soumission à la liste preload vient encore plus tard : attendez 3 mois de fonctionnement stable avant de soumettre à chromium preload.
| Phase | Écriture de l’en-tête HSTS | Période d’observation | Points de risque |
|---|---|---|---|
| Premier niveau | Strict-Transport-Security: max-age=300 | 1 semaine | Risque quasi nul, retour en arrière possible à tout moment |
| Deuxième niveau | max-age=86400 | 1 mois | Quelques vieux navigateurs peuvent ne pas être compatibles |
| Troisième niveau | max-age=31536000; includeSubDomains | 3 mois | Tous les sous-domaines doivent être prêts en HTTPS |
| Palier final | Ajouter la directive preload et soumettre à hstspreload.org | Long terme | Le retrait après soumission coûte extrêmement cher |
Exemple concret : un site d’équipement industriel à l’international, dont le site principal example.com est en HTTPS, mais legacy.example.com est encore en HTTP. Activer includeSubDomains directement bloquerait les utilisateurs du sous-domaine legacy. La bonne méthode : d’abord passer tous les sous-domaines en HTTPS, puis faire monter le HSTS du site principal jusqu’à un an. La liste des sous-domaines est visible dans le rapport de test SSL Labs.
HSTS et Fondations de conformité pour un site à l’international les exigences de sécurité des transmissions vont dans le même sens : le chiffrement des données personnelles imposé par le RGPD trouve dans HSTS sa mise en œuvre technique la plus directe.
III. Contenu mixte : mise à niveau automatique et nettoyage manuel, deux étapes
Le contenu mixte désigne des ressources chargées en http:// dans une page HTTPS. Il en existe deux types : le contenu mixte passif (images, vidéos, polices) que le navigateur bloque automatiquement sans signaler d’erreur ; et le contenu mixte actif (<script>, <iframe>, fetch, XHR) qui fait passer la page en rouge, que le navigateur refuse de charger et qui casse purement et simplement la fonctionnalité.
La correction se fait en deux temps. Première étape : ajouter l’en-tête de réponse Content-Security-Policy: upgrade-insecure-requests; le navigateur transforme alors automatiquement toutes les requêtes http:// de la page en https://, ce qui règle 80 % des cas. Deuxième étape : passer le panneau Console de Chrome DevTools pour repérer ce qui reste, puis supprimer les http:// codés en dur dans le code et la base de données — en particulier siteurl et home dans la table wp_options de WordPress, ainsi que les anciennes données du type <img src=”http://…”> dans les articles historiques.
| Type de contenu mixte | Comportement du navigateur | Priorité de correction | Méthode de correction |
|---|---|---|---|
| http://<script>或<iframe> | Blocage direct, erreur sur la page | P0, à corriger immédiatement | Passer la source en https ou changer de CDN |
| Requêtes http:// XHR/fetch | Erreur en console, fonctionnalité hors service | P0, à corriger immédiatement | Passer en protocole relatif ou en https dans le code |
| http://<img> images | Certains navigateurs mettent à jour automatiquement | P1, à corriger sous une semaine | upgrade-insecure-requests en secours |
| http:// polices ou images de fond CSS | échec silencieux, styles perdus | P1, à corriger sous une semaine | remplacer les liens par du https sur le CDN |
| liens http://<a href> | redirection vers HTTP, sans erreur mais avec fuite | P2, nettoyage mensuel | remplacement en masse dans le sitemap |
Le piège le plus courant sur un site WordPress, ce sont les liens d’images en http:// codés en dur dans les anciens articles. Ne faites pas de remplacement SQL en masse directement dans la base de données : sauvegardez d’abord, puis utilisez l’outil Search Replace DB pour un remplacement compatible avec les données sérialisées, sinon vous corrompez les données PHP sérialisées. Pour la sauvegarde, voir Sauvegarde et restauration : s’entraîner à réagir.
Le nettoyage du contenu mixte et Optimiser les Core Web Vitals sont liés : les scripts bloqués retardent le LCP, les images refusées provoquent du CLS. Une fois le contenu mixte nettoyé, ces deux indicateurs s’améliorent généralement d’eux-mêmes.
IV. Liste de vérification et inspection mensuelle
La configuration HTTPS ne se fait pas une fois pour toutes. Les certificats expirent, de nouveaux sous-domaines apparaissent, d’anciens contenus réintroduisent des liens http. Il faut mettre en place un tableau d’inspection mensuel, à exécuter une fois par mois, en 5 à 10 minutes.
| Point de contrôle | Outil/méthode | Seuil de qualification | En cas d’échec |
|---|---|---|---|
| Note SSL Labs | ssllabs.com/ssltest | A ou A+ | ajuster la configuration TLS, désactiver les anciens protocoles |
| Validité restante du certificat | openssl s_client | ≥ 15 jours | déclencher le renouvellement immédiatement |
| Redirection HTTP vers HTTPS | curl -I http://example.com | 301 vers https | ajouter la règle rewrite |
| Présence de l’en-tête HSTS | curl -I pour voir les en-têtes de réponse | max-age≥86400 | ajouter la configuration d’en-tête |
| Nombre de contenus mixtes | Chrome DevTools Console | 0 | localiser et remplacer les http codés en dur |
| Version TLS | Rapport SSL Labs | TLS 1.2/1.3 uniquement | désactiver TLS 1.0/1.1 |
Pour automatiser l’inspection, voir Surveillance et alertes du site le chapitre sur la surveillance de l’expiration des certificats et de la disponibilité. Après un piratage, la configuration HTTPS est souvent endommagée ; pour la procédure de nettoyage, voir Nettoyage et réindexation après un piratage de site.
Rappel contre-intuitif : ne soumettez pas HSTS preload à la légère. Une fois votre domaine inscrit dans la liste preload intégrée aux navigateurs, le retirer exige une procédure dédiée, et pendant plusieurs mois les navigateurs des utilisateurs existants continueront d’imposer HTTPS. Si votre activité ajuste encore fréquemment des sous-domaines et des environnements de test, attendez au moins six mois de fonctionnement stable du site principal avant d’envisager preload.
FAQ — Questions fréquentes
Un certificat Let’s Encrypt gratuit suffit-il, ou faut-il acheter un OV payant ?
Peut-on mettre max-age=31536000 dès la première configuration HSTS ?
Comment corriger le contenu mixte en masse, existe-t-il un outil tout-en-un ?
Comment configurer le renouvellement automatique du certificat, et quel est le piège à craindre ?
Le HTTPS a-t-il un impact sur le SEO, faut-il passer tout le site en HTTPS ?
Comment configurer les versions TLS, faut-il désactiver TLS 1.0 et 1.1 ?
Pour conclure
Configurer HTTPS, on le voit souvent comme une simple histoire de certificat à installer. En réalité, c’est le socle de la sécurité et du SEO d’un site indépendant. Certificat expiré, HSTS absent, contenu mixte résiduel : chacun de ces trois problèmes déclenche une alerte rouge dans le navigateur. L’acheteur voit l’avertissement et ferme la page, et le référencement en prend un coup. Une bonne configuration, puis un contrôle mensuel : le coût est minime, le bénéfice visible sur tout le site.
Trois étapes concrètes : d’abord, passez le cap du certificat avec le renouvellement automatique Let’s Encrypt et visez un A minimum sur SSL Labs ; ensuite, faites monter le HSTS par paliers, de 5 minutes à un an ; enfin, ramenez le contenu mixte à zéro avec upgrade-insecure-requests et un nettoyage manuel. Une fois ces trois étapes faites, HTTPS est vraiment configuré. La liste d’entretien quotidien se trouve Les six tâches mensuelles de la maintenance d’un site : intégrez-y le contrôle HTTPS.
Une phrase à retenir : HTTPS, ce n’est pas un certificat installé et terminé. Renouvellement automatique du certificat, montée progressive du HSTS, contenu mixte à zéro : il faut passer ces trois niveaux pour avoir un vrai HTTPS. S’il en manque un, l’alerte rouge du navigateur fera fuir vos acheteurs à votre place.