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)

Einführung der neuen Generation der DFN-PKI

Die bestehende DFN-PKI wird seit 2007 mit dem Wurzelzertifikat „Deutsche Telekom Root CA 2“ betrieben, das bis zum 9. Juli 2019 gültig ist. In dieser Zertifizierungshierarchie kann es kein Zertifikat, ob für Server oder für Nutzer, mit längerer Gültigkeit geben.

Für den Betrieb über den 9. Juli 2019 hinaus bietet die DFN-PKI ein neues Wurzelzertifikat an: „T-TeleSec GlobalRoot Class 2“ mit einer Gültigkeit, die bis 2033 reicht. Das Zertifikat können Sie auf folgender Übersichtsseite einsehen: https://www.pki.dfn.de/root/globalroot2/

Die Einführung des neuen Wurzelzertifikats geschieht schrittweise; insbesondere kann die bestehende DFN-PKI unverändert weiter genutzt werden. Allerdings verkürzen sich automatisch die Laufzeiten der ausgestellten Nutzer- und Serverzertifikate durch das feste Ablaufdatum des alten Wurzelzertifikats auf den 9. Juli 2019.

Die „T-TeleSec GlobalRoot Class 2“ ist in den aktuellen Versionen aller relevanten Betriebssysteme und Browser vorinstalliert. Leider gibt es mit Android <= 4.4 ein nicht mehr aktuelles, aber noch weit verbreitetes System, welches das neue Wurzelzertifikat nicht unterstützt. Es besteht allerdings für alle Teilnehmer der DFN-PKI die Möglichkeit, weiterhin Zertifikate in der alten Hierarchie unter der „Deutsche Telekom Root CA 2“ auszustellen. Systeme, die zwingend rückwärtskompatibel sein müssen, können also weiterhin mit Zertifikaten aus der alten Hierarchie ausgestattet werden – diese sind dann aber auch immer nur bis 2019 gültig. Zu diesem Zeitpunkt dürfte Android <= 4.4 keine Rolle mehr spielen. Dies muss also ggf. bei der Ausstellung eines neuen Zertifikats berücksichtigt werden.

Zur Nutzung des neuen Wurzelzertifikats werden von der DFN-PCA bis Herbst 2016 für jeden Teilnehmer der DFN-PKI separate, neue Zugänge bereitgestellt. Die Bereitstellung erfolgt automatisch und ohne weitere Anforderung vom Teilnehmer. Die Teilnehmer können dann selbst entscheiden, wann sie die neuen Zugänge mit der neuen Zertifizierungshierarchie nutzen wollen.

Die DFN-PCA informiert jeden Teilnehmer, wenn der neue Zugang bereitsteht.

Zertifizierungshierarchie

Server- und Nutzerzertifikate wurden in der DFN-PKI bisher mit der folgenden beispielhaften Zertifizierungskette ausgestellt:

 

 

 

 

 


Mit dem neuen Wurzelzertifikat wird sich diese Zertifizierungskette ändern. Das Wurzelzertifikat, das in den Webbrowsern und Betriebssystemen verankert ist, ist in Zukunft die „T-Telesec GlobalRoot Class 2“. Darunter gibt es dann die „DFN-Verein Certification Authority 2“.

In der Vergangenheit hatte fast jede Einrichtung in der DFN-PKI ein eigenes Sub-CA-Zertifikat. Dieses Verfahren wird umgestellt: Im Regelfall wird nun ein allgemeines Herausgeber-Zertifikat mit dem Namen „DFN-Verein Global Issuing CA“ verwendet.

Damit wird eine Zertifizierungskette in der DFN-PKI in Zukunft den folgenden Aufbau haben:



Beantragung

Zur Beantragung von Zertifikaten wählen Antragssteller bisher Adressen der Form https://pki.pca.dfn.de/<teilnehmer-ca>/pub an, um dort auf den Antragsseiten ihre Daten einzugeben.

Zur Nutzung der neuen Generation der DFN-PKI müssen in der Einführungsphase neue Adressen der Form https://pki.pca.dfn.de/<teilnehmer-ca>-g2/pub angewählt werden.

Nach der Einführungsphase wird es auf den bisherigen Antragsseiten einen Verweis auf die neuen Adressen geben (Voraussichtlich in der ersten Hälfte von 2017).

