Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:dfnpki:faq:sha2 [2018/06/07 11:23] – Heike Ausserfeld
+++ de:dfnpki:faq:sha2 [Unbekanntes Datum] (aktuell) – gelöscht - Externe Bearbeitung (Unbekanntes Datum) 127.0.0.1
@@ Zeile 1: / Zeile 1: @@
-~~NOTOC~~
-===== Fragen und Antworten zur Umstellung von SHA-1 auf SHA-2 in der DFN-PKI =====
-{{INLINETOC 3}}
-====1. Welche Bedeutung haben Hash-Algorithmen in SSL-Zertifikaten?====
-Zertifikate werden von einer Zertifizierungsstelle unter Verwendung eines bestimmten Algorithmus signiert. Bestandteil des Algorithmus ist dabei üblicherweise ein Hash-Verfahren. Lange Zeit wurde für das Signieren von Zertifikaten das SHA-1-Hash-Verfahren mit RSA als Verschlüsselungsalgorithmus (sha1WithRSAEncryption) verwendet.
-Aktueller Stand der Technik ist der Nachfolger SHA-2 (mit RSA als sha256WithRSAEncryption).
-====2. Ab wann gibt es in der DFN-PKI SHA-2-Zertifikate?====
-Bereits seit Ende 2014 wird für das Signieren von Zertifikaten in der DFN-PKI der SHA-2-Hash-Algorithmus (in der Variante SHA-256) mit RSA als Verschlüsselungsalgorithmus (sha256WithRSAEncryption) verwendet. Bis Ende 2015 konnte auf Anfrage in Ausnahmefällen noch SHA-1 genutzt werden.
-====3. Gibt es in der DFN-PKI noch neue SHA-1-Zertifikate?====
-Die DFN-PKI ist komplett auf SHA-2 umgestellt und es gibt seit dem 1.1.2016 keine neuen SHA-1-Zertifikate mehr. Ausgenommen von dieser Regelung sind spezielle Zertifizierungsstellen, die ausschließlich für den internen Gebrauch vorgesehen sind und dabei nicht unter den bekannten DFN-PKI Hierarchien (Global, Classic, Basic, Grid bzw. SLCS) betrieben werden.
-====4. Was passiert mit alten SHA-1-Zertifikaten aus der DFN-PKI?====
-Alte SHA-1-signierte Zertifikate behalten aus technischer Sicht ihre Gültigkeit bis diese abläuft oder die Zertifikate gesperrt werden. Allerdings führen alte SHA-1-signierte Server- und Zwischen-Zertifizierungsstellen-Zertifikate immer häufiger zu SSL-Verbindungsproblemen in Web-Browsern.
-Auch alte SHA-1-signierte Nutzerzertifikate werden in absehbarer Zeit zu Problemen führen.
-Deswegen sollten diese alten Zertifikate durch neue SHA-2-signierte Zertifikate ausgetauscht werden.
-====5. Warum meldet ein Web-Browser, dass eine SSL-Verbindung wegen SHA-1-Zertifikaten unsicher ist oder gar nicht zustande kommt?====
-Wahrscheinlich nutzt der Web-Server noch ein altes SHA-1-signiertes Server-Zertifikat oder die vom Web-Server beim SSL-/TLS-Verbindungsaufbau mit ausgelieferten Zertifizierungsstellen-Zertifikate (CA-Kette) enthalten noch ein oder mehrere alte SHA-1-signierte Zwischen-Zertifizierungsstellen-Zertifikate. Ein Wurzel/Stamm-Zertifizierungsstellen-Zertifikat darf noch SHA-1-signiert mit der CA-Kette ausgeliefert werden. Ein Austausch der betroffenen SHA-1-signierten Server- und Zwischen-Zertifizierungsstellen-Zertifikate durch neue SHA-2-signierte Zertifikate bringt Abhilfe.
-Ist der Web-Server aus dem öffentlichen Internet unter Port 443 zu erreichen, so ist der SSL-Server-Test von SSLlabs ebenfalls hilfreich, um SSL-Problemen auf die Spur zu kommen.
-====6. Müssen auch Wurzel/Stamm-Zertifizierungsstellen-Zertifikate SHA-2-signiert vorliegen?====
-Nein, denn der verwendete Hash-Algorithmus für die Selbst-Signatur von Wurzel/Stamm-Zertifizierungsstellen-Zertifikaten hat keine sicherheitskritische Bedeutung und kann somit beliebig sein. Daher gibt es das "Deutsche Telekom Root CA 2"-Zertifikat weiterhin ausschließlich als SHA-1-signiertes Wurzel/Stamm-Zertifizierungsstellen-Zertifikat.
-Technisch wird das Zertifikatformat mit der Selbst-Signatur von Wurzel/Stamm-Zertifizierungsstellen-Zertifikaten nur als Container für die öffentlichen Schlüssel der Wurzel/Stamm-Zertifizierungsstellen genutzt und die darin enthaltene Signatur ist einfach ein Bestandteil des Zertifikatformats.
-Die Gewissheit, dass es sich bei einem Wurzel/Stamm-Zertifizierungsstellen-Zertifikaten um das authentische Zertifikat handelt, muss sich von demjenigen, der das Wurzel/Stamm-Zertifizierungsstellen-Zertifikat in ein System integriert (also vom Software/Betriebssystem-Hersteller oder Nutzer) oder die Authentizität eines vorhandenen Wurzel/Stamm-Zertifizierungsstellen-Zertifikats überprüft, über den Abgleich eines digitalen Fingerabdrucks des Zertifikats verschafft werden. Hierzu wird z.B. der SHA-2-Fingerabruck des im System befindlichen Zertifikats (nicht zu verwechseln mit z.B. einer SHA-1-Selbst-Signatur im Zertifikat) mit dem von der Zertifizierungsstelle veröffentlichten (oder anderweitig authentisch übermittelten) SHA-2-Fingerabruck Wurzel/Stamm-Zertifizierungsstellen-Zertifikats abgeglichen.