Come controllare se un sito web ha un certificato SSL valido

Conferma l'host esatto che desideri verificare

Inizia con l'indirizzo esatto, non con il nome del marchio che hai in mente. Un certificato per www.example.com non è lo stesso di uno per example.com, e un sottodominio come shop.example.com può avere il proprio certificato, il proprio emittente e i propri problemi.

Sembra ovvio, ma è qui che molti controlli vanno storti. Un visitatore può atterrare su un reindirizzamento, un alias di marketing o un sottodominio di paese, e il certificato deve solo corrispondere all'host che il browser vede effettivamente.

Digita l'URL completo con attenzione. Se il sito utilizza sia www che non-www, testali entrambi. Se stai controllando un'area di accesso o un host API, verifica anche quel nome host esatto, perché un host può essere a posto mentre un altro fallisce.

Questo è ancora più importante su un sito web aziendale con diversi punti di accesso, dove la homepage, l'area di supporto e il dominio dell'app possono comportarsi in modo diverso. Un sottodominio mancante può creare un falso senso di sicurezza.

Una nota veloce: un lucchetto che sembra sicuro su una pagina non prova che l'intera famiglia di domini sia coperta. Prova solo che una risposta su un host ha presentato un certificato.

Ispeziona la catena del certificato, non solo il lucchetto

Il lucchetto è solo il primo indizio. Un browser può mostrare HTTPS mentre la catena di certificati è incompleta, disordinata o ancorata a un emittente di cui il browser non si fida.

Apri i dettagli del certificato nel tuo browser e cerca la catena completa: il certificato del sito, eventuali certificati intermedi e il percorso di fiducia radice. Se manca un intermedio, alcuni browser possono comunque recuperare, ma altri si lamenteranno e alcuni client rifiuteranno la connessione.

Ecco perché controllare se un sito web ha un certificato SSL valido non è una domanda da un clic. Devi vedere cosa invia il server, non solo cosa suggerisce l'icona del lucchetto.

In pratica, una catena incompleta spesso si presenta dopo un rinnovo o una migrazione del server. Il certificato stesso può essere attuale, ma la catena inviata dal server è errata, quindi gli utenti ricevono comunque avvisi.

Utilizza i dettagli del certificato del browser, un controllore SSL o uno strumento da riga di comando se hai accesso. Un sito che funziona in un browser può comunque fallire in un altro se il server omette un certificato intermedio.

Un caso reale: un sito dietro un CDN può presentare un certificato leaf valido all'edge ma una catena rotta su un percorso di origine legacy. Il visitatore vede il problema solo sul percorso meno comune.

Controlla che il certificato corrisponda al nome host

Un certificato deve nominare l'host che il browser sta visitando. I certificati moderni utilizzano il campo SAN, e quella lista è più importante del vecchio campo CN, anche se le persone continuano a dare un'occhiata al CN per primo.

Controlla se le voci SAN includono il dominio e il sottodominio esatti che hai testato. Se il certificato elenca example.com e www.example.com, potrebbe andare bene per entrambi. Se elenca solo example.com, allora www.example.com potrebbe comunque fallire.

Non assumere che i caratteri jolly risolvano tutto. Un carattere jolly come *.example.com di solito copre un'etichetta profonda, quindi shop.example.com potrebbe essere coperto, mentre api.shop.example.com non lo è.

Gli alias sono una trappola comune. Il team di marketing potrebbe promuovere go.example.com, ma il certificato copre solo example.com e www.example.com. La pagina si carica, il lucchetto appare per un momento, e poi il browser genera un errore di nome.

Ecco l'abitudine utile: abbina ciò che gli utenti digitano, cosa reindirizza a cosa e quali sono effettivamente i nomi del certificato. Tre stringhe. Un controllo.