Wichtig: Zertifikatnutzer müssen beim Import eines neu ausgestellten Zertifikats darauf achten, die neue Zertifizierungskette in die Anwendungen einzubinden. Die Kette musste zwar bisher auch schon eingebunden werden, möglicherweise sparen sich Nutzer aber fälschlicherweise diesen Schritt, wenn sie schon ein früheres DFN-PKI-Zertifikat besitzen.

Konfiguration der Client-Authentisierung auf Server-Seite

Wird auf Server-Seite eine Authentisierung mittels Client-Zertifikaten eingesetzt, so muss diese Konfiguration um die neue DFN-PKI Hierarchie erweitert werden. Außerdem ist zu beachten, dass Client-Zertifikate mehrerer Einrichtungen unterhalb derselben Zertifizierungsstelle liegen und daher die Prüfungsbedingungen in der Server-Konfiguration entsprechend angepasst werden müssen.

Wichtig: Wird die Konfiguration der Client-Authentisierung auf Server-Seite nicht korrekt angepasst, haben möglicherweise auch unberechtigte Nutzer Zugriff!

Hinweise zur sicheren Konfiguration von Servern für Client-Authentisierung finden Sie im Artikel „SSL-Authentisierung mit Nutzerzertifikaten“ in den DFN-Mitteilungen Nr. 86.

https://www.pki.dfn.de/fileadmin/PKI/Mitteilungen/DFN86_SSL_Authentisierung.pdf

Teilnehmerservice

Wie für die Antragssteller gibt es auch für den Teilnehmerservice neue Zugänge. Die bestehenden Teilnehmerservice-Mitarbeiter-Zertifikate können dabei unverändert sowohl für den alten als auch für den neuen Zugang verwendet werden. In der Java RA-Oberfläche wird der neue Zugang automatisch zur Verfügung gestellt, und erscheint als zusätzlicher Knoten („Häuschen“) im linken Teil der Oberfläche. Im Beispielbild als „HS Musterstadt (Global Issuing CA)“:

 

 

 

 

 

 

 

Bei der Bearbeitung von Zertifizierungs- und Sperrwünschen müssen Teilnehmerservice-Mitarbeiter den richtigen Knoten auswählen. Für Zertifizierungsanträge ist die CA und damit der auszuwählende Knoten auf dem Ausdruck in der Fusszeile vermerkt:

Domain-Verwaltung

Zum Zeitpunkt der Umstellung werden die dann aktuell zur Zertifizierung freigeschalteten Domains in die neue DFN-PKI übertragen. Ab diesem Zeitpunkt müssen die Domains jeweils getrennt in der alten und neuen DFN-PKI über die bekannten Mechanismen der Java RA-Oberfläche verwaltet werden.

Eigenentwicklungen zum Zugriff auf die DFN-PKI

Einige Einrichtungen verwenden für die Verwaltung von Zertifikaten in der DFN-PKI selbst entwickelte Software, die entweder direkt oder über die Java-Bibliothek „soapclient“ über ein SOAP-API mit den DFN-PKI-Servern kommunizieren.

Auch hier kommen die oben beschriebenen Änderungen zum Tragen: Die SOAP-Endpunkte ändern sich für den Zugriff auf die PKI mit dem neuen Wurzelzertifikat. Am API selbst verändert sich nichts.

Eine Software, die sowohl mit der alten und der neuen Zertifizierungshierarchie kompatibel sein soll, muss also für Antragsstellung und RA-Funktionen zwei verschiedene SOAP-Endpunkte bedienen können.

Wichtig: Auch der optionale Parameter „RaID“ muss konfigurierbar gehalten werden und für alte und neue Hierarchie auf unterschiedliche Werte gesetzt werden können.

Die bestehendenen Teilnehmerservice-Zertifikate aus der alten Zertifizierungshierarchie können, wie beim manuellen Zugriff auch, für die neue Hierarchie weiterverwendet werden. Eigenentwicklungen müssen also nicht zwei verschiedene Teilnehmerservice-Zertifikate verwalten können.

Und auch hier gilt: Der Zugang zur alten PKI wird nicht vorzeitig abgeschaltet. Nach der Bereitstellung des neuen Zugangs durch die DFN-PCA kann der Umstiegszeitpunkt von den Teilnehmern selbst gesteuert werden und ist lediglich durch das End-Datum der alten PKI am 9. Juli 2019 bestimmt.

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

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)

Version 3.5 der Zertifizierungsrichtlinie DFN-PKI Global

