Archiv für den Monat: August 2014

Google Chrome und SHA-1 Zertifikate

[Update 04.09.2014:Google hat seinen Plan modifiziert, siehe Update zu Google Chrome/SHA-1 Zertifikate]

Nachdem Microsoft im letzten Herbst angekündigt hat, ab 2017 mit dem Signaturalgorithmus SHA-1 signierte Zertifikate nicht mehr zu akzeptieren, wird auch in Chromium und Google Chrome an entsprechenden Maßnahmen gearbeitet.

Dabei sind Änderungen für die Version 39 (angekündigt für Herbst 2014) vorgesehen, die aktuell kontrovers diskutiert werden:

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/2-R4XziFc S7A/YO0ZSrX_X4wJ

https://code.google.com/p/chromium/issues/detail?id=401365

Im Gegensatz zu Microsofts Plänen hätten die Änderungen in Chromium und Google Chrome bereits jetzt Auswirkungen: Bei Serverzertifikaten, die länger als bis zum 01.01.2016 gültig und mit dem Signaturalgorithmus SHA-1 signiert sind, wird das „https-Schloss“ in der Adresszeile rot durchgestrichen sein.

Zertifikate, die länger als bis zum 01.01.2017 gültig sind, sollen zusätzlich sogar Warnhinweise ähnlich den Mixed-Content-Warnungen erhalten, die einen Klick des Nutzers erfordern, um die Web-Seite anzuzeigen.

Sollte Chromium/Google diese Änderungen wie geplant umsetzen, bedeutet dies für die DFN-PKI Folgendes:

  • In der DFN-PKI werden relativ lange gültige Serverzertifikate mit 5-jähriger Laufzeit ausgestellt. (Nur noch bis zum 31.03.2015 möglich, siehe DFN-PKI CP Kapitel 6.3.2)
  • Dadurch sind sehr viele der aktuell im Einsatz befindlichen Serverzertifikate der DFN-PKI länger gültig als bis 1.1.2016 bzw. 1.1.2017 und noch mit SHA-1 signiert, und damit von den Änderungen des Chromium-Projektes betroffen.
  • Um die mit diesen Zertifikaten geschützten Webseiten weiterhin ohne UI-Einschränkungen auch in Chromium bzw. Google Chrome ab Version 39 anzeigen zu können, ist ein Austausch des Serverzertifikats gegen ein neues, mit SHA-2 signiertes Zertifikat erforderlich.

Da die SHA-2-Migration der DFN-PKI abgeschlossen ist, werden alle neu ausgestellten Serverzertifikate automatisch mit SHA-2 signiert.

Wenn Sie also eine Webseite betreiben, auf die Chromium oder Google Chrome Nutzer zugreifen, so können Sie ein neues Serverzertifikat beantragen und ausstellen lassen. Das neue Zertifikat erfüllt dann automatisch die neuen Anforderungen.

Wenn Chromium/Google die Pläne tatsächlich umsetzt, werden wir wieder berichten.

DFN-PKI FAQ zur SHA-2-Umstellung: https://www.pki.dfn.de/faqpki/faqpki-sha2/

(jbr, 29.08.2014)

Wie lässt sich testen, welches DFN-PCA-Zertifikat auf einem Server installiert ist?

Inzwischen gibt es drei verschiedene DFN-PCA-Zertifikate im Sicherheitsniveau Global, ausgestellt im:

  • Dezember 2006
  • Februar 2014
  • Juli 2014

Das DFN-PCA Zertifikat von Februar 2014 darf nicht mehr verwendet werden. Die Hintergründe hatten wir beschrieben: Austausch des DFN-PCA-Zertifikats, Sicherheitsniveau Global

Insbesondere auf Servern könnte dieses DFN-PCA-Zertifikat installiert worden sein, und von dort während des SSL-Handshakes an Clients verteilt werden.

Da es bei vielen Servern recht mühsam ist, in allen Konfigurationen nachzuschauen, haben wir ein kleines Skript entwickelt, was als Client prüft, welches DFN-PCA-Zertifikat ausgeliefert wird. Es ist verfügbar unter: https://info.pca.dfn.de/doc/testserver.sh

Das Skript wird mit dem Namen des zu testenden Servers aufgerufen, optional mit dem Port. Als Beispiel:

$ ./testserver.sh www.dfn.de

OK: www.dfn.de:443 liefert das PCA-Zertifikat von Juli 2014 aus.

Aktuell besteht für Sie kein Handlungsbedarf.

Das Skript kann nur HTTP-Server testen. Für SMTP- oder IMAP-Server mit STARTTLS muss entweder eine Anpassung vorgenommen oder doch die Serverkonfiguration direkt untersucht werden.

(jbr, 14.08.2014)

Austausch des DFN-PCA-Zertifikats, Sicherheitsniveau Global

In Umstellung der DFN-PKI (Sicherheitsniveau Global) auf SHA-2  hatten wir beschrieben, wie der Hash-Algorithmus der DFN-PKI vom veralteten SHA-1 auf SHA-2 vorgenommen wird.

Für diese Umstellung ist auch eine Neu-Signierung des DFN-PCA-Zertifikats mit SHA-2 notwendig.

DFN-PCA-Zertifikat vom 11.2.2014

