Plano ng LetsEncrypt na bawiin ang mga certificate nito dahil sa isang bug ng software

Ang LetsEncrypt, na nag-aalok ng mga libreng SSL certificate para sa pag-encrypt, ay napipilitang bawiin ang ilang mga certificate.

Ang problema ay may kaugnayan sa error sa software sa Boulder control software na ginamit sa pagbuo ng CA. Karaniwan, ang pag-verify ng DNS ng tala ng CAA ay nangyayari nang sabay-sabay sa pagkumpirma ng pagmamay-ari ng domain, at karamihan sa mga subscriber ay tumatanggap ng sertipiko kaagad pagkatapos ng pag-verify, ngunit ginawa ito ng mga developer ng software upang ang resulta ng pag-verify ay maituturing na pasado sa loob ng susunod na 30 araw . Sa ilang mga kaso, posibleng suriin ang mga tala sa pangalawang pagkakataon bago lang maibigay ang certificate, partikular na ang CAA ay kailangang muling i-verify sa loob ng 8 oras bago ang pag-isyu, kaya ang anumang domain na na-verify bago ang panahong ito ay dapat na muling ma-verify.

Ano ang pagkakamali? Kung ang isang kahilingan sa certificate ay naglalaman ng N domain na nangangailangan ng paulit-ulit na pag-verify ng CAA, pipili si Boulder ng isa sa mga ito at ibe-verify ito ng N beses. Bilang resulta, posibleng mag-isyu ng certificate kahit na sa ibang pagkakataon (hanggang X+30 araw) ay nagtakda ka ng CAA record na nagbabawal sa pag-isyu ng LetsEncrypt certificate.

Upang i-verify ang mga sertipiko, naghanda ang kumpanya online na toolna magpapakita ng isang detalyadong ulat.

Magagawa ng mga advanced na user ang lahat gamit ang mga sumusunod na command:

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

Susunod na kailangan mong tumingin dito iyong serial number, at kung ito ay nasa listahan, inirerekumenda na i-renew ang (mga) sertipiko.

Upang i-update ang mga certificate, maaari mong gamitin ang certbot:

certbot renew --force-renewal

Ang problema ay natagpuan noong Pebrero 29, 2020; upang malutas ang problema, ang pagpapalabas ng mga sertipiko ay sinuspinde mula 3:10 UTC hanggang 5:22 UTC. Ayon sa panloob na pagsisiyasat, ang pagkakamali ay ginawa noong Hulyo 25, 2019; ang kumpanya ay magbibigay ng mas detalyadong ulat sa ibang pagkakataon.

UPD: ang online na serbisyo sa pag-verify ng sertipiko ay maaaring hindi gumana mula sa mga IP address ng Russian.

Pinagmulan: www.habr.com