Schlagwort-Archive: SHA-2

Ablauf der alten Generation 1 der DFN-PKI Global

[Update 22.03.2019: Wichtig: SHA-1-CA-Zertifikate müssen komplett entfernt werden]

Die CA-Zertifikate der ersten Generation der DFN-PKI Global laufen nun ab. Zuerst sind die in 2007 erstellten, noch mit SHA-1 signierten CA-Zertifikate betroffen.

Achtung: Für diese alten CA-Zertifikate, die im Betrieb längst durch ihre mit SHA-2 signierten Pendants ersetzt worden sein sollten, werden von uns keine Zertifikatablaufwarnmails versandt.

Achtung: Wenn Sie auf Servern trotz der in den Auslieferungsmails der DFN-PKI mitgelieferten Kette noch eine Zwischenzertifizierungskette mit den alten SHA-1 CA-Zertifikaten beibehalten haben, kann es Ihnen passieren, dass diese Kette eher abläuft als das Serverzertifikat.

[Update 22.03.] Es kann sogar dann zu Problemen kommen, wenn neben den alten SHA-1 CA-Zertifikaten eine neue, gültige SHA-2-Kette vorhanden ist, da Serversoftware unter Umständen alte, ungültige Zertifikate bevorzugt (unlogischerweise).

Hierdurch werden dann unter Umständen Clients schlagartig nicht mehr auf die betroffenen Server zugreifen können. Betroffen sind alle Arten von Anwendungen, z.B. auch openvpn oder jabber.

Server unter Microsoft Windows sollten nicht betroffen sein, da hier die SHA-1 signierten CA-Zertifikate aufgrund von Policy-Entscheidungen von Microsoft sowieso nicht mehr verwendet werden können. Webserver sollten ebenfalls nicht betroffen sein, da Webbrowser Zertifizierungsketten mit SHA-1 CA-Zertifikaten schon seit längerem ablehnen.

Problembeschreibung

Die mit SHA-1 signierten CA-Zertifikate der DFN-PKI waren in 2007 mit einer Laufzeit von exakt 12 Jahren ausgestellt worden, wodurch sie über die erste Hälfte des Jahres 2019 verteilt ablaufen.

Im Jahr 2014 trafen die Browserhersteller die Entscheidung, ab Anfang 2017 mit SHA-1 signierte Zertifikate, auch von CAs, nicht mehr zu akzeptieren. Daraufhin wurden neue CA-Zertifikate mit SHA-2 ausgestellt. Diese erhielten die maximale Lebensdauer bis zum Ablauf der Root-Zertifikate.

Dadurch haben die SHA-2 CA-Zertifikate eine um teilweise wenige Monate längere Laufzeit als die zugehörigen SHA-1 CA-Zertifikate. Davon ausgestellte Serverzertifikate können also eine Laufzeit haben, die über die Laufzeit der SHA-1 Version hinausragt.

Im Beispiel der DFN-CERT Services GmbH CA:

SHA-1 CA-Zertifikat:
14.02.2007 --------------------------------------> 13.02.2019

SHA-2 CA-Zertifikat:
               25.03.2014 -----------------------------------------> 30.06.2019

Serverzertifikat beispiel.dfn-cert.de:
                            27.08.2017 ----------------------------> 30.06.2019

Wurde nun entgegen der Anleitungen in der DFN-PKI beim Austausch eines Serverzertifikates die Zertifizierungskette nicht mit ausgetauscht, fehlt möglicherweise das SHA-2 CA-Zertifikat. Dadurch erhalten Clients unter Umständen eine nicht konsistente Kette mit einem abgelaufenen SHA-1 CA-Zertifikat und einem noch gültigen Serverzertifikat.

Auch das PCA-Zertifikat (CN = DFN-Verein PCA Global – G01) ist mit wenigen Tagen Versatz betroffen: Die SHA-1-Version läuft am 30.06.2019 ab, die SHA-2-Version am 09.07.2019.

Ablaufdaten

