{"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\/de\/blog\/novosti-interneta\/sboi-v-openbsd-dragonfly-bsd-i-electron-iz-za-ustarevaniya-kornevogo-sertifikata-identrust","title":{"rendered":"Ausf\u00e4lle in OpenBSD, DragonFly BSD und Electron aufgrund eines veralteten Wurzelzertifikats von IdenTrust","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Das Auslaufen des Root-Zertifikats von IdenTrust (DST Root CA X3), das zur Kreuzsignierung des Root-Zertifikats der Zertifizierungsstelle Let’s Encrypt verwendet wird, hat zu Problemen bei der Zertifikatsvalidierung von Let’s Encrypt in Projekten gef\u00fchrt, die \u00e4ltere Versionen von OpenSSL und GnuTLS verwenden. Diese Probleme betrafen auch die LibreSSL-Bibliothek, deren Entwickler fr\u00fchere Erfahrungen mit Ausf\u00e4llen, die nach dem Verfall des Root-Zertifikats von AddTrust (Sectigo\/Comodo) auftraten, nicht ber\u00fccksichtigten. <\/p>\n
Beachten Sie, dass in den Versionen von OpenSSL bis einschlie\u00dflich der Version 1.0.2 und in GnuTLS bis zur Version 3.6.14 ein Fehler vorlag, der die korrekte Verarbeitung von cross-signed Zertifikaten verhinderte, wenn eines der Root-Zertifikate, die an der Signatur beteiligt waren, abgelaufen war, selbst wenn andere g\u00fcltige Vertrauenskette vorhanden waren (im Falle von Let's Encrypt verhindert das Ablaufen des Root-Zertifikats von IdenTrust die \u00dcberpr\u00fcfung, selbst wenn das System ein eigenes, bis 2030 g\u00fcltiges Root-Zertifikat von Let's Encrypt unterst\u00fctzt). Der Kern des Problems liegt darin, dass \u00e4ltere Versionen von OpenSSL und GnuTLS das Zertifikat als lineare Kette interpretierten, w\u00e4hrend gem\u00e4\u00df RFC 4158 das Zertifikat einen gerichteten verteilten zykli- schen Graphen mit mehreren Vertrauensanker darstellen kann, die ber\u00fccksichtigt werden m\u00fcssen. <\/p>\n
Um den Fehler zu umgehen, wird empfohlen, das Zertifikat \u201eDST Root CA X3\u201c aus dem System-Speicher (\/etc\/ca-certificates.conf und \/etc\/ssl\/certs) zu entfernen und dann den Befehl \u201eupdate-ca-certificates -f -v\u201c auszuf\u00fchren. In CentOS und RHEL kann das Zertifikat \u201eDST Root CA X3\u201c auf die schwarze Liste gesetzt werden: trust dump \u2014filter \u201epkcs11:id=\u201c | openssl x509 | sudo tee \/etc\/pki\/ca-trust\/source\/blacklist\/DST-Root-CA-X3.pem sudo update-ca-trust extract <\/ul>\n
Einige der aufgefallenen St\u00f6rungen, die nach der Sperrung des Root-Zertifikats von IdenTrust auftraten: <\/p>\n
\n
Die syspatch-Anwendung, die zur Installation von Bin\u00e4rupdates im OpenBSD verwendet wird, funktioniert nicht mehr. Das OpenBSD-Projekt hat heute dringende Patches f\u00fcr die Versionen 6.8 und 6.9 ver\u00f6ffentlicht, um Probleme mit der \u00dcberpr\u00fcfung von cross-signierten Zertifikaten in LibreSSL zu beheben, wobei eines der Root-Zertifikate in der Vertrauenskette abgelaufen ist. Als Workaround wird empfohlen, in \/etc\/installurl von HTTPS auf HTTP umzuschalten (dies bedroht die Sicherheit nicht, da die Updates zus\u00e4tzlich durch digitale Signaturen verifiziert werden) oder ein alternatives Mirror auszuw\u00e4hlen (ftp.usa.openbsd.org, ftp.hostserver.de, cdn.openbsd.org). Alternativ kann das abgelaufene Root-Zertifikat DST Root CA X3 aus der Datei \/etc\/ssl\/cert.pem entfernt werden.\n
In DragonFly BSD treten \u00e4hnliche Probleme beim Arbeiten mit DPorts auf. Bei der Ausf\u00fchrung des Paketmanagers pkg wird ein Zertifikatspr\u00fcfungsfehler angezeigt. Die Korrektur wurde heute in die Branches master, DragonFly_RELEASE_6_0 und DragonFly_RELEASE_5_8 aufgenommen. Als Workaround kann das Zertifikat DST Root CA X3 entfernt werden.\n
Der Prozess zur \u00dcberpr\u00fcfung von Let\u2019s Encrypt-Zertifikaten in Anwendungen auf der Electron-Plattform war gest\u00f6rt. Das Problem wurde in den Updates 12.2.1, 13.5.1, 14.1.0, 15.1.0 behoben.\n
In manchen Distributionen gibt es Probleme mit dem Zugriff auf die Paketrepositorys beim Einsatz des Paketmanagers APT, die mit alten Versionen der GnuTLS-Bibliothek zusammenh\u00e4ngen. Betroffen ist Debian 9, in dem ein fehlerhafter GnuTLS-Paket eingesetzt wurde, was zu Problemen beim Zugriff auf deb.debian.org f\u00fchrte, insbesondere f\u00fcr Nutzer, die die Updates nicht rechtzeitig installiert hatten (der Fix gnutls28-3.5.8-5+deb9u6 wurde am 17. September angeboten). Als vor\u00fcbergehende L\u00f6sung wird empfohlen, DST_Root_CA_X3.crt aus der Datei \/etc\/ca-certificates.conf zu entfernen.\n
Die Funktionalit\u00e4t des acme-Clients in der OPNsense-Distribution f\u00fcr die Erstellung von Firewalls ist beeintr\u00e4chtigt. Obwohl das Problem im Voraus gemeldet wurde, konnten die Entwickler nicht rechtzeitig einen Patch bereitstellen.\n
Das Problem betraf das Paket OpenSSL 1.0.2k in RHEL\/CentOS 7. Vor einer Woche wurde ein Update f\u00fcr das Paket ca-certificates-2021.2.50-72.el7_9.noarch f\u00fcr RHEL 7 und CentOS 7 bereitgestellt, in dem das IdenTrust-Zertifikat entfernt wurde, d.h. die Manifestation des Problems wurde bereits im Voraus blockiert. Ein \u00e4hnliches Update wurde vor einer Woche f\u00fcr Ubuntu 16.04, Ubuntu 14.04, Ubuntu 21.04, Ubuntu 20.04 und Ubuntu 18.04 ver\u00f6ffentlicht. Da die Updates im Voraus herausgegeben wurden, war das Problem mit der \u00dcberpr\u00fcfung von Let\u2019s Encrypt-Zertifikaten nur f\u00fcr Benutzer \u00e4lterer RHEL\/CentOS- und Ubuntu-Versionen relevant, die nicht regelm\u00e4\u00dfig Updates installieren.\n
Der Prozess der Zertifikats\u00fcberpr\u00fcfung in gRPC ist gest\u00f6rt.\n
Fehler beim Erstellen der Cloudflare Pages-Plattform.\n
Probleme bei Amazon Web Services (AWS).\n
Verbindungsprobleme mit der Datenbank bei DigitalOcean-Nutzern.\n
Fehler auf der Cloud-Plattform von Netlify.\n
Zugriffsprobleme auf die Dienste von Xero.\n
Fehler beim Versuch, eine TLS-Verbindung zur Web-API des MailGun-Dienstes herzustellen.\n
Fehler in den Versionen von macOS und iOS (11, 13, 14), die das Problem theoretisch nicht betreffen sollte.\n
Fehler in den Diensten von Catchpoint.\n
Zertifikats\u00fcberpr\u00fcfungsfehler beim Zugriff auf die PostMan-API.\n
Fehler im Guardian Firewall-Dienst.\n
St\u00f6rung der Support-Seite von monday.com.\n
Fehler in der Cerb-Plattform.\n
Fehler bei der \u00dcberpr\u00fcfung der Verf\u00fcgbarkeit in Google Cloud Monitoring.\n
Problem bei der \u00dcberpr\u00fcfung der Zertifikate im Cisco Umbrella Secure Web Gateway.\n
Verbindungsprobleme mit den Proxys von Bluecoat und Palo Alto.\n
Bei OVHcloud gab es Probleme mit der Verbindung zum OpenStack API.\n
Probleme bei der Berichtserstellung in Shopify.\n
Es gibt Probleme beim Zugriff auf die API von Heroku.\n
Fehler im Ledger Live Manager.\n
Zertifikatpr\u00fcfungsfehler in den Entwicklertools f\u00fcr Facebook-Anwendungen.\n
Probleme bei Sophos SG UTM.\n
Probleme mit der Zertifikat\u00fcberpr\u00fcfung in cPanel. <\/ul>\n