Inventorier les noms d’hôte, les dépendances et les responsabilités
Listez chaque nom d’hôte utilisé par les visiteurs ou les intégrations : domaine racine, www, sous-domaines, API, hôtes de ressources, portails et noms régionaux. Pour chacun, indiquez où TLS se termine, qui peut le modifier, la couverture et la date d’expiration du certificat, la méthode de renouvellement et les dépendances qui génèrent des URL. Un certificat doit couvrir le nom d’hôte demandé dans sa liste Subject Alternative Name. Incluez le CMS, le CDN, le gestionnaire de balises, le stockage d’objets, le fournisseur de paiement, les modèles d’e-mails et les contenus tiers intégrés ; ils introduisent souvent des URL HTTP après le premier passage à HTTPS.
Sélectionnez un nom d'hôte canonique en www ou apex et redirigez l'alternative directement vers lui en HTTPS.
Déployer le certificat et les versions TLS actuelles
Configurez le serveur web, le proxy inverse, le CDN ou le répartiteur de charge qui répond à la requête publique. Installez le certificat et la chaîne requise, associez-les aux noms prévus et vérifiez-les depuis l’extérieur du réseau d’hébergement. Le navigateur vérifie la chaîne, le nom d’hôte et les dates ; un avertissement public bloque la mise en production. Utilisez TLS 1.3 par défaut et ne conservez TLS 1.2 que lorsque la compatibilité l’exige. Désactivez SSL ainsi que TLS 1.0 et 1.1. Suivez les recommandations à jour de la plateforme plutôt que de réutiliser une ancienne liste de suites de chiffrement, et appliquez les correctifs au serveur et à la bibliothèque TLS.
Limitez l'accès aux clés privées et consignez chaque système qui en partage une afin que le remplacement les atteigne tous.
Rediriger HTTP une seule fois et faire de HTTPS la référence canonique
Renvoyez une redirection permanente côté serveur, normalement 301 ou 308, de chaque URL HTTP vers son équivalent HTTPS. Évitez les chaînes : elles ajoutent de la latence et des points de défaillance. Publiez les URL HTTPS canoniques dans les liens internes, balises canonical, sitemaps, données structurées, balises sociales, e-mails et liens absolus générés par l'application. Testez la page d'accueil, une page profonde, une URL avec requête, les routes d'erreur et les variantes de nom d'hôte. Lorsque TLS se termine sur un proxy, configurez la gestion fiable du protocole transféré afin que l'application n'oscille pas entre HTTP et HTTPS.
Il ne doit rester disponible que pour rediriger ou pour compléter un challenge de certificat, pas pour servir un site public distinct.
Détecter et corriger le contenu mixte à la source
Le contenu mixte correspond à une page HTTPS qui sollicite une ressource via HTTP ou un autre protocole non sécurisé. Les navigateurs peuvent mettre à niveau certains médias, mais bloquent de nombreuses requêtes risquées, notamment les scripts, les feuilles de style, les cadres, les appels fetch et les polices. Remplacez chaque référence par une URL HTTPS testée, une URL relative pour votre propre contenu ou une solution approuvée. Explorez des modèles représentatifs et inspectez les outils de développement tout au long des parcours clés. Vérifiez le CSS, le JavaScript, les blocs du CMS, les manifestes de ressources, les entrées du gestionnaire de balises, les téléchargements et les contenus intégrés par les fournisseurs. Une page sécurisée ne doit pas proposer de téléchargement en HTTP.
La mise à niveau automatique par le navigateur peut laisser une dépendance tierce indisponible ou non prise en charge ; corrigez l'URL stockée.
Automatiser le renouvellement et tester la procédure de récupération des certificats
Traitez le renouvellement comme un déploiement automatisé, non comme un rappel de calendrier. Le processus doit renouveler le certificat, le déployer sur chaque couche de service et recharger le service en toute sécurité. Testez le même parcours de validation avant l’expiration en production. Let’s Encrypt, par exemple, recommande de renouveler ses certificats de 90 jours tous les 60 jours ; suivez le cycle de vie défini par votre autorité émettrice et votre plateforme. Tenez un inventaire des noms de certificats, du compte auprès de l’émetteur, de la méthode de validation, de l’automatisation, de l’emplacement des clés, des cibles et des contacts d’urgence. Vérifiez les dates depuis le point de terminaison public après le déploiement.
En cas d'échec de renouvellement, vérifiez le DNS, le routage du challenge, les permissions, l'accès à l'émetteur, les limites de taux et le déploiement CDN→origin.
N'activer HSTS qu'après que l'environnement HTTPS est prêt
HTTP Strict Transport Security (HSTS) est un en-tête de réponse HTTPS qui indique aux navigateurs d'utiliser HTTPS lors des visites ultérieures d'un hôte. Les navigateurs n'offrent alors plus de contournement pour les erreurs de certificat. Envoyez-le uniquement sur HTTPS et conservez la redirection HTTP car HSTS est appris après une réponse sécurisée, sauf si une liste de preload s'applique. Commencez avec un max-age limité et augmentez-le après avoir validé les renouvellements et les routes nécessaires. N'ajoutez pas includeSubDomains tant que chaque sous-domaine présent et futur ne peut servir un HTTPS valide. Le preload ne fait pas partie de la spécification HSTS et mérite un examen d'engagement distinct et durable.
max-age=0 ne fonctionne que lorsqu'un navigateur a atteint une réponse HTTPS valide ; il ne peut pas réparer un hôte sécurisé inaccessible.
Publier, tester et revenir en arrière sans compromettre la sécurité du transport
Conservez avant toute modification la configuration validée du certificat, de la périphérie et des redirections. Définissez qui approuve un retour en arrière, procédez par étapes lorsque c’est possible et ne modifiez qu’une catégorie de contrôles à la fois. Vérifiez immédiatement les points de terminaison publics depuis plusieurs réseaux, suivez les redirections, inspectez le certificat et effectuez les principales actions des visiteurs. Testez les navigateurs et les groupes de clients importants pour votre audience. Pour les flux de paiement ou réglementés, demandez au fournisseur de paiement et à un professionnel qualifié de la sécurité de vérifier les exigences applicables. Si une modification casse HTTPS, restaurez une configuration sécurisée validée ; ne servez pas les pages clients en HTTP comme solution de contournement.
Capturez le nom d'hôte, l'heure, le client, l'erreur, le changement et le résultat afin de faciliter le diagnostic au prochain renouvellement ou à la prochaine migration.