Die alten SHA-1 CA-Zertifikate laufen abhängig vom Ausstellungsdatum gestaffelt über das Jahr 2019 ab. Erstes Ablaufdatum ist der 2. Januar („CN=DFN-Verein CA Services“), letztes Ablaufdatum ist der 30. Juni.

Die SHA-2 CA-Zertifikate der DFN-PKI Global G1 laufen zwischen dem 30. Juni und dem 9. Juli 2019 ab.

Konkrete Daten können Sie der folgenden Tabelle entnehmen:
Sortiert_Ablaufdaten_DFNPKI_Global_IssueingCAs

Maßnahmen

  • Wenn Sie auf Ihren Servern bereits Zertifikate aus der neuen DFN-PKI Global G2 einsetzen, müssen Sie nichts weiter prüfen.
  • Wenn Sie noch Zertifikate aus der alten DFN-PKI Global G1 einsetzen, so sollten Sie prüfen, ob Sie die korrekte SHA-2 Zwischenzertifizierungskette konfiguriert haben. Außer dem Root-Zertifikat „Deutsche Telekom Root CA 2“ müssen alle konfigurierten CA-Zertifikate mit SHA-2 signiert sein.
    [Update 22.03.] Auch Reste der alten SHA-1-CA-Zertifikate neben der gültigen SHA-2-Kette können zu Problemen führen!
    Leider können wir hier nur eine abstrakte Anleitung geben, da Ihre individuellen CA-Zertifikate betroffen sind. Zur Prüfung gehen Sie generell wie folgt vor:

  • Alternativ können Sie die Gelegenheit nutzen, gleich ein neues, aktuelles Serverzertifikat aus der neuen Generation 2 der DFN-PKI zu erzeugen und zu installieren.
  • Es ist unwahrscheinlich, dass Server betroffen sind, die ihr erstes Zertifikat nach 2014 bekommen haben, da dann der Rollout der SHA-2 CA-Zertifikate abgeschlossen war.
  • Hinweis: Wie im Blogartikel „Nächste Phase der SHA-1-Abschaltung“ geschildert ist das Root-Zertifikat der Generation 1 der DFN-PKI „Deutsche Telekom Root CA 2“ mit SHA-1 signiert. Dies ist nach wie vor richtig und kein Grund für weitere Aktionen.

Diese Maßnahmen sind nur erforderlich, wenn bei der Installation eines neuen Serverzertifikats aus der DFN-PKI Global G1 nicht wie in der Anleitung beschrieben die SHA-2 Zwischenzertifizierungskette installiert wurde.

Für Rückfragen melden Sie sich bitte gerne unter mailto:dfnpca@dfn-cert.de

(jbr, 07.12.2018)

SHA-1 Kollisionen und deren Bedeutung für die DFN-PKI

Wissenschaftler vom CWI Amsterdam und von Google haben eine Forschungsarbeit veröffentlicht, in der praktisch vorgeführt wird, wie Kollisionen für den Hashalgorithmus SHA-1 berechnet werden können. Dabei ist es gelungen, zwei PDF-Dokumente so zu konstruieren, dass sie denselben Hashwert besitzen.

http://shattered.io/

Artikel auf Heise: https://www.heise.de/newsticker/meldung/Todesstoss-Forscher-zerschmettern-SHA-1-3633589.html

Artikel Golem: https://www.golem.de/news/kollissionsangriff-hashfunktion-sha-1-gebrochen-1702-126355.html

Die Auswirkungen für die DFN-PKI sind nach unserer Einschätzung gering, denn noch ist niemand in der Lage, sogenannte Pre-Image-Angriffe durchzuführen. Dies bedeutet, dass es noch nicht möglich ist, zu einem bestehenden alten Zertifikat ein zweites, „gefälschtes“ mit identischer Signatur, aber anderen Daten zu berechnen.

Der jetzt veröffentlichte Angriff setzt nach unserem Kenntnisstand voraus, dass beide Datenobjekte, das „Original“ und die „Fälschung“, hochvariable Daten unter Angreiferkontrolle beinhalten. Ein erfolgreicher Angriff wäre damit nur möglich, wenn die DFN-PKI weiterhin Zertifikate oder andere Daten mit SHA-1 signieren würde. Dies ist nicht der Fall, die DFN-PKI ist komplett auf SHA-2 umgestiegen.

