LetsEncrypt is van plan zijn certificaten in te trekken vanwege een softwarefout.

Het bedrijf LetsEncrypt, dat gratis SSL-certificaten voor encryptie aanbiedt, is gedwongen enkele certificaten te annuleren.

Het probleem is gerelateerd aan een softwarefout in de beheerdersoftware Boulder, die wordt gebruikt voor het opzetten van de CA. Gewoonlijk vindt de controle van het DNS CAA-record gelijktijdig plaats met de bevestiging van het domeinvinderschap, en de meeste abonnees ontvangen het certificaat onmiddellijk na de controle. De softwareontwikkelaars hebben echter zo geprogrammeerd dat het resultaat van de controle als geslaagd wordt beschouwd voor de komende 30 dagen. In sommige gevallen kan de controle opnieuw worden uitgevoerd, vlak voor de uitgifte van het certificaat, in het bijzonder is een hercontrole van de CAA binnen 8 uur voor de uitgifte vereist, waardoor elk domein dat eerder is gecontroleerd binnen deze termijn opnieuw moet worden gecontroleerd.

Wat is de fout? Als het verzoek om certificaat N domeinen bevat die een hercontrole van de CAA vereisen, selecteerde Boulder er een van en controleerde deze N keer. Als gevolg hiervan was het mogelijk om een certificaat uit te geven, zelfs als later (tot X+30 dagen) een CAA-record werd ingesteld dat de uitgifte van LetsEncrypt-certificaten verbood.

Voor de controle van certificaten heeft het bedrijf een online tool, die een gedetailleerd rapport toont.

Geavanceerde gebruikers kunnen alles zelf doen met de volgende commando's:

# проверка 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 :
# в принципе аналогично проверяются и другие сервисы

Daarna moet je kijken naar je hier serienummer, en als deze in de lijst staat, wordt aanbevolen om het certificaat(aten) bij te werken.

Voor het bijwerken van certificaten kan certbot worden gebruikt:

certbot renew --force-renewal

Het probleem werd op 29 februari 2020 ontdekt, en om het probleem op te lossen werd de uitgifte van certificaten stopgezet van 3:10 UTC tot 5:22 UTC. Uit intern onderzoek bleek dat de fout op 25 juli 2019 was geïntroduceerd. Het bedrijf zal later een gedetailleerd rapport verstrekken.

UPD: de online certificaatcontroledienst werkt mogelijk niet met Russische IP-adressen.

Bron: habr.com