Zum 26.04.2016 tritt die Version 3.5 der Zertifizierungsrichtlinie  (CP) der DFN-PKI für das Sicherheitsniveau Global in Kraft. Das Dokument finden Sie unter: https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_V3.5.pdf

Mit Änderungsmarkierungen:  https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_V3.5-diff.pdf

Diese Version 3.5 bereitet die nächste Generation der DFN-PKI vor, die bereits in den Startlöchern steht.

Wurzelzertifikate

Als größte Neuerung ist im neuen CP in Kapitel 1.3.1 der Nachfolger des aktuellen Wurzelzertifikats beschrieben. Zur Zeit wird in der DFN-PKI die „Deutsche Telekom Root CA 2“ verwendet, die am 9. Juli 2019 abläuft. Die nächste Generation der DFN-PKI wird mit dem Wurzelzertifikat „T-TeleSec GlobalRoot Class 2“ in den Betriebssystemen und Browsern verankert sein.

Die DFN-PKI hat von T-Systems bereits ein neues DFN-PCA-Zertifikat unter dieser neuen Wurzel ausgestellt bekommen, mit Gültigkeit bis zum 22. Februar 2031. Der Name des neuen DFN-PCA-Zertifikats ist:

C=DE, O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU=DFN-PKI, CN=DFN-Verein Certification Authority 2

Weitere Informationen zur Zertifizierungskette der nächsten Generation der DFN-PKI finden Sie unter: https://www.pki.dfn.de/root/global-generation-2/

Die DFN-PCA wird mit Inkrafttreten des neuen CP 3.5 beginnen, die Zertifizierungshierarchie neu aufzubauen und den Teilnehmern Zugänge zur neuen Generation der DFN-PKI zur Verfügung zu stellen.

Gültigkeitsdauer Nutzerzertifikate

Des Weiteren gibt es eine Änderung bei der Laufzeit für Nutzerzertifikate (Kapitel 6.3.2).

Insbesondere Anwender, die Chipkarten ausgeben, haben den Wunsch nach einer längeren Gültigkeit von Nutzerzertifikaten geäußert. Grund hierfür ist, die Hardware möglichst lange nutzen zu können und den Enrollment-Prozess so selten wie möglich durchführen zu müssen. Nach Gesprächen mit T-Systems als Inhaber der Wurzelzertifikate und TÜViT als Auditor können wir jetzt die Laufzeit für Nutzerzertifikate in der DFN-PKI auf 5 Jahre verlängern.

Für Serverzertifikate muss es bei den schon bisher festgeschriebenen 39 Monaten Laufzeit bleiben, da die Richtlinien des CA/Browserforums keine längere Nutzungsdauer erlauben.

Die neue, längere Laufzeit für Nutzerzertifikate steht erst zur Verfügung, wenn die nächste Generation der DFN-PKI in Betrieb ist, da die jetzige Generation in der Laufzeit bis Mitte 2019 beschränkt ist.

Wir empfehlen, die längere Laufzeit nur für Nutzerzertifikate auf Chipkarten im Zusammenhang mit gut funktionierenden, automatisierten Identity-Managementprozessen einzusetzen, da ansonsten die Gefahr besteht, dass zu viele eigentlich veraltete Zertifikate nicht gesperrt werden und die Verlässlichkeit der PKI für den Teilnehmer leidet.

Abschaffung von Sonderregelungen für Zertifikate mit internen Domainnamen, Hostnamen und reservierten IP-Adressen

Die in früheren Zertifizierungsrichtlinien vorhandenen Sonderregelungen für Zertifikate mit internen Domainnamen, Hostnamen und reservierten IP-Adressen sind nach Ablauf von Übergangsfristen des CA/Browserforums aus Kapitel 3.1.2 und Kapitel 6.3.2 entfernt worden. Weitere Informationen hierzu: https://blog.pki.dfn.de/2015/02/interne-domainnamen/

(jbr, 11.04.2016)

Neues Zertifikatprofil in der DFN-PKI: Webserver MustStaple nach RFC7633

In der DFN-PKI gibt es ein neues Zertifikatprofil: Webserver MustStaple.

Zertifikate aus diesem Profil sind ganz speziell für den Einsatz auf Webservern vorgesehen, die OCSP-Stapling unterstützen. Die Zertifikate signalisieren über eine besondere Erweiterung jedem prüfenden Client, dass sie ausschließlich zusammen mit einer über Stapling übertragenen OCSP-Response eingesetzt werden. Fehlt die OCSP-Response, z.B. weil sie von einem Angreifer blockiert wurde, soll der Client die Verbindung abbrechen.

