La desactivació del certificat arrel d'AddTrust provoca errors als sistemes OpenSSL i GnuTLS

El 30 de maig va expirar el període de validesa de 20 anys del certificat arrel AddTrustQue aplicat per generar certificats de signatura creuada d'una de les autoritats de certificació més grans Sectigo (Comodo). La signatura creuada permetia la compatibilitat amb dispositius heretats que no tenien el nou certificat arrel USERTRust afegit al seu magatzem de certificats arrel.

La desactivació del certificat arrel d'AddTrust provoca errors als sistemes OpenSSL i GnuTLS

Teòricament, la terminació del certificat arrel AddTrust només hauria de comportar una violació de la compatibilitat amb sistemes heretats (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9, etc.), ja que el segon certificat arrel utilitzat en la signatura creuada es manté. navegadors vàlids i moderns ho tenen en compte a l'hora de comprovar la cadena de confiança. A la pràctica va aparèixer Problemes amb la verificació de signatures creuades en clients TLS que no són de navegador, inclosos els basats en OpenSSL 1.0.x i GnuTLS. Ja no s'estableix una connexió segura amb un error que indica que el certificat està obsolet si el servidor utilitza un certificat Sectigo enllaçat per una cadena de confiança al certificat arrel AddTrust.

Si els usuaris dels navegadors moderns no es van adonar de l'obsolescència del certificat arrel AddTrust en processar certificats Sectigo amb signatura creuada, els problemes van començar a aparèixer en diverses aplicacions de tercers i gestors del costat del servidor, cosa que va provocar violació treballar moltes infraestructures que utilitzen canals de comunicació xifrats per a la interacció entre components.

Per exemple, n'hi havia problemes amb accés a alguns repositoris de paquets a Debian i Ubuntu (apt va començar a generar un error de verificació del certificat), les sol·licituds dels scripts que utilitzaven les utilitats "curl" i "wget" van començar a fallar, es van observar errors en utilitzar Git, violat La plataforma de transmissió Roku funciona, ja no es truca als gestors Raya и DataDog, va començar es produeixen accidents a les aplicacions Heroku, aturat Els clients OpenLDAP es connecten, es detecten problemes amb l'enviament de correu a servidors SMTPS i SMTP amb STARTTLS. A més, s'observen problemes en diversos scripts Ruby, PHP i Python que utilitzen un mòdul amb un client http. Problema del navegador afecta Epiphany, que va deixar de carregar llistes de bloqueig d'anuncis.

Els programes Go no es veuen afectats per aquest problema perquè Go ofereix implementació pròpia TLS.

Es va suposarque el problema afecta versions de distribució anteriors (incloent-hi Debian 9, Ubuntu 16.04, RHEL 6/7) que utilitzen branques OpenSSL problemàtiques, però el problema es va manifestar també quan el gestor de paquets APT s'executa a les versions actuals de Debian 10 i Ubuntu 18.04/20.04, ja que APT utilitza la biblioteca GnuTLS. El quid del problema és que moltes biblioteques TLS/SSL analitzen un certificat com una cadena lineal, mentre que segons RFC 4158, un certificat pot representar un gràfic circular distribuït dirigit amb múltiples ancoratges de confiança que cal tenir en compte. Sobre aquest defecte a OpenSSL i GnuTLS era conegut durant molts anys. A OpenSSL, el problema es va solucionar a la branca 1.1.1 i a GnuTLS roman sense corregir.

Com a solució alternativa, es recomana eliminar el certificat "AddTrust External CA Root" del magatzem del sistema (per exemple, eliminar de /etc/ca-certificates.conf i /etc/ssl/certs i, a continuació, executar "update-ca -certificates -f -v"), després del qual OpenSSL comença a processar normalment certificats amb signatura creuada amb la seva participació. Quan utilitzeu el gestor de paquets APT, podeu desactivar la verificació del certificat per a sol·licituds individuals sota el vostre propi risc (per exemple, "apt-get update -o Acquire::https::download.jitsi.org::Verify-Peer=false") .

Per bloquejar el problema Fedora и RHEL Es proposa afegir el certificat AddTrust a la llista negra:

trust dump —filter «pkcs11:id=%AD%BD%98%7A%34%B4%26%F7%FA%C4%26%54%EF%03%BD%E0%24%CB%54%1A;type=cert» \
> /etc/pki/ca-trust/source/blacklist/addtrust-external-root.p11-kit
extracte update-ca-trust

Però aquest mètode no funciona per a GnuTLS (per exemple, un error de verificació del certificat continua apareixent quan s'executa la utilitat wget).

Al costat del servidor, podeu canviar l'ordre llistant els certificats de la cadena de confiança enviada pel servidor al client (si el certificat associat amb "AddTrust External CA Root" s'elimina de la llista, la verificació del client serà correcta). Per comprovar i generar una nova cadena de confiança, podeu utilitzar el servei whatsmychaincert.com. Sectigo també proporcionat certificat intermedi alternatiu amb signatura creuada "Serveis de certificats AAA", que serà vàlid fins al 2028 i mantindrà la compatibilitat amb versions anteriors del sistema operatiu.

Addició: problema també apareix en LibreSSL.

Font: opennet.ru

Afegeix comentari