Controllo del certificato SSL e HTTPS: individuare gli errori comuni

Oggi HTTPS fa parte dello standard di un sito web professionale. Crittografa la connessione tra il browser e il server web e protegge i dati trasmessi dall'essere letti o modificati in modo invisibile durante il trasporto.

Il fatto che un sito web fondamentalmente tramite https:// essere raggiungibile, tuttavia, non significa ancora automaticamente che l'intera configurazione HTTPS sia priva di errori.

Un certificato scaduto, un nome host errato, contenuti misti, reindirizzamenti difettosi o problemi con la catena di certificati possono far sì che i browser mostrino avvisi di sicurezza o non carichino correttamente singole risorse.

In questo articolo ti mostriamo come esaminare sistematicamente i problemi di SSL/TLS e HTTPS e come distinguere tra loro i vari errori tipici.

Breve spiegazione: I certificati SSL consentono una connessione HTTPS crittografata e confermano per quale dominio o nome host un certificato è valido. Se il browser mostra un avviso HTTPS, dovresti quindi verificare non solo se è presente un certificato, ma anche la sua validità, il nome host, la catena di certificati e le risorse caricate dal sito web.

SSL e TLS: qual è la verità? #

Nella vita di tutti i giorni si continua a parlare spesso di un Certificato SSL parlato.

Tecnicamente, tuttavia, le moderne connessioni HTTPS utilizzano TLS. SSL si riferisce a vecchi protocolli precedenti.

Termini come:

Certificato SSL
Crittografia SSL
SSL per sito web

sono comunque ancora comuni nell'uso comune.

Tecnicamente più preciso sarebbe, ad esempio:

Certificato TLS

o

Connessione HTTPS con TLS

In questo articolo usiamo il termine comune certificato SSL laddove facilita la comprensione.

Che cosa fa HTTPS? #

In una connessione HTTPS, il browser comunica in modo cifrato con il server.

In sintesi:

Browser
   ↓
Connessione TLS
   ↓
Verifica identità / certificato
   ↓
connessione cifrata
   ↓
Web server

Ciò mira in particolare a proteggere la riservatezza e l'integrità dei dati trasmessi.

HTTP e HTTPS sono varianti di URL diverse #

Questi due URL sembrano simili:

http://example.com/

https://example.com

Tuttavia, dal punto di vista tecnico, si tratta di varianti di URL diverse.

Su un sito web completamente convertito in HTTPS, la versione HTTP dovrebbe normalmente reindirizzare in modo pulito alla corrispondente versione HTTPS.

Per esempio:

http://example.com/beispiel/

        ↓

301 Permanent Redirect

        ↓

https://example.com/beispiel/

Spieghiamo come funzionano i reindirizzamenti permanenti su Configurazione del reindirizzamento 301: reindirizzare gli URL in modo permanente.

Che cos'è un certificato SSL? #

Un certificato contiene informazioni necessarie per la creazione e la verifica di una connessione sicura.

Ciò include, tra le altre cose, informazioni su quali nomi host il certificato è valido, da chi è stato emesso e in quale periodo è valido.

Un browser verifica queste informazioni durante la creazione della connessione HTTPS.

Quali informazioni dovresti verificare su un certificato? #

Durante la ricerca degli errori sono particolarmente rilevanti i seguenti punti:

Dominio / Nome host

Emittente

Inizio validità

Fine validità

Nomi alternativi del soggetto (SAN)

Catena di certificati

Attendibilità

I browser moderni forniscono una parte di queste informazioni tramite le informazioni di sicurezza o dei certificati oppure tramite gli strumenti di sviluppo.

Il simbolo del lucchetto non è l'intera diagnosi #

Le interfaccia dei browser cambiano regolarmente. A seconda del browser e della versione, una connessione sicura non viene quindi sempre rappresentata esattamente con lo stesso simbolo.

Non affidarti esclusivamente a un simbolo di lucchetto per la diagnosi tecnica.

Più importante è:

Viene utilizzato https://?

Il certificato è valido?

Corrisponde al nome host?

La connessione è attendibile?

Vengono caricate risorse non sicure?

Primo test: accedere al sito web direttamente con HTTPS #

Inizia con il vero indirizzo HTTPS:

https://deine-domain.ch

Verifica prima se la pagina si apre senza avvisi di sicurezza.

Successivamente, non dovresti testare solo la pagina iniziale, ma anche alcune tipiche pagine secondarie.

Per esempio:

Home page

Sotto-pagina