In den Webservern, in denen die Zertifikate eingesetzt werden, muss daher unbedingt die OCSP-Stapling-Funktion aktiviert sein. Im Microsoft IIS ist diese per Voreinstellung aktiviert.

Für Apache finden Sie in folgendem Beitrag Konfigurationshinweise:  https://blog.pki.dfn.de/2015/03/mehr-privacy-fuer-den-nutzer-ocsp-stapling/

Für nginx: https://blog.pki.dfn.de/2015/06/ocsp-stapling-in-nginx/

Der Mechanismus schützt Nutzer dagegen, dass ein Angreifer einen Webserver mit einem gesperrten Zertifikat spooft (also nachmacht) und die Abfrage des Sperrstatus durch die Clients blockiert.

Aber Achtung: Auch beim Einsatz auf falsch konfigurierten oder ungeeigneten Webservern wird die Verbindung von konformen Clients abgewiesen.

Das Zertifikatprofil „Webserver MustStaple“ kann ausschließlich vom Teilnehmerservice nach der Beantragung durch den Serveradministrator gesetzt werden.

Die zugrunde liegende Spezifikation ist RFC7633. Die Zertifikate enthalten eine sogenannte „TLS Feature Extension“ mit Wert „status_request“.

(jbr, 30.03.2016)

Ausweis-Scan bei „POSTIDENT durch Postfiliale“

In der DFN-PKI müssen Personen mit bestimmten Funktionsrollen regelmäßig persönlich identifiziert werden.

Die DFN-PKI nutzt seit einigen Jahren zusätzlich zur persönlichen Identifizierung in den DFN-Geschäftsstellen oder bei der DFN-CERT Services GmbH auch das „POSTIDENT Basic“-Verfahren der Deutschen Post AG. Das POSTIDENT-Verfahren ermöglicht eine Identifizierung am Ort und hilft dabei, aufwendige Dienstreisen zu vermeiden.

Ende 2015 hat die Post ihre POSTIDENT-Produkte umbenannt und den Umfang ergänzt. Das altbekannte „POSTIDENT Basic“ ist jetzt im „POSTIDENT durch Postfiliale“ aufgegangen. Zusätzlich zur bewährten Identifizierung scannt die Post nun bei einer Identifizierung in der Filiale auch noch den vorgelegten Ausweis. Dies ist der Post, die mit den POSTIDENT-Verfahren hauptsächlich eine Geldwäsche- und Signaturgesetz-konforme Methode zur Identifizierung von Personen anbietet, nach dem deutschen Geldwäschegesetz erlaubt.

Für die zu identifizierenden Personen und den DFN-Verein gibt es leider keine Möglichkeit mehr, POSTIDENT ohne diesen Ausweis-Scan durchführen zu lassen.

Der Ausweis-Scan liegt der Post nur in digitaler Form vor und wird dem Auftraggeber der Identifizierung erst auf gesonderte Vereinbarung zugänglich gemacht. Der DFN-Verein hat mit der Post keine Vereinbarung hierüber geschlossen und dementsprechend auch keinen Zugriff auf die Ausweis-Scans. Der DFN-Verein erhält wie gehabt ausschließlich das von der/dem Identifizierten in der Filiale unterschriebene Papierformular.

Nach Aussage der Post werden die Daten ausschließlich auf deutschen Servern gespeichert. Die Daten werden im Fall des DFN-Vereins von der Post nach der kürzest möglichen Speicherdauer von zwei Tagen gelöscht, ohne dass dieser Zugriff auf die digitalen Daten erhält.

Leider gibt es keine in der DFN-PKI nutzbare POSTIDENT-Variante in der Postfiliale/-Agentur ohne Ausweis-Scan. Wenn Sie nicht wünschen, dass Ihr Ausweis von der Post eingescannt wird, können wir Sie auf die selbstverständlich immer mögliche persönliche Identifizierung direkt in den Geschäftsstellen des DFN-Vereins (Berlin oder Stuttgart) bzw. in den Räumlichkeiten der DFN-CERT Services GmbH (Hamburg) verweisen. Alternativ bietet sich auch ein Treffen bei einer Veranstaltung mit DFN-Beteiligung (z.B. Betriebstagungen, Konferenzen etc.) an.

