Archiv der Kategorie: Uncategorized

SOAP-Client Version 3.8/4.0.1

Das Bundle mit der Dokumentation und der Java-Client-Bibliothek der SOAP-Schnittstelle der DFN-PKI steht nun in neuen Versionen bereit. Wesentliche Neuerung ist die Verwendung von BouncyCastle 1.60.

Für JDK 11: https://info.pca.dfn.de/doc/soapclient-bundle-4.0.1.tar.gz

Für JDK 8 (Umstieg auf JDK 11 empfohlen): https://info.pca.dfn.de/doc/soapclient-bundle-3.8.tar.gz

Für Entwicklungsarbeiten empfehlen wir dringend, dass Sie unsere Test-PKI verwenden. Sprechen Sie uns bitte an, um einen Zugang zu erhalten. Kontakt: mailto:dfnpca@dfn-cert.de

Bitte beachten Sie, dass Sie bei der Implementierung von eigenen Systemen unbedingt die Vorgaben der Zertifizierungsrichtlinie und des Dokumentes Pflichten der Teilnehmer einhalten müssen. Bitte besprechen Sie Ihr Projekt vorab mit uns. Kontakt: mailto:dfnpca@dfn-cert.de

(Jürgen Brauckmann, 03.04.2019)

Let’s DFN-PKI!

Häufig wird in letzter Zeit die Frage nach dem Verhältnis der DFN-PKI zu Let’s Encrypt oder nach der Unterstützung des ACME-Protokolls gestellt. Es muss hierbei beachtet werden, was genau gemeint ist: Häufig wird ACME und Let’s Encrypt in einen Topf geworfen, was die Beantwortung der Frage nicht einfacher macht: Soll die DFN-PKI wirklich ACME sprechen oder soll sie so (einfach) funktionieren wie Let’s Encrypt?

Um diese Frage zu beantworten, müssen zwei Aspekte erst einmal getrennt betrachtet werden:

  1. Was ist der Unterschied zwischen der DFN-PKI und Let’s Encrypt?
  2. Unterstützt die DFN-PKI das ACME-Protokoll bzw. ist dies geplant?

Was ist der Unterschied zwischen der DFN-PKI und Let’s Encrypt?

Ganz einfach: Let’s Encrypt stellt domainvalidierte (DV) Serverzertifikate aus, die DFN-PKI stellt organisationsvalidierte (OV) Serverzertifikate aus. Aber was heißt das konkret? Das bereitgestellte Vertrauensniveau soll hier anhand der Aussage eines Serverzertifikats verglichen werden:

Zunächst das OV-Zertifikat, z.B. aus der DFN-PKI:

„Der Server www.example.com hat den öffentlichen Schlüssel 123456. Das Zertifikat wurde der Organisation XYZ ausgestellt und die Berechtigung dieser Organisation zur Verwendung der Domain in einem Zertifikat wurde geprüft. Die Rechtsperson Organisation XYZ sitzt in Land A in Stadt B in Bundesland C.“

Nun die Aussage eines DV-Zertifikats:

 „Der Server www.example.net hat den öffentlichen Schlüssel 987654“

DV-Zertifikate treffen also keine Auskunft darüber, wer den Server betreibt oder wo derjenige zu finden wäre. Das heißt, DV-Zertifikate taugen nur für die Verschlüsselung der übertragenen Daten. Die Authentisierung der juristischen Person des Verantwortlichen für den Server entfällt vollständig. Das bedeutet wiederum, dass für einen Nutzer nicht ersichtlich ist, ob er auf der richtigen Webseite ist. Dies lässt sich an www.dfn.de und www.dfn.com veranschaulichen. Beide Webseiten könnten problemlos mit validen DV-Serverzertifikaten geschützt sein. Ein Nutzer könnte dann aber nicht erkennen, ob er mit der Webseite der Organisation kommuniziert, die er intendiert hat (www.dfn.de vom DFN-Verein e.V.) oder einem völlig unbeteiligten Dritten. Noch schlimmer wird es, wenn diese Verwechslungsgefahr von Angreifern böswillig ausgenutzt wird.

Bei DV-Zertifikaten ist also lediglich die Kommunikation verschlüsselt, was Man-In-The-Middle-Angriffe verhindert. Sollte ein Betreiber aber in bösartiger Absicht www.dfn.de mit einer ähnlichen Domain und einem völlig validen DV-Serverzertifikat für diese Domain imitieren, beispielsweise um Passwörter abzugreifen, bestünde kein Schutz dagegen. Im Gegenteil würden sich viele Nutzer durch das Schloss in der URL-Zeile des Browsers möglicherweise sogar bestätigt sehen, eine „sichere“ Verbindung zu haben und daher ihr Passwort arglos eingeben.

