Pourquoi le site affiche-t-il toujours un avertissement de sécurité après l’installation d’un certificat SSL ?

Après l’installation d’un certificat de sécurité SSL, si le navigateur affiche toujours « Connexion non sécurisée », « Certificat non valide » ou qu’aucune icône de cadenas n’apparaît dans la barre d’adresse, le problème ne vient généralement pas du fichier de certificat lui-même, mais d’unechaîne de déploiement incomplète, d’un nom de domaine visité non correspondant, de ressources HTTP encore chargées par la page ou d’une activation incorrecte du HTTPS sur le serveur. Ces problèmes affectent la confiance des visiteurs envers le site et peuvent également entraîner le blocage ou l’affichage d’avertissements par le navigateur lors de la connexion, de l’envoi de formulaires ou des redirections de paiement.

Lors du diagnostic, ne vous contentez pas de vérifier si « le certificat a été acheté et téléversé ». Basez-vous sur le certificat réellement consulté par le navigateur, le chemin d’accès et les ressources de la page : confirmez d’abord le type d’erreur, vérifiez ensuite le nom de domaine, la chaîne de certificats, le port et les règles de redirection, puis traitez le contenu mixte. Cela évite de remplacer le certificat à plusieurs reprises sans résoudre le problème.

Commencez par examiner le message du navigateur afin de déterminer à quel niveau se situe le problème

Cliquez sur l’indication « Non sécurisé » ou sur l’icône de cadenas dans la barre d’adresse du navigateur pour consulter les détails du certificat et le message d’erreur spécifique. Des phénomènes différents correspondent à des pistes différentes.

La console du navigateur est également essentielle. Si la console affiche « Mixed Content », cela signifie que la page principale est ouverte en HTTPS, mais que certaines ressources sont encore demandées via HTTP ; si elle indique une erreur de nom de certificat ou un échec de validation de la chaîne de certificats, revenez à la couche de déploiement du serveur pour effectuer les vérifications.

L’incompatibilité du nom de domaine est le problème le plus facilement négligé après l’installation d’un certificat de sécurité SSL

Un certificat n’est valide que pour les noms de domaine qui y sont répertoriés et ne couvre pas automatiquement toutes leurs variantes. Par exemple, si le certificat est émis uniquement pourwww.example.com, l’accès direct àexample.compeut toujours générer une erreur ; de même, un certificat standard à domaine unique émis pour le domaine principal ne couvre généralement pas les sous-domaines tels queshop.example.cometen.example.com.

Vérifiez les « noms alternatifs du sujet (SAN) » ou les noms alternatifs du détenteur dans les détails du certificat, et comparez-les un par un avec les points d’accès réellement utilisés. Confirmez au minimum les éléments suivants :

• si les domaines avecwwwet sanswwwsont tous deux couverts, ou s’ils font l’objet d’une redirection unifiée ;
• si les sites multilingues, sous-sites de boutique, sites de téléchargement, back-offices d’administration, etc., utilisent des sous-domaines indépendants ;
• si les utilisateurs peuvent accéder directement au site via un ancien domaine, un domaine de test ou une adresse IP ;
• si le certificat est déployé dans la liaison de domaine ou la configuration de l’hôte virtuel actuellement exposé au public.

N’essayez pas de masquer une incompatibilité de nom en « redirigeant tous les domaines vers HTTPS ». La redirection intervient après la négociation TLS : le navigateur doit d’abord vérifier le certificat du domaine actuel, et un avertissement s’affichera toujours si le nom du certificat ne correspond pas. La bonne pratique consiste à étendre la couverture du certificat aux points d’accès réellement utilisés, ou à normaliser les noms de domaine au niveau du DNS, des points d’entrée du site et des liens promotionnels.

Lorsque la chaîne de certificats est incomplète, le serveur semble correctement configuré, mais le client ne peut pas effectuer la validation

Un certificat SSL ne se compose généralement pas d’un seul certificat serveur. Le navigateur doit également établir un chemin de validation vers un certificat racine de confiance via des certificats intermédiaires. Si seul le certificat du nom de domaine est téléversé lors du déploiement, sans configurer le paquet de certificats intermédiaires fourni par l’AC, certains navigateurs ou anciens appareils signaleront que le certificat n’est pas fiable.

Dans un environnement Nginx, un problème courant est quessl_certificatepointe vers un fichier de certificat isolé plutôt que vers un fichier de chaîne complète contenant le certificat serveur et les certificats intermédiaires ; pour Apache, il faut confirmer que la configuration correspondante de la chaîne de certificats répond aux exigences de la version actuellement utilisée. Dans un environnement de panneau de contrôle, utilisez le fichier « chaîne de certificats complète », « fullchain » ou « CA Bundle » fourni par l’autorité de certification, au lieu de ne coller que le premier bloc du certificat.

