{"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\/news\/sboi-v-openbsd-dragonfly-bsd-i-electron-iz-za-ustarevaniya-kornevogo-sertifikata-identrust","title":{"rendered":"Fehler in OpenBSD, DragonFly BSD und Electron aufgrund der Veralterung des Stammzertifikats von IdenTrust","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Das Ablaufen des Root-Zertifikats der Firma IdenTrust (DST Root CA X3), das zur Kreuzsignierung des Root-Zertifikats der Zertifizierungsstelle Let’s Encrypt verwendet wurde, f\u00fchrte zu Problemen bei der \u00dcberpr\u00fcfung von Let’s Encrypt-Zertifikaten in Projekten, die \u00e4ltere Versionen von OpenSSL und GnuTLS verwenden. Auch die LibreSSL-Bibliothek war betroffen, deren Entwickler fr\u00fchere Erfahrungen im Zusammenhang mit Ausf\u00e4llen, die nach dem Ablauf des Root-Zertifikats von AddTrust der Zertifizierungsstelle Sectigo (Comodo) auftraten, nicht ber\u00fccksichtigt hatten. <\/p>\n
Erinnern wir uns daran, dass in OpenSSL-Versionen bis einschlie\u00dflich 1.0.2 und in GnuTLS bis zur Version 3.6.14 ein Fehler vorhanden war, der nicht erlaubte, kreuzsignierte Zertifikate korrekt zu verarbeiten, wenn eines der beteiligten Root-Zertifikate abgelaufen war, selbst wenn andere g\u00fcltige Vertrauensketten vorhanden waren (im Fall von Let’s Encrypt erlaubt das Ablaufen des Root-Zertifikats von IdenTrust keine \u00dcberpr\u00fcfung, selbst wenn das System das eigene Root-Zertifikat von Let’s Encrypt unterst\u00fctzt, das bis 2030 g\u00fcltig ist). Das Problem liegt darin, dass \u00e4ltere Versionen von OpenSSL und GnuTLS das Zertifikat als lineare Kette interpretierten, w\u00e4hrend das Zertifikat gem\u00e4\u00df RFC 4158 einen gerichteten, verteilten, zyklichen Graphen mit mehreren Vertrauensanker darstellen kann, die ber\u00fccksichtigt werden m\u00fcssen. <\/p>\n
Um einen Ausfall zu umgehen, wird empfohlen, das Zertifikat «DST Root CA X3» aus dem systemweiten Speicher (/etc/ca-certificates.conf und /etc/ssl/certs) zu l\u00f6schen und anschlie\u00dfend den Befehl «update-ca-certificates -f -v» auszuf\u00fchren. In CentOS und RHEL kann das Zertifikat «DST Root CA X3» auf die schwarze Liste gesetzt werden: trust dump —filter «pkcs11:id=» | openssl x509 | sudo tee /etc/pki/ca-trust/source/blacklist/DST-Root-CA-X3.pem sudo update-ca-trust extract <\/ul>\n
Einige der aufgetretenen Fehler, die nach dem Ablaufen des Root-Zertifikats IdenTrust auftraten: <\/p>\n
\n
Die syspatch-Utility in OpenBSD funktioniert nicht mehr, was zur Installation von bin\u00e4ren Systemupdates verwendet wird. Das OpenBSD-Projekt hat heute eiligst Patches f\u00fcr die Versionen 6.8 und 6.9 ver\u00f6ffentlicht, die Probleme mit der \u00dcberpr\u00fcfung von cross-signierten Zertifikaten in LibreSSL beheben, da eines derRoot-Zertifikate in der Vertrauenskette abgelaufen ist. Als Umgehungsl\u00f6sung wird empfohlen, in \/etc\/installurl von HTTPS auf HTTP umzuschalten (was der Sicherheit nicht schadet, da Updates zus\u00e4tzlich durch digitale Signaturen verifiziert werden) oder ein alternatives Mirror auszuw\u00e4hlen (ftp.usa.openbsd.org, ftp.hostserver.de, cdn.openbsd.org). Es ist auch m\u00f6glich, das abgelaufene Root-Zertifikat DST Root CA X3 aus der Datei \/etc\/ssl\/cert.pem zu entfernen.\n
\u00c4hnliche Probleme treten in DragonFly BSD bei der Arbeit mit DPorts auf. Beim Start des Paketmanagers pkg wird ein Zertifikats\u00fcberpr\u00fcfungsfehler ausgegeben. Die Behebung wurde heute in die Branches master, DragonFly_RELEASE_6_0 und DragonFly_RELEASE_5_8 hinzugef\u00fcgt. Als Umgehung kann das Zertifikat DST Root CA X3 entfernt werden.\n
Der Prozess zur \u00dcberpr\u00fcfung von Let’s Encrypt-Zertifikaten in Anwendungen auf Basis der Electron-Plattform ist gest\u00f6rt. Das Problem wurde in den Updates 12.2.1, 13.5.1, 14.1.0, 15.1.0 behoben.\n
In einigen Distributionen gibt es Probleme beim Zugriff auf Paketrepositorys bei Verwendung des Paketmanagers APT, die mit \u00e4lteren Versionen der Bibliothek GnuTLS verbunden sind. Das Problem betraf Debian 9, in dem ein fehlerhafter GnuTLS-Paket verwendet wurde, was zu Problemen beim Zugriff auf deb.debian.org f\u00fcr Benutzer f\u00fchrte, die die Updates nicht rechtzeitig installiert hatten (die Korrektur gnutls28-3.5.8-5+deb9u6 wurde am 17. September vorgeschlagen). Als Umgehungsl\u00f6sung wird empfohlen, die Datei DST_Root_CA_X3.crt aus \/etc\/ca-certificates.conf zu entfernen.\n
Die Funktionalit\u00e4t des acme-client in der Firewall-Distribution OPNsense ist gest\u00f6rt; das Problem wurde im Voraus gemeldet, aber die Entwickler konnten rechtzeitig keinen Patch herausgeben.\n
Das Problem betraf das OpenSSL-Paket 1.0.2k in RHEL\/CentOS 7, aber vor einer Woche wurde f\u00fcr RHEL 7 und CentOS 7 ein Update des Pakets ca-certificates-2021.2.50-72.el7_9.noarch bereitgestellt, aus dem das IdenTrust-Zertifikat entfernt wurde, d.h. die Auswirkung des Problems wurde im Voraus blockiert. Ein \u00e4hnliches Update wurde vor einer Woche auch 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 ver\u00f6ffentlicht wurden, hatte das Problem mit der Zertifikats\u00fcberpr\u00fcfung von Let's Encrypt nur Auswirkungen auf Benutzer \u00e4lterer Versionen von RHEL\/CentOS und Ubuntu, die Updates nicht regelm\u00e4\u00dfig installiert haben.\n
Der Zertifizierungsprozess in grpc wurde gest\u00f6rt.\n
Fehler beim Erstellen der Cloudflare Pages-Plattform.\n
Probleme mit Amazon Web Services (AWS).\n
Probleme beim Anschluss an die Datenbank f\u00fcr DigitalOcean-Benutzer.\n
Ausfall der Cloud-Plattform Netlify.\n
Zugangsprobleme zu den Xero-Diensten.\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), von denen theoretisch nicht betroffen sein sollte.\n
Fehler in den Catchpoint-Diensten.\n
Fehler bei der \u00dcberpr\u00fcfung von Zertifikaten beim Zugriff auf die API von PostMan.\n
Ausfall des Guardian Firewalls.\n
St\u00f6rungen auf der Support-Seite von monday.com.\n
Fehler auf der Cerb-Plattform.\n
Fehler bei der \u00dcberpr\u00fcfung der Verf\u00fcgbarkeit in Google Cloud Monitoring.\n
Probleme bei der \u00dcberpr\u00fcfung von Zertifikaten in Cisco Umbrella Secure Web Gateway.\n
Probleme mit der Verbindung zu den Proxys Bluecoat und Palo Alto.\n
Bei OVHcloud gab es Probleme mit dem Anschluss an die OpenStack-API.\n
Probleme mit der Erstellung von Berichten in Shopify.\n
Es gibt Probleme beim Zugriff auf die Heroku-API.\n
Ausfall des Ledger Live Managers.\n
Fehler bei der Zertifikatspr\u00fcfung in den Entwicklerwerkzeugen f\u00fcr Facebook-Anwendungen.\n
Probleme mit Sophos SG UTM.\n
Probleme bei der \u00dcberpr\u00fcfung von Zertifikaten in cPanel. <\/ul>\n