{"id":101490,"date":"2021-10-01T16:22:46","date_gmt":"2021-10-01T14:22:46","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/sboi-v-openbsd-dragonfly-bsd-i-electron-iz-za-ustarevaniya-kornevogo-sertifikata-identrust"},"modified":"2021-10-01T16:22:46","modified_gmt":"2021-10-01T14:22:46","slug":"sboi-v-openbsd-dragonfly-bsd-i-electron-iz-za-ustarevaniya-kornevogo-sertifikata-identrust","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/sboi-v-openbsd-dragonfly-bsd-i-electron-iz-za-ustarevaniya-kornevogo-sertifikata-identrust","title":{"rendered":"Fallos en OpenBSD, DragonFly BSD y Electron debido a la caducidad del certificado ra\u00edz de IdenTrust","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
La caducidad del certificado ra\u00edz de la empresa IdenTrust (DST Root CA X3), utilizado para la firma cruzada del certificado ra\u00edz de la autoridad certificadora Let’s Encrypt, ha provocado problemas en la verificaci\u00f3n de los certificados de Let’s Encrypt en proyectos que utilizan versiones antiguas de OpenSSL y GnuTLS. Los problemas tambi\u00e9n afectaron a la biblioteca LibreSSL, cuyos desarrolladores no tomaron en cuenta la experiencia previa relacionada con las fallas ocurridas despu\u00e9s de la caducidad del certificado ra\u00edz AddTrust de la autoridad certificadora Sectigo (Comodo). <\/p>\n
Recordemos que en las versiones de OpenSSL hasta la rama 1.0.2 inclusive y en GnuTLS hasta la versi\u00f3n 3.6.14, exist\u00eda un error que imped\u00eda procesar correctamente los certificados firmados cruzadamente en caso de caducidad de uno de los certificados ra\u00edz involucrados en la firma, incluso si hab\u00eda otras cadenas de confianza v\u00e1lidas (en el caso de Let’s Encrypt, la caducidad del certificado ra\u00edz de IdenTrust impide la verificaci\u00f3n, incluso si el sistema tiene soporte para su propio certificado ra\u00edz de Let’s Encrypt, vigente hasta 2030). La esencia del error es que las versiones antiguas de OpenSSL y GnuTLS trataban el certificado como una cadena lineal, mientras que, de acuerdo con el RFC 4158, el certificado puede representar un grafo c\u00edclico distribuido orientado con m\u00faltiples anclas de confianza que deben ser consideradas. <\/p>\n
Como soluci\u00f3n alternativa para resolver el fallo, se sugiere eliminar del almac\u00e9n del sistema (\/etc\/ca-certificates.conf y \/etc\/ssl\/certs) el certificado \u00abDST Root CA X3\u00bb, tras lo cual debe ejecutarse el comando \u00abupdate-ca-certificates -f -v\u00bb. En CentOS y RHEL, se puede a\u00f1adir el certificado \u00abDST Root CA X3\u00bb a la lista negra: trust dump \u2014filter \u00abpkcs11:id=\u00bb | openssl x509 | sudo tee \/etc\/pki\/ca-trust\/source\/blacklist\/DST-Root-CA-X3.pem sudo update-ca-trust extract <\/ul>\n
Algunos de los fallos observados tras la caducidad del certificado ra\u00edz de IdenTrust: <\/p>\n
\n
En OpenBSD dej\u00f3 de funcionar la utilidad syspatch, utilizada para instalar actualizaciones binarias del sistema. El proyecto OpenBSD lanz\u00f3 de emergencia hoy parches para las ramas 6.8 y 6.9, que solucionan problemas en LibreSSL relacionados con la verificaci\u00f3n de certificados cruzados firmados, uno de cuyos certificados ra\u00edz en la cadena de confianza ha expirado. Como soluci\u00f3n temporal, se recomienda cambiar en \/etc\/installurl de HTTPS a HTTP (esto no pone en riesgo la seguridad, ya que las actualizaciones se verifican adicionalmente mediante una firma digital) o elegir un espejo alternativo (ftp.usa.openbsd.org, ftp.hostserver.de, cdn.openbsd.org). Tambi\u00e9n se puede eliminar el certificado ra\u00edz expirado DST Root CA X3 del archivo \/etc\/ssl\/cert.pem.\n
En DragonFly BSD se observan problemas similares al trabajar con DPorts. Al iniciar el gestor de paquetes pkg se produce un error de verificaci\u00f3n del certificado. La soluci\u00f3n se ha a\u00f1adido hoy en las ramas master, DragonFly_RELEASE_6_0 y DragonFly_RELEASE_5_8. Como soluci\u00f3n alternativa, se puede eliminar el certificado DST Root CA X3.\n
Se interrumpi\u00f3 el proceso de verificaci\u00f3n de los certificados de Let’s Encrypt en aplicaciones basadas en la plataforma Electron. El problema se ha resuelto en las actualizaciones 12.2.1, 13.5.1, 14.1.0, 15.1.0.\n
En algunas distribuciones se observan problemas de acceso a los repositorios de paquetes al usar el gestor de paquetes APT, relacionado con versiones antiguas de la biblioteca GnuTLS. Debian 9 se vio afectado, ya que utilizaba un paquete de GnuTLS sin corregir, lo que llev\u00f3 a problemas para acceder a deb.debian.org para los usuarios que no instalaron las actualizaciones a tiempo (la correcci\u00f3n gnutls28-3.5.8-5+deb9u6 se propuso el 17 de septiembre). Como soluci\u00f3n alternativa, se recomienda eliminar DST_Root_CA_X3.crt del archivo \/etc\/ca-certificates.conf.\n
Se ha interrumpido el funcionamiento del acme-client en la distribuci\u00f3n para crear cortafuegos OPNsense; se hab\u00eda informado sobre el problema con antelaci\u00f3n, pero los desarrolladores no pudieron lanzar el parche a tiempo.\n
El problema afectaba al paquete OpenSSL 1.0.2k en RHEL\/CentOS 7, pero hace una semana se lanz\u00f3 una actualizaci\u00f3n del paquete ca-certificates-2021.2.50-72.el7_9.noarch para RHEL 7 y CentOS 7, de la cual se elimin\u00f3 el certificado IdenTrust, es decir, la manifestaci\u00f3n del problema fue bloqueada de antemano. Una actualizaci\u00f3n similar se public\u00f3 hace una semana para Ubuntu 16.04, Ubuntu 14.04, Ubuntu 21.04, Ubuntu 20.04 y Ubuntu 18.04. Dado que las actualizaciones se lanzaron de forma anticipada, el problema con la verificaci\u00f3n de los certificados de Let’s Encrypt afect\u00f3 solo a los usuarios de las versiones antiguas de RHEL\/CentOS y Ubuntu que no instalaban regularmente actualizaciones.\n
Se interrumpi\u00f3 el proceso de verificaci\u00f3n de certificados en grpc.\n
Fallo al compilar la plataforma Cloudflare Pages.\n
Problemas en Amazon Web Services (AWS).\n
Problemas de conexi\u00f3n a la base de datos para los usuarios de DigitalOcean.\n
Fallo en el funcionamiento de la plataforma en la nube Netlify.\n
Problemas de acceso a los servicios de Xero.\n
Fallo al intentar establecer una conexi\u00f3n TLS con el Web API del servicio MailGun.\n
Fallas en las versiones de macOS e iOS (11, 13, 14), que te\u00f3ricamente no deber\u00edan haber sido afectadas por el problema.\n
Fallo en los servicios de Catchpoint.\n
Error de verificaci\u00f3n de certificados al acceder al API de PostMan.\n
Fallo en el funcionamiento de Guardian Firewall.\n
Interrupci\u00f3n en la p\u00e1gina de soporte de monday.com.\n
Fallo en el funcionamiento de la plataforma Cerb.\n
Fallo al verificar el uptime en Google Cloud Monitoring.\n
Problema de verificaci\u00f3n de certificados en Cisco Umbrella Secure Web Gateway.\n
Problemas de conexi\u00f3n con el proxy Bluecoat y Palo Alto.\n
En OVHcloud se presentaron problemas de conexi\u00f3n con OpenStack API.\n
Problemas en la generaci\u00f3n de informes en Shopify.\n
Se observan problemas al acceder al API de Heroku.\n
Fallo en el funcionamiento de Ledger Live Manager.\n
Error de verificaci\u00f3n de certificado en las herramientas para desarrolladores de aplicaciones de Facebook.\n
Problemas en Sophos SG UTM.\n
Problemas de verificaci\u00f3n de certificados en cPanel. <\/ul>\n