Bezugsquellen für Java zum Betrieb der RA-Oberfläche

[Ergänzung 16.05.: Hinweise zu Updates von OpenJDK]

Mit Stand 05/2019 sind folgende Java-Varianten zur Installation auf dem eigenen Desktop verfügbar:

  • Frei verwendbare OpenJDK Builds von Oracle. Diese Builds folgen im Support-Zeitraum exakt dem Release-Zyklus von Java. Daher gibt es für jede Java Version nur 6 Monate Support. Danach muss das nächste Major-Release installiert werden, um weiterhin Security Updates zu erhalten. Quelle: https://jdk.java.net/
  • Lizenzpflichtige Oracle Builds. Für die nicht ausschließlich private Nutzung muss für diese Builds pro Arbeitsplatz eine kostenpflichtige Lizenz von Oracle beschafft werden (Ausnahme: Software-Entwicklung). Bei diesen Builds gibt es ebenfalls einen 6-monatigen Release-Zyklus, allerdings mit verlängertem Support für extra ausgezeichnete LTS-Versionen wie z.B. Java 11. Quelle: https://www.oracle.com/technetwork/java/javase/downloads/index.html
  • Java Builds von Drittanbietern, z.B. AdoptOpenJDK, Azul oder die bei diversen Linux-Distributionen enthaltene Java. Naturgemäß gibt es hier unterschiedliche Lizenzen und Support-Zeiträume.

Die Java RA-Oberfläche der DFN-PKI wird für das jeweils aktuelle frei verwendbare OpenJDK Build von Oracle, das den Zustand „General Availability“ (GA) erreicht hat, erstellt und getestet.

Die Java RA-Oberfläche benötigt aktuell mindestens Java 11.

Die aktuelle GA-Version des OpenJDK Builds von Oracle erhalten Sie unter https://jdk.java.net/  oder https://openjdk.java.net/projects/jdk/ (Hinweis: Wählen Sie keine Version, die mit „In Development“ markiert ist, sondern nur die mit „GA“ gekennzeichneten Downloads).

Ergänzung 16.5.: Achtung: Die frei verfügbaren OpenJDK Builds von Oracle haben keinen automatischen Update-Mechanismus. Sie werden auch nicht auf neue Versionen des OpenJDK hingewiesen. Sie müssen selbst für die rechtzeitige Aktualisierung sorgen!

(Jürgen Brauckmann, 15.05.2019)

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

Das CA/Browser-Forum hat im Februar 2019 mit Ballot SC7 die Verfahren zur Validierung von IP-Adressen, die in Zertifikate aufgenommen werden sollen, geändert: https://cabforum.org/2019/02/09/ballot-sc7-update-ip-address-validation-methods/

Die DFN-PKI hat diese Änderung mit der Version 4 der Zertifizierungsrichtlinie umgesetzt. Konkret bedeutet dies:

  • Bestehende Zertifikate mit IP-Adressen bleiben unverändert gültig.
  • Ab dem 31.07.2019 müssen IP-Adressen erneut durch die DFN-PCA validiert werden, wenn sie in neue Zertifikate aufgenommen werden sollen. Die Validierungen sind 825 Tage für weitere Zertifikate gültig.
  • Wenn Sie eine Fehlermeldung „Die IP-Adresse w.x.y.z  ist nicht erlaubt“ beim Hochladen oder Editieren eines Zertifikatantrages erhalten, wenden Sie sich bitte an mailto:dfnpca@dfn-cert.de, um das Verfahren zur Freischaltung des IP-Adress-Blocks zu starten.

Vorab 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.

Achtung: Der Validierungsprozess und die Freischaltung beinhalten einige manuelle Schritte auch auf unserer Seite. Daher funktionieren diese nicht so kurzfristig und Self-Service-artig wie bei der Domain-Validierung.

(Jürgen Brauckmann, 25.04.2019)

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

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

  • Titel und Fußzeile: Versionsnummer und Datum. Versionierung ab dieser Version ohne „Minor Version“
  • 1.2: OIDs
  • 3.2.2: Methoden zur IP-Adress-Validierung an Baseline Requirements 1.6.4 angepasst
  • 4.1.2: Klarstellung, dass pers. ID nur für Zertifikate f. nat. Personen durchgeführt wird (Dies ist keine inhaltliche Änderung, nur eine Präzisierung)

Die Versionsnummer des begleitenden Dokumentes „Erklärung zum Zertifizierungsbetrieb“ für das Sicherheitsniveau „Global“ wurde ebenfalls auf 4 hochgezählt. Inhaltlich wurden keine Änderungen vorgenommen. Die neuen Dokumente finden Sie unter den folgenden URLs:

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

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

Mit Änderungsmarkierungen:

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

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

(Jürgen Brauckmann, 25.04.2019)

Java RA-Oberfläche Version 3.0.2

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

guira-3.0.2.zip

guira-3.0.2.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.2 (16.04.2019)

  • Fehlerbehandlung im Passwort-Dialog verbessert.
  • Fehler beim Aufruf von ‚Datei->Beenden‘ behoben.
  • Fehler beim Exportieren von Zertifikaten behoben.
  • Korrektur des Windows-Startskriptes guira-windows.bat.

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

(Jürgen Brauckmann, 24.04.2019)

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)