Archiv des Autors: Juergen Brauckmann

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

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.

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

X.509-Authentifizierung im Shibboleth IdP

Die DFN-AAI ist bekanntermaßen ein sehr erfolgreicher Mechanismus zur organisationsübergreifenden Anmeldung. Herkömmliche Konfigurationen arbeiten üblicherweise mit normalen Passwörtern mit all ihren Nachteilen.

Im Wiki der Trust und Identity Dienste des DFN steht nun eine Anleitung zur Verwendung von Client-Zertifikaten im Shibboleth Identity Provider 3 bereit:

https://doku.tid.dfn.de/de:shibidp3x509

(jbr, 25.06.2018)

Der CAA-Record im DNS ist nicht passend gesetzt

Seit September 2017 muss jede CA, die den Regeln des CA/Browser-Forums unterliegt, vor der Ausstellung eines Serverzertifikats CAA Resource Records im DNS prüfen. Eine Beschreibung des Systems findet sich in den folgenden Artikeln:

https://blog.pki.dfn.de/2017/03/rfc-6844-certification-authority-authorization-caa

https://blog.pki.dfn.de/2017/09/caa-rrs-reihenfolge-im-dns

In der DFN-PKI im Sicherheitsniveau Global wird die Prüfung direkt im Anschluss an das Genehmigen eines Serverzertifikat-Antrags in der Java RA-Oberfläche durchgeführt. Der Prüf-Mechanismus läuft dabei selbstverständlich auf den Servern der DFN-PKI, nicht in der Java RA-Oberfläche. Ist die Prüfung nicht erfolgreich, erscheint die folgende Fehlermeldung:


Hierfür kann es mehrere Ursachen geben. Zur Untersuchung können die DNS-Abfragen, die das DFN-PKI-System durchführt, manuell nachgestellt werden. Ein nützliches Werkzeug ist dig. Achtung: Nur relativ neue Versionen unterstützen die Abfrage von CAA-Records in einer leserlichen Form. Eine Alternative sind Web-Werkzeuge wie z.B. die Dig-Toolbox von Google https://toolbox.googleapps.com/apps/dig/#CAA/

Erscheint die Fehlermeldung beispielsweise für den Namen www.sub1.hs-musterstadt.de, so sollten nacheinander die folgenden Abfragen durchgeführt werden:

dig +adflag www.sub1.hs-musterstadt.de CAA
dig +adflag sub1.hs-musterstadt.de CAA
dig +adflag hs-musterstadt.de CAA
dig +adflag de CAA

Wichtig: Der verwendete rekursive Resolver muss security-aware sein und DNSSEC validieren. Wenn der Standard-Resolver Ihrer Einrichtung dies nicht leistet, muss ein alternativer validierender Resolver wie 1.1.1.1 oder 8.8.8.8 verwendet werden.

Ergibt eine Abfrage einen CNAME, muss auch das CNAME-Target auf CAA-Records abgefragt werden.

Im Idealfall ergeben alle Abfragen einen Status NOERROR oder NXDOMAIN (kein SERVFAIL). Wenn CAA-Records gefunden werden, so sollten diese immer auch den Wert pki.dfn.de enthalten.

Die Prüfung bricht stets beim ersten gefundenen CAA-Record ab.

Mögliche Fehlerursache: CAA-Record für falsche PKI gesetzt

Wenn Sie beispielsweise nur folgenden Record finden, ist es der DFN-PKI nicht erlaubt, Zertifikate auszustellen:

sub1.hs-musterstadt.de. IN CAA 0 issue "letsencrypt.org"

Lösung: Zusätzlichen CAA-Record hinzufügen.

sub1.hs-musterstadt.de. IN CAA 0 issue "letsencrypt.org"
sub1.hs-musterstadt.de. IN CAA 0 issue "pki.dfn.de"

Mögliche Fehlerursache: Defekter CAA-Record gesetzt

Mindestens ein uns bekanntes DNS-Management-Werkzeug produziert defekte CAA-Records, die die Ausstellung von Zertifikaten verhindern (beachten Sie den fehlenden Typ „issue“ vor dem Wert „pki.dfn.de“):

sub1.hs-musterstadt.de. IN CAA 0 0 "pki.dfn.de"

Lösung: Defekten CAA-Record entfernen oder Werkzeug dazu überreden, korrekte Records zu setzen.

