Schlagwort-Archive: DFN-PKI

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)

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)

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)

Version 3.6 der Zertifizierungsrichtlinie DFN-PKI Global

Zum 04.09.2017 tritt die Version 3.6 der Zertifizierungsrichtlinie  (CP) der DFN-PKI für das Sicherheitsniveau Global in Kraft. Das Dokument finden Sie unter: https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_V3.6.pdf

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

Die Version 3.6 beinhaltet einige nähere Erläuterungen zu den Prozessen der DFN-PCA, die durch das Mozilla-Root-Programm von allen PKIs angefordert wurden.

Des Weiteren gibt es die folgenden Änderungen:

Klarstellung über die Verwendung von digitalen Signaturen bei Zertifikaterneuerung

In Kapitel 3.3.1 ist geregelt, dass die Authentifizierung eines Zertifikatantrags auch über eine digitale Signatur eines gültigen digitalen Zertifikats möglich ist.

Es wird nun klargestellt, dass auch dieses Verfahren nur zulässig ist, wenn die zugrundeliegende Identifizierung innerhalb des Wiederverwendungszeitraums stattfand.

Unterstützung von RFC 6844 Certification Authority Authorization (CAA)

In Kapitel 4.2.2 wird nun die Unterstützung von CAA beschrieben. Nähere Erläuterungen finden Sie hierzu in dem folgenden Blog-Artikel:

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

Gültigkeitsdauer Serverzertifikate

Das CA/Browserforum hat mit Ballot 193 beschlossen, dass ab März 2018 die Laufzeit von ab dann neu ausgestellten Serverzertifikaten 825 Tage nicht überschreiten darf.

Diese Regelung wurde bereits jetzt mit Wirkung zum 01.03.2018 in das Kapitel 6.3.2 aufgenommen.

Erklärung zum Zertifizierungsbetrieb

Die Erklärung zum Zertifizierungsbetrieb (CPS) der DFN-PKI wurde ebenfalls neu veröffentlicht und trägt nun auch die Version 3.6. Das Dokument ist inhaltlich gegenüber der Vorgängerversion 3.1 unverändert.

Durch die Aktualisierung der Versionsnummer wird nun deutlich gemacht, dass das Dokument jährlich überprüft wird. Das Dokument finden Sie unter: https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CPS_V3.6.pdf

(jbr, 21.08.2017)

Funktionseinschränkungen bei der Web RA-Oberfläche

Seit vielen Jahren gibt es in der DFN-PKI zwei Schnittstellen für den Teilnehmerservice: Die Web RA-Oberfläche unter https://ra.pca.dfn.de/<CA-Kürzel>/ra und die neuere Java RA-Oberfläche unter https://pki.pca.dfn.de/guira/guira.jnlp.

Aktuell ist die Web RA-Oberfläche nur noch im Firefox-Browser voll funktionsfähig, und dieses mit den neueren Firefox-Versionen auch nur mit dem Add-On SigntextJS+ zur Genehmigung von Anträgen. Im Gegensatz zur Java RA-Oberfläche unterstützt die Web RA-Oberfläche weit weniger Funktionen, es fehlen z.B. die Verwaltung von Domainnamen und Teilnehmerservice-Mitarbeitern.