Die zusätzlichen Aussagen zum Betreiber der Webseite bei Organisationsvalidierung (Organisationsname, Land, Ort und Bundesland) müssen durch die CA validiert werden. Diese Schritte sind in der DFN-PKI notwendig und erzeugen den wahrnehmbaren Overhead zu domainvalidierten Zertifikaten. Alle diese Werte können aber in den DFN-PKI für die betreffenden Domains vorab validiert werden, d.h. vor einer tatsächlichen Antragsstellung für Zertifikate unter dieser Domain. Wenn alle Werte für hs-pellworm.de vorab validiert sind, kann die Ausstellung aller konkreten Zertifikate mit FQDNs mit dieser Domain ohne erneute Validierung durch die DFN-PKI geschehen[1].

Unterstützt die DFN-PKI das ACME-Protokoll oder ist das geplant?

Das ACME-Protokoll wird in der DFN-PKI derzeit nicht unterstützt, ist aber perspektivisch in der Tat sehr interessant. ACMEv1 war allerdings nicht mächtig genug für die Organisationsvalidierung. Das ist mit ACMEv2 inzwischen besser geworden und ACME wurde als RFC 8555 von der IETF standardisiert. Die Umsetzung einer ACME-Schnittstelle in der DFN-PKI bringt allerdings signifikante Softwareentwicklungs-Aufwände mit sich, die wohl überlegt sein wollen.

Derzeit besteht mit der SOAP-Schnittstelle der DFN-PKI schon eine etablierte Schnittstelle, mit der ähnliche Workflows wie mit ACME umgesetzt werden können. Diese Schnittstelle ist zwar nicht standardisiert, die Softwareentwicklung gegen diese Schnittstelle wird von der DFN-PKI aber mit Beispiel-Implementierungen und API-Dokumentationen unterstützt. Der Vorteil der Unterstützung von ACME wäre also auf eine Unterstützung durch zunehmend Verbreitung findende ACME-Client-Tools beschränkt. Komplett neue Workflows, die derzeit nicht möglich wären, ergeben sich aber nicht unbedingt.

Darüber hinaus gibt es noch eine weitere Argumente, die zumindest dagegen sprechen, dass eine ACME-Unterstützung das „Allheilmittel“ für die effiziente Serverzertifikaterstellung in der DFN-PKI wäre:

  • Für einige Appliances/Softwares, die jetzt ACME mit Bordmitteln können, gilt, dass sie auf Let’s Encrypt hart verdrahtet sind – Es brächte also in diesen Fällen keinen Vorteil, wenn die DFN-PKI eine ACME-Schnittstelle anböte.
  • Die ACME-Tools funktionieren im Wesentlichen auf „normalen“ (Web-)Servern, die auch Verbindungen nach Außen aufmachen können/dürfen. Appliances, Access Points, Firewalls, interne Server ohne Außenkommunikation,… unterstützen in der Regeln kein ACME, benötigen aber auch häufig Server-Zertifikate. Dies müsste also auch bei der Verwendung von ACME mittels eigener Software auf dedizierten „Zertifikatsantragsmaschinen“ automatisiert werden – diese könnten dann aber auch gleich gegen die DFN-PKI SOAP-Schnittstelle entwickelt werden.
  • Es bleiben die Validierungspflichten von OV – so einfach wie Let’s Encrypt wird es also auch mit ACME nicht, manuelle Schritte bleiben notwendig (auch wenn diese, wie bereits jetzt, größtenteils vor der ersten Beantragung für eine Domain erledigt werden können).

Ein derzeit notwendiger manueller Schritt ist die Freigabe des Zertifikatantrags durch den Teilnehmerservice der DFN-PKI vor Ort anhand des Papierantrags, der bei der Beantragung als PDF erzeugt wird und ausgedruckt, unterschrieben und geprüft werden muss. Wenn dieser manuelle und analoge Schritt entfiele, wäre das für viele Workflows hilfreicher als die Umstellung von der DFN-PKI SOAP-Schnittstelle auf ACME. Daher konzentriert sich das Team der DFN-PKI derzeit weniger auf die Einführung der ACME-Schnittstelle als auf die Umstellung auf eine papierlose Zertifikatbeantragung für Serverzertifikate.

Fazit

