Come risolvere gli errori del certificato TLS e le pagine HTTPS che non si caricano

Quando una pagina sicura smette di caricarsi, il browser visualizza uno strano avviso relativo al certificato e il lucchetto scompare, è normale farsi prendere dal panico. Gli errori del certificato TLS e le pagine HTTPS che non si caricano possono minare la fiducia degli utenti, causare un improvviso calo delle vendite e, incidentalmente, danneggiare la SEO se non vengono risolti tempestivamente.

La buona notizia è che la maggior parte di questi errori ha una spiegazione e una soluzione. Molti problemi derivano da semplici configurazioni errate, certificati scaduti, contenuti misti o errori DNS , piuttosto che da attacchi sofisticati. In questa guida, vedrai, passo dopo passo, come identificare le cause più comuni, come risolvere ogni tipo di errore (sia dal lato utente che dal lato server) e cosa fare per prevenirli in futuro.

Cos'è un certificato TLS/SSL e perché la connessione HTTPS si interrompe?

Prima di iniziare a modificare qualsiasi cosa, è importante capire cosa succede dietro le quinte. Un certificato TLS/SSL è un file digitale che identifica il tuo sito web e crittografa i dati tra il tuo browser e il server . È ciò che ti permette di passare da HTTP a HTTPS e di visualizzare la familiare icona del lucchetto nella barra degli indirizzi.

Questo certificato è rilasciato da un'autorità di certificazione (CA) riconosciuta, include il nome di dominio, le date di validità e la chiave pubblica , ed è accompagnato da una catena di certificati intermedi che estendono la fiducia fino alla CA radice. Se qualcosa in questa catena o nella configurazione non è corretto, il browser interromperà il processo e visualizzerà un messaggio di errore.

Oggigiorno, raramente si parla di SSL "puro". I browser moderni utilizzano TLS (Transport Layer Security), l'evoluzione di SSL , anche se per abitudine tendiamo ancora a dire SSL/TLS. Il principio è lo stesso: viene negoziata una connessione crittografata, il certificato viene convalidato e, se tutto va bene, l'utente naviga con i propri dati protetti.

Quando le cose non vanno per il verso giusto, il browser non riesce a verificare che il server sia effettivamente chi dichiara di essere o che la connessione soddisfi i requisiti minimi di sicurezza . È in questi casi che compaiono errori come ERR_SSL_PROTOCOL_ERROR, certificati non validi, avvisi di "connessione non privata" e altre spiacevoli sorprese che scoraggerebbero qualsiasi utente medio.

Le cause più frequenti di errori nei certificati TLS e HTTPS che impediscono il caricamento

Gli avvisi di sicurezza non compaiono tutti per lo stesso motivo. Un errore del certificato TLS potrebbe essere causato da problemi di configurazione del server, errori del certificato, errori DNS o persino dalle impostazioni locali dell'utente (data, antivirus, firewall, ecc.). Comprendere le cause evita di procedere per tentativi.

