Archiv des Autors: Juergen Brauckmann

Überwachen der Zertifikate zu eigenen Domains mit Certificate Transparency

[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:

  • Weitere Datenbasis für das Organisations-eigene Zertifikatmanagement
  • Schnelle Erkennung von fälschlich oder betrügerisch ausgestellten Zertifikaten, z.B. durch eigene Fehler oder Fehler/Schwachstellen bei der CA  (Bedingung: Die Mechanismen der CA zum Schreiben in die CT Logs wurden vom Angreifer nicht überwunden)
  • Zentrales Monitoring über die in der Organisation eingesetzten CAs
  • Erkennen von zusätzlichen Zertifikaten im Zusammenhang mit CDN- oder Cloud-Diensten

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.

crt.sh

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.

„leaf certificate“ und „Precertificate“

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.

crt.sh Datenbank

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.

showSQL=Y

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)

ETSI-Audit 2020 abgeschlossen

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)

Zum 07.10.2020: Umstellung des Verfahrens zur Validierung von IP-Adressen

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)

Version 8 der Zertifizierungsrichtlinie der DFN-PKI im Sicherheitsniveau „Global“

Zum 30.09.2020 tritt die Zertifizierungsrichtlinie 8 im Sicherheitsniveau „Global“ in Kraft. Änderungen in Version 8:

    • Titel und Fußzeile: Versionsnummer und Datum.
    • 1.2: OIDs
    • 1.5.2 und 4.9: Telefonnummer entfernt
    • 4.9.8: Zeitspanne korrigiert
    • 4.9.10: Synchronität zwischen OCSP und CRL
    • 5.2.1 Bearbeitung eigener Anträge durch TS-MA konkretisiert
    • Kapitel 8.1-8.4 neu sortiert
    • 9.17: Accessibility, Aktualisierung CP, Sicherheitskonzept, Assets, Management Approval

Die Version 8 der Erklärung zum Zertifizierungsbetrieb für das Sicherheitsniveau „Global“, Datum Inkrafttretens ebenfalls 30.09.2020, beinhaltet folgende Änderungen:

      • Titel und Fußzeile: Versionsnummer und Datum
      • 1.2: OIDs
      • 5.1.1: Beschreibung der Gefahrenmeldeanlage ergänzt
      • 5.4.1: Entry/Exit und Verfügbarkeit+Auslastung
      • 5.4.8: Beschreibung Vulnerability Scan und Penetration Tests
      • 6.6.2: Change Control
      • 6.7: Netzwerktrennung

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)

Java RA-Oberfläche Version 3.3

Die Java RA-Oberfläche für den Teilnehmerservice der DFN-PKI können Sie in der Version 3.3 hier herunterladen:

guira-3.3.zip

guira-3.3.zip.SHA256sum

Entpacken Sie das ZIP-Archiv. In den Dateien README.txt und Anleitung_Windows.pdf finden Sie weitere Hinweise zur Installation und Inbetriebnahme.

Änderungen

Version 3.3 (16.06.2020)

    • Spalte mit dem Namen des Antragsstellers (Kontakt-Namen) in Übersichtslisten hinzugefügt.
    • In der Detail-Ansicht von Sperr-Requests Unterzeichnerinformationen ergänzt.
    • PKCS#11SignatureProvider verwendet nun SHA256 für die Selbst-Signatur des Requests.
    • Probleme bei der Listenansicht bei Verwendung eines dunklem Themes behoben.
    • Fehler beim Exportieren von Zertifikaten mit ‚/‘ im CN behoben.
    • Zertifikatspolling in Assistenten resililienter gegen Netzwerkprobleme gemacht.

Systemvoraussetzungen

  • OpenJDK ab Version 11
  • Andere aktuelle Java Umgebungen können auch verwendet werden. Bitte beachten Sie hierzu: In unseren Abnahmetests verwenden wir ausschließlich OpenJDK.

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

Konfiguration

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)

Ende August 2020: Reduzierung der Laufzeit von Serverzertifikaten

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)

Version 7 der Zertifizierungsrichtlinie der DFN-PKI im Sicherheitsniveau „Global“

Zum 03.06.2020 tritt die Zertifizierungsrichtlinie 7 im Sicherheitsniveau „Global“ in Kraft. Änderungen in Version 7:

  • Titel und Fußzeile: Versionsnummer und Datum.
  • 1.2: OIDs
  • 1.5.2: E-Mail-Adresse für Problem Reports
  • 3.2.2: Validierung von IP-Adressen auch nach Methode 3.2.2.5.3 der BR möglich. Abgelaufene Methode entfernt.
  • 3.2.3: Anpassung an Umstellung von PostIdent
  • 4.9: E-Mail-Adresse, Klarstellung Bearbeitung
  • 6.3.2: Anpassung der Laufzeit von Zertifikaten für Datenverarbeitungssysteme nach Apples Vorgaben ab 01.09.2020
  • 6.4.2: Umstellung des Schutzes von Aktivierungsdaten