Daraus folgt: Der neue Angriff ändert noch nichts an der Sicherheit von bestehenden Zertifikaten der DFN-PKI, selbst wenn sie mit SHA-1 signiert sein sollten.

Es gilt aber natürlich nach wie vor: Die Verwendung von SHA-1-signierten Zertifikaten (sei es als Sub-CA-Zertifikat, als Server- oder als Nutzerzertifikat) sollte sehr zügig beendet werden, da die weitere Entwicklung nicht absehbar ist. Insbesondere sollten Sie darauf achten, dass Sie bei der Inbetriebnahme eines neuen SHA-2-Zertifikats auch die neue SHA-2-Zwischenzertifizierungskette einbinden.

Hinweis: Aktuelle Versionen von z.B. Google Chrome oder Internet Explorer/Edge lehnen SHA-1-signierte Server- oder Sub-CA-Zertifikate ab. Ob Sie Ihren Server korrekt konfiguriert haben, können Sie z.B. mit https://www.ssllabs.com/ssltest/ überprüfen.

Spezialfall Wurzelzertifikat

Die Tatsache, dass die erste Generation der DFN-PKI mit der „Deutsche Telekom Root CA 2“ aufgebaut ist, führt ebenfalls mit dem jetzt vorgestellten Angriff nicht zu Problemen. Dieses Wurzelzertifikat trägt zwar eine SHA-1-Selbstsignatur. Diese hat aber keine Sicherheitsfunktion. Dem Wurzelzertifikat wird vertraut, weil es in der Software (z.B. Betriebssystem, Webbrowser) fest vorinstalliert ist, die Signatur spielt keine Rolle. Siehe hierzu auch den Artikel in unserer FAQ: https://www.pki.dfn.de/faqpki/faq-umstellung-sha-2/#c18430

(jbr, 24.02.2017)

Alte SHA-1-Serverzertifikate in der Java RA-Oberfläche identifizieren