ACME ist mittelfristig für die DFN-PKI ein interessanter Standard, um die SOAP-Schnittstelle abzulösen. Dies sollte aber erst passieren, wenn die bestehende SOAP-Schnittstelle „End of Life“ ist und sowieso eine Neuentwicklung ansteht, da sich keine grundlegend neuen oder effizientere Workflows durch die Umstellung auf ACME ergeben. Dies jetzt vorzuziehen würde Entwicklerkapazitäten binden, die derzeit an anderen Stellen der DFN-PKI sinnvoller eingesetzt werden.

Domainvalidierte Zertifikate wie die von Let’s Encrypt eignen sich gegebenenfalls für den privaten Gebrauch oder für Testumgebungen, Prototypen, etc. um niederschwellig an ein „echtes“ Serverzertifikat zu kommen. Auf Produktivsystemen sollte man sich aber sehr genau überlegen, ob das niedrigere Vertrauensniveau der Domainvalidierung ausreicht und ob die ACME-Tools überhaupt auf allen beteiligten Systemen lauffähig sind und auch zu den Validerungsservern der gewünschten CA kommunizieren dürfen/können.

Zur Vereinfachung von Workflows zur Ausstellung von Serverzertifikaten in der DFN-PKI wird derzeit die papierlose Beantragung von Serverzertifikaten konzipiert. Dies in Kombination mit der bestehenden SOAP-Schnittstelle erlaubt weitestgehend die gleichen Workflows wie bei der Verwendung des ACME-Protokolls. Dabei wird aber das Vertrauensniveau der DFN-PKI mit organisationsvalidierten Zertifikaten unter einer vertrauenswürdigen Root-CA und dem vertrauenswürdigen Betrieb der Sub-CAs durch den DFN-Verein genutzt, was bei einem Wechsel zu einem domainvalidierenden Anbieter nicht der Fall wäre.

(Ralf Gröper, 27.03.2019)

[1] Alle 825 Tage (=ca. 2,25 Jahre) müssen die Werte re-validiert werden. Das geschieht für Name, Land, Stadt und Bundesland „hinter den Kulissen“ automatisch durch die DFN-PCA. Für die Domains passiert dies im Self-Service durch den Teilnehmerservice vor Ort mit wenigen Klicks in wenigen Sekunden.

E-Mail-Verteilerliste dfnpki-d

Wir haben nun auf listserv.dfn.de die E-Mail-Verteilerliste dfnpki-d@listserv.dfn.de eingerichtet. Die unmoderierte Liste soll den Austausch unter den Teilnehmern an der DFN-PKI befördern und die Diskussion von Problemen und die Verbreitung von Lösungsvorschlägen ermöglichen.

Eine Anmeldung ist für Teilnehmer möglich unter:

https://www.listserv.dfn.de/sympa/info/dfnpki-d

(jbr, 19.03.2019)

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

Zum 14.02.2019 tritt die Zertifizierungsrichtlinie 3.9 im Sicherheitsniveau „Global“ in Kraft.

Änderungen in Version 3.9:

  • 1.1: Policy NCP
  • 2.2: Link-Umbruch korrigiert
  • 3.2.2 1: Alte Domainvalidierungsmethoden entfernt (WhoIs, Domainautorisierungssschreiben)
  • 3.2.2 4: Reservierte IPV6-Adressen
  • 3.2.3: Alternative zu 5 Stellen PA-Nummer (nur!) für eID
  • 4.2.3 Bearbeitungsdauern: No Stipulation aufgelöst
  • 4.4.2: Zwangsveröffentlichung von Server-Zertifikaten über CTLog
  • 4.9.11: No Stipulation aufgelöst
  • 5.7.1: Schwachstellen nach 48 Stunden behandeln
  • 5.7.1: Information von Betroffenen nach Sicherheitsvorfällen
  • 6.8: No Stipulation aufgelöst
  • 7.1: Dokumentation zu 64 Bit Zufallszahlen in SN statt 20 korrigiert
  • 7.2.2: No Stipulation aufgelöst
  • 9.16.2: No Stipulation aufgelöst

Gleichzeitig ändert sich das begleitende Dokument „Erklärung zum Zertifizierungsbetrieb“ für das Sicherheitsniveau „Global“. Die neue Versionsnummer ist ebenfalls 3.9, die Änderungen sind:

  • 5.3.5: No Stipulation aufgelöst
  • 6.6.3: No Stipulation aufgelöst; umbenannt, um dem RFC-Template zu entsprechen

Die neuen Dokumente finden Sie unter den folgenden URLs:

https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_V3.9.pdf

https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CPS_V3.9.pdf

Mit Änderungsmarkierungen:

https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_V3.9_redline.pdf

https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CPS_V3.9_redline.pdf

(jbr, 28.01.2019)

ETSI-Audit 2018 abgeschlossen