Die Version 7 der Erklärung zum Zertifizierungsbetrieb für das Sicherheitsniveau „Global“, Datum des Inkrafttretens ebenfalls 03.06.2020, beinhaltet folgende Änderungen:

  • Titel und Fußzeile: Versionsnummer und Datum
  • 1.2: OIDs

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)

Version 6 der Zertifizierungsrichtlinie der DFN-PKI im Sicherheitsniveau „Global“

Zum 03.04.2020 tritt die Zertifizierungsrichtlinie 6 im Sicherheitsniveau „Global“ in Kraft. Änderungen in Version 6:

  • Titel und Fußzeile: Versionsnummer und Datum.
  • 1.2: OIDs
  • 4.9.7 und 7.2: Anpassungen der Regeln zum Ausstellen von Sperrlisten

Die Version 6 der Erklärung zum Zertifizierungsbetrieb für das Sicherheitsniveau „Global“, Datum des Inkrafttretens ebenfalls 03.04.2020, beinhaltet folgende Änderungen:

  • Titel und Fußzeile: Versionsnummer und Datum
  • 1.2: OIDs

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)

DFN-PKI und COVID-19

[Version 6, Scan ergänzt: 06.05.2020, Jürgen Brauckmann
Version 5, Video-Identifizierung: 23.04.2020, Jürgen Brauckmann
Version 4: 26.03.2020, Jürgen Brauckmann
Version 3: 25.03.2020, Reimer Karlsen-Masur
Version 2: 18.03.2020, Jürgen Brauckmann
Version 1: 17.03.2020, Jürgen Brauckmann]

Wir möchten Ihnen an dieser Stelle Informationen zum Betrieb der DFN-PKI in der aktuellen Corona-Krise geben.

DFN-PCA-Betrieb

Für die DFN-PCA in Hamburg stellen wir die Erreichbarkeit über die Telefonnummer 040 80 80 77 580 sicher, sind aber für eine primäre Kontaktaufnahme per E-Mail (mailto:dfnpca@dfn-cert.de) dankbar.

Die Bearbeitung von per Post eingehenden Anträgen für Teilnehmerservice-Zertifikate ist sichergestellt.

Neubeantragung von Nutzerzertifikaten

Bei der Neuausstellung von Nutzerzertifikaten (auch von Pseudonym-Zertifikaten) ist in der DFN-PKI eine persönliche Identifizierung erforderlich. Diese findet im Rahmen eines persönlichen Treffens statt, bei der der Teilnehmerservice die Identität anhand eines amtlichen Ausweisdokumentes mit Lichtbild überprüft.

Wenn der direkte Kontakt zwischen Teilnehmerservice und Antragsteller vermieden werden muss, gibt es die folgenden Alternativen.

Eine persönliche Identifizierung ist selbstverständlich auch in einer klassischen Schaltersituation hinter einer Trennscheibe möglich.

Video-Identifizierungen durch den Teilnehmerservice

Seit Ende April 2020 steht ein Verfahren zur Identifizierung über Video-Chat zur Verfügung, dass jeder Teilnehmerservice selbst durchführen kann. Voraussetzung hierfür ist eine gründliche Durchsicht der Richtlinie zur Video-Identifizierung und eine einmalige Dokumentation der Selbstschulung. Als Zusatz zum normalen Antragsformular muss eine separate Checkliste Video-Identifizierung verwendet werden, um einen korrekten Ablauf sicherzustellen.

Alle Dokumente und die Checkliste, die zu dem Verfahren gehören, finden Sie unter:
https://www.pki.dfn.de/policies/videoident/

Identifizierungen durch Dienstleister

Der Einsatz eines Dienstleisters für Identifizierungen, der eine Zertifizierung für Zwecke des TKG oder Geldwäschegesetz hat, ist möglich. Der DFN-Verein kann aber leider nicht als Vermittler auftreten. Es ist ein Vertrag zwischen Ihrer Einrichtung und dem Anbieter erforderlich.

Gruppenzertifikate