Articolo del blog

Pagina di contatto

Pagina negozio o di prodotto

Un problema può riguardare solo singole pagine o risorse.

Secondo test: richiama la versione HTTP #

Chiama poi consapevolmente la variante non criptata:

http://deine-domain.ch/

Su un sito web completamente convertito in HTTPS, di solito questo dovrebbe diventare il corrispondente indirizzo HTTPS.

Controlla anche una pagina secondaria:

http://deine-domain.ch/beispiel/

Non dovrebbe essere inviata genericamente alla homepage, ma normalmente a:

https://deine-domain.ch/beispiel

controllare anche www e non-www #

Inoltre, esistono spesso varianti con e senza www.

Per esempio:

https://example.com/

https://www.example.com/

Se solo una di queste varianti viene utilizzata come sito web principale, l'altra dovrebbe reindirizzare ad essa in modo coerente.

Lo stesso vale per le varianti HTTP.

Una configurazione tipica potrebbe ad esempio apparire così:

http://example.com/
        ↓
https://www.example.com/

http://www.example.com/
        ↓
https://www.example.com/

https://example.com/
        ↓
https://www.example.com/

Quale variante venga utilizzata come indirizzo principale è meno importante di un'implementazione tecnica coerente.

Errore 1: Il certificato è scaduto #

I certificati hanno un periodo di validità limitato.

Se un certificato non viene rinnovato in tempo, il browser può mostrare un avviso di sicurezza.

Pertanto, durante la diagnosi dovresti controllare le date di validità:

valido dal:
...

valido fino al:
...

Se la data attuale non rientra nel periodo di validità, il certificato deve essere rinnovato o è necessario verificare il rinnovo automatico.

Perché i certificati vengono rinnovati automaticamente #

I moderni sistemi di hosting automatizzano spesso l'emissione e il rinnovo dei certificati.

Tuttavia, un rinnovo automatico può fallire se, ad esempio, il dominio non punta più correttamente al server o se non è possibile eseguire una validazione necessaria.

Pertanto, in caso di certificato scaduto, non bisogna solo sostituire manualmente il certificato, ma è necessario anche indagare sulla causa del rinnovo fallito.

Errore 2: Il certificato non è ancora valido #

Anche un certificato con una data di validità futura può causare un avviso.

In solchen Fällen sollte zusätzlich überprüft werden, ob Datum und Uhrzeit auf dem betroffenen Gerät beziehungsweise System korrekt eingestellt sind.

Un orologio locale errato può far sì che un certificato altrimenti valido sembri non ancora valido o già scaduto dal punto di vista del dispositivo.

Errore 3: Il certificato non corrisponde al dominio #

Un certificato deve essere valido per il nome host richiesto.

Supponendo che tu chiami:

https://shop.example.com

Il certificato consegnato copre tuttavia solo:

www.example.com

ab.

Allora c'è una mancata corrispondenza del nome host.

Il browser non può verificare che il certificato sia stato emesso per il nome host effettivamente visitato.

Controlla i Subject Alternative Names #

I certificati moderni possono essere validi per più hostname.

Questi vengono tipicamente specificati tramite i cosiddetti Subject Alternative Names, in breve SAN.

Ad esempio, un certificato potrebbe coprire i seguenti nomi:

example.com

www.example.com

Un altro sottodominio come:

shop.example.com

non è quindi automaticamente incluso.

Certificati wildcard #

Un certificato wildcard può coprire più sottodomini di un determinato livello.

Per esempio:

*.example.com

può essere utilizzato per nomi host come:

shop.example.com

mail.example.com

portal.example.com

essere utilizzato.

Il dominio principale:

example.com

tuttavia non è automaticamente coperta dal nome con carattere jolly stesso. Potrebbe essere necessario includerla ulteriormente nel certificato.

Errore 4: catena dei certificati incompleta #

I browser non si fidano di un certificato del server in isolamento. Tra il certificato del sito web e un'autorità di certificazione radice attendibile possono esservi certificati intermedi.

In sintesi:

Certificato del sito web
        ↓
CA intermedia
        ↓
CA radice

Il server deve fornire correttamente la catena di certificati richiesta.

Se manca un certificato intermediario necessario, singoli client potrebbero riscontrare problemi nella verifica dell'attendibilità.

Perché una catena di certificati difettosa a volte funziona comunque? #

Un browser già utilizzato o un determinato sistema operativo potrebbero già conoscere i certificati intermedi necessari.

