LetsEncrypt planas revoki ĝiajn atestilojn pro programara cimo

LetsEncrypt, kiu ofertas senpagajn SSL-atestilojn por ĉifrado, estas devigita revoki iujn atestojn.

La problemo rilatas al eraro de programaro en la Boulder-kontrolprogramaro uzita por konstrui la CA. Tipe, la DNS-konfirmo de la CAA-rekordo okazas samtempe kun la konfirmo de domajna proprieto, kaj plej multaj abonantoj ricevas atestilon tuj post konfirmo, sed la programistoj faris ĝin tiel ke la rezulto de la konfirmo estas konsiderata pasita ene de la sekvaj 30 tagoj. . En iuj kazoj, eblas kontroli rekordojn duan fojon ĵus antaŭ ol la atestilo estas elsendita, precipe la CAA devas esti re-kontrolita ene de 8 horoj antaŭ emisio, do ajna domajno kontrolita antaŭ ĉi tiu periodo devas esti re-kontrolita.

Kio estas la eraro? Se atestilpeto enhavas N domajnojn kiuj postulas ripetan CAA-konfirmon, Boulder elektas unu el ili kaj kontrolas ĝin N fojojn. Rezulte, eblis elsendi atestilon eĉ se vi poste (ĝis X+30 tagoj) starigis CAA-rekordon, kiu malpermesas emision de LetsEncrypt-atestilo.

Por kontroli atestojn, la kompanio preparis interreta ilokiu montros detalan raporton.

Altnivelaj uzantoj povas fari ĉion mem uzante la jenajn komandojn:

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

Poste vi devas rigardi tie via seria numero, kaj se ĝi estas en la listo, oni rekomendas renovigi la atestilon(j)n.

Por ĝisdatigi atestojn, vi povas uzi certbot:

certbot renew --force-renewal

La problemo estis trovita la 29-an de februaro 2020; por solvi la problemon, la emisio de atestiloj estis suspendita de 3:10 UTC ĝis 5:22 UTC. Laŭ la interna enketo, la eraro estis farita la 25-an de julio 2019; la kompanio provizos pli detalan raporton poste.

UPD: la reta atestila konfirmservo eble ne funkcias de rusaj IP-adresoj.

fonto: www.habr.com