Das Audit der DFN-PKI nach ETSI EN 319 411-1 wurde auch 2018 mit der Ausstellung der Zertifizierungsurkunde durch TÜViT erfolgreich abgeschlossen: https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/67122UD_s.pdf

Wie jedes Jahr fanden angekündigte und vorbereitete Besuche bei Teilnehmern der DFN-PKI statt, bei der die Arbeit des Teilnehmerservice stichprobenartig untersucht wurde. Wir bedanken uns bei allen Einrichtungen, die ein erfolgreiches Audit der DFN-PKI  ermöglicht haben!

(jbr, 08.01.2019)

Java RA-Oberfläche Version 3.0.1

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

guira-3.0.1.zip

guira-3.0.1.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.0.1 (12.12.2018)

  • Kommandozeilenparameter ‚dfnpki2:dfn-ca-global-g2‘ im Start-Skript ergänzt

Systemvoraussetzungen

  • OpenJDK ab Version 11
  • Oracle Java ab Version 11 kann auch verwendet werden. Bitte beachten Sie hierzu:
    • In unseren Abnahmetests verwenden wir OpenJDK
    • Bitte berücksichtigen Sie die geänderten Lizenzbedingungen für den nicht-privaten Einsatz von Oracle.

Die enthaltenen Startskripte erwarten eine gesetzte Umgebungsvariable JAVA_HOME. Hinweise hierfür finden Sie in den Dateien README.txt und Anleitung_Windows.pdf.

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.

Java Web Start

Oracle hat ab Version 11 Java Web Start entfernt. Für Teilnehmer, die noch Java 8 einsetzen, stellen wir weiterhin bis voraussichtlich Mitte 2019 eine Java Web Start-Version der RA-Oberfläche zur Verfügung. Achtung: Die Java Web Start-Version erhält nur noch Sicherheitsupdates und keine Ergänzungen der Funktionalität!

https://pki.pca.dfn.de/guira/guira.jnlp

Bitte beachten Sie, dass Java 8 am Ende seines Lebenszyklus angekommen ist und ab Anfang 2019 keine öffentlichen Updates mehr erhält.

 

(jbr, 13.12.2018)

Java RA-Oberfläche Version 3.0

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

guira-3.0.zip

guira-3.0.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.0 (28.11.2018)

  • Anpassung an OpenJDK11
  • Aktualisierung der BouncyCastle Version auf 1.60.

Systemvoraussetzungen

  • OpenJDK ab Version 11
  • Oracle Java ab Version 11 kann auch verwendet werden. Bitte beachten Sie hierzu:
    • In unseren Abnahmetests verwenden wir OpenJDK
    • Bitte berücksichtigen Sie die geänderten Lizenzbedingungen für den nicht-privaten Einsatz von Oracle.

Die enthaltenen Startskripte erwarten eine gesetzte Umgebungsvariable JAVA_HOME. Hinweise hierfür finden Sie in den Dateien README.txt und Anleitung_Windows.pdf.

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.

Java Web Start

Oracle hat ab Version 11 Java Web Start entfernt. Für Teilnehmer, die noch Java 8 einsetzen, stellen wir weiterhin bis voraussichtlich Mitte 2019 eine Java Web Start-Version der RA-Oberfläche zur Verfügung. Achtung: Die Java Web Start-Version erhält nur noch Sicherheitsupdates und keine Ergänzungen der Funktionalität!

https://pki.pca.dfn.de/guira/guira.jnlp

Bitte beachten Sie, dass Java 8 am Ende seines Lebenszyklus angekommen ist und ab Anfang 2019 keine öffentlichen Updates mehr erhält.

 

(jbr, 12.12.2018)

Ablauf der alten Generation 1 der DFN-PKI Global

[Update 22.03.2019: Wichtig: SHA-1-CA-Zertifikate müssen komplett entfernt werden]

Die CA-Zertifikate der ersten Generation der DFN-PKI Global laufen nun ab. Zuerst sind die in 2007 erstellten, noch mit SHA-1 signierten CA-Zertifikate betroffen.

Achtung: Für diese alten CA-Zertifikate, die im Betrieb längst durch ihre mit SHA-2 signierten Pendants ersetzt worden sein sollten, werden von uns keine Zertifikatablaufwarnmails versandt.

Achtung: Wenn Sie auf Servern trotz der in den Auslieferungsmails der DFN-PKI mitgelieferten Kette noch eine Zwischenzertifizierungskette mit den alten SHA-1 CA-Zertifikaten beibehalten haben, kann es Ihnen passieren, dass diese Kette eher abläuft als das Serverzertifikat.

