Ausführliche und regelmäßig aktualisierte Informationen zum Betrieb der DFN-PKI in der aktuellen Corona-Krise finden Sie unter: https://blog.pki.dfn.de/2020/03/dfn-pki-und-covid-19
Ausführliche und regelmäßig aktualisierte Informationen zum Betrieb der DFN-PKI in der aktuellen Corona-Krise finden Sie unter: https://blog.pki.dfn.de/2020/03/dfn-pki-und-covid-19
[Update 21.01.2021: Hinweise zu Limitierungen bei der Ergebnisgröße; showSQL=Y]
Certificate Transparency ist ein seit einigen Jahren etablierter Mechanismus, um die in der sog. Web-PKI verwendeten Zertifikate sichtbar zu machen.
Kern des Systems sind öffentlich zugängliche Certificate Transparency Logs, die von Organisationen wie Google, Cloudflare oder kommerziellen CAs betrieben werden. In diese Logs wird üblicherweise direkt bei Erstellung eines Zertifikats ein sogenanntes „Precertificate“ mit allen relevanten Daten geschrieben und öffentlich wieder abrufbar gemacht. Aktuell gibt es 30 Logs, die vom Chrome-Browser akzeptiert werden: https://www.certificate-transparency.org/known-logs
Die DFN-PKI nutzt dieses System seit 2018, siehe auch https://blog.pki.dfn.de/2018/01/certificate-transparency-in-der-dfn-pki/
Inzwischen ist davon auszugehen, das praktisch jedes weltweit ausgestellte Serverzertifikat mit Browser-Verankerung in den Logs erscheinen wird. Dies kann man sich zunutze machen, um neu ausgestellte Zertifikate für die eigene Domain zu überwachen. Dies kann z.B. für die folgenden Zwecke geschehen:
Zertifikate aus internen CAs, die nicht per Default im Browser oder Betriebssystem als vertrauenswürdig erscheinen, werden mit Certificate Transparency nicht erfasst.
Inzwischen gibt es einige Angebote, die Certificate Transparency Logs abfragen, die Informationen aufbereiten und zur Verfügung stellen, beispielsweise von Censys.io, Cloudflare, sslmate, Sectigo (crt.sh), Google und Facebook (teilweise auch kostenpflichtig).
Prinzipiell ist es möglich, die 30 Certificate Transparency Logs direkt selbst zu untersuchen. Mit certspotter
steht hierfür sogar eine fertige Software zur Verfügung: https://github.com/SSLMate/certspotter
Leider ist hierfür ein relativ hoher betrieblicher Aufwand notwendig: Aufgrund der Menge der weltweit ausgestellten Serverzertifikate kann der Ressourcen-Bedarf von certspotter
, insbesondere in Bezug auf die nötige Bandbreite, beträchtlich sein. Schlimmer noch: Einige der Logs wachsen um mehrere hundert Zertifikate pro Sekunde, liefern mitunter aber nicht in entsprechender Rate aus, so dass es teilweise gar nicht möglich ist, die im Log vorhandenen Zertifikate kontinuierlich zu monitoren.
Ein anderer Weg macht sich den Dienst von https://crt.sh zu nutze. crt.sh fragt kontinuierlich alle relevanten CT Logs ab, und bereitet die Daten in einer leicht konsumierbaren Form auf. Der Dienst wird von Sectigo, einem CA-Anbieter, betrieben, und ist öffentlich zugänglich.
crt.sh bietet ein einfaches API an, um zu einer Domain ausgestellte Zertifikate zu erhalten. Die Ergebnisse werden auf Wunsch als JSON zurückgegeben.
Abfrage (unter Ausschluss von abgelaufenen Zertifikaten):
https://crt.sh/?q=%.example.org&exclude=expired&output=json
Ausgabe:
[{"issuer_ca_id":185756,"issuer_name":"C=US, O=DigiCert Inc, CN=DigiCert TLS RSA SHA256 2020 CA1", "common_name":"www.example.org", "name_value":"example.org\nwww.example.org, "id":3704614715, "entry_timestamp":"2020-11-27T13:49:06.706", "not_before":"2020-11-24T00:00:00","not_after":"2021-12-25T23:59:59", "serial_number":"0fbe08b0854d05738ab0cce1c9afeec9"}, ....
Mit Hilfe des Eintrags "id"
aus der Ausgabe kann das entspr. Zertifikat mit der Abfrage https://crt.sh/?id=<Wert von id> direkt betrachtet werden, z.B. https://crt.sh/?id=3704614715
Großer Nachteil dieser Lösung: Die Anzahl der zurückgelieferten Zertifikate ist limitiert. Daher können auf diesem Wege nur Domains oder Subdomains mit weniger als ca. 1000 Zertifikaten überwacht werden.
Es gibt keine Möglichkeit, das Ergebnis auf einen bestimmten Zeitraum einzuschränken. Für eine eigene Monitoring-Lösung muss man also eine eigene Datenbank mit bereits bekannten Zertifikaten aufbauen, und die Ergebnisse gegen diese abgleichen.
crt.sh ist ein sehr belasteter Dienst, und es kommt gelegentlich vor, dass eine Abfrage mit einem HTTP Status 502 abbricht. In diesem Fall empfiehlt sich eine kleine Wartezeit und ein erneuter Versuch.
Häufig wird man zu einem existierenden Zertifikat zwei Einträge finden. Im o.g. Beispiel:
https://crt.sh/?id=3692510597
https://crt.sh/?id=3704614715
Die beiden Einträge meinen das gleiche Zertifikat mit identischen Daten und identischer Seriennummer, aber einmal als normales „leaf certificate“ und einmal als „Precertificate“ (Zeile „Summary“ ganz am Anfang der Darstellung bei crt.sh). Dies ist nicht ungewöhnlich und kein Grund zur Sorge. Ein Precertificate ist, grob gesagt, ein Artefakt mit dem die CA vor der Ausstellung des korrekten „echten“ Zertifikats einen Beweis für die Aufnahme in CT Logs generieren kann. Eine genauere Beschreibung von Precertificates findet sich in Kapitel 3.1 des RFC: https://tools.ietf.org/html/rfc6962#section-3.1
Fügt man zur Abfrage den Parameter deduplicate=Y
hinzu, erhält man nicht mehr sowohl leaf als auch Precertificate in der Ausgabe.
Neben der Abfrage per HTTP ist auch die zugrunde liegende postgresql-Datenbank von crt.sh direkt ansprechbar:
$ psql -h crt.sh -p 5432 -U guest certwatch
Eine Beispiel-Abfrage zum Abruf der nicht abgelaufenen Zertifikate der Domain example.org
(Quelle):
SELECT ci.ISSUER_CA_ID, ca.NAME ISSUER_NAME, ci.NAME_VALUE NAME_VALUE, min(c.ID) MIN_CERT_ID, min(ctle.ENTRY_TIMESTAMP) MIN_ENTRY_TIMESTAMP, x509_notBefore(c.CERTIFICATE) NOT_BEFORE, x509_notAfter(c.CERTIFICATE) NOT_AFTER FROM ca, ct_log_entry ctle, certificate_identity ci, certificate c WHERE ci.ISSUER_CA_ID = ca.ID AND c.ID = ctle.CERTIFICATE_ID AND reverse(lower(ci.NAME_VALUE)) LIKE reverse(lower('%.example.org')) AND ci.CERTIFICATE_ID = c.ID AND x509_notAfter(c.CERTIFICATE) > statement_timestamp() GROUP BY c.ID, ci.ISSUER_CA_ID, ISSUER_NAME, NAME_VALUE, c.CERTIFICATE ORDER BY MIN_ENTRY_TIMESTAMP DESC, NAME_VALUE, ISSUER_NAME;
Die Datenbank ist allerdings durchaus nicht-trivial. Viele Daten sind nicht als gewöhnliche Spalten verfügbar, sondern müssen über Funktionen abgefragt werden. Auch die postgresql-Datenbank ist hoch belastet; Verbindungsfehler oder Timeouts sind nicht ungewöhnlich.
Um eine Ausgangsbasis für mögliche Abfragen in der Datenbank zu erhalten, kann man wieder die Webseite https://crt.sh verwenden: Fügt man an das Ende einer Suche den Parameter showSQL=Y
an, zeigt crt.sh die zugehörige Datenbankabfrage.
Beispiel:
https://crt.sh/?dNSName=%25.example.org&exclude=expired&deduplication=Y&showSQL=Y
(Jürgen Brauckmann, 11.01.2021)
Auch dieses Jahr wurde die DFN-PKI auditiert, um die Erfüllung der Anforderungen von ETSI EN 319 411-1 und den Baseline Requirements des CA/Browserforums nachweisen zu können. Wie bei jedem Audit, der bisher durchgeführt wurde, wurde bei einer geringen Anzahl von Teilnehmern die Arbeit des Teilnehmerservice untersucht.
Wir bedanken uns bei allen Einrichtungen, die wie auch in den letzten Jahren mit ihrer guten Arbeit ein erfolgreiches Audit der DFN-PKI ermöglicht haben!
Die zugehörige Zertifizierungsurkunde ist Anfang Dezember vom TÜViT veröffentlicht worden: https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/67133UD.pdf
(Jürgen Brauckmann, 10.12.2020)
Ab 07.10.2020 werden wir, wie auf der Betriebstagung des DFN-Vereins angekündigt und mit der Zertifizierungsrichtline der DFN-PKI im Sicherheitsniveau „Global“ in Version 6 vorbereitet, die Validierung von IP-Adressen, die in Zertifikate für Datenverarbeitungssysteme aufgenommen werden sollen, erneut umstellen.
Das nun umgesetzte Verfahren nach den Baseline Requirements des CA/Browser-Forums, Kap. 3.2.2.5.3, sieht vor, dass zu jeder IP-Adresse, die aufgenommen werden soll, ein Reverse Lookup durchgeführt wird. Ist einer der Namen, die als Ergebnis geliefert wurden, über eine bestehende Domain-Freischaltung im zuständigen Teilnehmerservice zugelassen, so kann auch die IP-Adresse in das Zertifikat aufgenommen werden.
Das bisherige Verfahren mit einer statischen Whitelist auf unseren Systemen, die per Hand gepflegt und mit Whois abgeglichen wurde, wird eingestellt.
Bestehende Zertifikate mit IP-Adressen, die nach der alten Methode geprüft wurden, bleiben natürlich unverändert gültig.
Bevor Sie sich die Mühe machen, eine IP-Adresse in einen Request aufzunehmen, sollten Sie genau prüfen, ob Sie wirklich ein Zertifikat mit einer IP-Adresse benötigen. Wird Ihr Dienst wirklich direkt per IP-Adresse angesprochen? Falls nicht, verzichten Sie auf die IP-Adresse im Zertifikat.
(Jürgen Brauckmann, 05.10.2020)
Mit der Einführung der Domain-Freischaltungen für Zertifikate per Challenge-E-Mail Ende Mai 2018 kommen seit dem 24. August 2020 nun langsam FIFO-artig die ersten damals freigeschalteten Domains in die Phase, in der der Freischaltungszeitraum (824 Tage) bald ausläuft oder bereits abgelaufen ist. Ist die Freischaltung bereits abgelaufen, so muss diese entweder erneuert werden oder es können keine neuen Zertifikate mehr für die betroffenen Domains beantragt und ausgestellt werden.
Um die Domain-Freischaltung für Zertifikate zu erneuern, muss durch die DFN-PKI Teilnehmerservice-MitarbeiterInnen, die im Besitz eines TS-Operator-Zertifikats sind, über die Java RA-Oberfläche in den Bereichen „Konfiguration->Server/E-Mail-Domains“ für die betroffenen rot markierten Domains zunächst eine erneute Challenge-E-Mail versendet werden, auf die die Empfänger der Challenge-E-Mail dann entsprechend reagieren müssen. Alle Domains deren Freischaltung bereits abgelaufen ist oder deren Freischaltung innerhalb der nächsten 30 Tage ausläuft sind in der entsprechenden Übersichtsliste (Server-Domains, E-Mail-Domains) rot markiert.
Ein Doppelklick auf die betroffene Domain und ein Klick auf „Speichern“ im folgenden Fenster lösen den Versand einer frischen Challenge-E-Mail an die im vorherigen Freischaltungsdurchgang ausgewählte E-Mail-Adresse aus.
Falls für eine Domain eine der Standard-Adressen ausgewählt war und zwischenzeitlich kein MX DNS-Record mehr für diese Domain existiert, muss beim Erneuern der Freischaltung eine andere der angebotenen E-Mail-Adressen ausgewählt werden, ebenso falls sich die E-Mail-Adresse des Zonenkontakts aus dem SOA DNS-Record der Domain geändert hat.
Im laufenden Betrieb des DFN-PKI Teilnehmerservices in den Einrichtungen vor Ort kommen über die Zeit einzelne neue Domains, für die Zertifikate ausgestellt werden sollen, hinzu, und für andere Domains sollen evtl. keine Zertifikate mehr ausgestellt werden. Bei letzteren muss geprüft werden, ob die Domains aus der Domain-Verwaltung der Java RA-Oberfläche, ggf. nach Sperrung von noch gültigen Zertifikaten, gelöscht werden sollen. Damit sich die Situation der auslaufenden Freischaltungen über die Zeit nicht komplett zerfasert und beispielsweise in jedem Monat einige wenige Freischaltungen ablaufen, kann es gegebenenfalls sinnvoll sein, jährlich oder zweijährlich zu einem bestimmten Termin alle bestehenden Freischaltungen auf einen Schlag zu erneuern. Damit liegen dann die zukünftigen Ablauftermine aller in dem Durchgang erneuerten Domain-Freischaltungen innerhalb eines deutlich kleineren Zeitfensters zusammen und durch die jährliche bzw. zweijährliche Wiederholung werden zwischenzeitliche Neuzugänge auch wieder eingefangen.
(rkm, 25.09.2020)
Zum 30.09.2020 tritt die Zertifizierungsrichtlinie 8 im Sicherheitsniveau „Global“ in Kraft. Änderungen in Version 8:
Die Version 8 der Erklärung zum Zertifizierungsbetrieb für das Sicherheitsniveau „Global“, Datum Inkrafttretens ebenfalls 30.09.2020, beinhaltet folgende Änderungen:
Die neuen Dokumente finden Sie unter den folgenden URLs:
https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_V8.pdf
https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CPS_V8.pdf
Mit Änderungsmarkierungen:
https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_V8_redline.pdf
https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CPS_V8_redline.pdf
(Jürgen Brauckmann, 15.09.2020)
Die Java RA-Oberfläche für den Teilnehmerservice der DFN-PKI können Sie in der Version 3.3 hier herunterladen:
Entpacken Sie das ZIP-Archiv. In den Dateien README.txt und Anleitung_Windows.pdf finden Sie weitere Hinweise zur Installation und Inbetriebnahme.
Version 3.3 (16.06.2020)
Die enthaltenen Startskripte erwarten eine gesetzte Umgebungsvariable JAVA_HOME. Hinweise hierfür finden Sie in den Dateien README.txt und Anleitung_Windows.pdf.
Hinweise zum Bezug von Java finden Sie unter: https://blog.pki.dfn.de/2019/05/bezugsquellen-fuer-java-zum-betrieb-der-ra-oberflaeche
Die RA-Oberfläche speichert die Einstellungen in Ihrem Home-Verzeichnis im Verzeichnis .dfn-pki. Sie können das entpackte ZIP-Archiv mit den ausführbaren Dateien beliebig verschieben, löschen oder neu herunterladen, ohne dass Sie die Einstellungen verlieren.
(Jürgen Brauckmann, 04.08.2020)
Im Februar deutete sich an, dass die Laufzeit der ab Anfang September neu ausgestellten Serverzertifikate von 27 Monaten auf ca 13 Monate (398 Tage) verkürzt werden muss (Siehe „Mögliche weitere Reduzierung der Laufzeit von Serverzertifikaten„). Inzwischen wurde diese Anforderung auch in die Baseline Requirements des CA/Browser Forums aufgenommen. Die DFN-PKI hat die Laufzeitverkürzung mit der Version 7 der Zertifizierungsrichtlinie umgesetzt.
Die DFN-PKI wird im Laufe des 27.08.2020 (also ein paar Tage vor der Frist) die Konfiguration so anpassen, dass neu ausgestellte Serverzertifikate eine Laufzeit von 397 Tagen haben. Die 397 Tage sind eine SHOULD-Regel des CA/Browser Forums.
Die Teilnehmer der DFN-PKI müssen nichts besonderes beachten. Die Laufzeit von neu ausgestellten Zertifikaten wird automatisch gesetzt. Bereits bestehende, noch gültige Zertifikate mit längerer Laufzeit können ganz normal verwendet werden und zu ihrem vorgesehenen Zeitpunkt ablaufen.
Die Änderung ist für alle Zertifikate wirksam, die für Datenverarbeitungssysteme ausgestellt werden. Nutzerzertifikate sind nicht betroffen.
(Jürgen Brauckmann, 27.07.2020)
Zum 03.06.2020 tritt die Zertifizierungsrichtlinie 7 im Sicherheitsniveau „Global“ in Kraft. Änderungen in Version 7:
Die Version 7 der Erklärung zum Zertifizierungsbetrieb für das Sicherheitsniveau „Global“, Datum des Inkrafttretens ebenfalls 03.06.2020, beinhaltet folgende Änderungen:
Die neuen Dokumente finden Sie unter den folgenden URLs:
https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_V7.pdf
https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CPS_V7.pdf
Mit Änderungsmarkierungen:
https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_V7_redline.pdf
https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CPS_V7_redline.pdf
(Jürgen Brauckmann, 18.05.2020)
Zum 03.04.2020 tritt die Zertifizierungsrichtlinie 6 im Sicherheitsniveau „Global“ in Kraft. Änderungen in Version 6:
Die Version 6 der Erklärung zum Zertifizierungsbetrieb für das Sicherheitsniveau „Global“, Datum des Inkrafttretens ebenfalls 03.04.2020, beinhaltet folgende Änderungen:
Die neuen Dokumente finden Sie unter den folgenden URLs:
https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_V6.pdf
https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CPS_V6.pdf
Mit Änderungsmarkierungen:
https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_V6_redline.pdf
https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CPS_V6_redline.pdf
(Jürgen Brauckmann, 20.03.2020)