Un certificat HTTPS doit correspondre aux noms utilisés par ton site, être correctement servi et rester renouvelable. Le cadenas du navigateur ne prouve ni la qualité d’un vendeur ni l’absence de faille dans le site. Ce guide aide à préparer l’installation et ses contrôles, sans appliquer une recette serveur à toutes les configurations.
1. Définir les noms à couvrir
Liste le domaine principal et les sous-domaines réellement utilisés : site public, espace client ou autre application. Vérifie où chaque nom arrive et quel service présente le certificat. Un proxy ou un service de diffusion peut ajouter une étape entre le navigateur et l’hébergement.
Note le responsable du domaine et celui de l’hébergement. L’accès au tableau de bord du site ne donne pas nécessairement le droit de modifier les réglages du domaine ou de demander un certificat pour un autre service.
2. Choisir une procédure adaptée à l’hébergement
Un hébergement administré peut proposer sa propre procédure ; un serveur géré séparément demande une organisation différente. Confirme qui installe le certificat, protège les clés et traite les erreurs. N’exécute pas une commande trouvée dans un guide sans vérifier qu’elle correspond à l’environnement et aux droits accordés.
La documentation de Let’s Encrypt décrit une validation du contrôle du domaine, puis une demande de certificat. Le renouvellement répète ces opérations. Selon la méthode retenue, les accès et les conditions de validation doivent donc rester disponibles.
3. Recevoir le certificat sur le site réellement servi
Après installation, ouvre chaque nom couvert dans un navigateur. Vérifie l’absence d’alerte, les noms indiqués et la date d’expiration du certificat effectivement reçu. Un message de réussite dans l’administration ne remplace pas ce contrôle depuis l’extérieur.
- Le domaine principal et ses variantes utiles répondent-ils comme prévu ?
- Les pages importantes, images et téléchargements restent-ils accessibles ?
- Le formulaire et les espaces connectés fonctionnent-ils dans les essais autorisés ?
- Une autre application ou un sous-domaine a-t-il été oublié ?
Conserve le résultat, les noms contrôlés et les limites de l’essai. Ne présente pas un contrôle de l’accueil comme une vérification de tous les services.
4. Prévoir le renouvellement et l’alerte
Identifie le mécanisme de renouvellement et la personne qui reçoit les erreurs. Une option « automatique » doit rester contrôlable : le mécanisme peut échouer si un accès ou un réglage change. Prévois une alerte avant expiration et une procédure de reprise.
Demande un contrôle du dispositif adapté à l’hébergement, sans provoquer une coupure réelle. Documente les éléments à vérifier après un changement de fournisseur, de domaine ou de service intermédiaire. L’expiration du certificat servi et celle affichée dans une interface doivent être rapprochées.
5. Ne pas confondre certificat et politique HTTPS
Le certificat, les redirections et les liens du site sont des éléments distincts. Une migration vers HTTPS demande aussi de vérifier les adresses publiques, les ressources chargées et les parcours. Elle ne se limite pas à activer une option.
Le mécanisme HSTS indique au navigateur de privilégier HTTPS lors des prochaines connexions. Avec une politique couvrant les sous-domaines, son effet s’étend aussi à ceux-ci. Consulte la documentation HSTS avant de retenir cette politique. Elle demande une validation de tous les services concernés, pas une activation systématique.
6. Écrire les responsabilités après installation
La remise doit identifier les noms couverts, les accès nécessaires, le renouvellement, les destinataires des alertes et la personne qui intervient. Elle doit également distinguer l’installation ponctuelle du suivi ultérieur et des opérations non incluses.
La maintenance du site peut intégrer des contrôles convenus, sans promettre une sécurité absolue. Envoie-moi ton domaine et l’environnement utilisé pour préparer un périmètre adapté. Ne transmets pas de clé privée ou de mot de passe dans le premier message.
