Installer un certificat SSL sur un serveur, c’est comme poser une serrure neuve sur une porte blindée : si personne ne pense à fermer la porte à clé derrière soi, la sécurité ne change rien. Beaucoup de propriétaires de sites respirent une fois le cadenas vert apparu dans la barre d’adresse, persuadés que le travail est terminé. Pourtant, la bascule vers HTTPS ne s’arrête pas à l’obtention du précieux sésame auprès d’une Autorité de Certification. Forcer la redirection, traquer les ressources encore chargées en HTTP et tester chaque page prennent plus de temps que l’installation elle-même. C’est précisément ce qui distingue une migration solide d’un site à moitié sécurisé.
Ce que le certificat SSL protège vraiment
Le SSL, et sa version plus récente le TLS, chiffrent les données qui transitent entre le navigateur d’un visiteur et le serveur qui héberge le site. Concrètement, lorsqu’un internaute remplit un formulaire de contact ou saisit un mot de passe, les informations circulent dans un tunnel illisible pour quiconque tenterait de les intercepter. C’est la raison pour laquelle un site sécurisé affiche la mention HTTPS au début de son URL, ce préfixe signalant que la connexion est établie sur une couche de chiffrement active.
Le certificat ne protège pas le contenu du site lui-même, ni les fichiers stockés côté serveur, ni même la base de données. Il sécurise uniquement le canal de transmission entre deux points. Cette distinction change la façon d’aborder les vérifications après installation : un cadenas visible sur la page d’accueil ne dit rien des autres URL, et encore moins des redirections internes qui pourraient renvoyer vers une version non chiffrée du même contenu.
Obtenir le certificat n’est que la première marche
Les premiers résultats de recherche sur le sujet détaillent longuement les types de certificats disponibles : validation de domaine, validation d’organisation, validation étendue. Chacun répond à un besoin précis, du blog personnel à la boutique en ligne qui veut afficher le nom de sa société dans la barre d’adresse. Depuis 2014, Google favorise les sites équipés d’un certificat SSL dans ses classements, un argument que les hébergeurs mettent en avant pour vendre leurs offres.
Mais franchement, la partie la plus commentée est rarement la plus délicate. Une fois le certificat émis et installé, le site peut très bien rester accessible en HTTP sur une partie de ses pages, tout en affichant un cadenas sur d’autres.
Le navigateur ne signale pas toujours le problème immédiatement, surtout si la redirection automatique n’est pas en place ou si certains liens internes pointent encore vers l’ancien protocole. C’est à ce moment que le travail commence, et c’est aussi le moment que la plupart des tutoriels expédient en deux phrases.
Forcer la redirection HTTPS sur tout le site
Une bascule complète repose sur une règle simple : toute requête arrivant en HTTP doit être renvoyée vers son équivalent en HTTPS. Cette redirection se configure au niveau du serveur, généralement dans le fichier .htaccess pour Apache ou dans le bloc de configuration pour Nginx.
Sans cette règle, un visiteur qui tape l’adresse du site sans le « s » continue de naviguer sur une version non chiffrée, sans même s’en rendre compte. Ce réglage de base se vérifie en quelques minutes, mais il conditionne tout le reste de la migration.
La redirection concerne toutes les URL, pas seulement la page d’accueil. Une ancienne adresse de billet de blog, une image partagée sur un réseau social, un lien dans une newsletter : chaque point d’entrée doit basculer correctement. Tester la redirection sur une seule page ne suffit donc pas.
Un site peut très bien renvoyer sa home page en HTTPS tout en laissant une page de contact ou une fiche produit accessible en HTTP, simplement parce que la règle de réécriture n’a pas été pensée pour l’ensemble des chemins d’accès. Voilà pourquoi un contrôle global reste indispensable.
Le problème se complique avec les ressources internes. Une page chargée en HTTPS peut très bien appeler une image, une feuille de style ou un script encore référencé en HTTP. Le navigateur bloque parfois ces éléments, parfois il les charge en affichant un avertissement, et le cadenas disparaît. C’est le fameux contenu mixte, qui mine la confiance des visiteurs même quand le certificat est parfaitement valide.
Passer chaque page au crible après l’installation
Peu de webmasters prennent le temps de parcourir leur site page par page après une migration HTTPS. C’est pourtant là que se cachent la plupart des erreurs de certificat et des avertissements de sécurité. Un certificat installé la veille peut très bien fonctionner sur la page d’accueil et échouer sur une sous-partie du site dont le certificat ne couvre pas le sous-domaine. Ce cas se produit fréquemment quand une boutique en ligne utilise un espace séparé pour son tunnel de paiement ou son back-office.
Voici quelques points de contrôle qui font gagner un temps considérable, car ils repèrent les défaillances invisibles depuis la seule page d’accueil. On pense en particulier aux sous-domaines oubliés et aux anciennes URL qui continuent d’être référencées par les moteurs de recherche, les favoris des internautes ou les publications partagées sur les réseaux sociaux. Ces vérifications prennent du temps, mais elles évitent de découvrir un problème après que les visiteurs l’ont déjà signalé.
Les vérifications qui évitent les mauvaises surprises
- Le certificat couvre-t-il bien tous les sous-domaines utilisés par le site, y compris ceux qui ne sont pas visibles dans le menu principal ?
- Les redirections automatiques renvoient-elles les anciennes URL HTTP vers les bonnes adresses HTTPS, sans créer de chaînes de redirections inutiles ?
- Quelles ressources internes sont encore appelées en HTTP ?
- Les liens canoniques et les balises méta pointent-ils systématiquement vers la version HTTPS des pages ?
- Le certificat intermédiaire est-il correctement installé sur le serveur, pour que les navigateurs mobiles aussi reconnaissent la chaîne de confiance ?
Chaque point mérite une vérification manuelle, car les outils automatiques ne remontent pas toujours les erreurs de contenu mixte sur des pages peu visitées. Un crawler comme Screaming Frog ou une extension de navigateur dédiée au HTTPS peut aider à dresser la liste des ressources fautives, mais un clic humain vaut mieux qu’un rapport généré pour les pages dynamiques ou les formulaires.
Quand le certificat pose problème
Les erreurs de certificat de sécurité SSL surviennent parfois des semaines après l’installation, sans qu’aucune modification n’ait été apportée au site. Le plus souvent, le certificat a expiré ou la date du serveur est incorrecte, ce qui suffit à faire paniquer les navigateurs. D’autres fois, le nom de domaine indiqué dans le certificat ne correspond plus à l’adresse visitée, notamment après un changement de domaine ou une migration vers un autre hébergeur.
La première réaction consiste à vérifier la chaîne de certification complète, car un certificat intermédiaire manquant produit un avertissement sur certains navigateurs et pas sur d’autres. Le site peut alors paraître sécurisé sur Chrome et afficher une erreur sur Firefox, ou l’inverse. Pour éviter ces écarts, il vaut la peine de tester le site sur plusieurs navigateurs et plusieurs appareils, sans se contenter de la machine de développement. Un test croisé apporte une vision plus fiable.
Il existe par ailleurs des services en ligne qui analysent la configuration TLS d’un serveur et remontent les protocoles obsolètes, les algorithmes faibles ou les certificats mal chaînés. Le site daonet.eu propose des ressources utiles pour les webmasters confrontés à ces questions, notamment sur l’installation et le dépannage des certificats. Ces outils ne remplacent pas la compréhension humaine du problème, mais ils orientent vite vers la cause la plus probable.
Une bascule HTTPS se valide dans la durée
Un site qui passe en HTTPS mérite mieux qu’un simple coup d’œil au cadenas de la page d’accueil. La redirection forcée, la chasse aux contenus mixtes et la vérification systématique de chaque page forment un tout, au même titre que l’obtention du certificat.
Un certificat SSL valide ne sert à rien si une partie du site continue de parler en clair, et les visiteurs finissent toujours par tomber sur l’URL qui pose problème. Alors, quand vous aurez fini la migration, oserez-vous ouvrir la console du navigateur sur une page au hasard, sans avoir peur de ce qu’elle va afficher ?
