ERR_CERT_DATE_INVALID: certificato scaduto o orologio sbagliato

Cosa significa ERR_CERT_DATE_INVALID

Ogni certificato TLS porta due timestamp, "Valid from" e "Valid to" (i campi X.509 notBefore e notAfter). Durante l'handshake, il browser confronta quei timestamp con la propria idea dell'ora corrente. Se la finestra del certificato si è chiusa, o non si è ancora aperta, o l'orologio del browser colloca "adesso" fuori da quella finestra per qualunque motivo, l'handshake si ferma prima ancora che il browser arrivi a controllare chi ha emesso il certificato. Chrome ed Edge mostrano NET::ERR_CERT_DATE_INVALID. Firefox mostra SEC_ERROR_EXPIRED_CERTIFICATE per il caso di scadenza. Safari mostra "This certificate has expired" o "This certificate is not yet valid."

Due situazioni distinte producono l'identico avviso, e il browser non può dirti quale delle due sia: il certificato è davvero scaduto o non ancora valido, oppure il certificato va bene e l'orologio del client è sbagliato. Entrambi falliscono lo stesso confronto.

Come appare l'errore

Nel browser, la pagina non si carica mai e compare un avviso a tutta scheda invece di un'icona di errore sul lucchetto su una pagina altrimenti caricata. Cliccare su "Avanzate" mostra il motivo specifico e, in Chrome, le date stesse del certificato.

Dalla riga di comando, curl riporta lo stesso fallimento con più precisione:

curl -v https://example.com/
...
* SSL certificate problem: certificate has expired
* Closing connection

Un certificato non ancora valido produce una riga simile che recita "certificate is not yet valid." I log del server e dell'applicazione dal lato di chi gestisce il sito di solito non mostrano assolutamente nulla per questo errore, perché l'handshake TLS fallisce prima che venga registrata qualunque richiesta HTTP. La prova sta nel certificato e nel client, non nel log di accesso del web server.

Cosa causa ERR_CERT_DATE_INVALID

• Il certificato è scaduto. Il rinnovo non è avvenuto prima della data "Valid to", il più delle volte perché un job di rinnovo automatico si è fermato silenziosamente.
• Il certificato non è ancora valido. Meno comune: un certificato è stato emesso o riemesso con una data "Valid from" leggermente nel futuro, oppure un server ha iniziato a servire un nuovo certificato prima che la sua finestra si aprisse.
• Un certificato intermedio nella catena è scaduto. Il certificato foglia può essere perfettamente attuale mentre un intermedio che il server continua a inviare ha superato la propria scadenza, e alcuni client controllano ogni certificato nella catena.
• L'orologio del dispositivo del visitatore è sbagliato. Un portatile spento da mesi, un telefono con la sincronizzazione automatica dell'ora disattivata, o un dispositivo con una batteria CMOS scarica possono avviarsi con una data sbagliata di anni in entrambe le direzioni.
• Una macchina virtuale o un container con un orologio non aggiornato. Le VM che sono state salvate come snapshot, clonate, o riprese dopo una lunga pausa spesso si avviano con un orologio che non si è aggiornato finché non si completa una sincronizzazione NTP.
• Un fuso orario mal configurato o una data manuale errata impostata da un utente o da un dispositivo tipo chiosco che non ha una propria fonte di tempo.

Come capire di chi è la colpa

Il modo più veloce per distinguere è controllare il certificato da un posto diverso dal dispositivo interessato. Se un secondo dispositivo con un orologio noto come corretto, o un punto di controllo fuori dalla tua rete, carica il sito senza un avviso sulla data, il certificato va bene e il problema è locale all'orologio di quel dispositivo. Se ogni punto di osservazione riporta la stessa data scaduta o non ancora valida, è il certificato stesso a richiedere attenzione. Eseguire un controllo SSL da più postazioni contemporaneamente risolve la questione in un solo passaggio invece di prendere in prestito un secondo portatile per fare il test.

Come correggere ERR_CERT_DATE_INVALID

Se sei un visitatore

1. Controlla prima data, ora e fuso orario del tuo dispositivo. Questa è di gran lunga la causa autoinflitta più comune, specialmente su dispositivi Android con la sincronizzazione automatica dell'ora disattivata, portatili vecchi rimasti inutilizzati, e macchine con una batteria CMOS che si sta esaurendo. Attiva "Imposta l'ora automaticamente" e conferma che l'anno sia corretto, non solo il quadrante dell'orologio.
2. Prova il sito su un dispositivo o una rete diversi. Se si carica correttamente altrove, l'orologio del tuo dispositivo originale (o un captive portal che intercetta la connessione) è la causa, non il sito.
3. Leggi le date effettive sulla pagina di avviso prima di fare qualunque altra cosa. Il pannello "Avanzate" di Chrome e il visualizzatore del certificato mostrano entrambi "Valid from" e "Valid to" in chiaro, il che ti dice immediatamente se il certificato è scaduto, non ancora valido, o se è il tuo orologio l'anomalia.
4. Non procedere su un certificato che è davvero scaduto su un sito che gestisce qualcosa di sensibile. Una volta corretto l'orologio, ricarica; non riprovare semplicemente lo stesso stato rotto.

Se gestisci il sito

1. Leggi le date effettive del certificato direttamente invece di fidarti di un promemoria sul calendario:

   openssl s_client -connect example.com:443 -servername example.com /dev/null   | openssl x509 -noout -dates

   Questo stampa notBefore e notAfter direttamente dal certificato che il server sta effettivamente presentando in questo momento.
