HTTPS fait aujourd'hui partie du standard d'un site web professionnel. Il chiffre la connexion entre le navigateur et le serveur web et protège les données transmises pour éviter qu'elles ne soient lues ou modifiées à l'insu des utilisateurs lors de leur acheminement.
Que qu'un site Web soit fondamentalement accessible via https:// l'accessibilité ne signifie toutefois pas automatiquement que l'ensemble de la configuration HTTPS est sans erreur.
Un certificat expiré, un nom d'hôte incorrect, du contenu mixte, des redirections défectueuses ou des problèmes de chaîne de certificats peuvent amener les navigateurs à afficher des avertissements de sécurité ou à ne pas charger correctement certaines ressources.
Dans cet article, nous vous montrons comment analyser systématiquement les problèmes SSL/TLS et HTTPS et comment différencier les erreurs typiques.
En bref : Les certificats SSL permettent une connexion HTTPS chiffrée et confirment pour quel domaine ou nom d'hôte un certificat est valide. Par conséquent, si le navigateur affiche un avertissement HTTPS, vous ne devez pas seulement vérifier si un certificat est présent, mais aussi sa validité, ses noms d'hôtes, sa chaîne de certification et les ressources chargées par le site web.
SSL et TLS : qu'est-ce qui est correct en fin de compte ? #
Dans la vie quotidienne, on parle encore souvent d'un Certificat SSL parlé.
Cependant, sur le plan technique, les connexions HTTPS modernes utilisent TLS. SSL désigne des protocoles antérieurs plus anciens.
Des termes tels que :
Certificat SSL
Chiffrement SSL
SSL pour site webrestent néanmoins courantes dans le langage courant.
Techniquement plus précis serait, par exemple :
Certificat TLS
ou
Connexion HTTPS avec TLSDans cet article, nous utilisons le terme courant de certificat SSL là où il facilite la compréhension.
Que fait HTTPS ? #
Lors d'une connexion HTTPS, le navigateur communique de manière cryptée avec le serveur.
Simplifié :
Navigateur
↓
Connexion TLS
↓
Vérifier l'identité / le certificat
↓
connexion chiffrée
↓
Serveur webCela vise en particulier à protéger la confidentialité et l'intégrité des données transmises.
HTTP et HTTPS sont des variantes d'URL différentes #
Ces deux URL se ressemblent :
http://example.com/
Cependant, sur le plan technique, il s'agit de variantes d'URL différentes.
Sur un site web entièrement migré vers HTTPS, la version HTTP doit normalement rediriger proprement vers la version HTTPS correspondante.
Par exemple :
http://example.com/beispiel/
↓
301 Redirection permanente
↓
https://example.com/beispiel/Nous expliquons le fonctionnement des redirections permanentes sur Configurer une redirection 301 : rediriger des URL de manière permanente.
Qu'est-ce qu'un certificat SSL ? #
Un certificat contient des informations nécessaires à l'établissement et à la vérification d'une connexion sécurisée.
Cela inclut, entre autres, des informations sur les noms d'hôtes pour lesquels le certificat est valide, par qui il a été émis et la période pendant laquelle il est valide.
Un navigateur vérifie ces informations lors de l'établissement de la connexion HTTPS.
Quelles informations devez-vous vérifier sur un certificat ? #
Lors de la recherche d'erreurs, les points suivants sont particulièrement pertinents :
Domaine / Nom d'hôte
Émetteur
Début de validité
Fin de validité
Noms alternatifs du sujet
Chaîne de certification
ConfianceLes navigateurs modernes fournissent une partie de ces informations via les informations de sécurité ou de certificat, ou via les outils de développement.
Le symbole du cadenas n'est pas tout le diagnostic #
Les interfaces des navigateurs évoluent régulièrement. Selon le navigateur et la version, une connexion sécurisée n'est donc pas toujours représentée par exactement le même symbole.
Ne vous fiez pas exclusivement à un symbole de cadenas lors d'un diagnostic technique.
Le plus important est :
Utilise-t-on https:// ?
Le certificat est-il valide ?
Correspond-il au nom d'hôte ?
La connexion est-elle digne de confiance ?
Des ressources non sécurisées sont-elles chargées ?Premier test : accéder directement au site web en HTTPS #
Commencez par la véritable adresse HTTPS :
Vérifiez d'abord si la page s'ouvre sans avertissement de sécurité.
Ensuite, tu devrais tester non seulement la page d'accueil, mais aussi quelques sous-pages typiques.
Par exemple :
Page d'accueil
Sous-page
Article de blog
Page de contact
Page boutique ou produitUn problème peut concerner seulement des pages ou des ressources individuelles.
Deuxième test : appeler la version HTTP #
Ouvre ensuite sciemment la variante non chiffrée :
http://deine-domain.ch/
Sur un site web entièrement migré vers HTTPS, cela devrait normalement devenir l'adresse HTTPS correspondante.
Vérifiez également une sous-page :
http://deine-domain.ch/beispiel/
Elle ne devrait pas être envoyée systématiquement sur la page d'accueil, mais normalement sur :
vérifier également www et non-www #
En outre, il existe souvent des variantes avec et sans www.
Par exemple :
https://example.com/
https://www.example.com/Si une seule de ces variantes est utilisée comme site Web principal, l'autre doit y rediriger de manière cohérente.
Il en va de même pour les variantes HTTP.
Une configuration type peut par exemple ressembler à ceci :
http://example.com/
↓
https://www.example.com/
http://www.example.com/
↓
https://www.example.com/
https://example.com/
↓
https://www.example.com/La variante utilisée comme adresse principale importe moins qu'une mise en œuvre technique cohérente.
Erreur 1 : Le certificat a expiré #
Les certificats ont une période de validité limitée.
Si un certificat n'est pas renouvelé à temps, le navigateur peut afficher un avertissement de sécurité.
Par conséquent, vous devez vérifier les dates de validité lors du diagnostic :
valable à partir du :
...
valable jusqu'au :
...Si la date actuelle se situe en dehors de la période de validité, le certificat doit être renouvelé ou son renouvellement automatique doit être vérifié.
Pourquoi les certificats sont renouvelés automatiquement #
Les systèmes d'hébergement modernes automatisent souvent l'émission et le renouvellement des certificats.
Cependant, un renouvellement automatique peut échouer si, par exemple, le domaine ne pointe plus correctement vers le serveur ou si une validation nécessaire ne peut pas être effectuée.
C'est pourquoi, en cas de certificat expiré, il ne faut pas seulement remplacer le certificat manuellement, mais aussi analyser la cause de l'échec du renouvellement.
Erreur 2 : Le certificat n'est pas encore valide #
Même un certificat dont la validité commence dans le futur peut provoquer un avertissement.
En présence de telles erreurs, il convient en outre de vérifier si la date et l'heure sont réglées correctement sur l'appareil ou le système concerné.
Une mauvaise heure locale peut faire qu'un certificat pourtant valide apparaisse comme non encore valide ou déjà expiré du point de vue de l'appareil.
Erreur 3 : Le certificat ne correspond pas au domaine #
Un certificat doit être valide pour le nom d'hôte appelé.
Supposons que tu appelles :
Cependant, le certificat délivré ne couvre que :
www.example.com
ab.
Il y a alors une non-correspondance de nom d'hôte.
Le navigateur ne peut pas confirmer que le certificat a été émis pour le nom d'hôte effectivement consulté.
Vérifier les noms alternatifs du sujet #
Les certificats modernes peuvent être valides pour plusieurs noms d'hôtes.
Celles-ci sont généralement spécifiées via des noms alternatifs du sujet, ou SAN en abrégé.
Par exemple, un certificat pourrait couvrir les noms suivants :
example.com
www.example.comUn autre sous-domaine tel que :
shop.example.com
n'est pas automatiquement inclus de ce fait.
Certificats génériques #
Un certificat générique peut couvrir plusieurs sous-domaines d'un niveau donné.
Par exemple :
*.example.com
peut être utilisé pour des noms d'hôte tels que :
boutique.example.com
mail.example.com
portail.example.comêtre utilisé.
Le domaine principal :
exemple.com
cependant n'est pas automatiquement couverte par le nom générique (wildcard) lui-même. Elle doit éventuellement être incluse en plus dans le certificat.
Erreur 4 : Chaîne de certificats incomplète #
Les navigateurs ne font pas confiance à un certificat de serveur de manière isolée. Des certificats intermédiaires peuvent se trouver entre le certificat du site Web et une autorité de certification racine de confiance.
Simplifié :
Certificat de site Web
↓
AC intermédiaire
↓
AC racineLe serveur doit fournir correctement la chaîne de certificats requise.
S'il manque un certificat intermédiaire nécessaire, certains clients peuvent rencontrer des problèmes lors de la vérification de la confiance.
Pourquoi une chaîne de certification défectueuse fonctionne-t-elle parfois quand même ? #
Il est possible qu'un navigateur déjà utilisé ou un système d'exploitation spécifique connaisse déjà les certificats intermédiaires nécessaires.
Par conséquent, une configuration de serveur incorrecte peut sembler fonctionner sur un appareil, tandis qu'un autre appareil affiche un avertissement de certificat.
Si des problèmes HTTPS surviennent uniquement sur certains appareils, la chaîne de certificats doit donc également être examinée.
Erreur 5 : Mixed Content #
Le contenu mixte se produit lorsqu'une page HTTPS charge des ressources via du HTTP non chiffré.
La page proprement dite est par exemple accessible via :
Cependant, dans le HTML, il y a une ressource telle que :
<img src="http://example.com/bild.jpg">ou
<script src="http://example.com/script.js"></script>Le site lui-même utilise HTTPS, mais certains éléments sont demandés via HTTP.
Pourquoi le contenu mixte pose problème #
HTTPS doit établir une connexion sécurisée pour les contenus livrés.
Si des composants sont chargés via HTTP, cette hypothèse de sécurité n'est pas entièrement vérifiée pour ces ressources.
Les navigateurs peuvent par conséquent bloquer de telles requêtes, les actualiser automatiquement ou afficher des avertissements, selon le type de ressource et le navigateur.
Causes typiques du contenu mixte #
Après un passage du HTTP au HTTPS, de vieilles URLs absolues subsistent souvent.
Par exemple dans :
contenus HTML
fichiers CSS
paramètres du thème
base de données WordPress
widgets
constructeurs de pages
JavaScript
ressources externes
anciennes URL d'imagesC'est particulièrement le cas pour les sites web anciens, où de telles URL peuvent être enregistrées à de nombreux endroits.
Trouver du contenu mixte avec les outils de développement du navigateur #
Les outils de développement des navigateurs modernes sont particulièrement utiles pour ce diagnostic.
Ouvrez la page concernée et vérifiez en particulier la console et l'onglet réseau.
En cas de contenu mixte, vous y trouverez souvent des indications sur la ressource concernée.
Rechercher des URL commençant par :
http://
commencer, bien que la page elle-même via :
https://
a été chargé.
Conseil pratique : Corrigez la véritable référence HTTP. Ignorer simplement un avertissement de navigateur ou désactiver localement les mécanismes de sécurité ne résout pas le problème pour vos visiteurs.
Contenu mixte dans WordPress #
Sous WordPress, le contenu mixte (mixed content) apparaît très souvent après un changement de domaine, une migration de site web ou une ancienne configuration HTTP.
Vérifiez d'abord si les adresses WordPress et du site Web sont correctement configurées sur HTTPS.
Par exemple :
https://example.comD'autres adresses HTTP peuvent en outre être enregistrées directement dans les contenus, les widgets, les options de thème ou les champs de base de données.
Ne pas se contenter d'un simple Rechercher & Remplacer aveugle #
Une recherche et un remplacement globaux directement dans une base de données WordPress peuvent s'avérer problématiques.
WordPress, les thèmes et les plugins peuvent stocker des données structurées ou sérialisées. Un remplacement inapproprié peut endommager ces données.
Utilisez par conséquent des outils WordPress appropriés et effectuez une sauvegarde avant toute modification importante.
Erreur 6 : Boucle de redirection après la transition HTTPS #
Une mauvaise configuration HTTPS peut provoquer une boucle de redirection.
Par exemple :
HTTP
↓
HTTPS
↓
HTTP
↓
HTTPS
↓
...Le navigateur arrête la redirection après un certain nombre d'étapes et signale une erreur.
La cause peut résider à différents endroits :
Configuration du serveur web
.htaccess
WordPress
Extension
Proxy inverse
CDN
Répartiteur de chargeÉviter plusieurs redirections HTTPS simultanées #
Des problèmes surviennent souvent lorsque plusieurs niveaux tentent indépendamment d'imposer HTTPS.
Par exemple :
Le CDN force le HTTPS
Le serveur web force le HTTPS
Le plugin WordPress force le HTTPS
Une règle .htaccess supplémentaire force le HTTPSCela ne provoque pas nécessairement une erreur, mais rend la configuration inutilement complexe et complique le diagnostic.
HTTPS doit être mis en œuvre de manière propre et transparente à un endroit approprié.
Erreur 7 : Trop de redirections #
Même sans boucle infinie, une chaîne de redirections inutilement longue peut se produire.
Par exemple :
http://example.com/
↓
http://www.example.com/
↓
https://www.example.com/
↓
https://www.example.com/de/Si cela est techniquement possible, les étapes intermédiaires inutiles doivent être évitées.
Une configuration propre redirige une ancienne variante aussi directement que possible vers l'URL de destination finale.
Erreur 8 : HTTPS ne fonctionne qu'avec ou sans www #
Si :
fonctionne, mais :
génère un avertissement de certificat, il convient de vérifier :
L'enregistrement DNS existe-t-il ?
Pointe-t-il vers la bonne infrastructure ?
Le nom d'hôte est-il inclus dans le certificat ?
Le serveur web est-il configuré pour cet hôte ?
La redirection est-elle correcte ?Un certificat ne peut être fourni de manière judicieuse pour un nom d'hôte que si l'ensemble de la configuration du domaine et du serveur correspond.
DNS et SSL sont liés lors de l'émission #
Dans le cadre de nombreuses procédures de certification automatisées, il est nécessaire de prouver que l'on contrôle le domaine ou le nom d'hôte.
Si le domaine pointe vers une infrastructure incorrecte, une émission ou un renouvellement automatique peut donc échouer.
En cas de problème, vous devez contrôler la résolution DNS. Nous expliquons comment cela fonctionne sur Vérifier les enregistrements DNS.
Ne pas confondre modification DNS et certificat #
Après un changement de serveur, deux processus distincts peuvent être impliqués :
DNS
→ Les visiteurs doivent atteindre le
bon serveur
TLS
→ ce serveur doit délivrer un
certificat valideUn certificat valide sur le nouveau serveur ne sert à rien si un visiteur, en raison de sa résolution DNS, accède toujours à un autre serveur.
Inversement, le domaine peut déjà pointer vers le nouveau serveur alors qu'aucun certificat adéquat n'y a encore été installé.
Erreur 9 : Un mauvais certificat est délivré #
Un serveur peut gérer plusieurs sites Web et certificats.
En cas de configuration erronée d'un hôte virtuel, un certificat d'un autre site web peut éventuellement être délivré pour un domaine.
Vous le remarquez au fait que le nom d'hôte appelé ne correspond pas aux noms figurant dans le certificat fourni.
Dans ce cas, ce n'est pas le navigateur qu'il faut réparer, mais la configuration du certificat ou du serveur web.
Erreur 10 : Certificat renouvelé, le navigateur affiche toujours l'ancien certificat #
Si un certificat a été renouvelé mais que l'ancien certificat continue d'être délivré, cela peut être dû à différentes causes.
Par exemple :
Le serveur Web utilise toujours
l'ancien fichier de certificat
Le service n'a pas été
correctement rechargé après la modification
Le proxy inverse fournit
un autre certificat
Le CDN termine le TLS
Le DNS pointe vers
un autre serveurIl est donc crucial non seulement de savoir quel certificat est stocké quelque part sur le serveur, mais aussi quel certificat est présenté lors de l'établissement effectif de la connexion.
Prendre en compte le CDN et le reverse proxy #
Lors de l'utilisation d'un CDN ou d'un reverse proxy, la connexion TLS peut avoir lieu à plusieurs endroits.
Simplifié :
Visiteur
↓ HTTPS
CDN / Proxy
↓ HTTPS
Serveur d'origineCela permet également d'impliquer différents certificats.
Par conséquent, un certificat valide sur le serveur d'origine ne signifie pas automatiquement que le certificat livré publiquement est correct, et vice versa.
Vérifier le HTTPS dans le navigateur #
Pour un premier diagnostic, vous pouvez utiliser le navigateur.
Vérifie :
URL demandée
État de sécurité
Informations sur le certificat
Nom d'hôte
Période de validité
Émetteur
Console
Requêtes réseauEn cas d'erreur, vous devez documenter le message exact au lieu de simplement noter „ SSL ne fonctionne pas “.
Le message d'erreur exact est crucial #
Il y a une grande différence entre les situations suivantes :
Certificat expiré
Nom d'hôte incorrect
Chaîne de certification erronée
Contenu mixte
Boucle de redirection
Le DNS pointe incorrectement
Serveur inaccessibleDu point de vue d'un utilisateur, ils peuvent tous ressembler initialement à un „ problème HTTPS “, mais ils nécessitent des solutions totalement différentes.
Vérifier en outre le code d'état HTTP #
Les codes d'état HTTPS et HTTP se situent à des niveaux différents.
Une connexion TLS peut être établie avec succès et le site Web peut ensuite tout de même répondre par :
404 Non trouvé
500 Erreur interne du serveur
503 Service indisponibleLa connexion chiffrée fonctionne alors, tandis que l'application ou le contenu demandé présente un autre problème.
Nous expliquons les principaux codes d'état sous Codes d'état HTTP expliqués : 200, 301, 404, 403 et 500.
Une erreur HTTP 500 n'est pas une erreur SSL #
Si le navigateur établit avec succès une connexion HTTPS et que le serveur répond ensuite par 500 Erreur interne du serveur répond, TLS a déjà fait sa part avec succès.
La cause se situe alors typiquement à un niveau ultérieur.
DNS
↓
TLS réussi
↓
Requête HTTP
↓
Application
↓
500 Internal Server ErrorBien dissocier ces niveaux permet de gagner beaucoup de temps lors du dépannage.
Une erreur DNS n'est pas non plus automatiquement une erreur SSL #
Si le nom de domaine ne peut pas être résolu du tout, il est possible que le navigateur n'atteigne pas encore de serveur avec lequel il pourrait établir une connexion TLS.
Même si le site Web n'apparaît pas dans le navigateur, il s'agit d'abord d'un problème de DNS ou d'accessibilité.
Surveillance HTTPS et de sites web #
Un moniteur HTTPS externe peut vérifier régulièrement si une connexion sécurisée au site Web peut être établie et si une réponse attendue peut être reçue.
Selon le système de surveillance, il est également possible de surveiller les problèmes de certificat ou une date d'expiration prochaine.
Nous expliquons le fonctionnement général de ce type d'examens sur Surveillance de sites web : surveiller l'accessibilité et les pannes.
Pourquoi la surveillance des certificats est utile #
Le renouvellement automatique des certificats réduit considérablement la charge administrative. Néanmoins, un renouvellement peut échouer en raison d'un dysfonctionnement technique.
Un contrôle externe supplémentaire peut donc aider à identifier à temps une date d'expiration imminente et inattendue.
Cependant, la surveillance ne remplace pas la résolution de la cause si le renouvellement automatique est effectivement perturbé.
HTTPS et Google #
Pour les moteurs de recherche, les signaux d'un site Web HTTPS doivent être cohérents.
Si HTTPS est la variante souhaitée, il faudrait entre autres :
liens internes
redirections
URLs canoniques
sitemap XML
URLs de sites Web publicspointer systématiquement vers la version HTTPS.
Le sitemap XML doit contenir les URL HTTPS souhaitées en conséquence. Pour en savoir plus, consultez Plan du site XML : Ce qu'il fait et comment le soumettre à Google.
Empêcher l'URL canonique de pointer vers du HTTP #
Lorsque le site Web a été entièrement migré vers HTTPS, une page HTTPS ne devrait normalement pas désigner simultanément une version HTTP comme URL privilégiée via son élément canonical.
Une telle configuration génère des signaux techniques contradictoires.
Pour faire simple, l'image devrait ressembler à ceci :
HTTP
↓ 301
HTTPS
↓
Canonique → HTTPS
↓
Sitemap → HTTPS
↓
Liens internes → HTTPSVérifier après une migration HTTP vers HTTPS #
Lorsqu'un site Web vient d'être migré vers HTTPS, vous ne devez pas seulement vérifier si la page d'accueil possède un certificat.
Vérifie de manière systématique :
Page d'accueil HTTPS accessible ?
HTTP → HTTPS ?
Sous-pages redirigées correctement ?
www / non-www correct ?
Certificat valide pour tous les noms d'hôtes requis ?
Présence de contenu mixte ?
Liens internes en HTTPS ?
Balise canonique en HTTPS ?
Le sitemap contient-il du HTTPS ?
Vérifier les pages importantes dans la Search Console ?Vérifier la version HTTPS dans Google Search Console #
L'outil d'inspection d'URL de la Google Search Console vous permet d'examiner quelle URL Google connaît et comment une page spécifique est traitée.
En cas de problèmes d'indexation, vous ne devez cependant pas considérer HTTPS de manière isolée. L'explorabilité, les statuts HTTP, les balises canonical, le sitemap et les directives d'indexation jouent également un rôle.
Vous trouverez la procédure systématique sous Google n'indexe pas mon site web : vérifier les causes.
Ne pas dramatiser le Mixed Content et le SEO #
Le contenu mixte doit être corrigé, principalement pour des raisons de sécurité, de fonctionnalité et de qualité.
Il est cependant peu utile de qualifier systématique chaque erreur HTTPS de „ catastrophe SEO “.
Les effets réels dépendent de l'erreur présente et des ressources ou URL concernées.
Les problèmes techniques devraient donc être résolus en fonction de leur cause réelle et non sur la base de promesses SEO exagérées.
HTTPS ne rend pas un site web automatiquement sûr #
Cette différence est particulièrement importante.
HTTPS protège le transfert de données entre le client et le serveur.
Il ne protège cependant pas automatiquement un site web contre :
mots de passe non sécurisés
extensions obsolètes
logiciels malveillants
injection SQL
identifiants volés
comptes utilisateurs non sécurisés
manipulation de fichiers
erreurs d'applicationImportant : Un certificat SSL valide signifie qu'une connexion chiffrée peut être établie avec le nom d'hôte confirmé. Il ne s'agit pas d'un certificat de sécurité général pour l'ensemble du site Web.
Même un site web piraté peut posséder un certificat valide #
Un serveur Web compromis peut continuer à délivrer un certificat TLS parfaitement valide.
Le navigateur peut alors établir une connexion techniquement chiffrée, bien que le site web lui-même ait été manipulé.
HTTPS et la sécurité des applications doivent donc être considérés séparément.
HTTPS ne protège pas contre un faux site web #
Un certificat valide confirme avant tout la connexion au nom d'hôte contenu dans le certificat. Il ne confirme pas qu'une entreprise, une offre ou un contenu est automatiquement digne de confiance.
Même les sites Web frauduleux peuvent utiliser HTTPS.
Les visiteurs doivent donc continuer à prêter attention au domaine réel et au contexte d'un site web.
Que faire en cas d'avertissement de navigateur ? #
Si votre navigateur vous avertit d'un problème de certificat ou de connexion HTTPS, vous ne devez pas simplement ignorer l'avertissement de manière permanente.
Pour votre propre site web, le diagnostic suivant est recommandé :
noter le message d'erreur exact
↓
contrôler le nom d'hôte
↓
examiner le certificat
↓
vérifier la période de validité
↓
vérifier SAN / nom d'hôte
↓
vérifier la chaîne de certification
↓
contrôler la résolution DNS
↓
prendre en compte le proxy / CDN
↓
vérifier la configuration du serveurNe pas accuser trop vite le cache du navigateur #
En cas de problèmes HTTPS, il est souvent recommandé en premier lieu de vider le cache du navigateur.
Cela peut être utile dans certaines situations, mais ne devrait pas remplacer un véritable diagnostic.
Si le certificat fourni publiquement a expiré ou a été émis pour le mauvais nom d'hôte, la suppression du cache normal du site Web ne résoudra pas le problème.
Vérifier le problème sur plusieurs appareils #
Si un seul appareil affiche un avertissement de certificat tandis que d'autres appareils récents fonctionnent sans problème, vous devez également examiner l'environnement local.
Les facteurs possibles sont :
heure système incorrecte
système d'exploitation obsolète
navigateur obsolète
proxy local
logiciel antivirus
réseau d'entreprise
magasin de certificats localSi, en revanche, de nombreux appareils indépendants reçoivent le même avertissement, cela plaide davantage en faveur d'un problème lié au serveur ou au certificat.
Erreur uniquement sur un réseau #
Si HTTPS fonctionne sur le réseau mobile mais pas sur le réseau d'entreprise ou domestique, des composants réseau locaux peuvent également être impliqués.
Par exemple :
Serveur proxy
Pare-feu
Résolveur DNS
Inspection TLS
VPN
Filtre localUn tel test aide à localiser la cause.
Vérifier l'heure du système #
Les certificats ont une période de validité définie.
Si la date ou l'heure d'un appareil sont manifestement erronées, un navigateur peut considérer un certificat valide comme invalide.
C'est pourquoi, en cas d'avertissements de certificat inexpliqués sur un seul appareil, l'heure du système fait partie des premières vérifications simples à effectuer.
Erreur après un déménagement de site web #
Après un changement d'hébergement ou de serveur, des problèmes HTTPS peuvent survenir si certains éléments de la transition ne concordent pas encore.
Vérifie en particulier :
Le DNS pointe-t-il vers le nouveau serveur ?
Le certificat est-il présent sur le nouveau serveur ?
Tous les noms d'hôtes requis sont-ils inclus ?
Les redirections HTTP sont-elles correctes ?
Anciennes URL HTTP dans le site web ?
CDN / Proxy mis à jour ?
Plan du site et balises canoniques corrects ?Les modifications DNS peuvent également prendre du temps avant que les différents résolveurs n'utilisent le nouvel état. Nous expliquons cela plus en détail sous Propagation DNS expliquée.
Erreur après le changement de domaine #
Si un site web est de :
sur
emménage, le nouveau domaine a besoin d'un certificat approprié.
L'ancienne domaine doit également rester techniquement accessible pendant la migration afin que les redirections vers le nouveau domaine puissent fonctionner.
Une erreur de certificat sur l'ancien domaine HTTPS peut toucher les visiteurs avant même qu'une redirection HTTP ne puisse être traitée.
Pourquoi HTTPS doit fonctionner avant une redirection #
Il s'agit d'un point technique souvent négligé.
Par exemple, un visiteur appelle :
Avant que le serveur Web ne réponde par :
301 Déplacé de manière permanente
peut envoyer, la connexion TLS vers l'ancien domaine doit d'abord être établie.
Si leur certificat est invalide, le navigateur peut afficher un avertissement de sécurité dès avant.
Conseil pratique : Lors d'une migration de domaine, ne laissez pas expérer prématurément le certificat de l'ancien domaine HTTPS. Les anciennes URLs doivent encore être accessibles de manière sécurisée afin que leurs redirections puissent être traitées de manière fiable.
Ne pas confondre certificat SSL et e-mail #
Un certificat pour le site Web sous :
ce n'est pas automatiquement toute la configuration TLS de tous les autres services du domaine.
Les services de messagerie tels que IMAP ou SMTP peuvent utiliser d'autres noms d'hôtes et leurs propres connexions TLS.
Un certificat HTTPS valide sur le site web ne prouve donc pas automatiquement que tous les services de messagerie sont correctement configurés.
Isoler systématiquement les erreurs HTTPS #
Un bon diagnostic suit un ordre précis.
Accéder au domaine
↓
Le DNS fonctionne ?
↓
Le serveur est-il accessible ?
↓
Connexion TLS possible ?
↓
Certificat valide ?
↓
Nom d'hôte correct ?
↓
Chaîne de certification correcte ?
↓
Réponse HTTP correcte ?
↓
Redirections correctes ?
↓
Mixed Content ?
↓
L'application fonctionne ?Cela vous évite de chercher des problèmes au mauvais niveau.
Erreurs SSL et HTTPS typiques #
Certificat expiré
Certificat pas encore valide
Nom d'hôte incorrect
www non couvert
Sous-réseau non couvert
Chaîne de certification incomplète
Mauvais certificat délivré
Contenu mixte
HTTP ne redirige pas vers HTTPS
Boucle de redirection
Chaîne de redirection inutile
Le DNS pointe vers le mauvais serveur
Le CDN fournit un autre certificat
Anciennes URL HTTP après la migration
La balise Canonical pointe vers HTTP
Le sitemap contient d'anciennes URL HTTP
L'ancien domaine perd son certificat avant la fin de la migrationListe de contrôle : Vérifier SSL et HTTPS #
accéder directement à https://
↓
Avertissement du navigateur présent ?
↓
Ouvrir le certificat
↓
Vérifier la période de validité
↓
Vérifier le nom d'hôte / SAN
↓
Vérifier la chaîne de certification
↓
Accéder à http://
↓
Vérifier la redirection vers HTTPS
↓
Vérifier www et non-www
↓
Vérifier les sous-pages importantes
↓
Ouvrir la console du navigateur
↓
Rechercher du contenu mixte (Mixed Content)
↓
Vérifier le statut HTTP
↓
Vérifier la résolution DNS
↓
Prendre en compte le CDN / Proxy
↓
Vérifier les liens internes
↓
Vérifier la balise Canonique
↓
Vérifier le sitemap XML
↓
Contrôler la surveillance externeRésumé #
Une configuration HTTPS fonctionnelle implique bien plus qu'un simple certificat SSL installé. Le domaine, le DNS, le certificat, le serveur web, les redirections et les ressources chargées par le site web doivent être en parfaite adéquation.
En cas d'erreur de certificat, vous devez d'abord vérifier si le certificat est valide en termes de durée et s'il correspond au nom d'hôte appelé. Ensuite, la chaîne de certificats, la résolution DNS, la configuration du serveur ainsi que, le cas échéant, le CDN ou le proxy inverse peuvent être examinés.
Le contenu mixte est un autre problème : ici, HTTPS fonctionne en principe, mais la page sécurisée essaie de charger certaines ressources via HTTP. De telles références devraient être corrigées à leur source d'origine.
Sur un site Web entièrement migré vers HTTPS, les variantes HTTP doivent rediriger proprement vers HTTPS. Les liens internes, les URL canoniques et les sitemaps XML doivent également utiliser de manière cohérente les adresses HTTPS souhaitées.
Une vigilance particulière est requise lors des migrations de domaines et de serveurs. L'ancien domaine a également besoin d'un certificat valide pendant une migration HTTPS si des visiteurs accèdent à d'anciennes URL sécurisées et doivent ensuite être redirigés.
HTTPS ne doit pas non plus être confondu avec la sécurité complète d'un site web. Une connexion chiffrée protège le transfert de données, mais n'empêche pas les failles de sécurité dans WordPress, les plugins, les applications ou les comptes d'utilisateurs.
En cas de problèmes HTTPS, le message d'erreur exact est donc plus important que la déclaration générale „ SSL ne fonctionne pas “. Quiconque considère le DNS, le TLS, le HTTP et l'application comme des couches distinctes trouve la cause réelle beaucoup plus rapidement.