[Update 22.03.] Es kann sogar dann zu Problemen kommen, wenn neben den alten SHA-1 CA-Zertifikaten eine neue, gültige SHA-2-Kette vorhanden ist, da Serversoftware unter Umständen alte, ungültige Zertifikate bevorzugt (unlogischerweise).

Hierdurch werden dann unter Umständen Clients schlagartig nicht mehr auf die betroffenen Server zugreifen können. Betroffen sind alle Arten von Anwendungen, z.B. auch openvpn oder jabber.

Server unter Microsoft Windows sollten nicht betroffen sein, da hier die SHA-1 signierten CA-Zertifikate aufgrund von Policy-Entscheidungen von Microsoft sowieso nicht mehr verwendet werden können. Webserver sollten ebenfalls nicht betroffen sein, da Webbrowser Zertifizierungsketten mit SHA-1 CA-Zertifikaten schon seit längerem ablehnen.

Problembeschreibung

Die mit SHA-1 signierten CA-Zertifikate der DFN-PKI waren in 2007 mit einer Laufzeit von exakt 12 Jahren ausgestellt worden, wodurch sie über die erste Hälfte des Jahres 2019 verteilt ablaufen.

Im Jahr 2014 trafen die Browserhersteller die Entscheidung, ab Anfang 2017 mit SHA-1 signierte Zertifikate, auch von CAs, nicht mehr zu akzeptieren. Daraufhin wurden neue CA-Zertifikate mit SHA-2 ausgestellt. Diese erhielten die maximale Lebensdauer bis zum Ablauf der Root-Zertifikate.

Dadurch haben die SHA-2 CA-Zertifikate eine um teilweise wenige Monate längere Laufzeit als die zugehörigen SHA-1 CA-Zertifikate. Davon ausgestellte Serverzertifikate können also eine Laufzeit haben, die über die Laufzeit der SHA-1 Version hinausragt.

Im Beispiel der DFN-CERT Services GmbH CA:

SHA-1 CA-Zertifikat:
14.02.2007 --------------------------------------> 13.02.2019

SHA-2 CA-Zertifikat:
               25.03.2014 -----------------------------------------> 30.06.2019

Serverzertifikat beispiel.dfn-cert.de:
                            27.08.2017 ----------------------------> 30.06.2019

Wurde nun entgegen der Anleitungen in der DFN-PKI beim Austausch eines Serverzertifikates die Zertifizierungskette nicht mit ausgetauscht, fehlt möglicherweise das SHA-2 CA-Zertifikat. Dadurch erhalten Clients unter Umständen eine nicht konsistente Kette mit einem abgelaufenen SHA-1 CA-Zertifikat und einem noch gültigen Serverzertifikat.

Auch das PCA-Zertifikat (CN = DFN-Verein PCA Global – G01) ist mit wenigen Tagen Versatz betroffen: Die SHA-1-Version läuft am 30.06.2019 ab, die SHA-2-Version am 09.07.2019.

Ablaufdaten

Die alten SHA-1 CA-Zertifikate laufen abhängig vom Ausstellungsdatum gestaffelt über das Jahr 2019 ab. Erstes Ablaufdatum ist der 2. Januar („CN=DFN-Verein CA Services“), letztes Ablaufdatum ist der 30. Juni.

Die SHA-2 CA-Zertifikate der DFN-PKI Global G1 laufen zwischen dem 30. Juni und dem 9. Juli 2019 ab.

Konkrete Daten können Sie der folgenden Tabelle entnehmen:
Sortiert_Ablaufdaten_DFNPKI_Global_IssueingCAs

Maßnahmen

  • Wenn Sie auf Ihren Servern bereits Zertifikate aus der neuen DFN-PKI Global G2 einsetzen, müssen Sie nichts weiter prüfen.
  • Wenn Sie noch Zertifikate aus der alten DFN-PKI Global G1 einsetzen, so sollten Sie prüfen, ob Sie die korrekte SHA-2 Zwischenzertifizierungskette konfiguriert haben. Außer dem Root-Zertifikat „Deutsche Telekom Root CA 2“ müssen alle konfigurierten CA-Zertifikate mit SHA-2 signiert sein.
    [Update 22.03.] Auch Reste der alten SHA-1-CA-Zertifikate neben der gültigen SHA-2-Kette können zu Problemen führen!
    Leider können wir hier nur eine abstrakte Anleitung geben, da Ihre individuellen CA-Zertifikate betroffen sind. Zur Prüfung gehen Sie generell wie folgt vor:

  • Alternativ können Sie die Gelegenheit nutzen, gleich ein neues, aktuelles Serverzertifikat aus der neuen Generation 2 der DFN-PKI zu erzeugen und zu installieren.
  • Es ist unwahrscheinlich, dass Server betroffen sind, die ihr erstes Zertifikat nach 2014 bekommen haben, da dann der Rollout der SHA-2 CA-Zertifikate abgeschlossen war.
  • Hinweis: Wie im Blogartikel „Nächste Phase der SHA-1-Abschaltung“ geschildert ist das Root-Zertifikat der Generation 1 der DFN-PKI „Deutsche Telekom Root CA 2“ mit SHA-1 signiert. Dies ist nach wie vor richtig und kein Grund für weitere Aktionen.

