Schlagwort-Archive: Chrome

Ab jetzt: Neue Antragsseiten für Nutzerzertifikate – ohne Verwendung von LocalStorage im Browser

Wie bereits Ende Januar im Beitrag Neue Antragsseiten für Nutzerzertifikate, die Zweite angekündigt, haben wir die Beantragung von Nutzerzertifikaten nun so umgestaltet, dass Offline-Website-Daten (LocalStorage) nicht mehr vorausgesetzt werden. Diese neue Version ist ab sofort in Betrieb. Damit entfällt für neu gestellte Nutzerzertifikatanträge die häufig fehleranfällige Abhängigkeit von LocalStorage.

Diese Umgestaltung hat zur Folge, dass sich der Zertifikatsbeantragungsfluss ändert. Die zuvor im LocalStorage des Browsers gehaltenen Antragsdaten inklusive des privaten Schlüssels müssen nun am Ende des Prozesses als passwortgeschützte Antragsdatei auf dem Gerät der/des Beantragenden abgespeichert werden.

Sobald das Nutzerzertifikat dann ausgestellt ist, kann dieses über die Antragsseiten unter Verwendung der lokal bei der/dem Beantragenden gespeicherten Antragsdatei heruntergeladen und dabei mit dem privaten Schlüssel aus der Antragsdatei verbunden werden. Das Ergebnis ist dann wie bisher eine Zertifikatsdatei mit zugehörigem privaten Schlüssel und passenden CA-Zertifikaten der Zertifizierungskette im PKCS#12-Format mit der Dateiendung „.p12“.

Für ältere Nutzerzertifikatanträge, die noch im LocalStorage des Browsers gespeichert sind, gibt es Kompatibilitätsmechanismen, so dass diese auch weiterhin verwendet werden können.

(Reimer Karlsen-Masur, 11.03.2020)

Neue Antragsseiten für Nutzerzertifikate, die Zweite

Nachdem Anfang September 2019 auf Grund von technischen Änderungen in den Browsern relativ kurzfristig neue Antragsseiten für die Beantragung von Nutzerzertifikaten in Betrieb genommen wurden, steht demnächst eine weitere Neuerung in diesem Bereich an.

Durch den Wegfall der Unterstützung des <KEYGEN>-Tags zur lokalen Erzeugung von privaten Schlüsseln direkt im Browser wurde im September letzten Jahres der Umstieg auf Antragsseiten mit JavaScript WebCrypto-Technologie unter Nutzung von (Offline-)Website-Daten (sog. LocalStorage), welche ein Teil der Browser-Chronik sind, zur Speicherung der Antragsdaten (inkl. privaten Schlüssel) während des andauernden Zertfifizierungsvorgangs vollzogen.

Die Erfahrung zeigt nun, dass der LocalStorage dabei oft nicht langlebig genug ist, da dieser viel zu häufig durch Browser-Einstellungen oder bestimmte Browser-Updates, die die Browser-Chronik (regelmäßig automatisch) löschen, verloren geht und damit auch die Antragsdaten und insbesondere die darin lokal abgelegten privaten Schüssel zu den ausstehenden Zertifikatanträgen. Das führte dann in etlichen Fällen dazu, dass ausgestellte Nutzerzertifikate nicht mehr mit deren zugehörigen privaten Schlüsseln zusammen geführt und zur weiteren Nutzung abgespeichert werden konnten.

Die zukünftige Version des neuen Antragsformulars wird nun im Laufe des Frühjahrs ohne die Verwendung des flüchtigen LocalStorage erscheinen, um diese Schwierigkeiten zu umgehen. Daher wird sich der Beantragungsfluss wieder ändern. Antragsteller von Nutzerzertifikaten müssen in der künftigen Version ihre Antragsdaten (inkl. lokal im Browser erzeugten privaten Schlüssel) als Datei-Download aus dem Browser herunterladen und zwischenspeichern und dann wieder in den Browser herein laden, um schlussendlich das fertige Zertifikat abzuholen und zusammen mit dem privaten Schlüssel als PKCS#12-Datei (.p12) abspeichern zu können.

Aber irgendetwas ist ja immer 🙂

(rkm, 27.01.2020)

Google Chrome: Zertifikatinformationen

In Chrome ab Version 56 sind die Informationen über die verwendeten Zertifikate eines Webservers leider nicht mehr so leicht zugänglich wie in vorigen Versionen.

