LetsEncrypt planuje wycofać swoje certyfikaty z powodu błędu w oprogramowaniu

Firma LetsEncrypt, oferująca bezpłatne certyfikaty SSL do szyfrowania, jest zmuszona unieważnić niektóre certyfikaty.

Problem dotyczy błędu programowego w oprogramowaniu Boulder, wykorzystywanym do budowy CA. Zwykle weryfikacja rekordu DNS CAA odbywa się jednocześnie z potwierdzeniem własności domeny, a większość subskrybentów otrzymuje certyfikat natychmiast po weryfikacji, jednak programiści oprogramowania skonstruowali to tak, że wynik weryfikacji uznawany jest za pozytywny przez następne 30 dni. W niektórych przypadkach można przeprowadzać weryfikację rekordów ponownie, bezpośrednio przed wydaniem certyfikatu, szczególnie wymagana jest powtórna weryfikacja CAA w ciągu 8 godzin przed wydaniem, dlatego każda domena, która była weryfikowana przed tym terminem, musi być sprawdzona ponownie.

Na czym polega błąd? Jeśli żądanie certyfikatu zawiera N domen wymagających ponownej weryfikacji CAA — Boulder wybierał jedną z nich i sprawdzał ją N razy. W rezultacie istniała możliwość wydania certyfikatu, nawet jeśli później (przed X+30 dniami) ustawiono rekord CAA, który zabraniał wydania certyfikatu LetsEncrypt.

Do weryfikacji certyfikatów firma przygotowała narzędzie online, które pokaże szczegółowy raport.

Zaawansowani użytkownicy mogą zrobić wszystko sami, używając poniższych poleceń:

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

Następnie należy sprawdzić tutaj swój numer seryjny, a jeśli jest na liście — zaleca się zaktualizować certyfikaty.

Do aktualizacji certyfikatów można użyć certbota:

certbot renew --force-renewal

Problem został wykryty jeszcze 29 lutego 2020 roku, a w celu rozwiązania problemu wstrzymano wydawanie certyfikatów od 3:10 UTC do 5:22 UTC. Zgodnie z wewnętrznym śledztwem błąd został wprowadzony 25 lipca 2019 roku, a bardziej szczegółowy raport firma przedstawi później.

UPD: usługa online do weryfikacji certyfikatów może nie działać z rosyjskich adresów IP.

Źródło: habr.com