2. Se usi Let's Encrypt, controlla il job di rinnovo, non solo il certificato. I certificati Let's Encrypt durano 90 giorni per progettazione e si rinnovano automaticamente intorno al trentesimo giorno, ma l'automazione può fallire silenziosamente per settimane prima che qualcuno se ne accorga: systemctl status certbot.timer (o l'equivalente voce cron) conferma che il timer sia ancora attivo e in esecuzione, e certbot renew --dry-run esercita il percorso di rinnovo senza cambiare nulla in produzione. Leggi /var/log/letsencrypt/letsencrypt.log per il fallimento effettivo, che è quasi sempre uno tra: una sfida DNS-01 le cui credenziali API sono scadute, una modifica al firewall che blocca il percorso della sfida HTTP-01, o i limiti di frequenza di Let's Encrypt superati durante ripetuti tentativi di risoluzione dei problemi.
3. Controlla l'intera catena che il tuo server invia, non solo il certificato foglia:

   openssl s_client -connect example.com:443 -servername example.com -showcerts /dev/null   | openssl x509 -noout -dates -in -

   Alcuni server continuano a servire un vecchio certificato intermedio dal disco dopo aver sostituito il foglia. Ogni certificato nella catena ha bisogno di una finestra di validità attuale, dato che alcuni client convalidano l'intero percorso.
4. Verifica l'orologio di sistema del server stesso. Un server con l'ora sbagliata può emettere rinnovi automatici con una data "Valid from" errata, e può anche fallire la propria convalida OCSP e dell'handshake indipendentemente dal certificato. Conferma che NTP sia in esecuzione e sincronizzato.
5. Rinnova o riemetti il certificato, poi ricarica il web server. Un certificato rinnovato sul disco non fa nulla finché il processo che serve il TLS non lo raccoglie: nginx -s reload, systemctl reload apache2, o l'equivalente per un load balancer o un edge CDN che tiene una propria copia.
6. Conferma la correzione dall'esterno della tua infrastruttura dopo il reload, dato che un browser o un sistema operativo sulla tua macchina potrebbero mettere in cache il vecchio certificato per una sessione.

Come prevenire ERR_CERT_DATE_INVALID

Un certificato in scadenza non dà alcun avviso a chi non lo sta specificamente monitorando: il sito continua a funzionare fino all'esatto secondo in cui la finestra si chiude, poi ogni visitatore vede lo stesso avviso contemporaneamente. Un controllo SSL pianificato che legge le date del certificato e avvisa prima della scadenza, invece che dopo che i visitatori iniziano a segnalare un sito rotto, trasforma un fallimento silenzioso del rinnovo in un ticket risolvibile con giorni di anticipo. I controlli SSL e di scadenza del dominio di HostTracker tracciano la finestra di validità effettiva del certificato dall'esterno della tua infrastruttura e avvisano via email, SMS, chiamata vocale, Slack, Telegram e altro prima che scada; esegui subito un controllo con il controllo del certificato SSL. La guida di accompagnamento su come verificare la scadenza del certificato SSL tratta come impostare tutto ciò in maggiore dettaglio.

Errori correlati

• ERR_CERT_AUTHORITY_INVALID - le date del certificato vanno bene, ma il browser non si fida di chi lo ha emesso.
• ERR_CERT_COMMON_NAME_INVALID - il certificato è valido e affidabile, ma non è stato emesso per l'hostname nella barra degli indirizzi.
• ERR_SSL_PROTOCOL_ERROR - l'handshake è fallito prima ancora di raggiungere qualunque certificato, di solito un mismatch di versione TLS, porta, o configurazione.

Domande frequenti

È sicuro procedere oltre un avviso ERR_CERT_DATE_INVALID?

Solo se sei certo che la causa sia l'orologio del tuo stesso dispositivo, dato che puoi verificarlo in modo indipendente. Se il certificato stesso è davvero scaduto, procedere oltre elimina l'unico controllo che conferma che stai parlando con il server reale attraverso un canale cifrato e verificato.

Perché questo succede subito dopo aver ripristinato o disimballato un dispositivo?

Un ripristino di fabbrica o un dispositivo rimasto a lungo inutilizzato spesso si avvia con l'orologio interno riportato a una data predefinita, a volte anni nel passato. Finché non si connette a internet e sincronizza l'ora automaticamente, ogni sito HTTPS può fallire con un errore di data, non solo uno.

Cancellare la cache del browser corregge ERR_CERT_DATE_INVALID?

Raramente. Questo errore è un confronto in tempo reale tra le date del certificato e l'orologio corrente, valutato di nuovo a ogni connessione, quindi una cancellazione della cache non cambia il risultato. Correggere l'orologio o il certificato sì.

Perché il mio certificato Let's Encrypt è scaduto senza alcun avviso?

Perché il rinnovo è pensato per essere completamente automatico, nessuno lo controlla manualmente, quindi un job cron rotto, una credenziale API DNS scaduta, o una regola firewall modificata possono fermare silenziosamente i rinnovi per settimane senza alcun sintomo visibile finché il certificato non scade davvero.

Una CDN o un load balancer possono cambiare cosa vedono i visitatori per questo errore?

Sì. Se l'edge della CDN tiene un certificato scaduto, ogni visitatore vede l'errore indipendentemente dal certificato che ha il server di origine, quindi controlla qualunque livello stia effettivamente terminando il TLS per la richiesta che è fallita.

Con che frequenza dovrei controllare la data di scadenza del mio certificato?

Un controllo automatico giornaliero è sufficiente per cogliere un fallimento del rinnovo con settimane di anticipo, dato che i certificati Let's Encrypt sono validi per 90 giorni e la maggior parte degli altri certificati dura da 90 giorni a un anno.