{"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\/fr\/blog\/news\/sboi-v-openbsd-dragonfly-bsd-i-electron-iz-za-ustarevaniya-kornevogo-sertifikata-identrust","title":{"rendered":"Pannes dans OpenBSD, DragonFly BSD et Electron dues \u00e0 l'expiration du certificat racine IdenTrust","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
L'expiration du certificat racine de l'entreprise IdenTrust (DST Root CA X3), utilis\u00e9 pour la signature crois\u00e9e du certificat racine de l'autorit\u00e9 de certification Let's Encrypt, a entra\u00een\u00e9 des probl\u00e8mes de v\u00e9rification des certificats Let's Encrypt dans les projets utilisant de anciennes versions d'OpenSSL et de GnuTLS. Les probl\u00e8mes ont \u00e9galement touch\u00e9 la biblioth\u00e8que LibreSSL, dont les d\u00e9veloppeurs n'ont pas tenu compte des exp\u00e9riences pass\u00e9es li\u00e9es aux d\u00e9faillances survenues apr\u00e8s l'expiration du certificat racine AddTrust de l'autorit\u00e9 de certification Sectigo (Comodo). <\/p>\n
Rappelons qu'il y avait un bug dans les versions d'OpenSSL jusqu'\u00e0 la branche 1.0.2 incluse et dans GnuTLS jusqu'\u00e0 la version 3.6.14, qui emp\u00eachait de traiter correctement les certificats sign\u00e9s de mani\u00e8re crois\u00e9e en cas d'expiration de l'un des certificats racines impliqu\u00e9s dans la signature, m\u00eame si d'autres cha\u00eenes de confiance valides \u00e9taient pr\u00e9sentes (dans le cas de Let's Encrypt, l'expiration du certificat racine IdenTrust emp\u00eache la v\u00e9rification, m\u00eame si le syst\u00e8me prend en charge son propre certificat racine Let's Encrypt valable jusqu'en 2030). L'essence du probl\u00e8me r\u00e9side dans le fait que les anciennes versions d'OpenSSL et de GnuTLS traitaient le certificat comme une cha\u00eene lin\u00e9aire, tandis que conform\u00e9ment \u00e0 la RFC 4158, un certificat peut repr\u00e9senter un graphe cyclique dirig\u00e9 distribu\u00e9 avec plusieurs ancres de confiance qui doivent \u00eatre prises en compte. <\/p>\n
En tant que solution de contournement pour r\u00e9soudre le probl\u00e8me, il est propos\u00e9 de supprimer le certificat \u00ab DST Root CA X3 \u00bb du stockage syst\u00e8me (en supprimant les entr\u00e9es de \/etc\/ca-certificates.conf et \/etc\/ssl\/certs), puis d'ex\u00e9cuter la commande \u00ab update-ca-certificates -f -v \u00bb. Dans CentOS et RHEL, vous pouvez ajouter le certificat \u00ab DST Root CA X3 \u00bb \u00e0 la liste noire : trust dump \u2014filter \u00ab pkcs11:id= \u00bb | openssl x509 | sudo tee \/etc\/pki\/ca-trust\/source\/blacklist\/DST-Root-CA-X3.pem sudo update-ca-trust extract <\/ul>\n
Voici quelques exemples de plantages survenus apr\u00e8s l'expiration du certificat racine d'IdenTrust : <\/p>\n
\n
Dans OpenBSD, l'outil syspatch, utilis\u00e9 pour installer des mises \u00e0 jour binaires du syst\u00e8me, a cess\u00e9 de fonctionner. Le projet OpenBSD a de toute urgence publi\u00e9 aujourd'hui des correctifs pour les branches 6.8 et 6.9, corrigeant dans LibreSSL des probl\u00e8mes de v\u00e9rification des certificats sign\u00e9s crois\u00e9s, l'un des certificats racines de la cha\u00eene de confiance \u00e9tant expir\u00e9. Comme solution de contournement, il est recommand\u00e9 de passer de HTTPS \u00e0 HTTP dans \\\/etc\\\/installurl (cela ne menace pas la s\u00e9curit\u00e9, car les mises \u00e0 jour sont v\u00e9rifi\u00e9es par une signature num\u00e9rique) ou de choisir un miroir alternatif (ftp.usa.openbsd.org, ftp.hostserver.de, cdn.openbsd.org). Il est \u00e9galement possible de supprimer le certificat racine expir\u00e9 DST Root CA X3 du fichier \\\/etc\\\/ssl\\\/cert.pem.\n
Dans DragonFly BSD, des probl\u00e8mes similaires se produisent lors de l'utilisation de DPorts. Lors du lancement du gestionnaire de paquets pkg, une erreur de v\u00e9rification de certificat est affich\u00e9e. Le correctif a \u00e9t\u00e9 ajout\u00e9 aujourd'hui aux branches master, DragonFly_RELEASE_6_0 et DragonFly_RELEASE_5_8. Comme solution de contournement, il est possible de supprimer le certificat DST Root CA X3.\n
Le processus de v\u00e9rification des certificats Let's Encrypt est interrompu dans les applications bas\u00e9es sur la plateforme Electron. Le probl\u00e8me a \u00e9t\u00e9 r\u00e9solu dans les mises \u00e0 jour 12.2.1, 13.5.1, 14.1.0, 15.1.0.\n
Certains distributions rencontrent des probl\u00e8mes d'acc\u00e8s aux d\u00e9p\u00f4ts de paquets lors de l'utilisation du gestionnaire de paquets APT, en raison de versions anciennes de la biblioth\u00e8que GnuTLS. Le probl\u00e8me a affect\u00e9 Debian 9, qui utilisait un paquet GnuTLS non corrig\u00e9, entra\u00eenant des probl\u00e8mes d'acc\u00e8s \u00e0 deb.debian.org pour les utilisateurs qui n'avaient pas install\u00e9 les mises \u00e0 jour \u00e0 temps (le correctif gnutls28-3.5.8-5+deb9u6 a \u00e9t\u00e9 propos\u00e9 le 17 septembre). Comme solution de contournement, il est recommand\u00e9 de supprimer DST_Root_CA_X3.crt du fichier \\\/etc\\\/ca-certificates.conf.\n
Le fonctionnement de acme-client dans la distribution pour les pare-feu OPNsense est perturb\u00e9, le probl\u00e8me ayant \u00e9t\u00e9 signal\u00e9 \u00e0 l'avance, mais les d\u00e9veloppeurs n'ont pas pu publier le correctif \u00e0 temps.\n
Le probl\u00e8me concernait le paquet OpenSSL 1.0.2k sur RHEL\/CentOS 7, mais une mise \u00e0 jour du paquet ca-certificates-2021.2.50-72.el7_9.noarch a \u00e9t\u00e9 cr\u00e9\u00e9e il y a une semaine pour RHEL 7 et CentOS 7, retirant le certificat IdenTrust, ce qui a bloqu\u00e9 l'apparition du probl\u00e8me \u00e0 l'avance. Une mise \u00e0 jour similaire a \u00e9t\u00e9 publi\u00e9e il y a une semaine pour Ubuntu 16.04, Ubuntu 14.04, Ubuntu 21.04, Ubuntu 20.04 et Ubuntu 18.04. \u00c9tant donn\u00e9 que les mises \u00e0 jour ont \u00e9t\u00e9 publi\u00e9es \u00e0 l'avance, le probl\u00e8me de v\u00e9rification des certificats Let's Encrypt n'a affect\u00e9 que les utilisateurs de versions anciennes de RHEL\/CentOS et Ubuntu, qui ne mettent pas r\u00e9guli\u00e8rement \u00e0 jour leurs syst\u00e8mes.\n
Le processus de v\u00e9rification des certificats dans grpc est interrompu.\n
\u00c9chec lors de la compilation de la plateforme Cloudflare Pages.\n
Probl\u00e8mes sur Amazon Web Services (AWS).\n
Probl\u00e8mes de connexion \u00e0 la base de donn\u00e9es pour les utilisateurs de DigitalOcean.\n
\u00c9chec de la plateforme cloud Netlify.\n
Probl\u00e8mes d'acc\u00e8s aux services Xero.\n
\u00c9chec lors de la tentative d'\u00e9tablissement d'une connexion TLS au Web API du service MailGun.\n
Pannes dans les versions macOS et iOS (11, 13, 14) qui, th\u00e9oriquement, ne devaient pas \u00eatre touch\u00e9es par le probl\u00e8me.\n
\u00c9chec des services Catchpoint.\n
Erreur de v\u00e9rification des certificats lors de l'acc\u00e8s \u00e0 l'API PostMan.\n
\u00c9chec du Guardian Firewall.\n
Interruption de la page de support de monday.com.\n
\u00c9chec de la plateforme Cerb.\n
\u00c9chec lors de la v\u00e9rification de l'uptime dans Google Cloud Monitoring.\n
Probl\u00e8me de v\u00e9rification des certificats dans Cisco Umbrella Secure Web Gateway.\n
Probl\u00e8mes de connexion aux proxies Bluecoat et Palo Alto.\n
Des probl\u00e8mes de connexion au OpenStack API ont \u00e9t\u00e9 signal\u00e9s chez OVHcloud.\n
Probl\u00e8mes de g\u00e9n\u00e9ration de rapports dans Shopify.\n
Des probl\u00e8mes sont observ\u00e9s lors de l'acc\u00e8s \u00e0 l'API Heroku.\n
\u00c9chec du Ledger Live Manager.\n
Erreur de v\u00e9rification du certificat dans les outils de d\u00e9veloppement d'applications pour Facebook.\n
Probl\u00e8mes sur Sophos SG UTM.\n
Probl\u00e8mes de v\u00e9rification des certificats dans cPanel. <\/ul>\n