[POSTIDENT AGBs]

(rkm, 17.03.2016)

Sperrung des fehlerhaften DFN-PCA-Zertifikats vom 11.02.2014

Bekanntermaßen gibt es inzwischen drei verschiedene DFN-PCA-Zertifikate im Sicherheitsniveau Global, ausgestellt im:

  • Dezember 2006 (mit SHA-1 signiert)
  • Februar 2014 (von T-Systems fehlerhaft produziert)
  • Juli 2014 (mit SHA-256 signiert)

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

Nach einer langen Frist wurde das fehlerhaft produzierte DFN-PCA-Zertifikat vom Februar 2014 von der T-Systems inzwischen gesperrt, und zwar am 07.02.2016. Die dazugehörige Sperrliste und die Einträge im OCSP-Responder wurden allerdings erst am 16.02.2016 veröffentlicht.

Betroffen sind Zertifikatinhaber, die zwischen Mitte Mai
2014 und Juli 2014 ein neues Zertifikat ausgestellt bekommen haben, und selbst die Zertifizierungskette von den Antragsseiten in ihre Software importiert haben. Dort besteht eine gewisse Wahrscheinlichkeit, dass noch dieses fehlerhafte DFN-PCA-Zertifikat installiert ist, und zu Problemen führt.

Möglicherweise auftretende Schwierigkeiten sind z.B.:

  • Bei Serverzertifikaten: Ablehnung eines Verbindungsaufbaus insbesondere durch Microsoft-Browsern
  • Bei Nutzerzertifikaten: Ungültige Signaturen unter E-Mails.

Allerdings sollte in den meisten Fällen Anwendungssoftware wie Thunderbird oder Outlook das aktuelle, gültige DFN-PCA-Zertifikat zwischenzeitlich über andere Wege, z.B. eingehende signierte E-Mails, installiert haben, so dass diese Probleme eben nicht auftreten.

Das gesperrte DFN-PCA Zertifikat hat die folgenden Merkmale:

Name: C=DE, O=DFN-Verein, OU=DFN-PKI, CN=DFN-Verein PCA Global - G01
Ausstellungsdatum ("notBefore"): Feb 11 13:11:45 2014 GMT
Seriennummer: 9912441563214940059 bzw. hexadezimal 89:90:11:15:58:3e:87:9b
SHA1 Fingerprint:
2E:EF:D9:C0:99:A2:BB:1C:2B:AC:52:97:BD:FF:D8:C8:55:71:5D:B8
SHA256 Fingerprint:
A8:C6:43:93:9C:FB:4C:8E:4E:13:53:56:2D:32:5B:A0:DB:9E:A3:81:27:1A:C6:0D:4C:41:1D:BF:7F:8F:3E:F0

Betroffene Zertifikatinhaber sollten dieses gegen das DFN-PCA-Zertifikat vom Juli 2014 austauschen. Hierzu muss das aktuelle zu verwendende, gültige Zertifikat der DFN-PCA in die Anwendungssoftware geladen werden, z.B. über einen der nachfolgenden Links:

Überblick: https://www.pki.dfn.de/root/globalroot/

Direkt-Links:

PEM-Format: https://pki.pca.dfn.de/global-root-ca/pub/cacert/cacert.pem

DER-Format: https://pki.pca.dfn.de/global-root-ca/pub/cacert/cacert.der

CRT-Format: https://pki.pca.dfn.de/global-root-ca/pub/cacert/cacert.crt

Merkmale:

Name: C=DE, O=DFN-Verein, OU=DFN-PKI, CN=DFN-Verein PCA Global - G01
Ausstellungsdatum ("notBefore"):  Jul 22 12:08:26 2014 GMT
Seriennummer: 5786781327811523684 bzw. hexadezimal 50:4e:c6:f5:3d:11:b4:64
Fingerprints:
SHA1 Fingerprint:
F4:C5:38:C3:BB:99:4F:13:F8:FD:C2:40:B6:79:A6:4B:19:34:A1:B5
SHA256 Fingerprint:
4D:BD:93:C9:C8:60:1C:B6:44:A8:A8:83:0C:CD:AB:B3:68:E7:81:EA:E4:8C:FD:1F:F5:3E:CC:45:F5:36:39:81

Bei Fragen hierzu wenden Sie sich gerne an dfnpca@dfn-cert.de.

(jbr, 18.02.2016)