Come verificare che il tuo certificato SSL funzioni dall’esterno

Anche dopo aver configurato un certificato SSL/TLS sul web server, possono sorgere dubbi sulla corretta fruizione del sito da parte degli utenti esterni: i visitatori visualizzeranno l'icona del lucchetto o un avviso di sicurezza lato browser?

In breve: Per verificare che un certificato SSL/TLS funzioni correttamente, è necessario testare il nome di dominio pubblico dall'esterno dell'infrastruttura, utilizzando sia un browser in modalità incognito che strumenti di analisi remota come SSL Labs. La validazione si articola su quattro controlli essenziali: la validità della catena di certificazione, la corrispondenza esatta tra l'Hostname e il Common Name (o Subject Alternative Name), la data di scadenza e la raggiungibilità della porta 443 da parte dei client esterni.

La verifica di un certificato SSL/TLS non deve basarsi unicamente sullo stato dei servizi locali del server, ma su ciò che viene effettivamente negoziato dal client durante il TLS Handshake.

Perché effettuare la verifica del protocollo HTTPS dall'esterno della rete?

Interrogare lo stato del web server dall'interno dell'host (ad esempio tramite curl su 127.0.0.1) non garantisce che i client remoti riescano a instaurare una connessione cifrata corretta.

Il corretto funzionamento del protocollo HTTPS dipende dall'allineamento di molteplici elementi dell'infrastruttura di rete:

• Risoluzione DNS: Il record DNS A/AAAA deve instradare il traffico verso l'indirizzo IP pubblico corretto.
• Accessibilità di rete: Il server deve accettare le connessioni sulla porta 443 (HTTPS) attraverso il Cloud Firewall e il Server Firewall locale.
• Integrità del certificato: Il certificato SSL/TLS deve essere valido e non superare la data di scadenza.
• Corrispondenza dell'Hostname: Il certificato deve includere espressamente il nome di dominio visitato nel campo Common Name (CN) o tra i Subject Alternative Names (SAN).
• Catena di Certificazione (Certificate Chain): Il browser deve poter ricostruire la catena di fiducia dall'entità finale (End-Entity Certificate) fino alla Certification Authority (CA) Radice tramite i certificati intermedi (Intermediate Certificates).

La presenza di un disallineamento anche in uno solo di questi componenti compromette la fruizione dell'applicazione web per l'utente finale.

Per le fasi propedeutiche di configurazione, fa' riferimento alle nostre guide su come collegare un dominio al tuo server e su come ottenere HTTPS gratis sul tuo server.

Procedura operativa per la verifica del certificato SSL/TLS

Per effettuare una verifica completa, occorre simulare il percorso di connessione di un utente esterno:

1. Test tramite Browser in modalità Incognito:

Accedere all'URL pubblico https://yourdomain.com da una finestra privata o da un endpoint esterno alla rete locale (es. da rete mobile) per evitare l'interferenza della cache del browser o del resolver DNS locale. Cliccando sull'icona di sicurezza accanto alla barra degli indirizzi, ispezionare i dettagli del certificato per confermarne la validità, l'emittente e la finestra temporale.

2. Analisi mediante Tool di Scansione Esterni:

Utilizzare uno strumento di analisi approfondita come Qualys SSL Labs (SSL Server Test). Inserire il Fully Qualified Domain Name (FQDN) per eseguire un'ispezione completa delle suite di cifratura (Cipher Suites), della versione del protocollo (TLS 1.2, TLS 1.3), dell'eventuale presenza di certificati intermedi mancanti (Incomplete Chain) e delle vulnerabilità note del server.

3. Verifica analitica per ciascun Hostname e Sottodominio:

Il test va ripetuto esplicitamente per ogni FQDN associato al servizio:

• example.com - www.example.com - subdomain.example.com

I certificati SSL standard coprono esclusivamente l'Hostname per il quale sono stati emessi; la copertura di più sottodomini richiede un certificato Multi-Domain (SAN) o un certificato Wildcard (*.example.com).

Diagnosi degli errori HTTPS e codici del browser