Diese Maßnahmen sind nur erforderlich, wenn bei der Installation eines neuen Serverzertifikats aus der DFN-PKI Global G1 nicht wie in der Anleitung beschrieben die SHA-2 Zwischenzertifizierungskette installiert wurde.

Für Rückfragen melden Sie sich bitte gerne unter mailto:dfnpca@dfn-cert.de

(jbr, 07.12.2018)

Java in der DFN-PKI

Oracle nimmt zur Zeit erhebliche Veränderungen an seiner Java Implementierung vor. Diese haben Auswirkungen auf die Java RA-Oberfläche der DFN-PKI. Die relevanten Änderungen betreffen die folgenden Punkte:

  • Java WebStart mit den bekannten JNLP-Dateien wird abgeschafft.
  • Die Lizenz von Oracle Java ändert sich.
  • Interne Mechanismen werden umgestellt. Teilweise geschieht dies in einer Art, die sowohl rückwärts als auch vorwärts inkompatibel ist (Initialisierung von PKCS11).

Daher werden wir die Java RA-Oberfläche im Herbst 2018 folgendermaßen umstellen:

  • Die Java RA-Oberfläche der DFN-PKI wird als komplettes Java-Archiv zusammen mit plattformspezifischen Start-Skripten zum Herunterladen angeboten werden (Download-Link wird noch bekanntgegeben).
  • Da es in Java keinen eingebauten Update-Mechanismus für Anwendungen mehr geben wird, den WebStart ganz bequem geliefert hat, wird die Java RA-Oberfläche selbst auf neue Versionen prüfen und gegebenenfalls zum Herunterladen einer Aktualisierung auffordern.
  • Systemvoraussetzung wird OpenJDK ab Version 11 sein.
  • Die existierende Java WebStart-Version der RA-Oberfläche, die unter Oracle Java 8 lauffähig ist, wird noch bis ca. Mitte 2019 zur Verfügung stehen.

Wir informieren Sie, wenn die neue Version zur Verfügung steht.

(jbr, 06.09.2018)

Tipps für die Domain-Freischaltung

[1. Update 13.07.2018: Ergänzung Standard-E-Mail-Adressen und Domain-Hoster]
[2. Update 19.07.2018: Geändertes TTL-Verhalten bei Änderungen des Zonen-Kontakts im SOA-Record beschrieben]

Seit einigen Wochen sind die neuen Verfahren zur Domain-Freischaltung in der DFN-PKI in Betrieb (Details siehe Anleitung). Basierend auf den dabei gesammelten Erfahrungen hier einige Tipps für Teilnehmerservice-MitarbeiterInnen der DFN-PKI:

Vor dem 1. August 2018 ist noch was zu tun!

Über 90% aller Domain-Freischaltungen in der DFN-PKI laufen am oder schon vor dem 1.8.2018 ab. Das liegt an der Übergangsphase der Domain-Freischaltungsverfahren durch die Vorgaben aus den Baseline Requirements des CA/Browser-Forum. Sofern es wichtig ist, dass für eine Domain jederzeit SSL-Zertifikate aus der DFN-PKI beantragt und ausgestellt werden können, müssen die vorhandenen Domain-Freischaltungen von den Teilnehmerservice-MitarbeiterInnen mit Hilfe der Java RA-Oberfläche geprüft werden. Wie dabei am geschicktesten vorzugehen ist, wird im Folgenden beschrieben.

Auslaufende Domain-Freischaltungen (wiederholend)

Sehr viele bestehende Domain-Freischaltungen laufen nach der Umstellung der Verfahren zum 1.8.2018 oder früher aus. Danach laufen die Freischaltungen für bereits nach den neuen Verfahren freigeschaltete Domains jeweils nach 825 Tagen aus.