Se gestisci un sito che si basa su diversi domini di accesso, questo è un buon posto per collegare la revisione del certificato con il lavoro sulla sicurezza del sito web. Un disallineamento del certificato non è solo un fastidio per il browser; può interrompere i flussi di accesso, i flussi di pagamento e qualsiasi cosa legata alla fiducia.

Verifica la scadenza e lo stato di rinnovo

Ogni certificato ha una data di inizio e una data di fine. Controlla entrambe. Se il certificato è già scaduto, l'avviso del browser non è un mistero, e se scade domani, è comunque un problema per gli utenti che aprono il sito dopo la mezzanotte.

Guarda la finestra di validità nel visualizzatore di certificati. Alcuni strumenti mostrano “non prima” e “non dopo”. Quelle due righe ti dicono se il certificato è attivo ora e se un rinnovo è già scaduto.

Il rinnovo non è sempre istantaneo. Un sito potrebbe essere nel mezzo di un rollout, con il vecchio certificato ancora visibile su un server e il nuovo su un altro. Questo può creare risultati incoerenti durante una finestra di transizione.

Un breve periodo di scadenza non è di per sé un difetto, ma alza le poste in gioco. Se un'attività di rinnovo automatizzato fallisce una volta, il sito può passare da funzionante a bloccato con pochissimo preavviso.

Tieni a mente la data quando ispezioni un certificato sospetto. Un certificato che scade tra 2 giorni merita un'attenzione più rapida rispetto a uno con mesi rimanenti, perché la soluzione potrebbe semplicemente essere un rinnovo che non si è ancora propagato.

Per i team che già utilizzano una piattaforma di analisi e monitoraggio dei siti web, abbinare i controlli dei certificati con gli avvisi di uptime aiuta a catturare un fallimento di rinnovo prima che lo facciano gli utenti. La tempistica è importante qui, non la teoria.

Cerca problemi di fiducia dall'autorità emittente

Un certificato può essere valido sulla carta e comunque attivare un avviso di fiducia. Questo di solito indica l'autorità di certificazione emittente, la catena di fiducia o un dispositivo che manca del giusto certificato radice.

Apri le informazioni dell'emittente e conferma che la CA è riconosciuta dai browser e dai sistemi operativi moderni. Se l'emittente sembra sconosciuto, o se il certificato è auto-firmato, il browser potrebbe rifiutare la fiducia anche quando HTTPS appare nella barra degli indirizzi.

I certificati auto-firmati sono comuni su strumenti interni, server di test e pagine di amministrazione private. Sono anche una fonte comune di confusione quando qualcuno copia quella stessa configurazione su un sito pubblico.

Gli avvisi del browser valgono la pena di essere letti riga per riga. Un avviso può menzionare un emittente non affidabile. Un altro può menzionare un problema di catena. Un terzo può dire che il certificato non è destinato all'host.

Quei messaggi sono diversi. Trattali in modo diverso.

Se stai controllando un sito pubblico che dovrebbe essere fidato per impostazione predefinita, un avviso del browser significa che il percorso di fiducia è interrotto da qualche parte. Questo può accadere dopo una migrazione gestita male, una cattiva configurazione del proxy o un certificato installato con il pacchetto intermedio sbagliato.

Un'autorità fidata non significa, ovviamente, "contenuto sicuro". Significa solo che il browser accetta il percorso del certificato come legittimo. Questa è un'affermazione più ristretta ed è l'unica affermazione che il certificato può fare.

Test per contenuti misti sulla pagina

Un certificato SSL valido non salva una pagina che continua a caricare risorse non sicure. Il contenuto misto si verifica quando la pagina principale utilizza HTTPS, ma immagini, script, font o frame provengono da URL HTTP.

Apri gli strumenti per sviluppatori e aggiorna la pagina. Cerca avvisi su risorse bloccate o aggiornate. Una pagina può ancora caricarsi visivamente mentre uno script fallisce silenziosamente perché il browser ha bloccato un file non sicuro.

Questo è un problema di sicurezza pratico, non cosmetico. Un singolo script non sicuro può indebolire la protezione che il certificato dovrebbe fornire.

