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 websono comunque ancora comuni nell'uso comune.
Tecnicamente più preciso sarebbe, ad esempio:
Certificato TLS
o
Connessione HTTPS con TLSIn 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 serverCiò 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/
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:
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 prodottoUn 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:
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:
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.comUn 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.comessere 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 radiceIl 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:
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 immaginiSoprattutto 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.comAltri 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 caricoEvitare 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 HTTPSCiò 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/Se tecnicamente possibile, i passaggi intermedi non necessari dovrebbero essere evitati.
Una configurazione pulita reindirizza una vecchia variante il più direttamente possibile all'URL di destinazione finale.
Errore 8: HTTPS funziona solo con o senza www #
Se:
funziona, ma:
genera un avviso di certificato, si dovrebbe verificare:
Esiste il record DNS?
Punta alla giusta infrastruttura?
L'hostname è incluso nel certificato?
Il web server è configurato per questo host?
Il reindirizzamento è corretto?Un certificato può essere fornito in modo sensato per un nome host solo se l'intera configurazione del dominio e del server è adatta allo scopo.
Il DNS e l'SSL sono correlati durante l'emissione #
In molte procedure di certificazione automatizzate è necessario dimostrare il controllo del dominio o del nome host.
Se il dominio punta a un'infrastruttura errata, l'emissione o il rinnovo automatico potrebbero quindi fallire.
In caso di problemi, dovresti controllare la risoluzione DNS. Ti spieghiamo come farlo su Controllare i record DNS.
Non confondere la modifica del DNS con il certificato #
Dopo un cambio di server possono essere coinvolti due processi distinti:
DNS
→ I visitatori devono raggiungere il
server corretto
TLS
→ questo server deve fornire un
certificato validoUn certificato corretto sul nuovo server non serve a nulla se un visitatore, a causa della sua risoluzione DNS, raggiunge ancora un altro server.
Al contrario, il dominio potrebbe già puntare al nuovo server mentre lì non è ancora stato installato un certificato adeguato.
Errore 9: Viene inviato il certificato errato #
Un server può gestire più siti Web e certificati.
In caso di una configurazione errata dell'host virtuale, per un dominio potrebbe essere consegnato il certificato di un altro sito Web.
Lo riconosci dal fatto che il nome host chiamato non corrisponde ai nomi nel certificato rilasciato.
In questo caso non è il browser a dover essere riparato, bensì la configurazione del certificato o del server web.
Errore 10: Certificato rinnovato, il browser mostra ancora il vecchio certificato #
Se un certificato è stato rinnovato ma continua a essere distribuito quello vecchio, ci possono essere diverse cause.
Per esempio:
Il server web sta ancora utilizzando il vecchio file di certificato
Il servizio non è stato ricaricato correttamente dopo la modifica
Il reverse proxy fornisce un certificato diverso
La CDN termina il TLS
Il DNS punta a un altro serverPerciò è determinante non solo quale certificato sia memorizzato da qualche parte sul server, ma quale certificato venga effettivamente inviato durante la connessione.
Considerare CDN e reverse proxy #
Quando si utilizza una CDN o un reverse proxy, la connessione TLS può avvenire in più punti.
In sintesi:
Visitatore
↓ HTTPS
CDN / Proxy
↓ HTTPS
Server di origineCiò consente di coinvolgere anche certificati diversi.
Un certificato valido sul server di origine non significa quindi automaticamente che il certificato consegnato pubblicamente sia corretto, e viceversa.
Controllare HTTPS nel browser #
Per una prima diagnosi puoi usare il browser.
Controlla:
URL chiamata
Stato di sicurezza
Informazioni sul certificato
Nome host
Periodo di validità
Emittente
Console
Richieste di reteIn caso di errore, dovresti documentare il messaggio esatto anziché annotare semplicemente „SSL non funziona“.
L'esatto messaggio di errore è fondamentale #
C'è una grande differenza tra le seguenti situazioni:
Certificato scaduto
Nome host non valido
Catena di certificati non valida
Contenuto misto
Loop di reindirizzamento
DNS configurato in modo errato
Server non raggiungibileAll'inizio possono sembrare tutti un „problema HTTPS“ dal punto di vista dell'utente, ma richiedono soluzioni completamente diverse.
Controllare ulteriormente il codice di stato HTTP #
I codici di stato HTTPS e HTTP operano su livelli diversi.
Una connessione TLS può essere stabilita con successo e il sito web può comunque rispondere con:
404 Non Trovato
500 Errore Interno del Server
503 Servizio Non DisponibileAllora la connessione crittografata funziona, mentre l'applicazione o il contenuto richiesto ha un altro problema.
Spiegheremo i codici di stato più importanti su Codici di stato HTTP spiegati: 200, 301, 404, 403 e 500.
Un errore HTTP 500 non è un errore SSL #
Se il browser stabilisce con successo una connessione HTTPS e il server successivamente risponde con Errore interno del server risponde, TLS ha già fatto la sua parte con successo.
La causa risiede quindi tipicamente a un livello successivo.
DNS
↓
TLS riuscito
↓
Richiesta HTTP
↓
Applicazione
↓
500 Internal Server ErrorTenere ben separati questi livelli fa risparmiare molto tempo nella ricerca degli errori.
Anche un errore DNS non è automaticamente un errore SSL #
Se il nome di dominio non può essere risolto affatto, è possibile che il browser non riesca ancora a raggiungere alcun server con cui poter stabilire una connessione TLS.
Anche se il sito web non viene visualizzato nel browser, si tratta inizialmente di un problema di DNS o di accessibilità.
HTTPS e monitoraggio del sito web #
Un monitor HTTPS esterno può verificare regolarmente se è possibile stabilire una connessione sicura con il sito Web e ricevere una risposta prevista.
A seconda del sistema di monitoraggio, è possibile monitorare anche problemi relativi ai certificati o una data di scadenza imminente.
Spieghiamo come funzionano in linea di principio tali esami su Monitoraggio di siti web: monitorare la disponibilità e le interruzioni.
Perché il monitoraggio dei certificati è utile #
Il rinnovo automatico del certificato riduce notevolmente l'onere amministrativo. Tuttavia, il rinnovo può fallire a causa di un guasto tecnico.
Un ulteriore controllo esterno può quindi aiutare a individuare tempestivamente una data di scadenza imprevista e imminente.
Il monitoraggio tuttavia non sostituisce la risoluzione della causa, se il rinnovo automatico è effettivamente compromesso.
HTTPS e Google #
Per i motori di ricerca, i segnali di un sito web HTTPS dovrebbero essere consistenti.
Se HTTPS è la variante desiderata, si dovrebbe, tra le altre cose:
link interni
Reindirizzamenti
URL Canonical
Sitemap XML
URL di siti Web pubblicipuntare in modo coerente alla versione HTTPS.
La sitemap XML dovrebbe contenere di conseguenza gli URL HTTPS desiderati. Maggiori informazioni sono disponibili su Mappa del sito XML: cosa fa e come inviarla a Google.
Evitare che i canonical puntino a HTTP #
Quando il sito web è stato completamente migrato a HTTPS, una pagina HTTPS normalmente non dovrebbe indicare contemporaneamente tramite il suo elemento canonical una versione HTTP come URL preferito.
Una simile configurazione genera segnali tecnici contraddittori.
In parole semplici, l'immagine dovrebbe apparire così:
HTTP
↓ 301
HTTPS
↓
Canonical → HTTPS
↓
Sitemap → HTTPS
↓
link interni → HTTPSVerificare dopo la migrazione da HTTP a HTTPS #
Quando un sito web è stato recentemente convertito in HTTPS, non dovresti controllare solo se la home page possiede un certificato.
Verifica sistematicamente:
Homepage HTTPS raggiungibile?
HTTP → HTTPS?
Sottopagine reindirizzate correttamente?
www / non-www corretto?
Certificato valido per tutti gli hostname necessari?
Contenuto misto presente?
Link interni a HTTPS?
Canonical su HTTPS?
La sitemap contiene HTTPS?
Controllare le pagine importanti nella Search Console?Controllare la versione HTTPS in Google Search Console #
Con lo strumento di controllo URL della Google Search Console puoi esaminare quale URL Google conosce e come viene elaborata una specifica pagina.
In caso di problemi con l'indicizzazione, tuttavia, non dovresti considerare l'HTTPS isolatamente. Anche la scansionabilità, lo stato HTTP, i canonical, la sitemap e le direttive di indicizzazione giocano un ruolo importante.
Puoi trovare la procedura sistematica su Google non indicizza il mio sito web: verifica le cause.
Non drammatizzare troppo i contenuti misti e la SEO #
Il contenuto misto dovrebbe essere risolto, soprattutto per motivi di sicurezza, funzionalità e qualità.
Tuttavia, è poco utile definire genericamente ogni errore HTTPS una „catastrofe SEO“.
Gli effetti effettivi dipendono da quale errore si verifica e da quali risorse o URL sono interessati.
I problemi tecnici dovrebbero quindi essere risolti in base alla loro reale causa e non a causa di promesse SEO esagerate.
HTTPS non rende automaticamente sicuro un sito web #
Questa differenza è particolarmente importante.
HTTPS protegge il trasferimento dei dati tra client e server.
Tuttavia, non protegge automaticamente un sito Web da:
password non sicuri
plugin obsoleti
malware
SQL injection
credenziali rubate
account utente non sicuri
manipolazione dei file
errori applicativiImportante: Un certificato SSL valido significa che è possibile stabilire una connessione crittografata con il nome host confermato. Non è un certificato di sicurezza generale per l'intero sito web.
Anche un sito web hackerato può possedere un certificato valido #
Un web server compromesso può continuare a fornire un certificato TLS perfettamente valido.
Il browser può quindi stabilire una connessione crittografata a livello tecnico, anche se il sito web stesso è stato manomesso.
HTTPS e la sicurezza delle applicazioni devono quindi essere considerati separatamente.
L'HTTPS non protegge da un sito Web falso #
Un certificato valido conferma in primo luogo la connessione al nome host contenuto nel certificato. Non conferma che un'azienda, un'offerta o un contenuto siano automaticamente affidabili.
Anche i siti Web fraudolenti possono utilizzare HTTPS.
I visitatori dovrebbero pertanto continuare a prestare attenzione al dominio effettivo e al contesto di un sito web.
Cosa fare in caso di avviso del browser? #
Se il tuo browser avvisa in merito a un certificato o a una connessione HTTPS, non dovresti semplicemente ignorare l'avviso in modo permanente.
Per il tuo sito web si consiglia la seguente diagnosi:
annotare il messaggio di errore preciso
↓
controllare l'hostname
↓
visualizzare il certificato
↓
verificare il periodo di validità
↓
verificare SAN / hostname
↓
verificare la catena dei certificati
↓
controllare la risoluzione DNS
↓
considerare proxy / CDN
↓
verificare la configurazione del serverNon dare subito la colpa alla cache del browser #
In caso di problemi HTTPS, spesso si consiglia per prima cosa di cancellare la cache del browser.
Questo può essere utile in determinate situazioni, ma non dovrebbe sostituire una vera e propria diagnosi.
Se il certificato pubblicato pubblicamente è scaduto o è stato emesso per il nome host sbagliato, la cancellazione della normale cache del sito web non risolverà il problema.
Verifica il problema su più dispositivi #
Se un solo dispositivo mostra un avviso di certificato, mentre altri dispositivi aggiornati funzionano senza problemi, dovresti esaminare anche l'ambiente locale.
I possibili fattori sono:
ora di sistema errata
sistema operativo obsoleto
browser obsoleto
proxy locale
software antivirus
rete aziendale
archivio certificati localiSe invece numerosi dispositivi indipendenti ricevono lo stesso avviso, ciò depone maggiormente a favore di un problema lato server o certificato.
Errore solo in una rete #
Se HTTPS funziona sulla rete mobile ma non sulla rete aziendale o domestica, potrebbero essere coinvolti ulteriori componenti di rete locali.
Per esempio:
Proxy
Firewall
Risolutore DNS
Ispezione TLS
VPN
Filtro localeUn tale test aiuta a circoscrivere la causa geograficamente.
Controllare l'ora del sistema #
I certificati hanno un periodo di validità definito.
Se la data o l'ora di un dispositivo sono notevolmente errate, un browser può valutare un certificato valido come non valido.
In caso di avvisi inspiegabili sui certificati su un solo dispositivo, l'ora di sistema è quindi uno dei primi controlli più semplici da effettuare.
Errore dopo un trasferimento del sito web #
Dopo un cambio di hosting o di server, possono verificarsi problemi HTTPS se i singoli componenti della migrazione non sono ancora perfettamente allineati.
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?Inoltre, le modifiche DNS possono richiedere del tempo prima che i diversi resolver utilizzino il nuovo stato. Spieghiamo di più al riguardo sotto Propagazione del DNS spiegata.
Errore dopo la modifica del dominio #
Se un sito web proviene da:
su
si trasferisce, il nuovo dominio necessita di un certificato adeguato.
Anche la vecchia dominio dovrebbe rimanere tecnicamente raggiungibile durante la migrazione, affinché i reindirizzamenti al nuovo dominio possano funzionare.
Un errore di certificato sul vecchio dominio HTTPS può colpire i visitatori prima ancora che sia possibile elaborare un reindirizzamento HTTP.
Perché HTTPS deve funzionare prima di un reindirizzamento #
Questo è un punto tecnico spesso trascurato.
Un visitatore accede, ad esempio, a:
Prima che il web server invii una risposta come:
301 - Spostato permanentemente
può inviare, è necessario prima stabilire la connessione TLS con il vecchio dominio.
Se il loro certificato non è valido, il browser potrebbe mostrare un avviso di sicurezza anche prima.
Consiglio pratico: Durante una migrazione di dominio, non lasciare che il certificato del vecchio dominio HTTPS scada prematuramente. Le vecchie URL devono essere ancora accessibili in modo sicuro affinché i loro reindirizzamenti possano essere elaborati in modo affidabile.
Non confondere il certificato SSL e l'e-mail #
Un certificato per il sito web all'indirizzo:
non è automaticamente l'intera configurazione TLS di tutti gli altri servizi del dominio.
I servizi di posta elettronica come IMAP o SMTP possono utilizzare nomi host diversi e connessioni TLS dedicate.
Un certificato HTTPS funzionante del sito web non dimostra quindi automaticamente che tutti i servizi di posta elettronica siano configurati correttamente.
Isolare sistematicamente gli errori HTTPS #
Una buona diagnosi segue un ordine preciso.
Accedere al dominio
↓
Il DNS funziona?
↓
Server raggiungibile?
↓
Connessione TLS possibile?
↓
Certificato valido?
↓
Nome host corretto?
↓
Catena di certificati corretta?
↓
Risposta HTTP corretta?
↓
Reindirizzamenti corretti?
↓
Contenuto misto?
↓
L'applicazione funziona?In questo modo eviti di cercare problemi al livello sbagliato.
Tipici errori SSL e HTTPS #
Certificato scaduto
Certificato non ancora valido
L'hostname non corrisponde
www non coperto
Sottodominio non coperto
Catena di certificati incompleta
Certificato errato inviato
Contenuto misto
HTTP non reindirizza a HTTPS
Ciclo di reindirizzamento
Catena di reindirizzamento non necessaria
DNS punta al server errato
La CDN fornisce un certificato diverso
Vecchi URL HTTP dopo la migrazione
Canonical punta a HTTP
La sitemap contiene vecchi URL HTTP
Il vecchio dominio perde il certificato prima del completamento della migrazioneChecklist: controllo di SSL e HTTPS #
https:// direttamente visitare
↓
Avviso del browser presente?
↓
Aprire il certificato
↓
Verificare il periodo di validità
↓
Verificare hostname / SAN
↓
Verificare la catena dei certificati
↓
chiamare http://
↓
Verificare il reindirizzamento a HTTPS
↓
Verificare www e non-www
↓
Verificare le sottopagine importanti
↓
Aprire la console del browser
↓
Cercare Mixed Content
↓
Verificare lo stato HTTP
↓
Verificare la risoluzione DNS
↓
Considerare CDN / Proxy
↓
Verificare i link interni
↓
Verificare il Canonical
↓
Verificare la Sitemap XML
↓
Controllare il monitoraggio esternoRiepilogo #
Una configurazione HTTPS funzionante consiste in più di un semplice certificato SSL installato. Dominio, DNS, certificato, web server, reindirizzamenti e le risorse caricate dal sito web devono coincidere.
In caso di errore di certificato, dovresti prima verificare se il certificato è valido nel tempo e corrisponde al nome host chiamato. Successivamente, è possibile esaminare la catena di certificati, la risoluzione DNS, la configurazione del server e, se necessario, la CDN o il reverse proxy.
Il Mixed Content è un altro problema: qui l'HTTPS in linea di principio funziona, ma la pagina sicura tenta di caricare singole risorse tramite HTTP. Tali riferimenti dovrebbero essere corretti alla loro origine effettiva.
Su un sito web completamente convertito in HTTPS, le varianti HTTP dovrebbero reindirizzare correttamente a HTTPS. Anche i link interni, i tag canonical e le sitemap XML dovrebbero utilizzare in modo coerente gli indirizzi HTTPS desiderati.
È necessaria particolare cautela in caso di migrazioni di domini e server. Anche il vecchio dominio richiede un certificato valido durante una migrazione HTTPS, qualora i visitatori accedano a vecchi URL sicuri e debbano successivamente essere reindirizzati tramite reindirizzamento.
Inoltre, HTTPS non deve essere confuso con la completa sicurezza del sito web. Una connessione cifrata protegge la trasmissione dei dati, ma non impedisce le vulnerabilità di sicurezza in WordPress, nei plugin, nelle applicazioni o negli account utente.
In caso di problemi HTTPS, l'esatto messaggio di errore è quindi più importante dell'affermazione generica „SSL non funziona“. Chi considera DNS, TLS, HTTP e applicazione come livelli separati trova la causa effettiva molto più velocemente.