Sofern es wichtig ist, dass jederzeit Zertifikate für bereits einmal freigeschaltete Domains (z.B.  für die Haupt-Domains einer Einrichtung) beantragt und ausgestellt werden können, sollte regelmäßig durch die Teilnehmerservice-MitarbeiterInnen in der Java RA-Oberfläche (Administration->Konfiguration Server-Domains) geprüft werden, ob die Freischaltung von Domains innerhalb der nächsten Wochen ausläuft. Das Tool hilft dabei, indem es die Domains, deren Freischaltung innerhalb der kommenden 30 Tage ausläuft, rot einfärbt. Sofern Sie für mehrere CAs bzw. RA-IDs verantwortlich sind, sollte diese Prüfung in allen CA-Zweigen (Baumhierarchie) und RA-IDs (über die Drop-Down-Liste), die in der Java RA-Oberfläche konfiguriert sind, durchgeführt werden.

Für „Neben-Domains“ ist es vielleicht nicht ganz so wichtig, dass jederzeit Zertifikate beantragt und ausgestellt werden können, so dass deren Freischaltung ggf. auslaufen kann und dann erst wieder bei konkretem Zertifikatsbedarf eine Auffrischung der Domain-Freischaltung erfolgt.

Auswahl der E-Mail-Adresse für den Versand der Challenge-E-Mails

Die zur Zeit von der DFN-PKI unterstützten Verfahren zur Domain-Freischaltung sehen alle den Versand einer Challenge-E-Mail an die E-Mail-Adresse eines vorgegebenen Domain-Kontakts vor. Wichtigste Voraussetzung dafür, dass dieser Prozess funktioniert, ist, dass diese Challenge-E-Mail bei jemandem ankommen kann, der/die damit etwas anfangen kann. Die E-Mail-Adresse muss also mit Bedacht ausgewählt werden. Wie geht man da am geschicktesten vor?

  1. Betroffene Domain in der Java RA-Oberfläche per Doppelklick auswählen (oder neu eintragen) und mal sehen, welche Mail-Adressen für den Versand der Challenge-E-Mail zur Auswahl angeboten werden.
  2. Sofern dabei eine E-Mail-Adresse aufgeführt ist, die direkt bei Ihnen oder bei direkten KollegInnen ankommt, sollten Sie diese E-Mail-Adresse auswählen.
  3. Können Sie keine E-Mail-Adresse identifizieren, von der Sie definitiv wissen, dass die E-Mails an diese Adresse ankommen und von jemandem gelesen werden, der/die weiß, worum es geht, dann sollten Sie sich eine gefühlt bestmögliche E-Mail-Adresse aussuchen und vor dem Start der (Re-)Validierung eine vorbereitende E-Mail an diese Adresse senden. Auf diese Weise finden Sie auch heraus, ob das ausgewählte Postfach überhaupt existiert oder eben doch nicht (Mail-Bounce).

Änderung des Zonen-Kontakts (SOA-Record) im DNS und die TTL

Die Änderung der E-Mail-Adresse im DNS-SOA-Record einer Domain benötigt im Normalfall ca. 10 Minuten (im Ausnahmefall maximal die eingestellte Time-To-Live (TTL) Zeit der DNS-Records der Domain), bis sie über den DNS-Resolver der DFN-PKI auch auf den DFN-PKI-Systemen angekommen und sichtbar ist und damit für die Domain-Freischaltung bei einem (erneuten) Freischaltungsvorgang zur Verfügung steht.

Keine E-Mail-Adresse aus dem Zonen-Kontakt (SOA-Record) im DNS

Es kann sein, dass für eine Domain keine E-Mail-Adresse aus dem Zonen-Kontakt (SOA-Record) zur Auswahl steht. Dann gibt es für diese Domain im DNS keine eigene Zone, also auch keinen SOA-Record, oder die E-Mail-Adresse wurde im SOA-Record fehlerhaft konfiguriert und wird daher nicht zur Auswahl angeboten.

Unten findet sich ein Kommandozeilenaufruf zur Abfrage des SOA. Die Syntax der E-Mail-Adresse ist etwas DNS-like. In diesem Beispiel ist noc.dns.icann.org. die gesuchte E-Mail-Adresse, die dann als noc@dns.icann.org interpretiert wird. Punkte im Lokalteil der Mail-Adresse werden im SOA-Record mittels Backslash geschützt, so wird beispielsweise vorname\.nachname.dns.icann.org. aus dem SOA-Record zu vorname.nachname@dns.icann.org. Der erste nicht geschützte Punkt von links wird zum @-Zeichen der Mail-Adresse.

dig SOA example.org

; <<>> DiG 9.11.0-P1 <<>> SOA example.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48535
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.org. IN SOA