Mögliche Fehlerursache: Abfrageprobleme (SERVFAIL) in Kombination mit DNSSEC

Bei Fehlern bei der DNS-Abfrage muss die DFN-PKI prüfen, ob die Zone mit DNSSEC gesichert sein sollte. Wenn dies der Fall ist, muss die Ausstellung von Zertifikaten abgelehnt werden. Insbesondere verhindern Nameserver, die (aus welchen Gründen auch immer) nicht aus dem Internet erreichbar sind, die Ausstellung von Zertifikaten, wenn die übergeordnete Zone mit DNSSEC gesichert ist.

Beispiel: Bei der Abfrage von sub1.hs-musterstadt.de kommt es zu einem Fehler, erkennbar am Header-Feld „status: SERVFAIL“:

$ dig +adflag sub1.hs-musterstadt.de
; <<>> DiG 9.11.3 <<>> +adflag sub1.hs-musterstadt.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 62481

Wie ist nun der Zustand der übergeordneten Zone?

$ dig +adflag hs-musterstadt.de

; <<>> DiG 9.11.3 <<>> +adflag hs-musterstadt.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36721
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 7

Da „flags: …ad“ zurückgeliefert wird, ist hs-musterstadt.de DNSSEC-geschützt. Damit kann die DFN-PKI keine Zertifikate für sub1.hs-musterstadt.de ausstellen.

Die Lösung hängt von der Ursache des SERVFAIL ab. Ist der eingetragene Nameserver nur für interne Zwecke vorgesehen und aufgrund von Router-ACLs nicht erreichbar, so bleibt leider keine andere Möglichkeit, als entweder für die DFN-PKI eine Erreichbarkeits-Ausnahme zu implementieren, oder aber die Zonen-Delegation aus der externen Sicht der hs-musterstadt.de-Nameserver zu entfernen (unterschiedliche Views für interne und externe Abfrager).

Liegt der Abfragefehler bei einer defekten DNSSEC-Konfiguration, so sollte diese repariert werden. Für eine genauere Analyse müssen in der Regel weitere Werkzeuge wie z.B. http://dnsviz.net verwendet werden.

Sollte die Ursache für die Fehlermeldung „Der CAA-Record im DNS ist nicht passend gesetzt“ weiterhin unklar bleiben, so helfen wir Ihnen gerne bei der Analyse. Kontakt: mailto:dfnpca@dfn-cert.de

(jbr, 30.04.2018)

Firefox 59, Windows und Probleme mit dem Zertifikatexport

[Update 18.5.: In Firefox 60 ist das Problem behoben]

[Update 22.3.: Thunderbird Im-/Export als weiteren Workaround]

Seit wenigen Tagen ist Firefox 59 verfügbar. Bei dieser Version kommt es beim Export von Zertifikaten zu einem Problem im Zusammenspiel mit Windows: Die aus Firefox exportierten Zertifikate im PKCS#12-Format sind nicht mehr in den Windows-Systemstore importierbar. Die Meldung von Windows lautet: „Das eingegebene Kennwort ist falsch“.

Update 18.05.: In Firefox 60 existiert das Problem nicht mehr.

Mutmaßlicher Hintergrund: Firefox 59 setzt die Iterationen der Schlüsselableitungsfunktion zum Verschlüsseln des PKCS#12 auf den Wert 1.000.000 (Wert bei Firefox 58 war 100.000). Mit diesem Wert kommt anscheinend die Krypto-Bibliothek von Windows nicht zurecht.

Ticket bei Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1436873

Mögliche Abhilfe: Exportierte PKCS#12-Files können mit openssl oder einem anderen Werkzeug umkodiert werden. Dabei wird dann üblicherweise eine Windows-kompatible Anzahl an Iterationen verwendet.

Anleitung openssl: https://blog.pki.dfn.de/2018/02/pkcs12-akrobatik/

Fertiges Werkzeug (Windows-Executable) von den Kollegen vom Steinbuch Centre for Computing des KIT: https://git.scc.kit.edu/KIT-CA/RecodeCertificate/blob/master/README.md

Auch ein Import des PKCS#12 in den Mailclient Thunderbird (getestet mit Version 52.6.0) mit anschließendem Export erzeugt ein Objekt, das in Windows importiert werden kann.

(jbr, 21.03.2018)

Ausblick: Umstellung der Verfahren zur Freischaltung von Domains