I colpevoli comuni sono vecchi URL di immagini, widget di terze parti, tag di analisi e lettori video incorporati. Un vecchio link HTTP in un modello può contaminare dozzine di pagine.

Se gestisci un portale di contenuti sugli investimenti, questo controllo è ancora più importante perché uno script di grafico rotto o un widget di quotazione possono far sembrare la pagina affidabile mentre falliscono silenziosamente sotto. L'icona del lucchetto non ti racconterà quella storia.

Il contenuto misto aiuta anche a spiegare perché gli utenti a volte segnalano "il sito è sicuro sul mio laptop, ma non sul mio telefono". Il certificato potrebbe essere a posto; le risorse della pagina non lo sono.

Confronta il comportamento su desktop e mobile

Esegui lo stesso controllo su almeno 2 ambienti: un browser desktop e un browser o dispositivo mobile. Un certificato può passare su un desktop moderno e fallire su un telefono più vecchio, specialmente se il trust store è obsoleto.

Quella differenza è importante. Una catena di certificati che sembra accettabile in Chrome su un laptop può comunque attivare un avviso in Safari su un iPhone più vecchio o in un browser con certificati radice obsoleti.

Prova l'host principale e un sottodominio. Se il sito reindirizza da www a non-www, ripeti il test dopo il reindirizzamento. Un fallimento sull'host reindirizzato è comunque un fallimento.

I controlli dei dispositivi rivelano anche stranezze relative ai cookie e alle sessioni. A volte l'avviso del browser appare solo dopo il login, perché viene chiamato un host diverso una volta che l'utente raggiunge un'area sicura.

Semplice è meglio qui. Apri il sito, ispeziona il lucchetto, conferma il nome host e confronta i dettagli del certificato su entrambi i dispositivi. Cinque minuti possono risparmiare un ticket di supporto in seguito.

I team che già dipendono dal supporto del sito web dopo il lancio conoscono bene questo schema: il rapporto del browser dal cliente è raramente lo stesso del risultato dalla macchina dello sviluppatore.

Sapere quando escalare al proprietario del sito o al fornitore di hosting

Escalare quando il certificato è scaduto, il nome host non corrisponde, la catena è interrotta o il browser mostra un avviso di fiducia che non puoi spiegare con le impostazioni locali del dispositivo. Questi non sono risultati da "forse più tardi".

Quando segnali il problema, includi l'host esatto, il timestamp, il nome del browser, l'errore visibile e uno screenshot dei dettagli del certificato. Se possibile, includi le voci SAN, il nome dell'emittente e la data di scadenza.

Mantieni il rapporto concreto. Dì “shop.example.com non funziona su iPhone Safari a causa di un disallineamento del nome host” invece di “l'SSL è rotto.” La prima frase fornisce a qualcuno un percorso per risolverlo.

Se gestisci il sito per un cliente, informalo se il problema è su un host o su più host. Questa distinzione può decidere se la soluzione riguarda il DNS, il bilanciatore di carico, il server web o il fornitore del certificato.

I fornitori di hosting spesso hanno bisogno di prove esatte per agire rapidamente. Un reclamo vago può rimbalzare tra i team per un giorno. Uno preciso può essere abbinato a un rinnovo, a un intermediario mancante o a un'implementazione errata in pochi minuti.

Per i team che lavorano su una piattaforma interna o un prodotto pubblico, il passaggio più pulito è quello che include l'host, il tipo di errore e il percorso del browser. Questo è sufficiente per separare un problema di certificato da un problema di pagina, il che salva tutti dal dover indovinare.

Un ultimo controllo aiuta con i casi ostinati: confronta il certificato sul sito live con quello sul server di origine o sull'host di staging, se hai accesso. Un'implementazione disallineata può lasciare un ambiente sistemato e un altro ancora in errore, e il browser si preoccupa solo dell'host che raggiunge.