Für geeignete Anwendungsfälle können auch Gruppenzertifikate („GRP:“ und „GRP – „) ausgestellt werden. Diese können ohne persönliche Identifizierung ausgestellt werden. So kann der individuelle Anwendungsfall im Subject des Zertifikats angegeben werden, bspw. „GRP: Max Mustermann VPN-Login“. Bitte beachten Sie hierbei aber, dass keine „gerichtsfeste“ Verbindung von Aktionen, die mit diesem Zertifikat durchgeführt werden zu genau einer natürlichen Person möglich ist. Gruppenzertifikate eignen sich somit mehr für interne Anwendungsfälle in der Einrichtung und weniger für die Signatur von E-Mails etc. die die Einrichtung verlassen – es sei denn, es handelt sich um Role-Accounts (bspw. „GRP: HS Musterstadt User Support“).

Hinweis: Dies ist streng zu unterscheiden von Pseudonym-Zertifikaten („PN:“ bzw. „PN – „). Diese werden in praktisch jeder Hinsicht wie Nutzerzertifikate behandelt.

Verlängerung von Nutzerzertifikaten

Post / Fax / Scan: Wenn der Nutzer innerhalb der letzten 39 Monate identifiziert wurde, und Sie das alte Antragsformular vorliegen haben, können Sie sich das neue handschriftlich unterschriebene Antragsformular per Post, Fax oder als Scan schicken lassen. Voraussetzung:

  • Sie müssen das alte Antragsformular physikalisch vorliegen haben (Also z.B. aus einem Archiv hervor suchen).
  • Prüfung der Unterschrift:
    • Sie müssen die Unterschrift des Antragsstellers eindeutig der Unterschrift auf dem alten Antragsformular zuordnen können.
  • Prüfung der letzten Identifizierung:
    • Wurde auf dem alten Antragsformular eine Identifizierung vorgenommen und ist diese nicht älter als 39 Monate? (Block „Identitätsprüfung“ vollständig ausgefüllt. Nicht „Identität bereits früher geprüft“ mit Datum älter 39 Monate.)
  • Prüfung des Namens:
    • Der Name des Antragsstellers darf sich nicht geändert haben. Der Name im beantragten Zertifikat muss mit dem Namen auf dem alten Antragsformular übereinstimmen.

Wenn der Name des Nutzers sich nicht geändert hat, Sie die Unterschriften erfolgreich vergleichen konnten und die letzte Identifizierung nachweislich nicht länger als 39 Monate alt ist, können Sie das Zertifikat ausstellen ohne den Nutzer persönlich gesehen oder erneut identifiziert zu haben.

Signierte E-Mail: Alternativ kann auch ein Antragsformular ohne handschriftliche Unterschrift per signierter E-Mail eingeschickt werden. Auch hier muss der alte archivierte Antragsformular vorliegen, um Prüfungen vornehmen zu können. Es sind folgende Vorgaben zur Prüfung der E-Mail-Signatur und zur sicheren Archivierung zu erfüllen.

  • Eingang des PDF-Antrags mit signierter E-Mail
  • Ausdruck des PDF-Antrags
  • Prüfung der Signatur der E-Mail:
    • Gültige Signatur und gültiges Zertifikat exakt des Antragsstellers?
    • Name des Antragsstellers im Zertifikat identisch mit beantragtem Namen?
    • Zertifikat nicht abgelaufen?
    • Zertifikat nicht gesperrt?
  • Prüfung der letzten Identifizierung:
    • Wurde auf dem alten Antragsformular eine Identifizierung vorgenommen und ist diese nicht älter als 39 Monate? (Block „Identitätsprüfung“ vollständig ausgefüllt. Nicht „Identität bereits früher geprüft“ mit Datum älter 39 Monate.)
  • Prüfung des Namens:
    • Der Name des Antragsstellers darf sich nicht geändert haben. Der Name im beantragten Zertifikat muss mit dem Namen auf dem alten Antragsformular übereinstimmen.
  • Dokumentation auf dem ausgedruckten Antrag, Ausfüllen der Felder des Teilnehmerservice
  • Geeignete Archivierung der signierten E-Mail, z.B. Abspeichern als Datei in einem geeignetem Verzeichnis oder Kopieren in einen dedizierten IMAP-Ordner. Achtung: Für dieses Archiv gilt die Aufbewahrungsfrist aus Kapitel 5.5.2 der Erklärung zum Zertifizierungsbetrieb: 7 Jahre nach Ablauf des Zertifikats!
  • Wenn Sie Ihr Archiv später konsolidieren wollen, um etwa nicht zwei unterschiedliche PKI-Archive pflegen zu müssen, können Sie die handschriftlichen Unterschriften der Antragssteller später nachholen und Ihr elektronisches Archiv wieder auflösen. Die Dokumentation der Prüfschritte muss aber stets vor Ausstellung des Zertifikats geschehen.

Wir raten Ihnen dringend, die unterschriebenen Papieranträge im Original einzufordern, da dort die Datenschutzeinwilligung enthalten ist.

