{"id":22925,"date":"2026-08-30T09:43:46","date_gmt":"2026-08-30T07:43:46","guid":{"rendered":"https:\/\/www.curiaweb.ch\/?post_type=docs&p=22925"},"modified":"2026-08-30T09:43:47","modified_gmt":"2026-08-30T07:43:47","password":"","slug":"ssl-https-pruefen","status":"publish","type":"docs","link":"https:\/\/www.curiaweb.ch\/it\/hilfe\/seo-monitoring\/ssl-https-pruefen\/","title":{"rendered":"Controllo del certificato SSL e HTTPS: individuare gli errori comuni"},"content":{"rendered":"

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.<\/p>\n\n\n\n

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

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

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

\n

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

SSL e TLS: qual \u00e8 la verit\u00e0?<\/h2>\n\n\n\n

Nella vita di tutti i giorni si continua a parlare spesso di un Certificato SSL<\/strong> parlato.<\/p>\n\n\n\n

Tecnicamente, tuttavia, le moderne connessioni HTTPS utilizzano TLS. SSL si riferisce a vecchi protocolli precedenti.<\/p>\n\n\n\n

Termini come:<\/p>\n\n\n\n

Certificato SSL\nCrittografia SSL\nSSL per sito web<\/code><\/pre>\n\n\n\n
sono comunque ancora comuni nell'uso comune.<\/p>\n\n\n\n
Tecnicamente pi\u00f9 preciso sarebbe, ad esempio:<\/p>\n\n\n\n
Certificato TLS\n\no\n\nConnessione HTTPS con TLS<\/code><\/pre>\n\n\n\n
In questo articolo usiamo il termine comune certificato SSL laddove facilita la comprensione.<\/p>\n\n\n\n
Che cosa fa HTTPS?<\/h2>\n\n\n\n
In una connessione HTTPS, il browser comunica in modo cifrato con il server.<\/p>\n\n\n\n
In sintesi:<\/p>\n\n\n\n
Browser\n   \u2193\nConnessione TLS\n   \u2193\nVerifica identit\u00e0 \/ certificato\n   \u2193\nconnessione cifrata\n   \u2193\nWeb server<\/code><\/pre>\n\n\n\n
Ci\u00f2 mira in particolare a proteggere la riservatezza e l'integrit\u00e0 dei dati trasmessi.<\/p>\n\n\n\n
HTTP e HTTPS sono varianti di URL diverse<\/h2>\n\n\n\n
Questi due URL sembrano simili:<\/p>\n\n\n\n
http:\/\/example.com\/<\/code><\/p>\n\n\n\n
\nhttps:\/\/example.com\n<\/div><\/figure>\n\n\n\n
Tuttavia, dal punto di vista tecnico, si tratta di varianti di URL diverse.<\/p>\n\n\n\n
Su un sito web completamente convertito in HTTPS, la versione HTTP dovrebbe normalmente reindirizzare in modo pulito alla corrispondente versione HTTPS.<\/p>\n\n\n\n
Per esempio:<\/p>\n\n\n\n
http:\/\/example.com\/beispiel\/\n\n        \u2193\n\n301 Permanent Redirect\n\n        \u2193\n\nhttps:\/\/example.com\/beispiel\/<\/code><\/pre>\n\n\n\n
Spieghiamo come funzionano i reindirizzamenti permanenti su Configurazione del reindirizzamento 301: reindirizzare gli URL in modo permanente<\/a>.<\/p>\n\n\n\n
Che cos'\u00e8 un certificato SSL?<\/h2>\n\n\n\n
Un certificato contiene informazioni necessarie per la creazione e la verifica di una connessione sicura.<\/p>\n\n\n\n
Ci\u00f2 include, tra le altre cose, informazioni su quali nomi host il certificato \u00e8 valido, da chi \u00e8 stato emesso e in quale periodo \u00e8 valido.<\/p>\n\n\n\n
Un browser verifica queste informazioni durante la creazione della connessione HTTPS.<\/p>\n\n\n\n
Quali informazioni dovresti verificare su un certificato?<\/h2>\n\n\n\n
Durante la ricerca degli errori sono particolarmente rilevanti i seguenti punti:<\/p>\n\n\n\n
Dominio \/ Nome host\n\nEmittente\n\nInizio validit\u00e0\n\nFine validit\u00e0\n\nNomi alternativi del soggetto (SAN)\n\nCatena di certificati\n\nAttendibilit\u00e0<\/code><\/pre>\n\n\n\n
I browser moderni forniscono una parte di queste informazioni tramite le informazioni di sicurezza o dei certificati oppure tramite gli strumenti di sviluppo.<\/p>\n\n\n\n
Il simbolo del lucchetto non \u00e8 l'intera diagnosi<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
Non affidarti esclusivamente a un simbolo di lucchetto per la diagnosi tecnica.<\/p>\n\n\n\n
Pi\u00f9 importante \u00e8:<\/p>\n\n\n\n
Viene utilizzato https:\/\/?\n\nIl certificato \u00e8 valido?\n\nCorrisponde al nome host?\n\nLa connessione \u00e8 attendibile?\n\nVengono caricate risorse non sicure?<\/code><\/pre>\n\n\n\n
Primo test: accedere al sito web direttamente con HTTPS<\/h2>\n\n\n\n
Inizia con il vero indirizzo HTTPS:<\/p>\n\n\n\n
\nhttps:\/\/deine-domain.ch\n<\/div><\/figure>\n\n\n\n
Verifica prima se la pagina si apre senza avvisi di sicurezza.<\/p>\n\n\n\n
Successivamente, non dovresti testare solo la pagina iniziale, ma anche alcune tipiche pagine secondarie.<\/p>\n\n\n\n
Per esempio:<\/p>\n\n\n\n
Home page\n\nSotto-pagina\n\nArticolo del blog\n\nPagina di contatto\n\nPagina negozio o di prodotto<\/code><\/pre>\n\n\n\n
Un problema pu\u00f2 riguardare solo singole pagine o risorse.<\/p>\n\n\n\n
Secondo test: richiama la versione HTTP<\/h2>\n\n\n\n
Chiama poi consapevolmente la variante non criptata:<\/p>\n\n\n\n
http:\/\/deine-domain.ch\/<\/code><\/p>\n\n\n\n
Su un sito web completamente convertito in HTTPS, di solito questo dovrebbe diventare il corrispondente indirizzo HTTPS.<\/p>\n\n\n\n
Controlla anche una pagina secondaria:<\/p>\n\n\n\n
http:\/\/deine-domain.ch\/beispiel\/<\/code><\/p>\n\n\n\n
Non dovrebbe essere inviata genericamente alla homepage, ma normalmente a:<\/p>\n\n\n\n
\nhttps:\/\/deine-domain.ch\/beispiel\n<\/div><\/figure>\n\n\n\n
controllare anche www e non-www<\/h2>\n\n\n\n
Inoltre, esistono spesso varianti con e senza www<\/code>.<\/p>\n\n\n\n
Per esempio:<\/p>\n\n\n\n
https:\/\/example.com\/\n\nhttps:\/\/www.example.com\/<\/code><\/pre>\n\n\n\n
Se solo una di queste varianti viene utilizzata come sito web principale, l'altra dovrebbe reindirizzare ad essa in modo coerente.<\/p>\n\n\n\n
Lo stesso vale per le varianti HTTP.<\/p>\n\n\n\n
Una configurazione tipica potrebbe ad esempio apparire cos\u00ec:<\/p>\n\n\n\n
http:\/\/example.com\/\n        \u2193\nhttps:\/\/www.example.com\/\n\nhttp:\/\/www.example.com\/\n        \u2193\nhttps:\/\/www.example.com\/\n\nhttps:\/\/example.com\/\n        \u2193\nhttps:\/\/www.example.com\/<\/code><\/pre>\n\n\n\n
Quale variante venga utilizzata come indirizzo principale \u00e8 meno importante di un'implementazione tecnica coerente.<\/p>\n\n\n\n
Errore 1: Il certificato \u00e8 scaduto<\/h2>\n\n\n\n
I certificati hanno un periodo di validit\u00e0 limitato.<\/p>\n\n\n\n
Se un certificato non viene rinnovato in tempo, il browser pu\u00f2 mostrare un avviso di sicurezza.<\/p>\n\n\n\n
Pertanto, durante la diagnosi dovresti controllare le date di validit\u00e0:<\/p>\n\n\n\n
valido dal:\n...\n\nvalido fino al:\n...<\/code><\/pre>\n\n\n\n
Se la data attuale non rientra nel periodo di validit\u00e0, il certificato deve essere rinnovato o \u00e8 necessario verificare il rinnovo automatico.<\/p>\n\n\n\n
Perch\u00e9 i certificati vengono rinnovati automaticamente<\/h2>\n\n\n\n
I moderni sistemi di hosting automatizzano spesso l'emissione e il rinnovo dei certificati.<\/p>\n\n\n\n
Tuttavia, un rinnovo automatico pu\u00f2 fallire se, ad esempio, il dominio non punta pi\u00f9 correttamente al server o se non \u00e8 possibile eseguire una validazione necessaria.<\/p>\n\n\n\n
Pertanto, in caso di certificato scaduto, non bisogna solo sostituire manualmente il certificato, ma \u00e8 necessario anche indagare sulla causa del rinnovo fallito.<\/p>\n\n\n\n
Errore 2: Il certificato non \u00e8 ancora valido<\/h2>\n\n\n\n
Anche un certificato con una data di validit\u00e0 futura pu\u00f2 causare un avviso.<\/p>\n\n\n\n
In solchen F\u00e4llen sollte zus\u00e4tzlich \u00fcberpr\u00fcft werden, ob Datum und Uhrzeit auf dem betroffenen Ger\u00e4t beziehungsweise System korrekt eingestellt sind.<\/p>\n\n\n\n
Un orologio locale errato pu\u00f2 far s\u00ec che un certificato altrimenti valido sembri non ancora valido o gi\u00e0 scaduto dal punto di vista del dispositivo.<\/p>\n\n\n\n
Errore 3: Il certificato non corrisponde al dominio<\/h2>\n\n\n\n
Un certificato deve essere valido per il nome host richiesto.<\/p>\n\n\n\n
Supponendo che tu chiami:<\/p>\n\n\n\n
\nhttps:\/\/shop.example.com\n<\/div><\/figure>\n\n\n\n
Il certificato consegnato copre tuttavia solo:<\/p>\n\n\n\n
www.example.com<\/code><\/p>\n\n\n\n
ab.<\/p>\n\n\n\n
Allora c'\u00e8 una mancata corrispondenza del nome host.<\/p>\n\n\n\n
Il browser non pu\u00f2 verificare che il certificato sia stato emesso per il nome host effettivamente visitato.<\/p>\n\n\n\n
Controlla i Subject Alternative Names<\/h2>\n\n\n\n
I certificati moderni possono essere validi per pi\u00f9 hostname.<\/p>\n\n\n\n
Questi vengono tipicamente specificati tramite i cosiddetti Subject Alternative Names, in breve SAN.<\/p>\n\n\n\n
Ad esempio, un certificato potrebbe coprire i seguenti nomi:<\/p>\n\n\n\n
example.com\n\nwww.example.com<\/code><\/pre>\n\n\n\n
Un altro sottodominio come:<\/p>\n\n\n\n
shop.example.com<\/code><\/p>\n\n\n\n
non \u00e8 quindi automaticamente incluso.<\/p>\n\n\n\n
Certificati wildcard<\/h2>\n\n\n\n
Un certificato wildcard pu\u00f2 coprire pi\u00f9 sottodomini di un determinato livello.<\/p>\n\n\n\n
Per esempio:<\/p>\n\n\n\n
*.example.com<\/code><\/p>\n\n\n\n
pu\u00f2 essere utilizzato per nomi host come:<\/p>\n\n\n\n
shop.example.com\n\nmail.example.com\n\nportal.example.com<\/code><\/pre>\n\n\n\n
essere utilizzato.<\/p>\n\n\n\n
Il dominio principale:<\/p>\n\n\n\n
example.com<\/code><\/p>\n\n\n\n
tuttavia non \u00e8 automaticamente coperta dal nome con carattere jolly stesso. Potrebbe essere necessario includerla ulteriormente nel certificato.<\/p>\n\n\n\n
Errore 4: catena dei certificati incompleta<\/h2>\n\n\n\n
I browser non si fidano di un certificato del server in isolamento. Tra il certificato del sito web e un'autorit\u00e0 di certificazione radice attendibile possono esservi certificati intermedi.<\/p>\n\n\n\n
In sintesi:<\/p>\n\n\n\n
Certificato del sito web\n        \u2193\nCA intermedia\n        \u2193\nCA radice<\/code><\/pre>\n\n\n\n
Il server deve fornire correttamente la catena di certificati richiesta.<\/p>\n\n\n\n
Se manca un certificato intermediario necessario, singoli client potrebbero riscontrare problemi nella verifica dell'attendibilit\u00e0.<\/p>\n\n\n\n
Perch\u00e9 una catena di certificati difettosa a volte funziona comunque?<\/h2>\n\n\n\n
Un browser gi\u00e0 utilizzato o un determinato sistema operativo potrebbero gi\u00e0 conoscere i certificati intermedi necessari.<\/p>\n\n\n\n
Ci\u00f2 pu\u00f2 far s\u00ec che una configurazione errata del server funzioni apparentemente su un dispositivo, mentre un altro dispositivo mostra un avviso di certificato.<\/p>\n\n\n\n
Se i problemi HTTPS si verificano solo su determinati dispositivi, \u00e8 necessario esaminare anche la catena dei certificati.<\/p>\n\n\n\n
Errore 5: Mixed Content<\/h2>\n\n\n\n
Il Mixed Content si verifica quando una pagina HTTPS carica risorse tramite HTTP non criptato.<\/p>\n\n\n\n
La pagina effettiva viene richiamata, ad esempio, tramite:<\/p>\n\n\n\n
\nhttps:\/\/example.com\n<\/div><\/figure>\n\n\n\n
tuttavia, nell'HTML si trova una risorsa come:<\/p>\n\n\n\n
<img src="http:\/\/example.com\/bild.jpg"><\/code><\/pre>\n\n\n\n
o:<\/p>\n\n\n\n
<script src=\"http:\/\/example.com\/script.js\"><\/script><\/code><\/pre>\n\n\n\n
Il sito stesso utilizza HTTPS, ma singoli componenti vengono richiesti tramite HTTP.<\/p>\n\n\n\n
Perch\u00e9 il Mixed Content \u00e8 problematico<\/h2>\n\n\n\n
HTTPS deve stabilire una connessione sicura per i contenuti forniti.<\/p>\n\n\n\n
Se i componenti vengono caricati tramite HTTP, questa assunzione di sicurezza non \u00e8 completamente garantita per tali risorse.<\/p>\n\n\n\n
I browser possono quindi bloccare tali richieste, aggiornarle automaticamente o emettere avvisi, a seconda del tipo di risorsa e del browser.<\/p>\n\n\n\n
Cause tipiche di contenuti misti<\/h2>\n\n\n\n
Dopo il passaggio da HTTP a HTTPS, rimangono spesso vecchi URL assoluti.<\/p>\n\n\n\n
Ad esempio in:<\/p>\n\n\n\n
contenuti HTML\n\nfile CSS\n\nimpostazioni del tema\n\ndatabase WordPress\n\nwidget\n\nPage Builder\n\nJavaScript\n\nrisorse esterne\n\nvecchi URL delle immagini<\/code><\/pre>\n\n\n\n
Soprattutto nei siti Web pi\u00f9 vecchi, tali URL possono essere memorizzati in molti punti.<\/p>\n\n\n\n
Trovare i contenuti misti con gli strumenti di sviluppo del browser<\/h2>\n\n\n\n
Gli strumenti di sviluppo dei browser moderni sono particolarmente utili per questa diagnosi.<\/p>\n\n\n\n
Apri la pagina interessata e controlla in particolare la console e la sezione di rete.<\/p>\n\n\n\n
In caso di Mixed Content, trovi spesso indicazioni sulla risorsa interessata.<\/p>\n\n\n\n
Ricerca di URL che iniziano con:<\/p>\n\n\n\n
http:\/\/<\/code><\/p>\n\n\n\n
iniziare, sebbene la pagina stessa riguardo:<\/p>\n\n\n\n
https:\/\/<\/code><\/p>\n\n\n\n
\u00e8 stato caricato.<\/p>\n\n\n\n
\n
Consiglio pratico:<\/strong> 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.<\/p>\n<\/blockquote>\n\n\n\n
Contenuto misto in WordPress<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
Verifica prima di tutto se l'indirizzo WordPress e l'indirizzo del sito web sono impostati correttamente su HTTPS.<\/p>\n\n\n\n
Per esempio:<\/p>\n\n\n\n
https:\/\/example.com<\/code><\/pre>\n\n\n\n
Altri indirizzi HTTP possono inoltre essere memorizzati direttamente in contenuti, widget, opzioni del tema o campi del database.<\/p>\n\n\n\n
Non eseguire semplicemente una ricerca e sostituzione alla cieca<\/h2>\n\n\n\n
Una ricerca e sostituzione generalizzata direttamente in un database WordPress pu\u00f2 essere problematica.<\/p>\n\n\n\n
WordPress, temi e plugin possono archiviare dati strutturati o serializzati. Una sostituzione inappropriata pu\u00f2 danneggiare questi dati.<\/p>\n\n\n\n
Utilizza quindi gli strumenti WordPress appropriati ed effettua un backup prima di apportare modifiche estese.<\/p>\n\n\n\n
Errore 6: Loop di reindirizzamento dopo il passaggio a HTTPS<\/h2>\n\n\n\n
Una configurazione HTTPS errata pu\u00f2 generare un ciclo di reindirizzamento.<\/p>\n\n\n\n
Per esempio:<\/p>\n\n\n\n
HTTP\n \u2193\nHTTPS\n \u2193\nHTTP\n \u2193\nHTTPS\n \u2193\n...<\/code><\/pre>\n\n\n\n
Il browser interrompe il reindirizzamento dopo un certo numero di passaggi e segnala un errore.<\/p>\n\n\n\n
La causa pu\u00f2 trovarsi in diversi punti:<\/p>\n\n\n\n
Configurazione del server web\n\n.htaccess\n\nWordPress\n\nPlugin\n\nProxy inverso\n\nCDN\n\nBilanciatore di carico<\/code><\/pre>\n\n\n\n
Evitare pi\u00f9 reindirizzamenti HTTPS contemporaneamente<\/h2>\n\n\n\n
I problemi si verificano spesso quando pi\u00f9 livelli cercano indipendentemente di imporre HTTPS.<\/p>\n\n\n\n
Per esempio:<\/p>\n\n\n\n
CDN impone HTTPS\n\nServer web impone HTTPS\n\nPlugin WordPress impone HTTPS\n\nregola .htaccess aggiuntiva impone HTTPS<\/code><\/pre>\n\n\n\n
Ci\u00f2 non deve necessariamente causare un errore, ma rende la configurazione inutilmente complessa e rende difficile la diagnostica.<\/p>\n\n\n\n
L'HTTPS dovrebbe essere implementato in modo pulito e comprensibile in un punto appropriato.<\/p>\n\n\n\n
Errore 7: Troppi reindirizzamenti<\/h2>\n\n\n\n
Anche senza un ciclo infinito, si pu\u00f2 creare una catena di reindirizzamenti inutilmente lunga.<\/p>\n\n\n\n
Per esempio:<\/p>\n\n\n\n
http://example.com\/\n \u2193\nhttp:\/\/www.example.com\/\n \u2193\nhttps:\/\/www.example.com\/\n \u2193\nhttps:\/\/www.example.com\/de\/<\/code><\/pre>\n\n\n\n
Wenn technisch m\u00f6glich, sollten unn\u00f6tige Zwischenschritte vermieden werden.<\/p>\n\n\n\n
Eine saubere Konfiguration leitet eine alte Variante m\u00f6glichst direkt auf die endg\u00fcltige Ziel-URL.<\/p>\n\n\n\n
Fehler 8: HTTPS funktioniert nur mit oder ohne www<\/h2>\n\n\n\n
Wenn:<\/p>\n\n\n\n
\nhttps:\/\/example.com\n<\/div><\/figure>\n\n\n\n
funktioniert, aber:<\/p>\n\n\n\n
\nhttps:\/\/www.example.com\n<\/div><\/figure>\n\n\n\n
eine Zertifikatswarnung erzeugt, sollte gepr\u00fcft werden:<\/p>\n\n\n\n
Existiert der DNS-Eintrag?\n\nZeigt er auf die richtige Infrastruktur?\n\nIst der Hostname im Zertifikat enthalten?\n\nIst der Webserver f\u00fcr diesen Host konfiguriert?\n\nIst die Weiterleitung korrekt?<\/code><\/pre>\n\n\n\n
Ein Zertifikat kann nur sinnvoll f\u00fcr einen Hostnamen bereitgestellt werden, wenn die gesamte Domain- und Serverkonfiguration dazu passt.<\/p>\n\n\n\n
DNS und SSL h\u00e4ngen bei der Ausstellung zusammen<\/h2>\n\n\n\n
Bei vielen automatisierten Zertifikatsverfahren muss nachgewiesen werden, dass die Domain beziehungsweise der Hostname kontrolliert wird.<\/p>\n\n\n\n
Wenn die Domain auf eine falsche Infrastruktur zeigt, kann eine automatische Ausstellung oder Erneuerung deshalb scheitern.<\/p>\n\n\n\n
Bei Problemen solltest du die DNS-Aufl\u00f6sung kontrollieren. Wie das funktioniert, erkl\u00e4ren wir unter Controllare i record DNS<\/a>.<\/p>\n\n\n\n
DNS-\u00c4nderung und Zertifikat nicht verwechseln<\/h2>\n\n\n\n
Nach einem Serverwechsel k\u00f6nnen zwei getrennte Vorg\u00e4nge beteiligt sein:<\/p>\n\n\n\n
DNS\n\u2192 Besucher m\u00fcssen den\n  richtigen Server erreichen\n\nTLS\n\u2192 dieser Server muss ein\n  g\u00fcltiges Zertifikat ausliefern<\/code><\/pre>\n\n\n\n
Ein korrektes Zertifikat auf dem neuen Server hilft nicht, wenn ein Besucher aufgrund seiner DNS-Aufl\u00f6sung noch einen anderen Server erreicht.<\/p>\n\n\n\n
Umgekehrt kann die Domain bereits auf dem neuen Server ankommen, w\u00e4hrend dort noch kein passendes Zertifikat installiert wurde.<\/p>\n\n\n\n
Fehler 9: Falsches Zertifikat wird ausgeliefert<\/h2>\n\n\n\n
Ein Server kann mehrere Websites und Zertifikate verwalten.<\/p>\n\n\n\n
Bei einer fehlerhaften virtuellen Host-Konfiguration kann f\u00fcr eine Domain unter Umst\u00e4nden ein Zertifikat einer anderen Website ausgeliefert werden.<\/p>\n\n\n\n
Das erkennst du daran, dass der aufgerufene Hostname nicht zu den Namen im ausgelieferten Zertifikat passt.<\/p>\n\n\n\n
In diesem Fall muss nicht der Browser repariert werden, sondern die Zertifikats- beziehungsweise Webserver-Konfiguration.<\/p>\n\n\n\n
Fehler 10: Zertifikat erneuert, Browser zeigt trotzdem altes Zertifikat<\/h2>\n\n\n\n
Wenn ein Zertifikat erneuert wurde, aber weiterhin das alte Zertifikat ausgeliefert wird, k\u00f6nnen unterschiedliche Ursachen bestehen.<\/p>\n\n\n\n
Per esempio:<\/p>\n\n\n\n
Webserver verwendet noch\nalte Zertifikatsdatei\n\nDienst wurde nach \u00c4nderung\nnicht korrekt neu geladen\n\nReverse Proxy liefert\nanderes Zertifikat\n\nCDN terminiert TLS\n\nDNS zeigt auf\nanderen Server<\/code><\/pre>\n\n\n\n
Entscheidend ist deshalb nicht nur, welches Zertifikat irgendwo auf dem Server gespeichert ist, sondern welches Zertifikat beim tats\u00e4chlichen Verbindungsaufbau ausgeliefert wird.<\/p>\n\n\n\n
CDN und Reverse Proxy ber\u00fccksichtigen<\/h2>\n\n\n\n
Bei Verwendung eines CDN oder Reverse Proxy kann die TLS-Verbindung an mehreren Stellen stattfinden.<\/p>\n\n\n\n
In sintesi:<\/p>\n\n\n\n
Besucher\n   \u2193 HTTPS\nCDN \/ Proxy\n   \u2193 HTTPS\nOrigin-Server<\/code><\/pre>\n\n\n\n
Damit k\u00f6nnen auch unterschiedliche Zertifikate beteiligt sein.<\/p>\n\n\n\n
Ein g\u00fcltiges Zertifikat am Origin-Server bedeutet deshalb nicht automatisch, dass das \u00f6ffentlich ausgelieferte Zertifikat korrekt ist \u2013 und umgekehrt.<\/p>\n\n\n\n
HTTPS im Browser pr\u00fcfen<\/h2>\n\n\n\n
F\u00fcr eine erste Diagnose kannst du den Browser verwenden.<\/p>\n\n\n\n
Controlla:<\/p>\n\n\n\n
aufgerufene URL\n\nSicherheitsstatus\n\nZertifikatsinformationen\n\nHostname\n\nG\u00fcltigkeitszeitraum\n\nAussteller\n\nKonsole\n\nNetzwerk-Anfragen<\/code><\/pre>\n\n\n\n
Bei einem Fehler solltest du die genaue Meldung dokumentieren, statt lediglich \u201eSSL funktioniert nicht\u201c zu notieren.<\/p>\n\n\n\n
Die genaue Fehlermeldung ist entscheidend<\/h2>\n\n\n\n
Zwischen folgenden Situationen besteht ein gro\u00dfer Unterschied:<\/p>\n\n\n\n
Zertifikat abgelaufen\n\nHostname stimmt nicht\n\nZertifikatskette fehlerhaft\n\nMixed Content\n\nRedirect-Schleife\n\nDNS zeigt falsch\n\nServer nicht erreichbar<\/code><\/pre>\n\n\n\n
Alle k\u00f6nnen aus Sicht eines Benutzers zun\u00e4chst wie ein \u201eHTTPS-Problem\u201c wirken, ben\u00f6tigen aber v\u00f6llig unterschiedliche L\u00f6sungen.<\/p>\n\n\n\n
HTTP-Statuscode zus\u00e4tzlich pr\u00fcfen<\/h2>\n\n\n\n
HTTPS und HTTP-Statuscodes sind unterschiedliche Ebenen.<\/p>\n\n\n\n
Eine TLS-Verbindung kann erfolgreich aufgebaut werden und die Website anschlie\u00dfend trotzdem antworten mit:<\/p>\n\n\n\n
404 Not Found\n\n500 Internal Server Error\n\n503 Service Unavailable<\/code><\/pre>\n\n\n\n
Dann funktioniert die verschl\u00fcsselte Verbindung, w\u00e4hrend die Anwendung oder der angeforderte Inhalt ein anderes Problem besitzt.<\/p>\n\n\n\n
Die wichtigsten Statuscodes erkl\u00e4ren wir unter Codici di stato HTTP spiegati: 200, 301, 404, 403 e 500<\/a>.<\/p>\n\n\n\n
Ein HTTP-500-Fehler ist kein SSL-Fehler<\/h2>\n\n\n\n
Wenn der Browser erfolgreich eine HTTPS-Verbindung aufbaut und der Server anschlie\u00dfend mit Errore interno del server<\/code> antwortet, hat TLS seinen Teil bereits erfolgreich erledigt.<\/p>\n\n\n\n
Die Ursache liegt dann typischerweise auf einer sp\u00e4teren Ebene.<\/p>\n\n\n\n
DNS\n \u2193\nTLS erfolgreich\n \u2193\nHTTP-Anfrage\n \u2193\nAnwendung\n \u2193\n500 Internal Server Error<\/code><\/pre>\n\n\n\n
Diese Ebenen sauber auseinanderzuhalten spart bei der Fehlersuche viel Zeit.<\/p>\n\n\n\n
Ein DNS-Fehler ist ebenfalls nicht automatisch ein SSL-Fehler<\/h2>\n\n\n\n
Kann der Domainname \u00fcberhaupt nicht aufgel\u00f6st werden, erreicht der Browser m\u00f6glicherweise noch keinen Server, mit dem er eine TLS-Verbindung aufbauen k\u00f6nnte.<\/p>\n\n\n\n
Auch wenn die Website im Browser nicht erscheint, liegt dann zun\u00e4chst ein DNS- beziehungsweise Erreichbarkeitsproblem vor.<\/p>\n\n\n\n
HTTPS und Website-Monitoring<\/h2>\n\n\n\n
Ein externer HTTPS-Monitor kann regelm\u00e4\u00dfig pr\u00fcfen, ob eine sichere Verbindung zur Website aufgebaut und eine erwartete Antwort empfangen werden kann.<\/p>\n\n\n\n
Je nach Monitoring-System k\u00f6nnen auch Zertifikatsprobleme oder ein bevorstehendes Ablaufdatum \u00fcberwacht werden.<\/p>\n\n\n\n
Wie solche Pr\u00fcfungen grunds\u00e4tzlich funktionieren, erkl\u00e4ren wir unter Monitoraggio di siti web: monitorare la disponibilit\u00e0 e le interruzioni<\/a>.<\/p>\n\n\n\n
Warum Zertifikats\u00fcberwachung sinnvoll ist<\/h2>\n\n\n\n
Automatische Zertifikatserneuerung reduziert den administrativen Aufwand erheblich. Trotzdem kann eine Erneuerung aufgrund einer technischen St\u00f6rung scheitern.<\/p>\n\n\n\n
Ein zus\u00e4tzlicher externer Check kann deshalb helfen, ein unerwartet bevorstehendes Ablaufdatum rechtzeitig zu erkennen.<\/p>\n\n\n\n
Monitoring ersetzt allerdings nicht die Behebung der Ursache, wenn die automatische Erneuerung tats\u00e4chlich gest\u00f6rt ist.<\/p>\n\n\n\n
HTTPS und Google<\/h2>\n\n\n\n
F\u00fcr Suchmaschinen sollten die Signale einer HTTPS-Website konsistent sein.<\/p>\n\n\n\n
Wenn HTTPS die gew\u00fcnschte Variante ist, sollten unter anderem:<\/p>\n\n\n\n
interne Links\n\nWeiterleitungen\n\nCanonical-URLs\n\nXML-Sitemap\n\n\u00f6ffentliche Website-URLs<\/code><\/pre>\n\n\n\n
konsistent auf die HTTPS-Version zeigen.<\/p>\n\n\n\n
Die XML-Sitemap sollte entsprechend die gew\u00fcnschten HTTPS-URLs enthalten. Mehr dazu findest du unter Mappa del sito XML: cosa fa e come inviarla a Google<\/a>.<\/p>\n\n\n\n
Canonical nicht auf HTTP zeigen lassen<\/h2>\n\n\n\n
Wenn die Website vollst\u00e4ndig auf HTTPS umgestellt wurde, sollte eine HTTPS-Seite normalerweise nicht gleichzeitig \u00fcber ihr Canonical-Element eine HTTP-Version als bevorzugte URL auszeichnen.<\/p>\n\n\n\n
Eine solche Konfiguration erzeugt widerspr\u00fcchliche technische Signale.<\/p>\n\n\n\n
Vereinfacht sollte das Bild so aussehen:<\/p>\n\n\n\n
HTTP\n \u2193 301\nHTTPS\n \u2193\nCanonical \u2192 HTTPS\n \u2193\nSitemap \u2192 HTTPS\n \u2193\ninterne Links \u2192 HTTPS<\/code><\/pre>\n\n\n\n
Nach einer HTTP-zu-HTTPS-Umstellung pr\u00fcfen<\/h2>\n\n\n\n
Wenn eine Website neu auf HTTPS umgestellt wurde, solltest du nicht nur kontrollieren, ob die Startseite ein Zertifikat besitzt.<\/p>\n\n\n\n
Verifica sistematicamente:<\/p>\n\n\n\n
HTTPS-Startseite erreichbar?\n\nHTTP \u2192 HTTPS?\n\nUnterseiten korrekt weitergeleitet?\n\nwww \/ non-www korrekt?\n\nZertifikat f\u00fcr alle\nben\u00f6tigten Hostnamen g\u00fcltig?\n\nMixed Content vorhanden?\n\ninterne Links auf HTTPS?\n\nCanonical auf HTTPS?\n\nSitemap enth\u00e4lt HTTPS?\n\nwichtige Seiten in\nSearch Console pr\u00fcfen?<\/code><\/pre>\n\n\n\n
HTTPS-Version in Google Search Console kontrollieren<\/h2>\n\n\n\n
Mit der URL-Pr\u00fcfung der Google Search Console kannst du untersuchen, welche URL Google kennt und wie eine konkrete Seite verarbeitet wird.<\/p>\n\n\n\n
Bei Problemen mit der Indexierung solltest du HTTPS jedoch nicht isoliert betrachten. Crawlbarkeit, HTTP-Status, Canonical, Sitemap und Indexierungsanweisungen spielen ebenfalls eine Rolle.<\/p>\n\n\n\n
Den systematischen Ablauf findest du unter Google non indicizza il mio sito web: verifica le cause<\/a>.<\/p>\n\n\n\n
Mixed Content und SEO nicht \u00fcberdramatisieren<\/h2>\n\n\n\n
Mixed Content sollte behoben werden, vor allem aus Sicherheits-, Funktions- und Qualit\u00e4tsgr\u00fcnden.<\/p>\n\n\n\n
Es ist jedoch wenig hilfreich, jeden HTTPS-Fehler pauschal als \u201eSEO-Katastrophe\u201c zu bezeichnen.<\/p>\n\n\n\n
Die tats\u00e4chlichen Auswirkungen h\u00e4ngen davon ab, welcher Fehler vorliegt und welche Ressourcen beziehungsweise URLs betroffen sind.<\/p>\n\n\n\n
Technische Probleme sollten deshalb anhand ihrer realen Ursache behoben werden und nicht aufgrund \u00fcbertriebener SEO-Versprechen.<\/p>\n\n\n\n
HTTPS macht eine Website nicht automatisch sicher<\/h2>\n\n\n\n
Questa differenza \u00e8 particolarmente importante.<\/p>\n\n\n\n
HTTPS sch\u00fctzt die Daten\u00fcbertragung zwischen Client und Server.<\/p>\n\n\n\n
Es sch\u00fctzt eine Website aber nicht automatisch vor:<\/p>\n\n\n\n
unsicheren Passw\u00f6rtern\n\nveralteten Plugins\n\nSchadsoftware\n\nSQL-Injection\n\ngestohlenen Zugangsdaten\n\nunsicheren Benutzerkonten\n\nDateimanipulation\n\nAnwendungsfehlern<\/code><\/pre>\n\n\n\n
\n
Importante:<\/strong> Ein g\u00fcltiges SSL-Zertifikat bedeutet, dass eine verschl\u00fcsselte Verbindung zu dem best\u00e4tigten Hostnamen hergestellt werden kann. Es ist kein allgemeines Sicherheitszertifikat f\u00fcr die gesamte Website.<\/p>\n<\/blockquote>\n\n\n\n
Auch eine gehackte Website kann ein g\u00fcltiges Zertifikat besitzen<\/h2>\n\n\n\n
Ein kompromittierter Webserver kann weiterhin ein vollkommen g\u00fcltiges TLS-Zertifikat ausliefern.<\/p>\n\n\n\n
Der Browser kann dann eine technisch verschl\u00fcsselte Verbindung herstellen, obwohl die Website selbst manipuliert wurde.<\/p>\n\n\n\n
HTTPS und Anwendungssicherheit m\u00fcssen deshalb getrennt betrachtet werden.<\/p>\n\n\n\n
HTTPS sch\u00fctzt nicht vor einer falschen Website<\/h2>\n\n\n\n
Ein g\u00fcltiges Zertifikat best\u00e4tigt in erster Linie die Verbindung zum im Zertifikat enthaltenen Hostnamen. Es best\u00e4tigt nicht, dass ein Unternehmen, Angebot oder Inhalt automatisch vertrauensw\u00fcrdig ist.<\/p>\n\n\n\n
Auch betr\u00fcgerische Websites k\u00f6nnen HTTPS verwenden.<\/p>\n\n\n\n
Besucher sollten deshalb weiterhin die tats\u00e4chliche Domain und den Kontext einer Website beachten.<\/p>\n\n\n\n
Was tun bei einer Browserwarnung?<\/h2>\n\n\n\n
Wenn dein Browser vor einer Zertifikats- oder HTTPS-Verbindung warnt, solltest du die Warnung nicht einfach dauerhaft umgehen.<\/p>\n\n\n\n
Bei deiner eigenen Website empfiehlt sich folgende Diagnose:<\/p>\n\n\n\n
genaue Fehlermeldung notieren\n        \u2193\nHostname kontrollieren\n        \u2193\nZertifikat ansehen\n        \u2193\nG\u00fcltigkeitszeitraum pr\u00fcfen\n        \u2193\nSAN \/ Hostname pr\u00fcfen\n        \u2193\nZertifikatskette pr\u00fcfen\n        \u2193\nDNS-Aufl\u00f6sung kontrollieren\n        \u2193\nProxy \/ CDN ber\u00fccksichtigen\n        \u2193\nServerkonfiguration pr\u00fcfen<\/code><\/pre>\n\n\n\n
Browser-Cache nicht vorschnell verantwortlich machen<\/h2>\n\n\n\n
Bei HTTPS-Problemen wird h\u00e4ufig zuerst empfohlen, den Browser-Cache zu l\u00f6schen.<\/p>\n\n\n\n
Das kann in bestimmten Situationen hilfreich sein, sollte aber keine eigentliche Diagnose ersetzen.<\/p>\n\n\n\n
Wenn das \u00f6ffentlich ausgelieferte Zertifikat abgelaufen oder f\u00fcr den falschen Hostnamen ausgestellt ist, wird das Problem durch das L\u00f6schen des normalen Website-Caches nicht behoben.<\/p>\n\n\n\n
Problem auf mehreren Ger\u00e4ten pr\u00fcfen<\/h2>\n\n\n\n
Wenn nur ein einzelnes Ger\u00e4t eine Zertifikatswarnung zeigt, w\u00e4hrend andere aktuelle Ger\u00e4te problemlos funktionieren, solltest du auch die lokale Umgebung untersuchen.<\/p>\n\n\n\n
M\u00f6gliche Faktoren sind:<\/p>\n\n\n\n
falsche Systemzeit\n\nveraltetes Betriebssystem\n\nveralteter Browser\n\nlokaler Proxy\n\nAntivirus-Software\n\nUnternehmensnetzwerk\n\nlokaler Zertifikatsspeicher<\/code><\/pre>\n\n\n\n
Wenn dagegen zahlreiche unabh\u00e4ngige Ger\u00e4te dieselbe Warnung erhalten, spricht das st\u00e4rker f\u00fcr ein server- oder zertifikatsseitiges Problem.<\/p>\n\n\n\n
Fehler nur in einem Netzwerk<\/h2>\n\n\n\n
Funktioniert HTTPS \u00fcber Mobilfunk, aber nicht im Firmen- oder Heimnetzwerk, k\u00f6nnen zus\u00e4tzlich lokale Netzwerkkomponenten beteiligt sein.<\/p>\n\n\n\n
Per esempio:<\/p>\n\n\n\n
Proxy\n\nFirewall\n\nDNS-Resolver\n\nTLS-Inspection\n\nVPN\n\nlokaler Filter<\/code><\/pre>\n\n\n\n
Ein solcher Test hilft dabei, die Ursache r\u00e4umlich einzugrenzen.<\/p>\n\n\n\n
Systemzeit kontrollieren<\/h2>\n\n\n\n
Zertifikate besitzen einen definierten G\u00fcltigkeitszeitraum.<\/p>\n\n\n\n
Ist Datum oder Uhrzeit eines Ger\u00e4ts deutlich falsch, kann ein Browser ein g\u00fcltiges Zertifikat als ung\u00fcltig bewerten.<\/p>\n\n\n\n
Bei unerkl\u00e4rlichen Zertifikatswarnungen auf nur einem Ger\u00e4t geh\u00f6rt die Systemzeit deshalb zu den einfachen ersten Kontrollen.<\/p>\n\n\n\n
Fehler nach einem Website-Umzug<\/h2>\n\n\n\n
Nach einem Hosting- oder Serverwechsel k\u00f6nnen HTTPS-Probleme entstehen, wenn einzelne Bestandteile der Umstellung noch nicht zusammenpassen.<\/p>\n\n\n\n
Verifica in particolare:<\/p>\n\n\n\n
DNS zeigt auf neuen Server?\n\nZertifikat auf neuem Server vorhanden?\n\nalle ben\u00f6tigten Hostnamen enthalten?\n\nHTTP-Weiterleitungen korrekt?\n\nalte HTTP-URLs in Website?\n\nCDN \/ Proxy aktualisiert?\n\nSitemap und Canonical korrekt?<\/code><\/pre>\n\n\n\n
DNS-\u00c4nderungen k\u00f6nnen au\u00dferdem Zeit ben\u00f6tigen, bis unterschiedliche Resolver den neuen Zustand verwenden. Mehr dazu erkl\u00e4ren wir unter DNS-Propagation erkl\u00e4rt<\/a>.<\/p>\n\n\n\n
Fehler nach \u00c4nderung der Domain<\/h2>\n\n\n\n
Wenn eine Website von:<\/p>\n\n\n\n
\nhttps:\/\/alte-domain.ch\n<\/div><\/figure>\n\n\n\n
su<\/p>\n\n\n\n
\nhttps:\/\/neue-domain.ch\n<\/div><\/figure>\n\n\n\n
umzieht, ben\u00f6tigt die neue Domain ein passendes Zertifikat.<\/p>\n\n\n\n
Auch die alte Domain sollte w\u00e4hrend der Migration weiterhin technisch erreichbar sein, damit Weiterleitungen zur neuen Domain funktionieren k\u00f6nnen.<\/p>\n\n\n\n
Ein Zertifikatsfehler auf der alten HTTPS-Domain kann Besucher treffen, bevor \u00fcberhaupt eine HTTP-Weiterleitung verarbeitet werden kann.<\/p>\n\n\n\n
Warum HTTPS vor einer Weiterleitung funktionieren muss<\/h2>\n\n\n\n
Das ist ein h\u00e4ufig \u00fcbersehener technischer Punkt.<\/p>\n\n\n\n
Ein Besucher ruft beispielsweise auf:<\/p>\n\n\n\n
\nhttps:\/\/alte-domain.ch\/seite\n<\/div><\/figure>\n\n\n\n
Bevor der Webserver eine Antwort wie:<\/p>\n\n\n\n
301 - Spostato permanentemente<\/code><\/p>\n\n\n\n
senden kann, muss zun\u00e4chst die TLS-Verbindung zur alten Domain aufgebaut werden.<\/p>\n\n\n\n
Ist deren Zertifikat ung\u00fcltig, kann der Browser bereits vorher eine Sicherheitswarnung anzeigen.<\/p>\n\n\n\n
\n
Consiglio pratico:<\/strong> Lass bei einer Domainmigration das Zertifikat der alten HTTPS-Domain nicht vorschnell auslaufen. Die alten URLs m\u00fcssen noch sicher erreichbar sein, damit ihre Weiterleitungen zuverl\u00e4ssig verarbeitet werden k\u00f6nnen.<\/p>\n<\/blockquote>\n\n\n\n
SSL-Zertifikat und E-Mail nicht verwechseln<\/h2>\n\n\n\n
Ein Zertifikat f\u00fcr die Website unter:<\/p>\n\n\n\n
\nhttps:\/\/www.example.com\n<\/div><\/figure>\n\n\n\n
ist nicht automatisch die gesamte TLS-Konfiguration aller anderen Dienste der Domain.<\/p>\n\n\n\n
E-Mail-Dienste wie IMAP oder SMTP k\u00f6nnen andere Hostnamen und eigene TLS-Verbindungen verwenden.<\/p>\n\n\n\n
Ein funktionierendes HTTPS-Zertifikat der Website beweist deshalb nicht automatisch, dass s\u00e4mtliche E-Mail-Dienste korrekt konfiguriert sind.<\/p>\n\n\n\n
HTTPS-Fehler systematisch eingrenzen<\/h2>\n\n\n\n
Eine gute Diagnose folgt einer festen Reihenfolge.<\/p>\n\n\n\n
Domain aufrufen\n        \u2193\nDNS funktioniert?\n        \u2193\nServer erreichbar?\n        \u2193\nTLS-Verbindung m\u00f6glich?\n        \u2193\nZertifikat g\u00fcltig?\n        \u2193\nHostname korrekt?\n        \u2193\nZertifikatskette korrekt?\n        \u2193\nHTTP-Antwort korrekt?\n        \u2193\nWeiterleitungen korrekt?\n        \u2193\nMixed Content?\n        \u2193\nAnwendung funktioniert?<\/code><\/pre>\n\n\n\n
Damit vermeidest du, Probleme auf der falschen Ebene zu suchen.<\/p>\n\n\n\n
Typische SSL- und HTTPS-Fehler<\/h2>\n\n\n\n
Zertifikat abgelaufen\n\nZertifikat noch nicht g\u00fcltig\n\nHostname stimmt nicht\n\nwww nicht abgedeckt\n\nSubdomain nicht abgedeckt\n\nZertifikatskette unvollst\u00e4ndig\n\nfalsches Zertifikat ausgeliefert\n\nMixed Content\n\nHTTP leitet nicht auf HTTPS\n\nRedirect-Schleife\n\nunn\u00f6tige Redirect-Kette\n\nDNS zeigt auf falschen Server\n\nCDN liefert anderes Zertifikat\n\nalte HTTP-URLs nach Migration\n\nCanonical zeigt auf HTTP\n\nSitemap enth\u00e4lt alte HTTP-URLs\n\nalte Domain verliert Zertifikat\nvor Abschluss der Migration<\/code><\/pre>\n\n\n\n
Checkliste: SSL und HTTPS pr\u00fcfen<\/h2>\n\n\n\n
https:\/\/ direkt aufrufen\n        \u2193\nBrowserwarnung vorhanden?\n        \u2193\nZertifikat \u00f6ffnen\n        \u2193\nG\u00fcltigkeitszeitraum pr\u00fcfen\n        \u2193\nHostname \/ SAN pr\u00fcfen\n        \u2193\nZertifikatskette pr\u00fcfen\n        \u2193\nhttp:\/\/ aufrufen\n        \u2193\nWeiterleitung auf HTTPS pr\u00fcfen\n        \u2193\nwww und non-www pr\u00fcfen\n        \u2193\nwichtige Unterseiten pr\u00fcfen\n        \u2193\nBrowser-Konsole \u00f6ffnen\n        \u2193\nMixed Content suchen\n        \u2193\nHTTP-Status pr\u00fcfen\n        \u2193\nDNS-Aufl\u00f6sung pr\u00fcfen\n        \u2193\nCDN \/ Proxy ber\u00fccksichtigen\n        \u2193\ninterne Links pr\u00fcfen\n        \u2193\nCanonical pr\u00fcfen\n        \u2193\nXML-Sitemap pr\u00fcfen\n        \u2193\nexternes Monitoring kontrollieren<\/code><\/pre>\n\n\n\n
Riepilogo<\/h2>\n\n\n\n
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\u00fcssen zusammenpassen.<\/p>\n\n\n\n
Bei einem Zertifikatsfehler solltest du zun\u00e4chst pr\u00fcfen, ob das Zertifikat zeitlich g\u00fcltig ist und zum aufgerufenen Hostnamen passt. Anschlie\u00dfend k\u00f6nnen Zertifikatskette, DNS-Aufl\u00f6sung, Serverkonfiguration sowie gegebenenfalls CDN oder Reverse Proxy untersucht werden.<\/p>\n\n\n\n
Mixed Content ist ein anderes Problem: Hier funktioniert HTTPS grunds\u00e4tzlich, die sichere Seite versucht jedoch einzelne Ressourcen \u00fcber HTTP zu laden. Solche Referenzen sollten an ihrer eigentlichen Quelle korrigiert werden.<\/p>\n\n\n\n
Bei einer vollst\u00e4ndig auf HTTPS umgestellten Website sollten HTTP-Varianten sauber auf HTTPS weiterleiten. Interne Links, Canonical-URLs und XML-Sitemaps sollten ebenfalls konsistent die gew\u00fcnschten HTTPS-Adressen verwenden.<\/p>\n\n\n\n
Besondere Vorsicht ist bei Domain- und Servermigrationen erforderlich. Auch die alte Domain ben\u00f6tigt w\u00e4hrend einer HTTPS-Migration weiterhin ein g\u00fcltiges Zertifikat, wenn Besucher sichere alte URLs aufrufen und anschlie\u00dfend per Redirect weitergeleitet werden sollen.<\/p>\n\n\n\n
HTTPS darf au\u00dferdem nicht mit vollst\u00e4ndiger Website-Sicherheit verwechselt werden. Eine verschl\u00fcsselte Verbindung sch\u00fctzt die Daten\u00fcbertragung, verhindert aber keine Sicherheitsl\u00fccken in WordPress, Plugins, Anwendungen oder Benutzerkonten.<\/p>\n\n\n\n
Bei HTTPS-Problemen ist deshalb die genaue Fehlermeldung wichtiger als die pauschale Aussage \u201eSSL funktioniert nicht\u201c. Wer DNS, TLS, HTTP und Anwendung als getrennte Ebenen betrachtet, findet die tats\u00e4chliche Ursache wesentlich schneller.<\/strong><\/p>","protected":false},"excerpt":{"rendered":"
HTTPS geh\u00f6rt heute zum Standard einer professionellen Website. Es verschl\u00fcsselt die Verbindung zwischen Browser und Webserver und sch\u00fctzt \u00fcbertragene Daten davor, auf dem Transportweg unbemerkt mitgelesen oder ver\u00e4ndert zu werden. Dass eine Website grunds\u00e4tzlich \u00fcber https:\/\/ erreichbar ist, bedeutet allerdings noch nicht automatisch, dass die gesamte HTTPS-Konfiguration fehlerfrei ist. Ein abgelaufenes Zertifikat, ein falscher Hostname, […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"_joinchat":[],"footnotes":""},"doc_category":[85],"doc_tag":[],"class_list":["post-22925","docs","type-docs","status-publish","hentry","doc_category-seo-monitoring"],"year_month":"2026-09","word_count":3911,"total_views":"5","reactions":{"happy":"0","normal":"0","sad":"0"},"author_info":{"name":"Silvio Mazenauer","author_nicename":"admin-curia","author_url":"https:\/\/www.curiaweb.ch\/it\/author\/admin-curia\/"},"doc_category_info":[{"term_name":"SEO & Monitoring","term_url":"https:\/\/www.curiaweb.ch\/it\/hilfe-kategorie\/seo-monitoring\/"}],"doc_tag_info":[],"knowledge_base_info":[],"knowledge_base_slug":[],"_links":{"self":[{"href":"https:\/\/www.curiaweb.ch\/it\/wp-json\/wp\/v2\/docs\/22925","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.curiaweb.ch\/it\/wp-json\/wp\/v2\/docs"}],"about":[{"href":"https:\/\/www.curiaweb.ch\/it\/wp-json\/wp\/v2\/types\/docs"}],"author":[{"embeddable":true,"href":"https:\/\/www.curiaweb.ch\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.curiaweb.ch\/it\/wp-json\/wp\/v2\/comments?post=22925"}],"version-history":[{"count":1,"href":"https:\/\/www.curiaweb.ch\/it\/wp-json\/wp\/v2\/docs\/22925\/revisions"}],"predecessor-version":[{"id":22927,"href":"https:\/\/www.curiaweb.ch\/it\/wp-json\/wp\/v2\/docs\/22925\/revisions\/22927"}],"wp:attachment":[{"href":"https:\/\/www.curiaweb.ch\/it\/wp-json\/wp\/v2\/media?parent=22925"}],"wp:term":[{"taxonomy":"doc_category","embeddable":true,"href":"https:\/\/www.curiaweb.ch\/it\/wp-json\/wp\/v2\/doc_category?post=22925"},{"taxonomy":"doc_tag","embeddable":true,"href":"https:\/\/www.curiaweb.ch\/it\/wp-json\/wp\/v2\/doc_tag?post=22925"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}