Der Klick auf das Schloss vor der URL führt wie bisher in ein Drop-Down-Menü:

Allerdings führt der Klick auf „Weitere Informationen“ nur auf Googles Online-Hilfesystem:

Um die bekannten Dialoge zum Zustand der TLS-Verbindung angezeigt zu bekommen, muss in den neuen Chrome-Versionen im Menü rechts unter „Weitere Tools“ der Punkt „Entwicklertools“ angewählt werden.

Der obere Bereich der Entwicklertools ist als Tab-Laufband gestaltet, dort dann „Security“ auswählen:

(jbr, 07.02.2017)

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)

Schlüsselgenerierung mit Google Chrome [Update 25.07.]

[Update 25.07.2016:

Mit den letzten Updates von Chrome funktioniert die Schlüsselerzeugung zwar wie unten beschrieben, der anschließende Import des Zertifikats wird aber nicht mehr korrekt durchgeführt. Dadurch kann das Zertifikat nicht verwendet werden.

Ein Update der Software der DFN-PKI, das diesen Hinweis auch direkt in der Antragsseite gibt, ist in Vorbereitung.

Wir müssen Ihnen leider von der Verwendung von Chrome in den aktuellen Versionen zur Beantragung von Nutzerzertifikaten abraten. Microsoft Internet Explorer und Mozilla Firefox funktionieren uneingeschränkt.

]

 

Seit Version 49 funktioniert die Beantragung von Nutzerzertifikaten in der DFN-PKI mit Google Chrome nicht mehr uneingeschränkt, da Google die dafür notwendige Funktionalität (das „<KEYGEN>“-Tag) in den Default-Einstellung von Chrome deaktiviert hat.

Die Ankündigung von Google (Überschrift „Keygen and application/x-x509-user-cert“): https://blog.chromium.org/2016/02/chrome-49-beta-css-custom-properties.html

Auch: https://bugs.chromium.org/p/chromium/issues/detail?id=588182

Zur Zeit kann in Google Chrome die Schlüsselerzeugung individuell freigeschaltet werden, indem der Nutzer auf das Schloss links neben der URL klickt und die Berechtigung für „Schlüsselgenerierung“ umsetzt. Achtung: Diese Einstellung steht ausschließlich auf der Seite „Nutzerzertifikat beantragen – Bestätigen“ zur Verfügung.

google_chrome_keygen

Alternativ kann der Mechanismus auch in chrome://settings/content freigeschaltet werden:

google_chrome_keygen_settings

Bis zu welcher Version diese Eingriffsmöglichkeit des Nutzers noch bestehen wird, ist nicht bekannt.

Es ist geplant, in der DFN-PKI alternative Beantragungsverfahren mit W3C WebCrypto umzusetzen, um wieder eine problemlose Beantragung von Nutzerzertifikaten anbieten zu können.

(jbr, 10.05.2016)

Wie lässt sich feststellen, ob auf einem Server ein SHA-1-Zertifikat installiert ist?

[Update 19.9.: Testprogramm um detailliertere Ausgaben erweitert]

Google und Microsoft haben Pläne veröffentlicht, nach denen ihre Software die bisher verwendeten, mit SHA-1 signierten Serverzertifikate nicht mehr akzeptieren wird: Update zu Google Chrome/SHA-1 Zertifikate

Da der Zeitplan von Google bereits dieses Jahr Auswirkungen auf die Darstellung von Webseiten in Google Chrome haben wird, empfiehlt sich ein Austausch der mit SHA-1 signierten Serverzertifikate.

Dabei ist zu beachten, dass die gesamte auf einem Server installierte Zertifikatkette (mit Ausnahme des Wurzelzertifikates „Deutsche Telekom Root CA 2“) mit SHA-2 signiert sein muss, also auch die Intermediate-CAs.

Umstellungszeitpunkt auf SHA-2 in der DFN-PKI

In der folgenden Liste ist aufgeführt, zu welchem Zeitpunkt die einzelnen CAs der DFN-PKI (Sicherheitsniveau Global) vollständig, also inklusive der Intermediate-CAs, auf SHA-2 umgestellt wurden:

Liste mit Umstellungszeitpunkten der CAs in der DFN-PKI Global