Am 11.2.2014 führte die T-Systems diese Neu-Signierung des DFN-PCA Zertifikats durch, und erzeugte ein neues Zertifikat mit „CN=DFN-Verein PCA Global – G01“, Serienummer 9912441563214940059 bzw. hexadezimal 89:90:11:15:58:3e:87:9b, gültig ab Feb 11 13:11:45 2014 GMT.

In der DFN-PKI wurde dieses DFN-PCA-Zertifikat schrittweise ab Mitte Mai 2014 in den Anwender-CAs zur Verfügung gestellt.

Die Parameter dieses DFN-PCA-Zertifikats sind so gewählt, dass es, mit Ausnahme der Verwendung von SHA-2 für die Erstellung der Signatur, vollständig kompatibel und austauschbar mit dem DFN-PCA-Zertifikat von 2006 ist.

Austausch

Anfang Juli 2014 forderte der Auditor von T-Systems dann leider den Austausch dieses Zertifikats, da bei der Ausstellung von T-Systems eine bestimmte Zertifikaterweiterung (certificatePolicies) nicht aufgenommen wurde.

T-Systems stellte daraufhin am 22.7.2014 ein weiteres, drittes DFN-PCA-Zertifikat aus, in dem die Mängel behoben sind. Auch dieses dritte DFN-PCA-Zertifikat ist kompatibel und austauschbar mit den beiden anderen.

Aktuelle Situation

Drei-PCA-Zertifikate

Anwender-CAs

Es gibt jetzt im Rahmen der Umstellung der DFN-PKI von SHA-1 auf SHA-2 für fast jede Anwender-CA zwei CA-Zertifikate:

  • Ein SHA-1 CA-Zertifikat
  • Ein SHA-2 CA-Zertifikat

Ausgestellte Nutzer- und Serverzertifikate können mit beiden CA-Zertifikaten verifiziert werden,  da die wichtigen Parameter wie verwendete Schlüssel oder Subject-DN identisch sind.

DFN-PCA

Des Weiteren gibt es durch die SHA-2-Umstellung und den erzwungenen Austausch drei DFN-PCA-Zertifikate:

  • Ausstellungsdatum 2006, mit SHA-1 signiert
  • Ausstellungsdatum Februar 2014, nicht zu benutzen
  • Ausstellungsdatum Juli 2014, mit SHA-2 signiert

Siehe hierzu auch: https://www.pki.dfn.de/root/globalroot/

Das DFN-PCA-Zertifikat von Februar 2014 wird in naher Zukunft gesperrt werden, und darf daher nicht mehr verwendet werden.

Die beiden DFN-PCA-Zertifikate von 2006 und von Juli 2014 sind aufgrund identischer Parameter austauschbar.

Pfade

Von ausgestellten Nutzer- und Serverzertifikaten gibt es jetzt mehrere Pfade bis zum Wurzelzertifikat der DFN-PKI „Deutsche Telekom Root CA 2“. Solange dabei das DFN-PCA-Zertifikat von Februar 2014 nicht verwendet wird, sind alle Pfade gültig.

(jbr, 14.08.2014)

Umstellung der DFN-PKI (Sicherheitsniveau Global) auf SHA-2

Seit Anfang 2014 läuft die Umstellung der DFN-PKI, Sicherheitsniveau Global, auf den Hashalgorithmus SHA-2.

Hintergrund der Umstellung ist insbesondere eine Ankündigung von Microsoft, ab 2017 keine Zertifikate mehr zuzulassen, die mit dem alten Algorithmus SHA-1 signiert wurden.

Hierfür wurde bereits für die meisten Anwender ihr CA-Zertifikat erneut mit SHA-2  signiert und über die Antragsseiten ihrer CA zur Verfügung gestellt (URL: https://pki.pca.dfn.de/<caname>/pub, dort unter dem Reiter  „CA-Zertifikate“).

Im gleichen Zuge wurden die Algorithmen für die Ausstellung von Nutzer- oder Serverzertifikaten ebenfalls auf SHA-2 umgestellt.

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

(jbr, 14.08.2014)

Java 7u51 und neuer: Änderungen beim CodeSigning

Seit Java 7u51, das Anfang 2014 herauskam, müssen Applets und Webstart-Anwendungen signiert sein. Sind sie es nicht, verweigern die Default-Sicherheitseinstellungen von Java die Ausführung.

Zum Signieren von Applets oder Webstart-Anwendungen wird das Tool jarsigner verwendet. Die CodeSigning-Zertifikate aus der DFN-PKI können hierfür genutzt werden.

Seit Java 7u51 gibt der jarsigner eine Warnung aus, wenn eine Signatur erstellt wird, ohne gleichzeitig einen Zeitstempel einzubinden. Mit folgendem Aufruf wird eine Signatur unter Verwendung des Zeitstempeldienstes der DFN-PKI erstellt:

jarsigner -tsa http://zeitstempel.dfn.de -keystore <CodeSigning-Zertifikat.p12> -storetype pkcs12

Optional kann, entgegen teilweise anzutreffender Dokumentation, auch noch ein Proxy für den Zeitstempelserver angegeben werden. Die Parameter hierfür sind:

-J-Dhttp.proxyHost=<ProxyHost> -J-Dhttp.proxyPort=<ProxyPort>
Weitere Informationen: https://www.pki.dfn.de/faqpki/faqpki-codesigning/
(jbr, 14.08.2014)