Archiv der Kategorie: Uncategorized

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/

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/

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.

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)

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)

RA-Zugang zur alten DFN-PKI Generation bei Neueinrichtung mit TS-Operator-Zertifikat aus der neuen DFN-PKI Generation 2

Wo ist mein bestehender RA-Zugang zur alten DFN-PKI Generation 1 in der Java RA-Oberfläche geblieben?

Nach einer kompletten Neuinstallation Ihres Betriebssystems oder der Neukonfiguration der Java RA-Oberfläche (z.B. unter einem anderen Nutzerkonto) mit einem TS-Operator-Zertifikat der neuen DFN-PKI Generation 2 steht der RA-Zugang zur alten DFN-PKI Generation 1 zunächst nicht mehr in der Java RA-Oberfläche zur Verfügung.

Um auch diesen RA-Zugang zur alten DFN-PKI Generation 1 in der Java RA-Oberfläche wieder herzustellen, ist etwas Handarbeit nötig: Die Konfigurationsdatei der Java RA-Oberfläche muss manuell von Ihnen angepasst werden:

  1. Ggf. beenden Sie die noch laufende Java RA-Oberfläche.
  2. Suchen Sie unterhalb Ihres Home-Verzeichnisses nach der Datei configuration.xml im Verzeichnis .dfn-pki.
  3. Machen Sie ggf. eine Sicherheitskopie dieser Datei.
  4. Öffnen Sie die Datei configuration.xml in einem ASCII-Text-Editor.
  5. Suchen Sie darin den aktuellen Abschnitt für den RA-Zugang zur neuen DFN-PKI Generation, z.B.

    <node type=“de.dfncert.guira.pki.DFNPKICATreeNode“>
    <property name=“caName“>dfn-ca-global-g2</property>
    <property name=“raAlias“>Alias-Name des TS-Operator-Zertifikats</property>
    <property name=“raSource“>/Pfad/zum/TS-Operator-Zertifikat-G2.p12</property>
    <property name=“displayName“>Uni Musterstadt CA G2</property>
    <property name=“raType“>PKCS12</property>
    </node>

  6. Kopieren Sie diesen Abschnitt einschließlich der den Abschnitt einfassenden <node type=…> und </node> Tags und fügen Sie ihn gleich dahinter nochmals ein.
  7. Im eingefügten Abschnitt ändern Sie jetzt die Properties für caName und displayName wie folgt ab:
    1. Als neuen CA-Namen setzen Sie den bekannten CA-Namen aus der alten DFN-PKI Generation 1. Diesen können Sie z.B. aus den alten Web-URLs zur Zertifikatsbeantragung in der alten DFN-PKI Generation 1 ableiten. Für eine beispielhafte Web-URL der Form https://pki.pca.dfn.de/uni-musterstadt-ca/cgi-bin/pub/… aus der alten DFN-PKI Generation 1 ist uni-musterstadt-ca der gesuchte CA-Name für diesen neuen Konfigurationsabschnitt.
    2. Ändern Sie auch den Display-Namen auf z.B. Uni Musterstadt CA G1 ab, so dass Sie diesen neuen Eintrag im Anzeigebaum der Java RA-Oberfläche wiedererkennen können.
    3. Der neue Abschnitt für den RA-Zugang zur alten DFN-PKI Generation 1 sieht dann nach unserem Beispiel wie folgt aus:

      <node type=“de.dfncert.guira.pki.DFNPKICATreeNode“>
      <property name=“caName“>uni-musterstadt-ca</property>
      <property name=“raAlias“>Alias-Name des TS-Operator-Zertifikats</property>
      <property name=“raSource“>/Pfad/zum/TS-Operator-Zertifikat-G2.p12</property>
      <property name=“displayName“>Uni Musterstadt CA G1</property>
      <property name=“raType“>PKCS12</property>
      </node>

      Die anderen Properties wurden hierbei unverändert übernommen.

  8. Speichern Sie die Datei ab.
  9. Starten Sie die Java RA-Oberfläche.

(rkm, 13.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)

 

 

PKCS#12-Akrobatik

Manchmal enthalten aus Anwendungen oder Appliances exportierte PKCS#12-Dateien (Dateiendung .p12 oder .pfx) leider doch nicht die gewünschten CA-Zertifikate der CA-Zertifikatskette oder sogar gar keine CA-Zertifikate, siehe auch Sicherung von eigenen Nutzerzertifikaten aus Mozilla/Firefox. Dann kann man hingehen und versuchen, die Anwendung oder Appliance zu überzeugen, doch das Gewünschte zu exportieren, oder man nimmt gleich das Kommandozeilenwerkzeug openssl her und formt sich die vorliegende unpassende PKCS#12-Datei selbst um.

Um etwa die CA-Zertifikatskette eines in einer PKCS#12-Datei vorliegenden Client-Zertifikats der DFN-Verein Global Issuing CA aus der neuen Generation der DFN-PKI auszutauschen, genügt folgende Akrobatik:

1. Privaten Schlüssel und Client-Zertifikat mittels

openssl pkcs12 -clcerts -in client-cert-with-privkey.p12 -out client-cert-with-privkey.pem

aus der vorliegenden PKCS#12-Datei in eine PEM-Datei exportieren. Hierbei wird das Passwort der PKCS#12-Datei abgefragt und ein neues Passwort auf dem exportierten privaten Schlüssel in der PEM-Datei gesetzt.

2. Vollständige CA-Kette der DFN-Verein Global Issuing CA im PEM-Format herunterladen:

wget https://pki.pca.dfn.de/dfn-ca-global-g2/pub/cacert/chain.txt

3. Neue PKCS#12-Datei mit der gerade heruntergeladenen CA-Zertifikatskette zusammenbauen:

openssl pkcs12 -export -in client-cert-with-privkey.pem -certfile chain.txt -out client-cert-with-privkey-and-chain.p12

Hierbei wird das eben gesetzte Passwort des privaten Schlüssels aus der PEM-Datei abgefragt und ein neues Passwort auf der zu erzeugenden PKCS#12-Datei gesetzt.

4. Abschließende Aufräumarbeiten durchführen, also die zwischenzeitlich erzeugten Dateien mit privatem Schlüssel, d.h. client-cert-with-privkey.pem und ggf. die alte unpassende PKCS#12-Datei client-cert-with-privkey.p12 nachhaltig löschen.

Dieses „Kunststück” kann natürlich für Client-Zertifikate, die in Form einer PKCS#12-Datei vorliegen und von beliebigen Zertifizierungsstellen ausgestellt sind, durchgeführt werden, sofern man die korrekte CA-Zertifikatskette im PEM-Format in einer Datei vorliegen hat.

(rkm, 09.02.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)