Ciò può far sì che una configurazione errata del server funzioni apparentemente su un dispositivo, mentre un altro dispositivo mostra un avviso di certificato.

Se i problemi HTTPS si verificano solo su determinati dispositivi, è necessario esaminare anche la catena dei certificati.

Errore 5: Mixed Content #

Il Mixed Content si verifica quando una pagina HTTPS carica risorse tramite HTTP non criptato.

La pagina effettiva viene richiamata, ad esempio, tramite:

https://example.com

tuttavia, nell'HTML si trova una risorsa come:

<img src="http://example.com/bild.jpg">

o:

<script src="http://example.com/script.js"></script>

Il sito stesso utilizza HTTPS, ma singoli componenti vengono richiesti tramite HTTP.

Perché il Mixed Content è problematico #

HTTPS deve stabilire una connessione sicura per i contenuti forniti.

Se i componenti vengono caricati tramite HTTP, questa assunzione di sicurezza non è completamente garantita per tali risorse.

I browser possono quindi bloccare tali richieste, aggiornarle automaticamente o emettere avvisi, a seconda del tipo di risorsa e del browser.

Cause tipiche di contenuti misti #

Dopo il passaggio da HTTP a HTTPS, rimangono spesso vecchi URL assoluti.

Ad esempio in:

contenuti HTML

file CSS

impostazioni del tema

database WordPress

widget

Page Builder

JavaScript

risorse esterne

vecchi URL delle immagini

Soprattutto nei siti Web più vecchi, tali URL possono essere memorizzati in molti punti.

Trovare i contenuti misti con gli strumenti di sviluppo del browser #

Gli strumenti di sviluppo dei browser moderni sono particolarmente utili per questa diagnosi.

Apri la pagina interessata e controlla in particolare la console e la sezione di rete.

In caso di Mixed Content, trovi spesso indicazioni sulla risorsa interessata.

Ricerca di URL che iniziano con:

http://

iniziare, sebbene la pagina stessa riguardo:

https://

è stato caricato.

Consiglio pratico: Risolvi il problema reale del riferimento HTTP. Ignorare semplicemente un avviso del browser o disattivare i meccanismi di sicurezza a livello locale non risolve il problema per i tuoi visitatori.

Contenuto misto in WordPress #

In WordPress si verifica un contenuto misto (mixed content) particolarmente spesso dopo una modifica del dominio, il trasferimento di un sito web o una precedente configurazione HTTP.

Verifica prima di tutto se l'indirizzo WordPress e l'indirizzo del sito web sono impostati correttamente su HTTPS.

Per esempio:

https://example.com

Altri indirizzi HTTP possono inoltre essere memorizzati direttamente in contenuti, widget, opzioni del tema o campi del database.

Non eseguire semplicemente una ricerca e sostituzione alla cieca #

Una ricerca e sostituzione generalizzata direttamente in un database WordPress può essere problematica.

WordPress, temi e plugin possono archiviare dati strutturati o serializzati. Una sostituzione inappropriata può danneggiare questi dati.

Utilizza quindi gli strumenti WordPress appropriati ed effettua un backup prima di apportare modifiche estese.

Errore 6: Loop di reindirizzamento dopo il passaggio a HTTPS #

Una configurazione HTTPS errata può generare un ciclo di reindirizzamento.

Per esempio:

HTTP
 ↓
HTTPS
 ↓
HTTP
 ↓
HTTPS
 ↓
...

Il browser interrompe il reindirizzamento dopo un certo numero di passaggi e segnala un errore.

La causa può trovarsi in diversi punti:

Configurazione del server web

.htaccess

WordPress

Plugin

Proxy inverso

CDN

Bilanciatore di carico

Evitare più reindirizzamenti HTTPS contemporaneamente #

I problemi si verificano spesso quando più livelli cercano indipendentemente di imporre HTTPS.

Per esempio:

CDN impone HTTPS

Server web impone HTTPS

Plugin WordPress impone HTTPS

regola .htaccess aggiuntiva impone HTTPS

Ciò non deve necessariamente causare un errore, ma rende la configurazione inutilmente complessa e rende difficile la diagnostica.

L'HTTPS dovrebbe essere implementato in modo pulito e comprensibile in un punto appropriato.

Errore 7: Troppi reindirizzamenti #

Anche senza un ciclo infinito, si può creare una catena di reindirizzamenti inutilmente lunga.

Per esempio:

http://example.com/
 ↓
http://www.example.com/
 ↓
https://www.example.com/
 ↓
