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)

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)

ETSI Audit 2016 abgeschlossen

Im Oktober 2016 wurden die Vorort-Termine des jährlichen Audits der DFN-PKI (Global) nach  ETSI TS 102 042 durchgeführt. Das Audit bestand wie in den vergangenen Jahren auch aus zwei Teilen: Der Hauptteil findet bei der DFN-PCA in Hamburg statt. Zusätzlich gibt es angekündigte und vorbereitete Besuche bei Teilnehmern der DFN-PKI, bei der die Arbeit des Teilnehmerservice stichprobenartig untersucht wird.

Vielen Dank an alle Einrichtungen, die auch dieses Jahr ein erfolgreiches Audit der DFN-PKI  ermöglicht haben!

Die Bescheinigung über das Audit ist auf den Webseiten von TÜViT zu finden:
https://www.tuvit.de/data/content_data/tuevit_de/6771UD_s.pdf

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

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)