Serverzertifikate

Bei Serverzertifikaten ist keine persönliche Identifizierung des Antragsstellers erforderlich. Sie müssen lediglich garantieren, dass die Berechtigung gegeben ist.

Übermittlung der Anträge von Serverzertifikaten

Post / Fax / Scan: Wenn Sie in der Lage sind, aus der handschriftlichen Unterschrift des Antragsstellers eine Zuordnung und eine Berechtigungsprüfung abzuleiten, können Sie per Post, Fax oder als Scan eingehende Anträge bearbeiten. Das Verfahren der Zuordnung / Berechtigungsprüfung ist von der DFN-PKI nicht zentral vorgegeben, da die Gegebenheiten in den Einrichtungen zu unterschiedlich sind. Das Verfahren darf nicht angewandt werden, wenn Sie keine Möglichkeit zur Prüfung von Unterschriften oder anderen Authentifizierungsmerkmalen haben. Andernfalls können Sie nicht verhindern, dass Ihnen ein Unbefugter einen Antrag unterschiebt.
Signierte E-Mail: Prinzipiell können Anträge für Serverzertifikate papierlos per signierter E-Mail zum Teilnehmerservice gelangen. Allerdings müssen zusätzliche Prüfschritte durchlaufen und dokumentiert werden. Hierzu müssen Sie folgendermaßen vorgehen:

  • Eingang des PDF-Antrags mit signierter E-Mail
  • Ausdruck des PDF-Antrags
  • Prüfung der Signatur der E-Mail:
    • Gültige Signatur und gültiges Zertifikat eines Berechtigten?
    • Zertifikat nicht abgelaufen?
    • Zertifikat nicht gesperrt?
  • Dokumentation auf dem ausgedruckten Antrag, Ausfüllen der Felder des Teilnehmerservice
  • Geeignete Archivierung der signierten E-Mail, z.B. Abspeichern als Datei in einem geeignetem Verzeichnis oder Kopieren in einen dedizierten IMAP-Ordner. Achtung: Für dieses Archiv gilt die Aufbewahrungsfrist aus Kapitel 5.5.2 der Erklärung zum Zertifizierungsbetrieb: 7 Jahre nach Ablauf des Zertifikats!
  • Wenn Sie Ihr Archiv später konsolidieren wollen, um etwa nicht zwei unterschiedliche PKI-Archive pflegen zu müssen, können Sie die handschriftlichen Unterschriften der Antragssteller später nachholen und Ihr elektronisches Archiv wieder auflösen. Die Dokumentation der Prüfschritte muss aber stets vor Ausstellung des Zertifikats geschehen.

Das Verfahren darf nicht angewandt werden, wenn Sie keine Möglichkeit zur authentifizierten Übermittlung der Anträge (eben durch signierte E-Mails) haben. Andernfalls können Sie nicht verhindern, dass Ihnen ein Unbefugter einen Antrag unterschiebt.

Erzeugung von Serverzertifikaten durch den Teilnehmerservice-Mitarbeiter

Bei Serverzertifikaten tritt die Einrichtung (juristische Person) als Antragsteller auf und nicht der individuelle Mitarbeiter (natürliche Person). Es ist daher aus PKI-Sicht grundsätzlich nichts dagegen einzuwenden, dass der Teilnehmerservice-Mitarbeiter Serverzertifikate selber beantragt und ausstellt.

Es gibt hierfür bereits ein Werkzeug: In der Java RA-Oberfläche finden Sie im Menü „Assistenten“ den Punkt „Serverzertifikat erstellen“, der die Erzeugung von privatem Schlüssel und Antrag und dessen Genehmigung automatisiert.

Eine Voraussetzung hierfür ist die Beachtung der folgenden Bedingung zur Nutzung von Serverzertifikaten (festgeschrieben zum einen im Antragsformular, zum anderen in „Informationen für Zertifikatinhaber“:

Der private Schlüssel darf nur Administratoren der im Zertifikat genannten Server zugänglich sein.

Sollte Ihr Teilnehmerservice also die Definition eines Administrators erfüllen (z.B. weil dieser direkt im Rechenzentrum angesiedelt ist), können Sie das Verfahren sofort umsetzen.

Voraussetzung: Sie müssen sichere Kommunikationskanäle haben, um die vom Teilnehmerservice erzeugten privaten Schlüssel übertragen zu können. Sie dürfen das Verfahren nicht anwenden, wenn Sie keine Möglichkeit haben, die Schlüssel sicher auf die Server zu übertragen.

Newsticker für weitere Dienste im DFN

Auf dem COVID-19-Newsticker vom DFN finden Sie Status-Updates für weitere DFN-Dienste.