;; ANSWER SECTION:
example.org. 3600 IN SOA sns.dns.icann.org. noc.dns.icann.org. 2018050817 7200 3600 1209600 3600
...

Google stellt ein Web-basiertes DNS-Werkzeug zur Abfrage des SOA-Records zur Verfügung https://toolbox.googleapps.com/apps/dig/#SOA/

Keine konstruierten Standard-E-Mail-Adressen

Es kann sein, dass für eine Domain keine konstruierten Standard-E-Mail-Adressen der Form (webmaster|hostmaster|postmaster|administrator|admin)@DOMAIN zur Auswahl stehen. Dann ist für diese Domain im DNS kein Mail-Server (MX-Record) eingetragen.

Unten findet sich ein Kommandozeilenaufruf zur Abfrage der Mail-Server (MX-Records) aus dem DNS.

> dig MX example.org

; <<>> DiG 9.11.0-P1 <<>> SOA example.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48535
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.org. IN MX

;; ANSWER SECTION:
example.org. 86400 IN MX 50 mail1.example.org.
example.org. 86400 IN MX 50 mail2.example.org.
...

Google stellt ein Web-basiertes DNS-Werkzeug zur Abfrage der MX-Records zur Verfügung https://toolbox.googleapps.com/apps/dig/#MX/

Das anlegen eines neuen DNS-MX-Records für eine Domain benötigt im Normalfall ca. 10 Minuten (im Ausnahmefall maximal die eingestellte Time-To-Live (TTL) Zeit der DNS-Records der Domain), bis dieser über den DNS-Resolver der DFN-PKI auch auf den DFN-PKI-Systemen angekommen und sichtbar ist und damit die Standard-E-Mail-Adressen für die Domain-Freischaltung bei einem (erneuten) Freischaltungsvorgang zur Verfügung stehen.

Standard-E-Mail-Adressen und Domain-Hosting

Prüfen Sie für betroffene Domains, ob das Domain-Paket bei Ihrem Domain-Provider die Möglichkeit einer simplen E-Mail-Weiterleitung einer Standard-E-Mail-Adresse wie etwa webmaster@DOMAIN über die Domain-Konfiguration an eine beliebige von Ihnen festgelegte E-Mail-Adresse in Ihrer eigenen Einrichtung (bevorzugt die Funktions-E-Mail-Adresse des eigenen PKI-Teams vor Ort) erlaubt.

Wird für eine Domain zum ersten Mal überhaupt eine E-Mail-Adresse beim Domain-Provider angelegt, so wird dabei implizit vom Domain-Hoster auch ein DNS-MX-Record angelegt. Bis dieser über den DNS-Resolver der DFN-PKI auch auf den DFN-PKI-Systemen angekommen und sichtbar ist und damit die Standard-E-Mail-Adressen für die Domain-Freischaltung bei einem (erneuten) Freischaltungsvorgang zur Verfügung stehen, können im Normalfall ca. 10 Minuten (im Ausnahmefall maximal die eingestellte Time-To-Live (TTL) Zeit der DNS-Records der Domain) vergehen.

Für die Domain-Validierung nutzbare Standard-E-Mail-Adressen, die für solch eine E-Mail-Weiterleitung konfiguriert werden können,  sind (webmaster|hostmaster|postmaster|administrator|admin)@DOMAIN.

E-Mail-Kontakt aus dem WHOIS

Das Inkrafttreten der Datenschutzgrundverordnung hat den Einsatz dieser Validierungsmethode grundsätzlich deutlich erschwert. Ursprünglich als manuelle und damit langsamere und nicht bevorzugte Validierungsmethode vorgesehen, ist sie leider seit dem 25.5.2018 so gut wie gar nicht mehr nutzbar, weil die meisten Domain-Registries keine E-Mail-Adressen von Domain-Inhaber, Admin-C oder Tech-C mehr über ein einfach für Dritte einsehbares WHOIS (Kommandozeile oder Web) herausgeben.

Falls Sie mittels dieser Methode eine Domain validieren wollen, prüfen Sie bitte vorab selbst, ob im einfach für Dritte einsehbaren WHOIS (Kommandozeile oder Web-WHOIS) des Registrars bzw. der entsprechenden TLD-Domain-Verwaltung E-Mail-Adressen von Domain-Inhaber, Admin-C oder Tech-C sichtbar sind. Nach unserer Erfahrung kann das für bestimmte .eu und .de Domains und ggf. mit einen sehr umständlichen Prozess im Einzelfall noch funktionieren.

Prüfen Sie bitte auf jeden Fall zunächst, ob die Domain nicht doch für eines der anderen Verfahren fit gemacht werden kann.

(rkm, 25.06.2018)