Zwischen 1.1.2011 und dem Umstellungszeitpunkt Ihrer CA  ausgestellte Serverzertifikate sind betroffen und sollten  ausgetauscht werden,  um auch weiterhin in Google Chrome und ab 2017 in Microsoft-Produkten ohne Beeinträchtigung zu funktionieren.

Vor dem 1.1.2011 ausgestellte Serverzertifikate sind zwar auch mit SHA-1 signiert, sind aber bei maximal 5 Jahren Laufzeit wegen der enthaltenen Ablaufdaten nicht von den Plänen von Google und Microsoft betroffen.

Testprogramm

Ein unter Linux laufendes Testprogramm 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.

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

================================================
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
Serverzertifikat:
  SubjectDN:    C=DE, ST=Hamburg, L=Hamburg, O=DFN-CERT Services GmbH, CN=www.dfn-cert.de
  Seriennummer: 6586080966759854 (0x176601787c55ae)
[...]
================================================
Ergebnisse:

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

Ansicht des Zertifikats im Browser

In Webbrowsern kann man sich üblicherweise das verwendete Serverzertifikat anschauen.

Als Beispiel der Firefox von Mozilla, mit dem Tab „Details“ in der Zertifikateansicht (erreichbar über einen Klick auf das Schloss in der Adresszeile, dann „Weitere Informationen…“, dann „Zertifikat anzeigen“) :

zertifikat

Ergebnis: Im unteren Bereich erscheint als Feld-Wert „PKCS # 1 SHA-256 mit RSA-Verschlüsselung“. Das Zertifikat ist also mit SHA-2 signiert, und müsste nicht ausgetauscht werden.

Achtung: Die Ansicht im Webbrowser verrät noch nicht, ob auch die komplette Zertifikatkette des Webservers auf SHA-2 umgestellt wurde. Insbesondere können die dargestellten Intermediate-CAs auch aus dem internen Zertifikatspeicher des Webbrowsers kommen und nicht die tatsächliche Konfiguration des Webservers widerspiegeln.

Mit dieser Webbrowser-Ansicht ist daher nur ein schneller Überblick möglich, man erhält aber keine vollständige Aussage. Eine genauere Prüfung, z.B. mit dem oben genannten Testprogramm oder auf dem Server selbst, ist also trotzdem sinnvoll.

Überprüfung durch externe Dienste

