LetsEncrypt prevede di revocare i propri certificati a causa di un errore software

L'azienda LetsEncrypt, che offre certificati ssl gratuiti per la crittografia, è costretta ad annullare alcuni certificati.

Il problema è legato a un errore software nel software di gestione Boulder, utilizzato per costruire CA. Di solito, il controllo del record DNS CAA avviene contemporaneamente alla verifica della proprietà del dominio, e la maggior parte dei sottoscrittori riceve il certificato immediatamente dopo la verifica, ma gli sviluppatori del software hanno progettato il sistema in modo che il risultato della verifica venga considerato superato per i successivi 30 giorni. In alcuni casi, è possibile eseguire una verifica dei record una seconda volta, direttamente prima dell'emissione del certificato; in particolare, è necessaria una nuova verifica CAA entro 8 ore dall'emissione, quindi qualsiasi dominio verificato prima di questo periodo deve essere ricontrollato.

Qual è l'errore? Se la richiesta per un certificato contiene N domini che richiedono una nuova verifica CAA, Boulder ne selezionava uno e lo verificava N volte. Di conseguenza, c'era la possibilità di emettere un certificato, anche se successivamente (fino a X+30 giorni) veniva impostato un record CAA che vietava l'emissione del certificato LetsEncrypt.

Per controllare i certificati, l'azienda ha preparato uno strumento online, che mostrerà un rapporto dettagliato.

Gli utenti avanzati possono fare tutto autonomamente utilizzando i seguenti comandi:

# проверка https
openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | grep -A 1 Serial Number | tr -d :
# вариант проверки от @simpleadmin 
echo | openssl s_client -connect example.com:443 |& openssl x509 -noout -serial
# проверка почтового сервера, протокол SMTP
openssl s_client -connect example.com:25 -starttls smtp -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | grep -A 1 Serial Number | tr -d :
# проверка почтового сервера, протокол SMTP
openssl s_client -connect example.com:587 -starttls smtp -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | grep -A 1 Serial Number | tr -d :
# проверка почтового сервера, протокол IMAP
openssl s_client -connect example.com:143 -starttls imap -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | grep -A 1 Serial Number | tr -d :
# проверка почтового сервера, протокол IMAP
openssl s_client -connect example.com:993 -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | grep -A 1 Serial Number | tr -d :
# в принципе аналогично проверяются и другие сервисы

Successivamente, è necessario controllare qui il proprio numero di serie, e se è nell'elenco, si consiglia di aggiornare il/i certificato/i.

Per aggiornare i certificati, è possibile utilizzare certbot:

certbot renew --force-renewal

Il problema è stato trovato il 29 febbraio 2020, per risolvere il problema è stata sospesa l'emissione di certificati dalle 3:10 UTC alle 5:22 UTC. Secondo un'inchiesta interna, l'errore è stato introdotto il 25 luglio 2019; l'azienda fornirà un report più dettagliato in seguito.

UPD: il servizio online di verifica dei certificati potrebbe non funzionare con indirizzi IP russi.

Fonte: habr.com