Zur Unterstützung von Certification Authority Authorization Records (https://blog.pki.dfn.de/2017/03/rfc-6844-certification-authority-authorization-caa/) wird das Backend der Java RA-Oberfläche mit entsprechenden Funktionen ausgerüstet.

Leider ist es nicht mehr sinnvoll, den hierfür notwendigen Aufwand auch für die in die Jahre gekommene Web RA-Oberfläche zu leisten. Daher müssen wir in der Web RA-Oberfläche das Genehmigen von Zertifikatanträgen für das Sicherheitsniveau Global voraussichtlich im Juli/August 2017 deaktivieren. Die weiteren Funktionen der Web RA-Oberfläche bleiben vorerst erhalten.

Zertifikatanträge im Sicherheitsniveau Global können also in Zukunft ausschließlich mit der Java RA-Oberfläche genehmigt werden. Hinweise zur Nutzung der Java RA-Oberfläche finden Sie unter https://www.pki.dfn.de/faqpki/faqpki-tsbetrieb/#c16300.

In den anderen Sicherheitsniveaus (Basic, Grid) und bei den internen CAs steht das Genehmigen von Zertifikatanträgen auch in der Web RA-Oberfläche weiter zur Verfügung.

Sperranträge können weiterhin uneingeschränkt in allen Sicherheitsniveaus über die Web- und die Java RA-Oberfläche genehmigt werden.

Für Fragen melden Sie sich bitte bei dfnpca@dfn-cert.de

(jbr, 29.05.2017)

RFC 6844 Certification Authority Authorization (CAA)

Seit Anfang 2013 gibt es den RFC 6844 „Certification Authority Authorization“ (CAA). CAA spezifiziert einen gleichnamigen Resource Record zur Ablage im DNS, mit dem ein Domain-Inhaber festlegen kann, welche Zertifizierungsstelle (CA) für seine Domain Zertifikate ausgeben darf.

Das CA/Browser-Forum verpflichtet mit Ballot 187 jede CA, ab spätestens September 2017 diese CAA Resource Records auszuwerten und zu beachten.

In der DFN-PKI wird dieser Mechanismus zum Sommer 2017 unterstützt werden.

Mechanismus

CAA RRs werden vor der Ausstellung von Zertifikaten durch die CA ausgewertet. Es wird geprüft, ob der Domain-Inhaber einen CAA RR mit der entsprechenden CA gesetzt hat. Gibt es keinen CAA RR, so kann jede CA für die Domain zertifizieren.

CAA wird also nicht von Nutzern von Zertifikaten ausgewertet, sondern ausschließlich von Zertifizierungsstellen exakt zum Zeitpunkt der Ausstellung des Zertifikats. Eine Auswertung durch Nutzer zum Zweck der Zertifikatvalidierung ist im RFC explizit ausgeschlossen.

Im RFC wird empfohlen, CAA in Kombination mit DNSSEC einzusetzen. Die Nutzung ohne DNSSEC ist aber ebenfalls erlaubt.

CAA definiert drei Properties:

  • issue enthält als Wert die Domain der CA, die für die Domain, in der die CAA RRs definiert sind, Zertifikate ausstellen darf.
  • issuewild hat dieselben Eigenschaften wie issue, wird aber für Wildcard-Zertifikate ausgewertet. Ist kein issuewild gesetzt, wird auch für Wildcard-Zertifikate issue ausgewertet
  • iodef spezifiziert Kontaktadressen des Domain-Inhabers, unter denen Probleme oder Verletzungen der CAA-Policy gemeldet werden können.

Die Properties können mehrmals spezifiziert werden, so dass mehreren CAs die Erlaubnis zur Zertifizierung für eine Domain gegeben werden kann.

Die Auswertung geschieht, wie im DNS üblich, hierarchisch aufsteigend und unter Befolgung von CNAME oder DNAME Einträgen. Für eine Zertifikatanfrage für den Domainnamen X.Y.Z wird zunächst im DNS unter X.Y.Z nach CAA RRs gesucht, dann unter Y.Z, dann unter Z.

Ein Beispiel einer Zonendatei mit CAA RRs für die DFN-PKI:

$ORIGIN hs-musterstadt.de
. CAA 0 issue "pki.dfn.de"
. CAA 0 iodef "mailto:certadmin@hs-musterstadt.de"

Werte für die DFN-PKI

Die DFN-PKI wird die issue-Werte „pki.dfn.de“ und „dfn.de“ akzeptieren:

. CAA 0 issue "pki.dfn.de"

oder

. CAA 0 issue "dfn.de"

Konsequenzen für die Web-RA-Schnittstelle

Die Auswertung von CAA ist nur mit erheblicher Implementierungsarbeit umzusetzen. Diese können wir leider nur für die SOAP-Schnittstelle der DFN-PKI (und damit für die Java RA-Oberfläche) realisieren.

Daher werden wir leider das Genehmigen von Zertifikatanträgen in der Web-RA-Schnittstelle für PKIs im Browserverankerten Sicherheitsniveau „Global“ deaktivieren müssen. Bitte verwenden Sie zum Genehmigen von Zertifikatanträgen die Java RA-Oberfläche (Java Webstart https://pki.pca.dfn.de/guira/guira.jnlp).

(jbr, 17.03.2017)

SHA-1 Kollisionen und deren Bedeutung für die DFN-PKI

Wissenschaftler vom CWI Amsterdam und von Google haben eine Forschungsarbeit veröffentlicht, in der praktisch vorgeführt wird, wie Kollisionen für den Hashalgorithmus SHA-1 berechnet werden können. Dabei ist es gelungen, zwei PDF-Dokumente so zu konstruieren, dass sie denselben Hashwert besitzen.

http://shattered.io/

Artikel auf Heise: https://www.heise.de/newsticker/meldung/Todesstoss-Forscher-zerschmettern-SHA-1-3633589.html

Artikel Golem: https://www.golem.de/news/kollissionsangriff-hashfunktion-sha-1-gebrochen-1702-126355.html

Die Auswirkungen für die DFN-PKI sind nach unserer Einschätzung gering, denn noch ist niemand in der Lage, sogenannte Pre-Image-Angriffe durchzuführen. Dies bedeutet, dass es noch nicht möglich ist, zu einem bestehenden alten Zertifikat ein zweites, „gefälschtes“ mit identischer Signatur, aber anderen Daten zu berechnen.

Der jetzt veröffentlichte Angriff setzt nach unserem Kenntnisstand voraus, dass beide Datenobjekte, das „Original“ und die „Fälschung“, hochvariable Daten unter Angreiferkontrolle beinhalten. Ein erfolgreicher Angriff wäre damit nur möglich, wenn die DFN-PKI weiterhin Zertifikate oder andere Daten mit SHA-1 signieren würde. Dies ist nicht der Fall, die DFN-PKI ist komplett auf SHA-2 umgestiegen.

Daraus folgt: Der neue Angriff ändert noch nichts an der Sicherheit von bestehenden Zertifikaten der DFN-PKI, selbst wenn sie mit SHA-1 signiert sein sollten.

Es gilt aber natürlich nach wie vor: Die Verwendung von SHA-1-signierten Zertifikaten (sei es als Sub-CA-Zertifikat, als Server- oder als Nutzerzertifikat) sollte sehr zügig beendet werden, da die weitere Entwicklung nicht absehbar ist. Insbesondere sollten Sie darauf achten, dass Sie bei der Inbetriebnahme eines neuen SHA-2-Zertifikats auch die neue SHA-2-Zwischenzertifizierungskette einbinden.

Hinweis: Aktuelle Versionen von z.B. Google Chrome oder Internet Explorer/Edge lehnen SHA-1-signierte Server- oder Sub-CA-Zertifikate ab. Ob Sie Ihren Server korrekt konfiguriert haben, können Sie z.B. mit https://www.ssllabs.com/ssltest/ überprüfen.

Spezialfall Wurzelzertifikat

Die Tatsache, dass die erste Generation der DFN-PKI mit der „Deutsche Telekom Root CA 2“ aufgebaut ist, führt ebenfalls mit dem jetzt vorgestellten Angriff nicht zu Problemen. Dieses Wurzelzertifikat trägt zwar eine SHA-1-Selbstsignatur. Diese hat aber keine Sicherheitsfunktion. Dem Wurzelzertifikat wird vertraut, weil es in der Software (z.B. Betriebssystem, Webbrowser) fest vorinstalliert ist, die Signatur spielt keine Rolle. Siehe hierzu auch den Artikel in unserer FAQ: https://www.pki.dfn.de/faqpki/faq-umstellung-sha-2/#c18430

(jbr, 24.02.2017)