Il faut également éviter un ordre incorrect de la chaîne. En règle générale, placez d’abord le certificat du site, puis ajoutez successivement les certificats intermédiaires ; il n’est généralement pas nécessaire que le serveur fournisse activement le certificat racine. Après avoir remplacé les fichiers, rechargez la configuration du service Web et vérifiez de nouveau depuis un réseau externe, au lieu de vérifier uniquement sur le serveur si les fichiers existent.

HTTPS est activé : pourquoi la page est-elle toujours affichée comme non sécurisée ?

Cette situation est souvent liée au contenu mixte. Le HTML de la page est transmis via HTTPS, mais les images, JavaScript, CSS, vidéos, polices, codes de suivi, iframe ou adresses d’interface sont encore définis avechttp://. Les navigateurs modernes bloquent directement certains contenus actifs, tels que les scripts et les requêtes XHR ; pour certaines ressources d’image ou multimédias, ils peuvent autoriser le chargement tout en réduisant le niveau de sécurité.

Le traitement doit commencer par le code source de la page et la console du navigateur, afin d’identifier les adresses précises des ressources, puis de contrôler leur origine :

1. les ressources statiques internes au site doivent être remplacées par des adresses absolues HTTPS ou utiliser des chemins relatifs adaptés au site actuel ;
2. les liens HTTP codés en dur dans les modèles, contenus enrichis, fiches produits et anciens articles doivent être examinés par lots ;
3. les scripts tiers, cartes, fenêtres de service client, intégrations vidéo et composants de formulaire doivent impérativement être compatibles avec HTTPS ;
4. les noms de domaine des interfaces, du stockage de fichiers et du CDN d’images doivent également disposer de certificats valides ; il ne suffit pas de modifier le nom de domaine de la page d’accueil ;
5. après modification, videz le cache du site, le cache CDN et le cache du navigateur, puis effectuez un nouveau test.

Il n’est pas recommandé de dépendre uniquement de la stratégie du navigateur consistant à « mettre automatiquement à niveau les requêtes non sécurisées ». Elle peut servir de mesure transitoire, mais ne garantit pas le chargement correct de toutes les ressources ; si une ressource tierce ne prend pas en charge HTTPS, cela peut encore provoquer l’absence de styles, des dysfonctionnements ou des échecs de requêtes de données.

Vérifiez l’écoute du serveur, les redirections et la configuration multi-nœuds

Un certificat correct ne signifie pas que le port 443 est déjà pris en charge par le bon site. Vérifiez que le pare-feu du serveur, le groupe de sécurité et le service Web autorisent tous l’accès au port 443, et que ce port est lié au certificat correspondant au nom de domaine cible. Dans les environnements à IP partagée et à plusieurs sites, une configuration SNI anormale peut amener le serveur à renvoyer le certificat d’un autre site, créant ainsi une incompatibilité de nom de domaine.

La redirection de HTTP vers HTTPS doit également être contrôlée. Idéalement, l’accès à la versionhttp://doit mener à l’adresse HTTPS normalisée via une seule redirection 301 ou 308 ; évitez les boucles où HTTP redirige vers HTTPS, puis HTTPS retourne vers HTTP, et ne laissez pas différentes pages basculer sans cesse entre les versions avec et sans www. Les pages de connexion, d’envoi de formulaires, de rappel de paiement et les points d’entrée du back-office doivent notamment être vérifiés séparément.

Si le site utilise un CDN, un équilibrage de charge ou un proxy inverse en amont, vérifiez séparément les certificats des nœuds périphériques et du serveur d’origine. Si les nœuds périphériques fonctionnent normalement mais que le serveur d’origine présente une anomalie, certains scénarios de retour à l’origine peuvent échouer ; si le serveur d’origine a été mis à jour mais que le CDN conserve encore l’ancien certificat, les accès externes peuvent également ne pas afficher le nouveau certificat. En cas de résolution double pile IPv4 et IPv6, les nœuds correspondant aux deux types d’adresses doivent être testés.

Évitez les problèmes récurrents d’erreur juste après un renouvellement

Si l’ancien certificat est toujours affiché après son renouvellement, cela provient souvent d’un chemin référencé dans la configuration qui n’a pas été mis à jour, d’un service qui n’a pas été rechargé ou d’un nœud n’ayant pas synchronisé les nouveaux fichiers. Lors de l’établissement des enregistrements de modification des certificats, notez également les noms de domaine couverts, la date d’expiration, l’emplacement de la clé privée, l’emplacement du fichier de chaîne complète, les nœuds de déploiement et l’opération de rechargement. Avant et après la mise à jour, vérifiez depuis l’extérieur le numéro de série et la période de validité afin de confirmer que le navigateur reçoit réellement le nouveau certificat.

Pour les pages de destination marketing, les sites indépendants et les pages multilingues, intégrez également la vérification HTTPS au processus de publication : vérifiez le protocole des ressources externes avant la mise en ligne d’une nouvelle page, confirmez que les nouveaux sous-domaines sont inclus dans le certificat et validez le code d’intégration des nouveaux outils tiers. Ainsi, les avertissements « Non sécurisé » peuvent être traités avant la publication, au lieu de devoir être corrigés un par un après les retours des visiteurs.