Una distinzione fondamentale è quella tra errori lato server (il sito web) ed errori lato client (il dispositivo dell'utente) . Come amministratori, possiamo intervenire solo sul lato server, ma comprendere entrambi gli aspetti è utile per una diagnosi accurata.

Tra le cause lato server più comuni si annoverano: certificati scaduti, domini non corrispondenti, stringhe intermedie incomplete, protocolli TLS obsoleti o reindirizzamenti tra HTTP e HTTPS configurati in modo errato . È frequente anche la presenza di contenuti misti: la pagina viene caricata tramite HTTPS, ma alcune risorse vengono ancora richieste tramite HTTP.

Dal punto di vista dell'utente, molti problemi derivano da impostazioni errate di data e ora del sistema, cache del browser danneggiata, antivirus o firewall che intercettano la connessione, DNS difettoso o file hosts modificati . Tutti questi fattori possono generare avvisi come ERR_SSL_PROTOCOL_ERROR anche se il server è configurato correttamente.

Errori tipici di SSL/TLS e il loro vero significato

I browser visualizzano molti messaggi diversi, ma quasi tutti possono essere raggruppati in poche categorie. Ogni codice di errore indica un tipo specifico di problema con il certificato o la connessione . Saperli interpretare è metà della soluzione.

Uno degli errori più noti è ERR_SSL_PROTOCOL_ERROR . Indica che il browser non è riuscito a completare il protocollo TLS con quel server: ciò potrebbe essere dovuto a un certificato scaduto, un protocollo non supportato, contenuti misti, errori nella catena di fiducia o persino un file hosts danneggiato che reindirizza a una destinazione diversa da quella prevista.

Un altro errore classico è ERR_CERT_COMMON_NAME_INVALID , che si verifica quando il nome di dominio del certificato non corrisponde al dominio a cui si sta tentando di accedere. Si tratta di un avviso serio perché può essere un segnale di un attacco Man-in-the-Middle o di una configurazione errata critica del server (ad esempio, l'utilizzo dello stesso certificato per più domini senza SAN (Subject Alternative Name) appropriati).

È anche frequente riscontrare l' errore NET::ERR_CERT_AUTHORITY_INVALID , che indica che il certificato non è stato emesso da un'autorità di certificazione (CA) considerata attendibile dal browser. Ciò può essere dovuto a certificati autofirmati, certificati interni o al fatto che l'antivirus o un proxy stia inserendo un proprio certificato senza che il browser lo riconosca come attendibile.

Strettamente correlato è Net::ERR_CERT_DATE_INVALID , che indica problemi di data: il certificato è scaduto oppure l'ora del computer dell'utente non corrisponde al periodo di validità. I ​​certificati TLS vengono emessi con una data fissa; se la data è al di fuori di tale intervallo, il browser presume che non sia attendibile.

Esistono altri messaggi meno piacevoli, come ERR_SSL_VERSION_OR_CIPHER_MISMATCH , che di solito compare quando il server supporta solo protocolli o suite di cifratura obsoleti che i browser moderni non accettano più. In pratica, ciò significa che la configurazione del server è obsoleta e deve essere aggiornata.

In alcuni casi, si verifica l' errore ERR_SSL_WEAK_EPHEMERAL_DH_KEY , che indica che il server sta utilizzando chiavi Diffie-Hellman temporanee troppo deboli. L'utente può fare ben poco al riguardo; la responsabilità ricade sull'amministratore del server, che deve aggiornare la configurazione crittografica.

Infine, sebbene non si tratti di un errore di certificato in sé, il messaggio ERR_TOO_MANY_REDIRECTS compare quando le regole di reindirizzamento tra HTTP e HTTPS, o tra le versioni con e senza www, creano un ciclo infinito. Il browser passa da un URL all'altro finché non si arrende e la pagina non viene mai caricata.

Errori di contenuto misto e siti HTTPS "non completamente sicuri".

Uno dei problemi più insidiosi è rappresentato dagli errori di contenuto misto . Questi si verificano quando la pagina principale viene caricata tramite HTTPS, ma alcune risorse interne (immagini, script, fogli di stile, iframe, ecc.) continuano ad essere accessibili tramite HTTP . Il risultato: il browser segnala che il sito non è completamente sicuro oppure blocca direttamente tali risorse.

Questo scenario è molto comune dopo la migrazione di un sito da HTTP a HTTPS senza un'adeguata verifica dei percorsi interni. Bastano un paio di immagini o uno script con un URL assoluto in HTTP per far scattare degli avvisi . Negli ambienti di produzione, alcuni browser bloccano addirittura script o iframe non sicuri, compromettendo funzionalità critiche.

Trovare queste risorse implica l'ispezione del codice o l'utilizzo di strumenti di auditing. Correggerle richiede la modifica degli URL in HTTPS, l'utilizzo di percorsi relativi allo schema o l'aggiornamento di template e plugin che generano link obsoleti . In molti CMS, un buon strumento di ricerca e sostituzione nel database (utilizzato con attenzione) è sufficiente per correggere centinaia di link contemporaneamente.

Non stiamo parlando solo di immagini o CSS. Anche gli script esterni, le librerie di terze parti e le chiamate API devono viaggiare tramite HTTPS . Se la tua pagina si carica tramite HTTPS ma include chiamate API che utilizzano HTTP, alcuni browser bloccheranno le richieste, interromperanno il flusso di accesso o impediranno il caricamento di determinati moduli.

Nel caso specifico delle applicazioni moderne, è inoltre necessario verificare gli URI di reindirizzamento OAuth (ad esempio, da Google) che puntano a localhost o HTTP . Questa combinazione può causare strani errori, avvisi inaspettati relativi ai certificati (come un certificato autofirmato per "localhost") e, per finire, interessare solo un utente o un ambiente specifico.

Problemi comuni di installazione e validità dei certificati

Oltre ai contenuti misti, molti problemi derivano da come il certificato è stato installato o rinnovato. Un certificato SSL/TLS installato in modo errato o non valido è solitamente dovuto a domini non corrispondenti, catene di certificati intermedie incomplete o server che continuano a fornire un certificato obsoleto.

Se il certificato non corrisponde al dominio (ad esempio, copre solo mydomain.com ma si sta accedendo a www.mydomain.com), il browser contrassegnerà la connessione come non sicura. Quando si acquista o si genera un certificato, assicurarsi di includere tutte le varianti necessarie (con e senza www, sottodomini, ecc.) oppure utilizzare SAN jolly quando appropriato.

Un altro errore comune è dimenticare la catena di certificati intermedi . Molte CA forniscono più file; se il server fornisce solo il certificato primario senza la catena fino alla CA radice, alcuni browser non saranno in grado di stabilire la fiducia. Il risultato: l'utente vede un certificato apparentemente valido, ma il browser non lo riconosce come tale.

Anche durante i rinnovi possono verificarsi delle sorprese. È piuttosto comune rinnovare un certificato presso il fornitore senza aggiornare il binding sul server o sulla piattaforma di hosting . Il pannello di controllo indica che il nuovo certificato è stato emesso, ma il sito web continua a utilizzare quello vecchio e scaduto. Finché non viene effettuata la risincronizzazione (o il binding non viene ristabilito), i visitatori continueranno a visualizzare gli avvisi.

Sulle piattaforme gestite come Azure App Service o Vercel, entrano in gioco anche le autorizzazioni sul Key Vault e le associazioni tra certificati e domini personalizzati . Se il servizio che gestisce i certificati non dispone di autorizzazioni sufficienti sul Key Vault o se non è stata eseguita la sincronizzazione automatica, l'applicazione continuerà a utilizzare il vecchio certificato.

È inoltre importante tenere presente la combinazione tra SNI e connessioni SSL basate su IP . In alcuni ambienti, quando entrambi vengono utilizzati simultaneamente, i client che non supportano SNI ricevono sempre il certificato associato all'IP, anche se accedono tramite un dominio che dovrebbe utilizzare un certificato diverso. Ciò può comportare la presentazione di un certificato errato, apparentemente in modo casuale, a seconda di chi si connette.

Reindirizzamenti HTTP/HTTPS, domini e DNS: fonti di errori invisibili

Anche con un certificato perfetto, il tuo sito web potrebbe non caricarsi tramite HTTPS se ci sono problemi con i reindirizzamenti, il dominio o il DNS . Questi livelli, che spesso tocchiamo una volta e poi dimentichiamo, sono una fonte inesauribile di errori subdoli.

Per garantire che un sito web appaia sempre sicuro, la prassi standard è quella di imporre l'HTTPS tramite regole di reindirizzamento (ad esempio, in .htaccess, Nginx, nel pannello di controllo dell'hosting o tramite un reverse proxy) . Se queste regole non sono configurate correttamente, si possono creare cicli tra http:// e https:// o tra www e non-www. Il risultato tipico è un errore ERR_TOO_MANY_REDIRECTS o una pagina che semplicemente non si carica.

È inoltre importante prestare attenzione alla configurazione del dominio presso il provider DNS. Quando si punta un dominio a un'applicazione web o a un servizio cloud, è necessario utilizzare correttamente i record A, CNAME e TXT . L'utilizzo di un record A e di un record CNAME per lo stesso host, la dimenticanza del record TXT di verifica o la mancata modifica dell'indirizzo IP in caso di cambio di server causeranno errori di risoluzione (DNS_PROBE_FINISHED_NXDOMAIN, ecc.).

Inoltre, i record DNS non si aggiornano istantaneamente . Ogni record ha un valore Time To Live (TTL), che indica per quanto tempo i resolver possono memorizzarlo nella cache. Se di recente hai cambiato provider di hosting o indirizzo IP, è normale che alcuni utenti visualizzino ancora il vecchio sito o un errore 404 per diverse ore. Strumenti come WhatsmyDNS possono aiutare a verificare che la propagazione stia procedendo correttamente.

A volte, il problema risiede nel browser o nel sistema dell'utente. Il DNS locale e la cache del browser potrebbero conservare indirizzi obsoleti . Svuotare la cache, svuotare la cache DNS (ad esempio, con `ipconfig /flushdns` su Windows) o riavviare il router è solitamente sufficiente per garantire che il dominio venga risolto correttamente e indirizzi al server corretto.

Non dimenticate nemmeno il file hosts del sistema operativo . Prima dell'avvento del DNS, tutto veniva risolto lì, ed è ancora oggi utilizzato per le mappature fisse nelle reti locali. Malware, strumenti di debug o configurazioni obsolete possono modificarlo e reindirizzarvi a indirizzi IP imprevisti o certificati falsi . Il ripristino del file alle impostazioni predefinite di solito elimina molti errori ERR_SSL_PROTOCOL_ERROR di origine sconosciuta.

Scenari particolari: nuvole, pannelli e limitazioni della piattaforma

Se lavori con piattaforme gestite (Azure, Vercel, cPanel, ecc.), alcuni errori sono determinati dall'infrastruttura stessa. Il modo in cui associ i certificati alle applicazioni, i limiti di acquisto e il tipo di piano influiscono su come e quando puoi utilizzare TLS.

In Azure App Service, ad esempio, non sarà possibile acquistare o utilizzare certificati se il piano è di tipo gratuito o condiviso e non supporta TLS . Inoltre, non sarà possibile acquistare un numero di certificati superiore a quello consentito dal tipo di abbonamento. Se un certificato viene segnalato come potenzialmente fraudolento, rimane in fase di revisione finché il fornitore del certificato non verifica il dominio e rimuove il blocco.

È anche relativamente comune che lo stesso certificato sia collegato a più applicazioni con lo stesso indirizzo IP tramite associazioni basate su IP . Se un VIP sta già utilizzando tale certificato, il portale potrebbe rifiutarsi di aggiungere una seconda associazione e visualizzare un messaggio di errore che indica che "un altro VIP sta già utilizzando tale certificato". La soluzione consiste nel rimuovere l'associazione precedente o, ove possibile, utilizzare associazioni SNI.

Per quanto riguarda i domini personalizzati acquistati tramite queste piattaforme, è importante notare che si affidano a registrar esterni (come GoDaddy) e ad Azure DNS o ad altri provider per l'hosting DNS . Ciò significa che potrebbero esserci limiti di acquisto, regole di rinnovo automatico e costi separati per la registrazione e il DNS.

Se un dominio viene eliminato per errore, di solito c'è un breve periodo (pochi giorni) durante il quale è possibile recuperarlo senza costi aggiuntivi . Trascorso tale periodo, sarà necessario contattare l'assistenza del provider o del registrar per verificare se è ancora disponibile e come ripristinarlo. Nel frattempo, tutti i certificati associati risulteranno inattivi.

Infine, il formato del certificato è importante . Molte piattaforme richiedono file .pfx con password e stringa chiave completa. Se la tua CA fornisce certificati in formato .pem o .key, dovrai convertirli (ad esempio, utilizzando OpenSSL) e includere la chiave privata e tutti i dati intermedi nell'ordine corretto prima di poterli caricare.

Come risolvere gli errori di connessione SSL dal lato utente

Se sei un utente e riscontri una pagina che non si carica tramite HTTPS, non sempre sarai in grado di risolvere il problema (se il problema è del server, c'è poco che tu possa fare). Tuttavia, ci sono alcuni semplici passaggi che vale la pena provare prima di arrendersi , perché spesso il problema risiede nel tuo dispositivo.

La prima cosa da fare è controllare la data e l'ora del sistema . Anche solo pochi minuti di differenza possono far sì che alcuni certificati apparentemente validi vengano considerati scaduti o "non ancora validi". L'attivazione della sincronizzazione automatica di data e ora (su Windows, macOS, Android o iOS) di solito risolve un buon numero di errori di connessione SSL contemporaneamente.

Successivamente, è il momento di fare pulizia: cancella i cookie e la cache del tuo browser . In Chrome, Firefox, Safari e altri, puoi eliminare i cookie e i file temporanei memorizzati dal menu delle impostazioni. Questo obbliga il browser a richiedere nuovamente i certificati e impedisce che vengano mantenuti stati precedenti o reindirizzamenti obsoleti.

Sui computer desktop, è consigliabile cancellare i certificati SSL memorizzati nella cache del sistema . In Windows, questa operazione si effettua dalle Opzioni Internet, scheda Contenuto, utilizzando il pulsante Cancella stato SSL. Su macOS, è possibile utilizzare Accesso Portachiavi per individuare i certificati associati a un dominio specifico ed eliminarli manualmente.

Se il problema persiste, il prossimo sospettato è il software di sicurezza . Alcuni programmi antivirus e firewall intercettano le connessioni HTTPS per analizzarle, iniettando un proprio certificato. Se qualcosa va storto durante questo processo, compariranno errori di autorità non valida o di protocollo. Disabilitare temporaneamente l'antivirus o il firewall (solo a scopo di test) può confermare se sono effettivamente i responsabili.

Un altro rapido controllo consiste nel provare un browser o un dispositivo diverso e, se possibile, anche una rete diversa (dati mobili invece del Wi-Fi) . Se funziona su altri browser e dispositivi, il problema è nel tuo computer. Se non funziona ovunque, il problema è probabilmente dovuto al server o al dominio.

Procedure consigliate per prevenire gli errori dei certificati TLS.

Al di là della semplice risoluzione dei problemi, l'aspetto veramente importante è che questi errori non si verifichino quasi mai. Prevenire i problemi con i certificati TLS implica mantenere certificati, server e DNS aggiornati e attentamente monitorati.

La prima cosa è ovvia ma facile da dimenticare: rinnovate i vostri certificati prima della scadenza e, se possibile, automatizzate il processo . Con Let's Encrypt e molte CA moderne, è facile impostare i rinnovi automatici, così non dovrete ricordarvene ogni pochi mesi. Ciononostante, è sempre una buona idea monitorare le date di scadenza e ricevere notifiche.

È inoltre fondamentale mantenere aggiornati il ​​server e i protocolli di sicurezza . È consigliabile disabilitare SSLv3, TLS 1.0 e altri protocolli obsoleti, optando per TLS 1.2 e 1.3, con suite di cifratura moderne e chiavi sufficientemente robuste. Guide come "Mozilla SSL Configuration" possono essere utili per configurare il server con un livello di sicurezza adeguato.

Altrettanto importante è verificare regolarmente le regole di reindirizzamento tra HTTP e HTTPS, e tra le varianti del dominio . Una modifica apparentemente innocua (una nuova regola in .htaccess, un proxy CDN, un WAF interposto) può introdurre loop o reindirizzare il traffico alla versione non sicura. È buona norma rivedere i reindirizzamenti ed eseguire test di carico completi dopo ogni modifica.

Un'altra misura fondamentale è quella di verificare la presenza di contenuti misti sul sito , soprattutto dopo le migrazioni a HTTPS o quando vengono installati nuovi plugin, temi o integrazioni esterne. Una singola risorsa HTTP può compromettere la percezione di sicurezza dell'intero sito web e portare al blocco selettivo dei contenuti.

Infine, non dimenticate gli strumenti di verifica dei certificati . Servizi online come SSL Labs, o gli strumenti di diagnostica forniti dagli stessi provider, consentono di analizzare la catena di certificati, i protocolli attivi, la compatibilità con i browser e le potenziali vulnerabilità. Integrare questi controlli nelle normali attività di manutenzione aiuta a individuare gli errori prima che i clienti se ne accorgano.

Tirando le somme, è chiaro che gli errori dei certificati TLS e le pagine HTTPS che non si caricano raramente sono dovuti a "magia nera" : sono quasi sempre causati da una data di scadenza dimenticata, una stringa incompleta, un DNS configurato in modo errato o semplicemente una discrepanza di orario sul dispositivo dell'utente. Affrontando le cause più comuni, automatizzando i rinnovi, gestendo i reindirizzamenti e adottando buone pratiche di configurazione, è possibile ridurre significativamente questi avvisi di sicurezza e offrire ai visitatori un'esperienza di navigazione fluida, sicura e senza interruzioni ogni volta che vedono il lucchetto verde.