Da die nächste Phase der SHA-1-Abschaltung durch die Web-Browser ab Anfang 2017 ins Haus steht, ist es an der Zeit, die alten SHA-1-Serverzertifikate endgültig auszutauschen. Ein Blick in die Java RA-Oberfläche kann bei der Identifizierung der betroffenen Serverzertifikate helfen:

  1. Öffnen Sie in der Java RA-Oberfläche die Übersichtsliste der gültigen Zertifikate.
  2. Geben Sie in den Suchfilter „SHA“ ein und schränken Sie die Suche über die Häkchen der Suchoptionen auf das Zertifikatsprofil ein. Hierdurch finden Sie alle gültigen SHA-1-Zertifikate die nach der generischen SHA-1-auf-SHA-2-Umstellung im Sommer 2014 über ein spezielles SHA-1-Zertifikatprofil ausgestellt worden sein könnten. (Einige DFN-PKI Nutzer haben sich diese speziellen SHA-1-Zertifikatsprofile für Spezialanwendungen zu einer Zeit konfigurieren lassen, als dieses durch die DFN-PKI Global Policy und die Baseline Requirements des CA/Browser-Forums noch erlaubt war.)
  3. Setzen Sie die Suchoptionen zurück, so dass wieder alle gültigen Zertifikate angezeigt werden.
  4. Sortieren Sie diese nun nach absteigender „Seriennummer“ bzw. „Gültig ab“ Spalte.
  5. Suchen Sie dann das jüngste Zertifikat in der Liste (dieses müsste so zwischen Mai 2014 und Juli 2014 oder früher ausgestellt worden sein), das mit dem SHA-1-Signaturalgorithmus signiert worden ist aber kein spezielles SHA-1-Zertifikatprofil besitzt. Dazu öffnen Sie kurz die Zertifikatdetails eines ausgewählten Kanditatenzertifikats und schauen darin nach einem Eintrag „Signatur Algorithmus RSA (PKCS #1 v1.5) with SHA-1 signature„. Hierdurch finden Sie alle gültigen SHA-1-Zertifikate die vor der generischen SHA-1-auf-SHA-2-Umstellung im Sommer 2014 ausgestellt worden sein könnten.
  6. Alle älteren Zertifikate sind ebenfalls mit dem SHA-1-Signaturalgorithmus signiert worden.

Spätestens jetzt zahlt es sich aus, wenn bereits ausgetauschte und außer Betrieb genommene Zertifikate gesperrt wurden, da diese von vornherein nicht mehr in der Liste der gültigen Zertifikate aufgeführt sind.

Die Java RA-Oberfläche kann nicht erkennen, ist, ob die neuen SHA-2-Serverzertifikate auf den Servern zusammen mit der SHA-2-CA-Zertifikat-Kette installiert und konfiguriert wurden. Im Blog-Artikel „Wie lässt sich feststellen, ob auf einem Server ein SHA-1-Zertifikat installiert ist?“ wird beschrieben, wie dieses überprüft werden kann.

(rkm, 02.12.2016)

Nächste Phase der SHA-1-Abschaltung durch die Web-Browser ab Anfang 2017

Die nächste Phase der SHA-1-Abschaltung durch die Web-Browser steht ab Anfang 2017 ins Haus:

Konkret bedeutet das, dass nach dem jeweiligen Stichtag Microsoft-Systeme bzw. Mozilla/Firefox und Google/Chrome Web-Browser (jeweils aktuelle Software vorausgesetzt) mit einer Zertifikatsfehlermeldung vor TLS/SSL-Verbindungen zu Servern warnen, falls diese immer noch ein altes SHA-1-Server-Zertifikat oder SHA-1-Zwischen-CA-Zertifikat der öffentlich vertrauten DFN-PKI „Global“ präsentieren.

Das mit einer SHA-1-Selbstsignatur versehene Wurzel-CA-Zertifikat „Deutsche Telekom Root CA 2“ der ersten DFN-PKI Global Generation muss auch weiterhin nicht ausgetauscht werden (siehe Erläuterung in der FAQ). Das Wurzel-CA-Zertifikat „T-TeleSec GlobalRoot Class 2“ der neuen DFN-PKI Global Generation trägt bereits eine SHA-256-Selbstsignatur.

Weiteres zum Thema:

(rkm, 02.12.2016)

SHA-2-Migration der DFN-PKI abgeschlossen

Die DFN-PKI hat seit 2013 eine Migration des Hash-Algorithmus, mit dem Signaturen unter Zertifikaten, Sperrlisten und OCSP-Antworten erstellt werden, vorgenommen.

Da bei der Migration berücksichtigt werden musste, dass Alt-Anwendungen und -Geräte unter Umständen nicht sofort mit dem neuen Algorithmus SHA-2 umgehen können, konnte der Prozess erst jetzt abgeschlossen werden.

Die Umstellungsdaten in der DFN-PKI:

  • Herbst 2013: Umstellung der ersten CAs auf SHA-2 (Grid, SLCS, DFN-eigene CAs)
  • Februar 2014: Neu signiertes PCA-Zertifikat mit SHA-2
  • Mai-Auguts 2014: Neu-Signatur der Sub-CA-Zertifikate mit SHA-2
  • Bis August 2014: Umstellung der Standard-Profile für Nutzer- und Server-Zertifikate auf SHA-2
  • Mitte 2015: Begrenzung der Laufzeit von SHA-1-Zertifikate für Alt-Geräte auf Dezember 2016
  • Dezember 2015: Abschaltung der Möglichkeit, für Alt-Geräte SHA-1-Zertifikate zu beziehen
  • März 2016: Umstellung der Signatur von OCSP-Antworten auf SHA-2
  • April 2016: Umstellung der Signatur von Zeitstempeln auf SHA-2
  • August 2016: Umstellung der Signatur von Sperrlisten (CRLs) auf SHA-2

Damit wird jetzt für die Erstellung von Signaturen in der DFN-PKI ausschließlich SHA-2 verwendet.

Weitere Informationen zur Umstellung finden Sie unter https://www.pki.dfn.de/faqpki/faq-umstellung-sha-2/

Alle Artikel in diesem Blog zu diesem Thema: https://blog.pki.dfn.de/tag/sha-2/

(jbr, 23.09.2016)

Zeitstempeldienst der DFN-PKI jetzt mit SHA-2 Signaturen

Der Zeitstempeldienst der DFN-PKI steht seit 2009 zur Nutzung im Rahmen der Satzung des DFN-Vereins zur Verfügung.

Am 14.04.2016 wurde eine neue Version der Zeitstempel-Server-Software installiert, die die Zeitstempelsignaturen mittels SHA256withRSAEncryption-Algorithmus bildet, um die Zeitstempel mit derzeit als sicher zu betrachtenden Signaturalgorithmen zu erzeugen.

SHA-2 in Zeitstempelanfragen

Um durchgängig SHA-2 zu verwenden, müssen Sie auch bei der Anfrage nach Zeitstempeln auf SHA-2 umsteigen. Bei der Erzeugung einer Zeitstempelanfrage mittels openssl geschieht dies durch die Angabe des Parameters -sha256:

$ echo "Stempel mich!" | openssl ts -sha256 -query -cert > reqest.tsq

Kompatibilität mit openssl

Die Umstellung des Signaturalgorithmus erzwingt eine kleine Änderung der Datenstrukturen der Zeitstempel: Es wird nun zur Identifikation des unterschreibenden Zertifikats anstelle eines Attributs SigningCertificate das Attribut SigningCertificateV2 nach RFC 5035 bzw. RFC5816 aufgenommen.

Hierbei gibt es leider eine Inkompatibilität mit openssl. Der openssl-Code zur Erzeugung und Verifikation von Zeitstempeln ist offensichtlich über 10 Jahre alt, und unterstützt noch kein SigningCertificateV2-Attribut:

https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/crypto/ts/ts_rsp_verify.c#L320

Ein Update von openssl wird zur Zeit diskutiert:

https://github.com/openssl/openssl/pull/771

Wegen der fehlenden Unterstützung dieser Datenstruktur, die für aktuelle Signaturalgorithmen zwingend erforderlich ist, kommt es bei der Verifikation von Zeitstempeln mit openssl zu Fehlermeldungen, z. B.:

$ openssl ts -verify -queryfile request.tsq -in response.tsr -CAfile zeitstempel-ca.pem 
Verification: FAILED
139957412427408:error:2F067065:time stamp routines:TS_CHECK_SIGNING_CERTS:
ess signing certificate error:ts_rsp_verify.c:291:

Leider ist die Verwendung des alten Attributs SigningCertificate durch unseren Dienst nicht möglich, da dieses für andere Signaturalgorithmen als SHA-1 verboten ist (siehe https://tools.ietf.org/html/rfc5816#section-2.2.1).

Die sonstigen üblichen Zeitstempel-Clients sind nicht betroffen. jarsigner und Adobe Acrobat unterstützen mittels SHA256withRSAEncryption signierte Zeitstempel nach RFC5816 völlig problemlos.

Alternatives Werkzeug zur Prüfung von Zeitstempeln

Als Alternative stellen wir Ihnen ein Java-Werkzeug zur Verfügung, mit dem Zeitstempel verifiziert werden können. Das Werkzeug benötigt BouncyCastle 1.52, und kann unter folgendem Link heruntergeladen werden:

https://info.pca.dfn.de/doc/timestampverifier-latest.tar.gz

(jbr, 20.04.2016)

Endgültiges Ende von SHA-1 in der DFN-PKI Global

Seit Mitte 2014 ist SHA-2 der Standard-Algorithmus für Signaturen in Zertifikaten der DFN-PKI. Der inzwischen veraltete Algorithmus SHA-1 wird nur noch ausnahmsweise verwendet, insbesondere aus Kompatibilitätsgründen für älteren Geräte.

In Übereinstimmung mit den Regeln des CA/Browser-Forums ist ab 30.12.2015 die Verwendung von SHA-1 zur Signatur von Zertifikaten im Sicherheitsniveau Global in der DFN-PKI auch ausnahmsweise nicht mehr möglich.

Bitte beachten Sie auch, dass insbesondere Google Chrome die Warnmeldungen in der Adresszeile beim Auftreten eines SHA-1-signierten Zertifikats in der Zertifizierungskette eines Servers in letzter Zeit deutlich verschärft hat.

Wir raten dringend dazu, noch in Betrieb befindliche SHA-1-Serverzertifikate auszutauschen. Dabei muss auch die gesamte Zertifizierungskette auf dem betreffenden Server mit ausgetauscht werden.

Weitere Informationen: https://www.pki.dfn.de/faqpki/faqpki-sha2/

(jbr, 13.11.2015)

Skript zum Testen der Zertifikatkette und SSLv3-Fähigkeit eines Servers

Es kann mühsam sein zu prüfen, welche Zertifikatkette ein HTTPS-Server ausliefert. Die Ansicht im Webbrowser ist unzuverlässig, da der Browser unter Umständen eigene Zertifikatketten bei der Anzeige verwendet.

Ein direkter Test ist daher sinnvoll. Wir haben ein kleines Testprogramm entwickelt, das als Bash-Skript unter Linux, MacOS X und Cygwin (Windows, mit installiertem openssl und curl) läuft.

Es ist verfügbar unter: https://info.pca.dfn.de/doc/testserver.sh

Das Skript stellt eine Verbindung zu einem zu testenden Server her, und untersucht die Zertifikate, die beim Verbindungsaufbau vom Server übermittelt werden. Gegebenenfalls werden Handlungsempfehlungen ausgegeben.

Zusätzlich testet das Skript, ob auf dem Server das unsichere SSL 3.0 aktiviert ist.

Das Skript wird mit dem Namen des zu testenden Servers aufgerufen, optional mit dem Port. Als Beispiel (verkürzte Ausgabe):

$ ./testserver.sh www.dfn-cert.de 443

================================================
Informationen:
--------------
Server: www.dfn-cert.de
        www.dfn-cert.de has address 193.174.13.92
        www.dfn-cert.de has IPv6 address 2001:638:714:2801:2::
Port: 443
SSLv3 ist abgeschaltet (gut!)
Serverzertifikat:
  SubjectDN:    C=DE, ST=Hamburg, L=Hamburg, O=DFN-CERT Services GmbH, CN=www.dfn-cert.de
  Seriennummer: 6586080966759854 (0x176601787c55ae)
[...]
================================================
Ergebnisse:

Kette OK: www.dfn-cert.de:443 hat eine korrekte SHA-2 Konfiguration von Serverzertifikat und Zertifikatkette. Es ist nichts weiter zu tun.

SSLv3 ist abgeschaltet (gut!)

(jbr, 17.10.2014)

Mozilla und SHA-1 Zertifikate

Nach Microsoft und Google hat auch Mozilla sein Vorgehen zur Abkündigung von SHA-1 Zertifikaten veröffentlicht.

Für Nutzer der DFN-PKI ergeben sich keine weiteren Einschränkungen, da Mozilla einen Mittelweg zwischen Microsofts und Googles Vorgehensweisen plant:

https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/

Nach aktuellem Stand wird Mozilla für Zertifikate,die einen Gültigkeitsbeginn ab 1.1.2016 haben und mit SHA-1 signiert sind, eine „Untrusted Connection“ anzeigen.

Ab 1.1.2017 wird für alle SHA-1 Zertifikate unabhängig vom Ausstellungsdatum eine „Untrusted Connection“ angezeigt.

(jbr, 24.09.2014)

Kompatibilitätsliste SHA-2

[Laufend aktualisiert]

Globalsign hat eine Liste mit Kompatibilitätsinformationen zu SHA-2 veröffentlicht:

https://support.globalsign.com/customer/portal/articles/1499561-sha-256-compatibility

Zusätzlich wissen wir von folgenden Produkten, dass sie Schwierigkeiten mit SHA-2 haben:

(jbr, 17.09.2014)