159 30/03/2026 07/04/2026 5 min

Quando un sito o un servizio HTTPS smette di essere raggiungibile, una delle cause più comuni è un certificato SSL scaduto, non rinnovato o installato sul vhost sbagliato. Il sintomo tipico è un avviso del browser, ma in produzione puoi vedere anche errori di handshake, redirect strani tra http e https, oppure API e webhook che falliscono senza messaggi chiari.

La causa non è sempre il certificato in sé: spesso il problema nasce da un rinnovo automatico fallito, da una challenge ACME bloccata da firewall o rewrite, da un dominio puntato al server sbagliato, oppure da una catena intermedia incompleta dopo la sostituzione del file. In ambienti con cPanel, Plesk o FastPanel il rinnovo può essere automatico, ma non è raro trovare un certificato ancora presente nel pannello e già scaduto sul servizio effettivamente esposto.

Se il sito è in produzione, questo va trattato come un incidente: prima si verifica la raggiungibilità reale, poi si identifica il certificato attivo, infine si esegue il rinnovo o la sostituzione con il minimo cambiamento possibile.

Verifiche immediate

  1. Apri il sito da browser in finestra anonima e controlla il messaggio esatto: se compare un errore di certificato, annota il dominio coinvolto e la data di scadenza mostrata. Se il browser non mostra nulla ma il problema è su API o app, prova anche l’endpoint HTTPS diretto.
  2. Dal pannello hosting verifica il certificato associato al dominio: in cPanel vai su SSL/TLS Status o Let’s Encrypt, in Plesk su Siti web e domini → Certificati SSL/TLS, in FastPanel nella sezione dominio/SSL. L’esito atteso è vedere il dominio coperto da un certificato valido e non scaduto.
  3. Se hai accesso SSH, controlla la data di scadenza del certificato servito davvero dal server con questo comando, sostituendo il dominio: 
    echo | openssl s_client -servername esempio.it -connect esempio.it:443 2>/dev/null | openssl x509 -noout -dates -subject -issuer
    L’esito atteso è una data notAfter futura e un subject coerente con il dominio.
  4. Verifica DNS e puntamento: se il dominio risolve su un IP diverso da quello del server che stai controllando, il certificato potrebbe essere corretto ma installato sul nodo sbagliato. Il controllo minimo è un dig o una verifica DNS dal pannello, con esito atteso coerente con l’IP del server.
  5. Controlla se il rinnovo automatico è fallito per blocco ACME: in tal caso spesso trovi log con errori di challenge, porta 80 non raggiungibile, redirect forzato, o limitazioni del provider. L’esito atteso della verifica è un messaggio che indica chiaramente la causa del fallimento.

Soluzione consigliata passo-passo

  1. Preferisci il rinnovo dal pannello, se disponibile. In cPanel cerca la gestione Let’s Encrypt o AutoSSL, seleziona il dominio e lancia il rinnovo. In Plesk usa Rinnova certificato o Installa dal certificato corretto. In FastPanel apri la configurazione del dominio e rigenera o associa il certificato. Dopo l’operazione ricarica il sito e verifica che il lucchetto torni valido.
  2. Se il rinnovo automatico non parte, correggi la causa prima di riprovare. Se la challenge HTTP-01 fallisce, verifica che il dominio risponda in chiaro sulla porta 80 e che non ci siano redirect o regole che blocchino /.well-known/acme-challenge/. Se il server è dietro CDN o proxy, controlla che la verifica ACME raggiunga l’origin corretto. Dopo la correzione, rilancia il rinnovo dal pannello.
  3. Se usi Certbot da terminale, rinnova solo dopo aver verificato il metodo usato. Un comando tipico è: 
    sudo certbot renew --dry-run
    L’esito atteso del dry-run è la conferma che il rinnovo può riuscire. Se il test passa, esegui il rinnovo reale con lo stesso metodo già configurato.
  4. Se il certificato è stato sostituito manualmente, controlla che il virtual host punti al file giusto. Verifica i percorsi del certificato, della chiave privata e della chain nel vhost di Apache, Nginx o nel pannello. Fai prima un backup del file di configurazione prima di cambiare qualcosa. Dopo il reload del web server, ripeti il controllo con openssl s_client per confermare che il certificato servito sia quello nuovo.
  5. Se il problema è la chain incompleta, reinstalla il bundle corretto. Molti browser non accettano un certificato valido ma senza intermedi corretti. In questo caso reinstalla il certificato completo, includendo la catena fornita dall’autorità. Il controllo successivo è la scomparsa degli errori di trust nel browser e l’output corretto di openssl.
  6. Se il dominio usa più servizi, allinea tutti i front-end. Verifica anche mail server, pannello di controllo, sottodomini e proxy inversi: può capitare che il sito principale sia a posto ma webmail, API o pannello espongano ancora un certificato scaduto. L’esito atteso è che ogni hostname risponda con il certificato corretto.

Controlli finali / rollback

  1. Riapri il sito in HTTPS da browser e verifica che non compaiano avvisi. L’esito atteso è il lucchetto valido e nessun errore di certificato sulla pagina principale e sugli endpoint critici.
  2. Ripeti il controllo da terminale con openssl s_client per confermare data di scadenza, subject e issuer. L’esito atteso è un certificato coerente con il dominio e con scadenza futura.
  3. Se hai modificato configurazioni del web server, riavvia o ricarica il servizio solo dopo aver salvato una copia del file originale. Se qualcosa va storto, rollback immediato ripristinando il backup e ricaricando il servizio.
  4. Monitora per qualche ora eventuali rinnovi automatici, log ACME e accessi HTTPS. Se il certificato torna a scadere o il rinnovo fallisce di nuovo, il rollback non è il certificato ma la correzione della causa primaria: challenge, DNS, proxy o mapping del vhost.

Assunzione: il problema riguarda un sito o servizio HTTPS su hosting o server Linux con accesso al pannello o a SSH. Se vuoi, posso trasformare questo articolo in una versione più orientata a cPanel, Plesk o Certbot puro.