https://www.example.com/de/

Wenn technisch möglich, sollten unnötige Zwischenschritte vermieden werden.

Eine saubere Konfiguration leitet eine alte Variante möglichst direkt auf die endgültige Ziel-URL.

Fehler 8: HTTPS funktioniert nur mit oder ohne www #

Wenn:

https://example.com

funktioniert, aber:

https://www.example.com

eine Zertifikatswarnung erzeugt, sollte geprüft werden:

Existiert der DNS-Eintrag?

Zeigt er auf die richtige Infrastruktur?

Ist der Hostname im Zertifikat enthalten?

Ist der Webserver für diesen Host konfiguriert?

Ist die Weiterleitung korrekt?

Ein Zertifikat kann nur sinnvoll für einen Hostnamen bereitgestellt werden, wenn die gesamte Domain- und Serverkonfiguration dazu passt.

DNS und SSL hängen bei der Ausstellung zusammen #

Bei vielen automatisierten Zertifikatsverfahren muss nachgewiesen werden, dass die Domain beziehungsweise der Hostname kontrolliert wird.

Wenn die Domain auf eine falsche Infrastruktur zeigt, kann eine automatische Ausstellung oder Erneuerung deshalb scheitern.

Bei Problemen solltest du die DNS-Auflösung kontrollieren. Wie das funktioniert, erklären wir unter Controllare i record DNS.

DNS-Änderung und Zertifikat nicht verwechseln #

Nach einem Serverwechsel können zwei getrennte Vorgänge beteiligt sein:

DNS
→ Besucher müssen den
  richtigen Server erreichen

TLS
→ dieser Server muss ein
  gültiges Zertifikat ausliefern

Ein korrektes Zertifikat auf dem neuen Server hilft nicht, wenn ein Besucher aufgrund seiner DNS-Auflösung noch einen anderen Server erreicht.

Umgekehrt kann die Domain bereits auf dem neuen Server ankommen, während dort noch kein passendes Zertifikat installiert wurde.

Fehler 9: Falsches Zertifikat wird ausgeliefert #

Ein Server kann mehrere Websites und Zertifikate verwalten.

Bei einer fehlerhaften virtuellen Host-Konfiguration kann für eine Domain unter Umständen ein Zertifikat einer anderen Website ausgeliefert werden.

Das erkennst du daran, dass der aufgerufene Hostname nicht zu den Namen im ausgelieferten Zertifikat passt.

In diesem Fall muss nicht der Browser repariert werden, sondern die Zertifikats- beziehungsweise Webserver-Konfiguration.

Fehler 10: Zertifikat erneuert, Browser zeigt trotzdem altes Zertifikat #

Wenn ein Zertifikat erneuert wurde, aber weiterhin das alte Zertifikat ausgeliefert wird, können unterschiedliche Ursachen bestehen.

Per esempio:

Webserver verwendet noch
alte Zertifikatsdatei

Dienst wurde nach Änderung
nicht korrekt neu geladen

Reverse Proxy liefert
anderes Zertifikat

CDN terminiert TLS

DNS zeigt auf
anderen Server

Entscheidend ist deshalb nicht nur, welches Zertifikat irgendwo auf dem Server gespeichert ist, sondern welches Zertifikat beim tatsächlichen Verbindungsaufbau ausgeliefert wird.

CDN und Reverse Proxy berücksichtigen #

Bei Verwendung eines CDN oder Reverse Proxy kann die TLS-Verbindung an mehreren Stellen stattfinden.

In sintesi:

Besucher
   ↓ HTTPS
CDN / Proxy
   ↓ HTTPS
Origin-Server

Damit können auch unterschiedliche Zertifikate beteiligt sein.

Ein gültiges Zertifikat am Origin-Server bedeutet deshalb nicht automatisch, dass das öffentlich ausgelieferte Zertifikat korrekt ist – und umgekehrt.

HTTPS im Browser prüfen #

Für eine erste Diagnose kannst du den Browser verwenden.

Controlla:

aufgerufene URL

Sicherheitsstatus

Zertifikatsinformationen

Hostname

Gültigkeitszeitraum

Aussteller

Konsole

Netzwerk-Anfragen

Bei einem Fehler solltest du die genaue Meldung dokumentieren, statt lediglich „SSL funktioniert nicht“ zu notieren.

Die genaue Fehlermeldung ist entscheidend #

Zwischen folgenden Situationen besteht ein großer Unterschied:

Zertifikat abgelaufen

Hostname stimmt nicht