Gli avvisi generati dai browser indicano cause precise di malfunzionamento durante la negoziazione TLS:

• NET::ERR_CERT_DATE_INVALID: Il certificato è scaduto o non è ancora entrato nella finestra di validità. Indica solitamente il fallimento del processo di rinnovo automatico del certificato (es. via Certbot).
• NET::ERR_CERT_COMMON_NAME_INVALID / SSL_ERROR_BAD_CERT_DOMAIN: L'Hostname inserito nella barra degli indirizzi non corrisponde ad alcun nome (CN o SAN) presente nel certificato presentato dal server.
• Your connection is not private (La connessione non è privata): Errore generico che segnala l'impossibilità di validare la catena di fiducia, la presenza di un certificato Self-Signed non riconosciuto o un'incompatibilità nel protocollo TLS.

Se la connessione restituisce un timeout invece di un avviso sul certificato, l'anomalia è solitamente imputabile a regole di firewalling o al mancato binding del web server sulla porta 443. Consulta la guida su perché il mio sito non si carica per l'analisi dei diversi livelli di rete.

Cause di discrepanza nella validazione (Funzionamento asimmetrico)

Se il sito web risulta accessibile tramite HTTPS ad alcuni utenti ma restituisce errori ad altri, le cause principali includono:

• Propagazione e Caching DNS: Presenza di record DNS obsoleti memorizzati nei resolver locali di alcuni client, che indirizzano il traffico verso un server non aggiornato o dismesso.
• Configurazione parziale degli Hostname: Assenza del certificato per una specifica variante del dominio (ad esempio, presenza del certificato per example.com ma assenza per www.example.com).
• Conflitti Server Name Indication (SNI): Errore nella gestione del Virtual Hosting sul web server (NGINX, Apache) quando più domini condividono il medesimo indirizzo IP pubblico. In assenza di una corretta mappatura SNI, il server può presentare il certificato del dominio predefinito anziché quello richiesto dal client. Per approfondire la gestione di più applicazioni, consulta la guida su come ospitare più siti web su un server.

FAQ

Qual è la differenza tra SSL e TLS? SSL (Secure Sockets Layer) è il protocollo di cifratura oramai obsoleto e deprecato. TLS (Transport Layer Security) è il suo successore moderno. Il termine "certificato SSL" rimane in uso commerciale, ma le connessioni cifrate attuali utilizzano le specifiche TLS 1.2 o TLS 1.3.

La verifica HTTPS deve essere effettuata sull'indirizzo IP o sul nome di dominio? Esclusivamente sul nome di dominio (FQDN). I certificati di cifratura pubblicamente riconosciuti vengono emessi e convalidati per nomi di dominio e non per indirizzi IP individuali.

La presenza del lucchetto nel browser garantisce l'assenza di altri problemi? Garantisce che il canale di comunicazione attuale è cifrato e che il certificato è valido per quel specifico FQDN. È comunque opportuno verificare la scadenza temporale e la corretta configurazione di tutti i sottodomini o reindirizzamenti.

Con quale frequenza è consigliabile testare i certificati SSL/TLS? La verifica va effettuata a seguito di modifiche ai record DNS, migrazioni di hosting, aggiornamenti delle configurazioni del web server e prima dei rilasci in produzione, verificando periodicamente il corretto funzionamento dei job di rinnovo automatico.

La soluzione intermedia

Server Manager centralizza il tracciamento dei certificati SSL/TLS, la gestione dei domini e l'associazione dei Virtual Host in una singola interfaccia.

L'adozione di una dashboard di controllo elimina le incertezze legate alle scadenze dei certificati, previene gli errori di configurazione del protocollo SNI e garantisce visibilità immediata sul livello di sicurezza applicato a ciascun dominio ospitato.

La configurazione del protocollo HTTPS si considera corretta quando le chiamate dirette all'Hostname pubblico completano il TLS Handshake senza avvisi, il certificato copre tutti i domini gestiti, la catena di certificazione è completa e i test esterni confermano la validità della configurazione.