Es gibt externe Dienste, die die Konfiguration von HTTPS-Webservern prüfen und Hinweise auf Verbesserungsmöglichkeiten geben. Ein gut funktionierender Dienst ist SSL Labs (https://www.ssllabs.com/ssltest). SSL Labs gibt bei SHA-1-Zertifikaten in der Zertifizierungskette eine Warnung aus.

Externe Dienste können natürlich nur genutzt werden, wenn der betreffende Server auch von außerhalb des eigenen Netzes erreichbar ist. Bitte beachten Sie bei der Nutzung von externen Diensten, dass Sie damit Daten über Ihre Server an Dritte weitergeben.

(jbr, 17.09.2014)

Update zu Google Chrome/SHA-1 Zertifikate

Google hat seine Pläne für Chrome/Chromium über die Bewertung von SHA-1-Zertifikaten jetzt etwas modifiziert. Der ursprüngliche Zeitplan war recht aggressiv und hätte bereits in Chrome 39 teilweise drastische User-Interface-Einschränkungen für Webserver mit SHA-1-Zertifikaten vorgesehen, wenn diese nach dem 1.1.2017 ablaufen.

Der modifizierte Plan sieht vor, dass diese User-Interface-Einschränkungen stufenweise umgesetzt werden.

Auswirkungen

An den Auswirkungen auf die DFN-PKI ändert sich nichts: Wird der Plan umgesetzt, werden Webseiten, die mit einem SHA-1-Serverzertifikat ausgestattet sind oder aber ein SHA-1-Intermediate-CA-Zertifikat ausliefern, in Chromium und Google Chrome mit Warnmeldungen angezeigt werden.

Wenn die folgenden Bedingungen zutreffen, sollten Serverzertifikate in der DFN-PKI gegen neue, mit SHA-2 Signierte ausgetauscht werden:

  • Das Serverzertifikat ist mit SHA-1 signiert. In der DFN-PKI wurden großflächig erst ab ca. Mitte Mai 2014 Serverzertifikate mit SHA-2 signiert. Wurde das Serverzertifikat vor Mai 2014 ausgestellt, ist die Wahrscheinlichkeit groß, dass es betroffen ist.
  • Das Zertifikat ist länger gültig als 1.1.2016 (Austausch nicht ganz so dringend) oder als 1.1.2017 (Austausch sehr dringend).
  • Das Zertifikat wird auf einem Server eingesetzt, auf den mit Chromium oder Google Chrome zugegriffen wird.

Des Weiteren muss sichergestellt sein, dass die auf dem Server installierte Zertifizierungskette ebenfalls durchgängig die SHA-2-Versionen der Intermediate-CAs enthält.

Austausch

Der Austausch ist einfach: Neu ausgestellte Serverzertifikate werden in der DFN-PKI automatisch mit SHA-2 signiert.

Eine SHA-2-Zertifizierungskette ist auf den Antragsseiten jeder CA unter dem Menüpunkt „CA-Zertifikate->Zertifikatkette anzeigen“ verfügbar.

Ist kein Austausch gegen ein mit SHA-2-signiertes Serverzertifikat möglich, weil z.B. neben Google Chrome noch andere Software eingesetzt wird, die immer noch nicht SHA-2-tauglich ist, so besteht die Möglichkeit, hilfsweise ein Serverzertifikat mit SHA-1 zu verwenden, dessen Laufzeit bis 31.12.2015 begrenzt ist. In diesem Fall verzichtet Google Chrome und Chromium ebenfalls auf Warnmeldungen.

Zeitplan

Der Zeitplan von Google für die schrittweise Umsetzung in den Chrome Versionen mit Stand 2.9.2014:

Chrome 39 (verfügbar ca. November/Dezember 2014)

Serverzertifikate, die am oder nach dem 1.1.2017 ablaufen, und bei denen Chrome bei der Validierung ein SHA-1-Zertifikat in der Zertifizierungskette verwendet, werden mit dem „Secure, but minor errors“ Icon dargestellt (Icons von Googles Support-Seite): minor

Dabei geht es nicht nur um das Serverzertifikat selbst: Ist auch nur ein Zertifikat aus der Kette von Serverzertifikat, Anwender-CA oder DFN-PCA mit SHA-1 signiert, wird die Warnung angezeigt.

Um die Warnung zu vermeiden, reicht es also nicht aus, ein Serverzertifikat einzusetzen, das mit SHA-2 signiert ist. Es müssen zusätzlich alle Zwischenzertifzierungsstellen in der SHA-2-Version auf dem Server installiert sein.

Das Wurzelzertifikat (in der DFN-PKI „Deutsche Telekom Root CA 2“) ist von der Prüfung nicht betroffen.

Chrome 40 (verfügbar ca. Januar/Februar 2015)

Serverzertifikate, die zwischen 1.6.2016 und 31.12.2016 ablaufen, und bei denen Chrome bei der Validierung ein SHA-1-Zertifikat in der Zertifizierungskette verwendet, werden mit dem „Secure, but minor errors“ Icon dargestellt: minor

Serverzertifikate, die am oder nach dem 1.1.2017 ablaufen, und bei denen Chrome bei der Validierung ein SHA-1-Zertifikat in der Zertifizierungskette verwendet, werden mit dem „Neutral, no security“ Icon dargestellt: neutral

Chrome 41 (verfügbar ca. März/April 2015)

Serverzertifikate, die zwischen 1.1.2016 und 31.12.2016 ablaufen, und bei denen Chrome bei der Validierung ein SHA-1-Zertifikat in der Zertifizierungskette verwendet, werden mit dem „Secure, but minor errors“ Icon dargestellt: minor

Serverzertifikate, die am oder nach dem 1.1.2017 ablaufen, und bei denen Chrome bei der Validierung ein SHA-1-Zertifikat in der Zertifizierungskette verwendet, werden mit dem „Affirmatively insecure, major errors“ Icon dargestellt: insecure

 

Die Ankündigung von Google: https://groups.google.com/a/chromium.org/d/msg/security-dev/2-R4XziFc7A/C0TpsP3GhKUJ

[Update: Eine lesbarere Ankündigung wurde am 5.9. veröffentlicht: http://googleonlinesecurity.blogspot.de/2014/09/gradually-sunsetting-sha-1.html]

(jbr, 04.09.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)