Zertifikatskette fehlerhaft

Mixed Content

Redirect-Schleife

DNS zeigt falsch

Server nicht erreichbar

Alle können aus Sicht eines Benutzers zunächst wie ein „HTTPS-Problem“ wirken, benötigen aber völlig unterschiedliche Lösungen.

HTTP-Statuscode zusätzlich prüfen #

HTTPS und HTTP-Statuscodes sind unterschiedliche Ebenen.

Eine TLS-Verbindung kann erfolgreich aufgebaut werden und die Website anschließend trotzdem antworten mit:

404 Not Found

500 Internal Server Error

503 Service Unavailable

Dann funktioniert die verschlüsselte Verbindung, während die Anwendung oder der angeforderte Inhalt ein anderes Problem besitzt.

Die wichtigsten Statuscodes erklären wir unter Codici di stato HTTP spiegati: 200, 301, 404, 403 e 500.

Ein HTTP-500-Fehler ist kein SSL-Fehler #

Wenn der Browser erfolgreich eine HTTPS-Verbindung aufbaut und der Server anschließend mit Errore interno del server antwortet, hat TLS seinen Teil bereits erfolgreich erledigt.

Die Ursache liegt dann typischerweise auf einer späteren Ebene.

DNS
 ↓
TLS erfolgreich
 ↓
HTTP-Anfrage
 ↓
Anwendung
 ↓
500 Internal Server Error

Diese Ebenen sauber auseinanderzuhalten spart bei der Fehlersuche viel Zeit.

Ein DNS-Fehler ist ebenfalls nicht automatisch ein SSL-Fehler #

Kann der Domainname überhaupt nicht aufgelöst werden, erreicht der Browser möglicherweise noch keinen Server, mit dem er eine TLS-Verbindung aufbauen könnte.

Auch wenn die Website im Browser nicht erscheint, liegt dann zunächst ein DNS- beziehungsweise Erreichbarkeitsproblem vor.

HTTPS und Website-Monitoring #

Ein externer HTTPS-Monitor kann regelmäßig prüfen, ob eine sichere Verbindung zur Website aufgebaut und eine erwartete Antwort empfangen werden kann.

Je nach Monitoring-System können auch Zertifikatsprobleme oder ein bevorstehendes Ablaufdatum überwacht werden.

Wie solche Prüfungen grundsätzlich funktionieren, erklären wir unter Monitoraggio di siti web: monitorare la disponibilità e le interruzioni.

Warum Zertifikatsüberwachung sinnvoll ist #

Automatische Zertifikatserneuerung reduziert den administrativen Aufwand erheblich. Trotzdem kann eine Erneuerung aufgrund einer technischen Störung scheitern.

Ein zusätzlicher externer Check kann deshalb helfen, ein unerwartet bevorstehendes Ablaufdatum rechtzeitig zu erkennen.

Monitoring ersetzt allerdings nicht die Behebung der Ursache, wenn die automatische Erneuerung tatsächlich gestört ist.

HTTPS und Google #

Für Suchmaschinen sollten die Signale einer HTTPS-Website konsistent sein.

Wenn HTTPS die gewünschte Variante ist, sollten unter anderem:

interne Links

Weiterleitungen

Canonical-URLs

XML-Sitemap

öffentliche Website-URLs

konsistent auf die HTTPS-Version zeigen.

Die XML-Sitemap sollte entsprechend die gewünschten HTTPS-URLs enthalten. Mehr dazu findest du unter Mappa del sito XML: cosa fa e come inviarla a Google.

Canonical nicht auf HTTP zeigen lassen #

Wenn die Website vollständig auf HTTPS umgestellt wurde, sollte eine HTTPS-Seite normalerweise nicht gleichzeitig über ihr Canonical-Element eine HTTP-Version als bevorzugte URL auszeichnen.

Eine solche Konfiguration erzeugt widersprüchliche technische Signale.

Vereinfacht sollte das Bild so aussehen:

HTTP
 ↓ 301
HTTPS
 ↓
Canonical → HTTPS
 ↓
Sitemap → HTTPS
 ↓
interne Links → HTTPS

Nach einer HTTP-zu-HTTPS-Umstellung prüfen #

Wenn eine Website neu auf HTTPS umgestellt wurde, solltest du nicht nur kontrollieren, ob die Startseite ein Zertifikat besitzt.

Verifica sistematicamente:

HTTPS-Startseite erreichbar?

HTTP → HTTPS?