[Update 21.03.: SOA-RR ergänzt]

Anfang Februar hat das CA/Browser Forum mit Ballot 218 festgelegt, dass
bestimmte auch in der DFN-PKI verwendete Verfahren zur Prüfung der
berechtigten Aufnahme von Domains in Serverzertifikaten umgestellt werden müssen.

Auf der letzten DFN-Betriebstagung am 14.-15.03.18 haben wir weitere Details der aktuellen Umstellungspläne vorgestellt, die Sie im Abschnitt „Validierung von Domains“ der Folien finden: https://www.dfn.de/fileadmin/3Beratung/Betriebstagungen/bt68/BT68_Sicherheit_NeuesPKI_Brauckmann.pdf

Nachtrag 21.03.:

Zusätzlich zu den Methoden, die in den Folien der Betriebstagung genannt sind, werden wir direkt im ersten Schritt eine Challenge-E-Mail an die E-Mail-Adresse des Zonenverwalters unterstützen. Diese E-Mail Adresse ist im SOA Resource Record zu der zu validierenden Domain im DNS hinterlegt (RNAME im SOA RR nach RFC 1035).

Beispiel anhand des SOAs für example.net:

example.net. 3600 IN SOA sns.dns.icann.org. noc.dns.icann.org. 2018013032 7200 3600 1209600 3600

Der Teilnehmerservice könnte in diesem Beispiel bestimmen, dass für eine Validierung die Challenge-E-Mail an noc@dns.icann.org gesendet wird. Auch die in den Folien bereits genannten Adressen hostmaster@example.net, webmaster@example.net, postmaster@example.net, admin@example.net, administrator@example.net wären zulässig.

(jbr, 19.03.2018)

Version 3.8 der Zertifizierungsrichtlinie DFN-PKI Global

Zum 19.03.2018 tritt die Zertifizierungsrichtlinie 3.8 im Sicherheitsniveau „Global“ in Kraft.

Änderungen in Version 3.8:

* Kapitel 3.2.2, Domain-Autorisierungen umgearbeitet.

Die neue Zertifizierungsrichtlinie (CP) finden Sie unter der folgenden URL:

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

Mit Änderungsmarkierungen:

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

(jbr, 19.03.2018)

 

 

Version 3.7 des CP DFN-PKI „Global“, Änderungen an weiteren Dokumenten

Als Ergebnis des letztjährigen Audits der DFN-PKI tritt zum 15.02.2018 eine neue Version 3.7 der Zertifizierungsrichtlinie der DFN-PKI im Sicherheitsniveau „Global“ in Kraft.

Die wichtigsten Änderungen sind im Einzelnen:

  • Neuer Audit-Standard ETSI EN 319 411-1
  • Klarstellungen bzgl. Verbots von E-Mail-Adressen in Serverzertifikaten
  • Klarstellungen bzgl. der Sperrgründe in Kapitel 4.9.1

Das neue CP finden Sie unter der folgenden URL:
https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_V3.7.pdf

Mit Änderungsmarkierungen:
https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_V3.7_redline.pdf

Änderungen an den Dokumenten „Pflichten der Teilnehmer“ und „Informationen für Zertifikatinhaber“

In „Pflichten der Teilnehmer“ wurden Regelungen für den Betrieb von Mailgateways aufgenommen. Des Weiteren wurde ein Passus zum regelmäßigen Audit der DFN-PKI „Global“ und die Notwendigkeit der Unterstützung durch die Teilnehmer ergänzt.

In „Informationen für Zertifikatinhaber“ wurden Hinweise für den Betrieb von Mailgateways und zur oben aufgeführten Veröffentlichung von Serverzertifikaten in Certificate Transparency eingeführt.

Die Dokumente finden Sie unter:

https://www.dfn.de/fileadmin/PKI/anleitungen/Pflichten-der-Teilnehmer_V1.3.pdf

https://www.dfn.de/fileadmin/PKI/anleitungen/Informationen-fuer-Zertifikatinhaber_V1.2.pdf

Mit Änderungsmarkierungen:

https://www.dfn.de/fileadmin/PKI/anleitungen/Pflichten-der-Teilnehmer_V1.3_redline.pdf

https://www.dfn.de/fileadmin/PKI/anleitungen/Informationen-fuer-Zertifikatinhaber_V1.2_redline.pdf

(jbr, 30.01.2018)