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.
Das kann in bestimmten Situationen hilfreich sein, sollte aber keine eigentliche Diagnose ersetzen.
Wenn das öffentlich ausgelieferte Zertifikat abgelaufen oder für den falschen Hostnamen ausgestellt ist, wird das Problem durch das Löschen des normalen Website-Caches nicht behoben.
Problem auf mehreren Geräten prüfen #
Wenn nur ein einzelnes Gerät eine Zertifikatswarnung zeigt, während andere aktuelle Geräte problemlos funktionieren, solltest du auch die lokale Umgebung untersuchen.
Mögliche Faktoren sind:
falsche Systemzeit
veraltetes Betriebssystem
veralteter Browser
lokaler Proxy
Antivirus-Software
Unternehmensnetzwerk
lokaler ZertifikatsspeicherWenn dagegen zahlreiche unabhängige Geräte dieselbe Warnung erhalten, spricht das stärker für ein server- oder zertifikatsseitiges Problem.
Fehler nur in einem Netzwerk #
Funktioniert HTTPS über Mobilfunk, aber nicht im Firmen- oder Heimnetzwerk, können zusätzlich lokale Netzwerkkomponenten beteiligt sein.
Par exemple :
Proxy
Firewall
DNS-Resolver
TLS-Inspection
VPN
lokaler FilterEin solcher Test hilft dabei, die Ursache räumlich einzugrenzen.
Systemzeit kontrollieren #
Zertifikate besitzen einen definierten Gültigkeitszeitraum.
Ist Datum oder Uhrzeit eines Geräts deutlich falsch, kann ein Browser ein gültiges Zertifikat als ungültig bewerten.
Bei unerklärlichen Zertifikatswarnungen auf nur einem Gerät gehört die Systemzeit deshalb zu den einfachen ersten Kontrollen.
Fehler nach einem Website-Umzug #
Nach einem Hosting- oder Serverwechsel können HTTPS-Probleme entstehen, wenn einzelne Bestandteile der Umstellung noch nicht zusammenpassen.
Vérifie en particulier :
DNS zeigt auf neuen Server?
Zertifikat auf neuem Server vorhanden?
alle benötigten Hostnamen enthalten?
HTTP-Weiterleitungen korrekt?
alte HTTP-URLs in Website?
CDN / Proxy aktualisiert?
Sitemap und Canonical korrekt?DNS-Änderungen können außerdem Zeit benötigen, bis unterschiedliche Resolver den neuen Zustand verwenden. Mehr dazu erklären wir unter DNS-Propagation erklärt.
Fehler nach Änderung der Domain #
Wenn eine Website von:
sur
umzieht, benötigt die neue Domain ein passendes Zertifikat.
Auch die alte Domain sollte während der Migration weiterhin technisch erreichbar sein, damit Weiterleitungen zur neuen Domain funktionieren können.
Ein Zertifikatsfehler auf der alten HTTPS-Domain kann Besucher treffen, bevor überhaupt eine HTTP-Weiterleitung verarbeitet werden kann.
Warum HTTPS vor einer Weiterleitung funktionieren muss #
Das ist ein häufig übersehener technischer Punkt.
Ein Besucher ruft beispielsweise auf:
Bevor der Webserver eine Antwort wie:
301 Déplacé de manière permanente
senden kann, muss zunächst die TLS-Verbindung zur alten Domain aufgebaut werden.
Ist deren Zertifikat ungültig, kann der Browser bereits vorher eine Sicherheitswarnung anzeigen.
Conseil pratique : Lass bei einer Domainmigration das Zertifikat der alten HTTPS-Domain nicht vorschnell auslaufen. Die alten URLs müssen noch sicher erreichbar sein, damit ihre Weiterleitungen zuverlässig verarbeitet werden können.
SSL-Zertifikat und E-Mail nicht verwechseln #
Ein Zertifikat für die Website unter:
ist nicht automatisch die gesamte TLS-Konfiguration aller anderen Dienste der Domain.
E-Mail-Dienste wie IMAP oder SMTP können andere Hostnamen und eigene TLS-Verbindungen verwenden.
Ein funktionierendes HTTPS-Zertifikat der Website beweist deshalb nicht automatisch, dass sämtliche E-Mail-Dienste korrekt konfiguriert sind.
HTTPS-Fehler systematisch eingrenzen #
Eine gute Diagnose folgt einer festen Reihenfolge.
Domain aufrufen
↓
DNS funktioniert?
↓
Server erreichbar?
↓
TLS-Verbindung möglich?
↓
Zertifikat gültig?
↓
Hostname korrekt?
↓
Zertifikatskette korrekt?
↓
HTTP-Antwort korrekt?
↓
Weiterleitungen korrekt?
↓
Mixed Content?
↓
Anwendung funktioniert?Damit vermeidest du, Probleme auf der falschen Ebene zu suchen.
Typische SSL- und HTTPS-Fehler #
Zertifikat abgelaufen
Zertifikat noch nicht gültig
Hostname stimmt nicht
www nicht abgedeckt
Subdomain nicht abgedeckt
Zertifikatskette unvollständig
falsches Zertifikat ausgeliefert
Mixed Content
HTTP leitet nicht auf HTTPS
Redirect-Schleife
unnötige Redirect-Kette
DNS zeigt auf falschen Server
CDN liefert anderes Zertifikat
alte HTTP-URLs nach Migration
Canonical zeigt auf HTTP
Sitemap enthält alte HTTP-URLs
alte Domain verliert Zertifikat
vor Abschluss der MigrationCheckliste: SSL und HTTPS prüfen #
https:// direkt aufrufen
↓
Browserwarnung vorhanden?
↓
Zertifikat öffnen
↓
Gültigkeitszeitraum prüfen
↓
Hostname / SAN prüfen
↓
Zertifikatskette prüfen
↓
http:// aufrufen
↓
Weiterleitung auf HTTPS prüfen
↓
www und non-www prüfen
↓
wichtige Unterseiten prüfen
↓
Browser-Konsole öffnen
↓
Mixed Content suchen
↓
HTTP-Status prüfen
↓
DNS-Auflösung prüfen
↓
CDN / Proxy berücksichtigen
↓
interne Links prüfen
↓
Canonical prüfen
↓
XML-Sitemap prüfen
↓
externes Monitoring kontrollierenRésumé #
Ein funktionierendes HTTPS-Setup besteht aus mehr als einem installierten SSL-Zertifikat. Domain, DNS, Zertifikat, Webserver, Weiterleitungen und die von der Website geladenen Ressourcen müssen zusammenpassen.
Bei einem Zertifikatsfehler solltest du zunächst prüfen, ob das Zertifikat zeitlich gültig ist und zum aufgerufenen Hostnamen passt. Anschließend können Zertifikatskette, DNS-Auflösung, Serverkonfiguration sowie gegebenenfalls CDN oder Reverse Proxy untersucht werden.
Mixed Content ist ein anderes Problem: Hier funktioniert HTTPS grundsätzlich, die sichere Seite versucht jedoch einzelne Ressourcen über HTTP zu laden. Solche Referenzen sollten an ihrer eigentlichen Quelle korrigiert werden.
Bei einer vollständig auf HTTPS umgestellten Website sollten HTTP-Varianten sauber auf HTTPS weiterleiten. Interne Links, Canonical-URLs und XML-Sitemaps sollten ebenfalls konsistent die gewünschten HTTPS-Adressen verwenden.
Besondere Vorsicht ist bei Domain- und Servermigrationen erforderlich. Auch die alte Domain benötigt während einer HTTPS-Migration weiterhin ein gültiges Zertifikat, wenn Besucher sichere alte URLs aufrufen und anschließend per Redirect weitergeleitet werden sollen.
HTTPS darf außerdem nicht mit vollständiger Website-Sicherheit verwechselt werden. Eine verschlüsselte Verbindung schützt die Datenübertragung, verhindert aber keine Sicherheitslücken in WordPress, Plugins, Anwendungen oder Benutzerkonten.
Bei HTTPS-Problemen ist deshalb die genaue Fehlermeldung wichtiger als die pauschale Aussage „SSL funktioniert nicht“. Wer DNS, TLS, HTTP und Anwendung als getrennte Ebenen betrachtet, findet die tatsächliche Ursache wesentlich schneller.