Unterseiten korrekt weitergeleitet?

www / non-www korrekt?

Zertifikat für alle
benötigten Hostnamen gültig?

Mixed Content vorhanden?

interne Links auf HTTPS?

Canonical auf HTTPS?

Sitemap enthält HTTPS?

wichtige Seiten in
Search Console prüfen?

HTTPS-Version in Google Search Console kontrollieren #

Mit der URL-Prüfung der Google Search Console kannst du untersuchen, welche URL Google kennt und wie eine konkrete Seite verarbeitet wird.

Bei Problemen mit der Indexierung solltest du HTTPS jedoch nicht isoliert betrachten. Crawlbarkeit, HTTP-Status, Canonical, Sitemap und Indexierungsanweisungen spielen ebenfalls eine Rolle.

Den systematischen Ablauf findest du unter Google non indicizza il mio sito web: verifica le cause.

Mixed Content und SEO nicht überdramatisieren #

Mixed Content sollte behoben werden, vor allem aus Sicherheits-, Funktions- und Qualitätsgründen.

Es ist jedoch wenig hilfreich, jeden HTTPS-Fehler pauschal als „SEO-Katastrophe“ zu bezeichnen.

Die tatsächlichen Auswirkungen hängen davon ab, welcher Fehler vorliegt und welche Ressourcen beziehungsweise URLs betroffen sind.

Technische Probleme sollten deshalb anhand ihrer realen Ursache behoben werden und nicht aufgrund übertriebener SEO-Versprechen.

HTTPS macht eine Website nicht automatisch sicher #

Questa differenza è particolarmente importante.

HTTPS schützt die Datenübertragung zwischen Client und Server.

Es schützt eine Website aber nicht automatisch vor:

unsicheren Passwörtern

veralteten Plugins

Schadsoftware

SQL-Injection

gestohlenen Zugangsdaten

unsicheren Benutzerkonten

Dateimanipulation

Anwendungsfehlern

Importante: Ein gültiges SSL-Zertifikat bedeutet, dass eine verschlüsselte Verbindung zu dem bestätigten Hostnamen hergestellt werden kann. Es ist kein allgemeines Sicherheitszertifikat für die gesamte Website.

Auch eine gehackte Website kann ein gültiges Zertifikat besitzen #

Ein kompromittierter Webserver kann weiterhin ein vollkommen gültiges TLS-Zertifikat ausliefern.

Der Browser kann dann eine technisch verschlüsselte Verbindung herstellen, obwohl die Website selbst manipuliert wurde.

HTTPS und Anwendungssicherheit müssen deshalb getrennt betrachtet werden.

HTTPS schützt nicht vor einer falschen Website #

Ein gültiges Zertifikat bestätigt in erster Linie die Verbindung zum im Zertifikat enthaltenen Hostnamen. Es bestätigt nicht, dass ein Unternehmen, Angebot oder Inhalt automatisch vertrauenswürdig ist.

Auch betrügerische Websites können HTTPS verwenden.

Besucher sollten deshalb weiterhin die tatsächliche Domain und den Kontext einer Website beachten.

Was tun bei einer Browserwarnung? #

Wenn dein Browser vor einer Zertifikats- oder HTTPS-Verbindung warnt, solltest du die Warnung nicht einfach dauerhaft umgehen.

Bei deiner eigenen Website empfiehlt sich folgende Diagnose:

genaue Fehlermeldung notieren
        ↓
Hostname kontrollieren
        ↓
Zertifikat ansehen
        ↓
Gültigkeitszeitraum prüfen
        ↓
SAN / Hostname prüfen
        ↓
Zertifikatskette prüfen
        ↓
DNS-Auflösung kontrollieren
        ↓
Proxy / CDN berücksichtigen
        ↓
Serverkonfiguration prüfen

Browser-Cache nicht vorschnell verantwortlich machen #

Bei HTTPS-Problemen wird häufig zuerst empfohlen, den Browser-Cache zu löschen.

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 Zertifikatsspeicher

Wenn 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.

Per esempio:

Proxy

Firewall

DNS-Resolver

TLS-Inspection

VPN

lokaler Filter

Ein 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.

Verifica in particolare:

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:

https://alte-domain.ch

su

https://neue-domain.ch

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:

https://alte-domain.ch/seite

Bevor der Webserver eine Antwort wie:

301 - Spostato permanentemente

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.

Consiglio pratico: 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:

https://www.example.com

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 Migration

Checkliste: 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 kontrollieren

Riepilogo #

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.