Derzeit keine.

Fragen und Antworten zu Zertifikaten in der DFN-PKI

1. Was sind die Pflichten von Zertifikatnehmern?

Jeder Zertifikatinhaber muss Sorge tragen, dass sein privater Schlüssel angemessen geschützt ist und dass das Zertifikat in Übereinstimmung mit der Policy der DFN-PKI eingesetzt wird. Das Zertifikat ist unverzüglich zu sperren, wenn die Angaben des Zertifikats nicht mehr korrekt sind oder wenn der private Schlüssel abhanden gekommen, gestohlen oder möglicherweise kompromittiert wurde. Eine Darstellung dieser Pflichten findet sich im Dokument "Informationen für Zertifikatinhaber in der DFN-PKI".

2. Wie sieht ein korrekter Zertifikatname (DN - Distiguished Name) aus?

Der Zertifikatname darf keine Umlaute und andere Sonderzeichen enthalten. Erlaubt sind a-z A-Z 0-9 ' ( ) , - . / : und Leerzeichen. Auf Groß- und Kleinschreibung ist zu achten. Dies gilt für alle Komponenten (Attribute) des Zertifikatnamens.

Der Zertifikatname muss der Namensform entsprechen, die im CPS Ihrer Zertifizierungsstelle festgelegt ist. Hierbei ist insbesondere auf die dort erlaubten bzw. festgelegten Attribute zu achten. Bei Beantragung eines Nutzerzertifikats über die Webschnittelle der Zertifizierungsstelle werden die festlegten Attribute automatisch übernommen. Regeln für den "Common Name" (Attribut CN) im Zertifikatnamen finden Sie unter Frage 3.

Bei Beantragung eines Serverzertifikats muss der Zertifikatname in einem PKCS#10 Zertifikatrequest übermittelt werden. Hinweise zur Erzeugung eines PKCS#10 Zertifikatrequests mit korrektem Zertifikatnamen finden Sie in der Anleitung zur Nutzung von OpenSSL.

3. Was ist beim CN (Common Name) – Eintrag im Zertifikatnamen zu beachten?

Neben den allgemeinen Regeln für Zertifikatnamen (s. Frage 1) ist beim CN-Eintrag folgendes zu beachten:

Nutzerzertifikate:
Der CN eines Nutzerzertifikats muss Vornamen und Nachnamen enthalten. Ausnahmen sind Gruppenzertifikate (CN=GRP:... oder GRP - ...) und Pseudonymzertifikate (CN=PN:... oder PN - ...). Namenszusätze, die im amtlichen Ausweispapier geführt werden (z.B. "Dr."), können in den CN aufgenommen werden. Darin nicht aufgeführte Namenszusätze (z.B. "Prof.") dürfen im CN nicht verwendet werden.

Server-/Maschinenzertifikate:
Der CN eines Serverzertifikats muss immer den voll qualifizierten Hostnamen (FQDN), z.B. server1.uni-musterstadt.de enthalten. Die Second-Level-Domain (im Beispiel uni-musterstadt) muss offiziell bei einer Domain-Registratur (z.B. DENIC) registriert sein und der Einrichtung, die das Zertifikat beantragt, gehören.

IP-Adressen dürfen im CN nicht angegeben werden.

4. Was ist bei Verwendung von Subject Alternative Names (SaN) zu beachten?

Falls aus bestimmten Gründen ein nicht registrierter oder nicht voll qualifizierter Hostname verwendet werden muss, kann dieser als Subject Alternative Name (SaN) in der Zertifikaterweiterung "subjectAlternativeName" mit dem Typ "DNS" eingetragen werden. IP-Adressen können ebenfalls als "subjectAlternativeName" mit dem Typ "IP" eingetragen werden. Bitte beachten Sie, dass neuere Versionen des Internet Explorers IP-Adressen im Subject Alternative Name nicht akzeptieren.

Der Eintrag von SaNs kann in der Regel nur von der Registrierungsstelle vorgenommen werden, indem ein vorliegender Zertifikatantrag bearbeitet wird. Sollten die für SaNs vorgesehenen freien Felder in der Bearbeitungsmaske der RA-Webschnittstelle nicht ausreichen, muss der Antrag nach dem Ausfüllen der vorhandenen Felder abgespeichert werden und die Bearbeitung anschließend fortgeführt werden. Es werden dann zusätzliche freie Felder für weitere SaNs angezeigt.

Bei Verwendung eines alternativen Namens sollte der voll qualifizierte Hostname aus dem CN immer auch zusätzlich als ein weiterer "subjectAlternativeName" angegeben werden. Das hilft vielen Browsern/Clients, Warnmeldungen wegen nicht zum Zertifikat passender Server-Namen zu vermeiden.

Der Eintrag eines "subjectAlternativeName" in einem PKCS#10 Zertifikatrequest, der über die Webschnittstelle für Nutzer und Administratoren übermittelt wird, wird in der DFN-PKI grundsätzlich übernommen. Ausnahme: Die Einrichtung hat für ihre CA die Ignorierung des "subjectAlternativeName" explizit vereinbart.

5. Können interne Domainnamen oder reservierte IP-Adressen verwendet werden?

Im Sicherheitsniveau Global dürfen interne Domainnamen wie z.B. "mail.local " oder reservierte IP-Adressen wie z.B. 192.168.6.1 seit Herbst 2015 nicht mehr in Zertifikaten verwendet werden.

Eine ausführliche Beschreibung und weitere Hinweise zu dieser Problematik finden Sie im Dokument "Interne Namen in Serverzertifikaten in der DFN-PKI."

6. Welches Zertifikatprofil soll ich wählen?

Wenn Sie über die Webschnittstelle Ihrer Zertifizierungsstelle ein Zertifikat unter der Registerkarte "Serverzertifikat" beantragen, müssen Sie ein Zertifikatprofil auswählen, das zu dem Einsatzzweck dieses Zertifikats passt. Welches Zertifikatprofil für welche Einsatzzwecke geeignet ist, finden Sie in der Liste DFN-PKI Zertifikatprofile (technische Beschreibung der Profile).

7. Wie erzeuge ich einen PKCS#10 Zertifikatrequest (CSR - Certificate Signing Request)?

Zum Beantragen eines Serverzertifikats über die Webschnittstelle Ihrer Zertifizierungsstelle müssen die Zertifikatdaten in einer PKCS#10 Datei im .pem-Format übermittelt werden. Dazu geben Sie in der Webschnittstelle an entsprechender Stelle den Namen der Datei an.

Die Datei kann auf verschiedene Weise erzeugt werden, z.B. mit Hilfe der entsprechenden Server-Software. Lesen Sie dazu bitte die Dokumentation Ihrer Server-Software und folgen Sie den Anweisungen.

Eine PKCS#10 Datei kann auch mit Hilfe der Open Source Software OpenSSL (http://www.openssl.org ) erzeugt werden. Lesen Sie dazu bitte die Anleitung zur Nutzung von OpenSSL.

8. Welche Bedingungen muss ein PKCS#10 Zertifikatrequest (CSR - Certificate Signing Request) erfüllen?

Ein CSR für ein Zertifikat in der DFN-PKI muss folgende Bedingungen erfüllen:

  • Er gehört zu einem mindestens 2048 Bit langem RSA Schlüssel, der z.B. als Datei oder innerhalb der Anwendung vorliegt und ggf. mit einem Passwort geschützt ist.
  • Er ist von dem enthaltenen Schlüssel selbstsigniert.
  • Der im CSR beantragte Zertifikatname (Distinguished Name, DN) genügt den Regeln für Zertifikatnamen (s. Frage 1) und entspricht der in Ihrem CPS festgelegten Namensform. Hierbei ist insbesondere auf die dort erlaubten bzw. festgelegten Attribute zu achten. Lesen Sie dazu bitte in der Anleitung zur Nutzung von OpenSSL das Kapitel 4 „Zertifikatnamen“.

Zur Erzeugung eines PKCS#10 Zertifikatrequests lesen Sie bitte die Anleitung zur Nutzung von OpenSSL.

9. Wie kann ich einen PKCS#10 Zertifikatrequest überprüfen?

Wenn Sie die Datei mit Ihrem PKCS#10 Zertifikatantrag vor dem Hochladen in die Webschnittstelle überprüfen möchten, können Sie dazu OpenSSL benutzen. Mit der Befehlszeile

openssl req -text -verify -in request.pem

zeigt Ihnen OpenSSL den Inhalt der CSR Datei „request.pem“ in lesbarer Form an und verifiziert auch gleich die Selbstsignatur des CSR.

Lesen Sie ggf. auch die Anleitung zur Nutzung von OpenSSL.

10. Wie wird der Public Key Fingerprint des PKCS#10 Zertifikatrequests berechnet?

Wenn Sie den PKCS#10 Zertifikatrequest als Datei vorliegen haben, so können Sie mit openssl den Public Key Fingerprint berechnen, indem Sie die folgende Befehlszeile nutzen:

openssl req -in <PKCS#10 Datei> -pubkey -noout | openssl rsa -pubin -text -noout | sed -e '/Modulus:$/d' | sed -e 's/Public-Key: (\(.*\))/Modulus (\1):/' | openssl sha1

11. Wie erzeuge ich eine PKCS#12 Datei?

Zum Import eines Zertifikats in eine Anwendung benötigen Sie in der Regel das Zertifikat zusammen mit dem privaten und öffentlichen Schlüssel und ggf. mit der gesamten Zertifikatkette in einer PKCS#12-Datei (Extension .p12). Wenn Sie das Schlüsselpaar in Ihrem Browser erzeugt und das Zertifikat in den Browser importiert haben, können Sie eine PKCS#12-Datei aus dem Browser heraus exportieren. Siehe dazu FAQ-Mozilla, Frage 5 bzw. FAQ-Windows, Frage 4.

Wenn Ihr privater Schlüssel und Ihr Zertifikat an anderer Stelle auf Ihrem Rechner abgelegt sind (in der Regel bei Serverzertifikaten), können Sie mit Hilfe von OpenSSL eine PKCS#12-Datei erzeugen, die das Zertifikat, den privaten und öffentlichen Schlüssel und die CA-Zertifikatkette enthält.
Lesen Sie dazu bitte die Anleitung zur Nutzung von OpenSSL.

12. Was bedeutet die Verlängerung eines Zertifikats?

Da Zertifikate ein Gültigkeitsende haben, müssen sie regelmäßig erneuert oder verlängert werden. Unter einer Zertifikatverlängerung versteht man das Ausstellen eines neuen Zertifikats mit demselben Distinguished Name eines bereits existierenden Zertifikats. Neues und altes Zertifikat unterscheiden sich immer mindestens im Gültigkeitszeitraum und der Seriennummer.

13. Welche Arten von Zertifikatverlängerung gibt es?

Technisch lässt sich die Zertifikatverlängerung auf zwei Arten durchführen: Entweder mit Austausch des geheimen und öffentlichen Schlüssels oder unter Beibehaltung des alten Schlüsselpaars.

Grundsätzlich sollte der erste Weg mit Austausch gewählt werden, was einer Neuausstellung entspricht. Dabei muss auf jeden Fall das alte Schlüsselpaar aufbewahrt werden, da sonst verschlüsselte Daten wie z.B. E-Mails nicht mehr gelesen werden können. Eine Ausnahme bilden Zertifikate für Webserver, die niemals zum persistenten Verschlüsseln von Daten verwendet wurden. Hier kann eine Zertifikatverlängerung auch ohne Schlüsseltausch problemlos durchgeführt werden.

Die Zertifikatverlängerung ohne Schlüsseltausch hat theoretisch zwar Vorteile, ist in der Praxis jedoch problematisch: Die meiste Software identifiziert Schlüssel anhand des dazugehörigen Zertifikats, so dass ein unbedachtes Löschen von abgelaufenen Zertifikaten auch hier dazu führen kann, dass verschlüsselte Daten nicht mehr zugänglich sind.

14. Wie kann ein Zertifikat in der DFN-PKI verlängert werden?

Für eine Verlängerung ist in der DFN-PKI wie beim Erstantrag vorzugehen. Der Antragsteller ruft die Antragsseiten seiner Zertifizierungsstelle auf, erstellt einen Antrag unter Beibehaltung seiner Angaben aus dem alten Zertifikat und druckt diesen Antrag aus. Der Antrag muss anschließend der Registrierungsstelle übermittelt werden, die die weitere Bearbeitung übernimmt.

15. Was bedeutet die Veröffentlichung von Zertifikaten?

Bei der Veröffentlichung von Zertifikaten muss grundsätzlich zwischen Nutzer- und Serverzertifikaten unterschieden werden.

Für Nutzerzertifikate gilt:

Wenn Sie der Veröffentlichung Ihres Nutzerzertifikats zustimmen, wird dieses zum Verzeichnisdienst der DFN-PKI hinzugefügt, der im Internet frei zugänglich ist. Der Vorteil einer Veröffentlichung besteht darin, dass jeder, der Ihnen eine verschlüsselte E-Mail senden möchte, dies leicht tun kann, da das entsprechende Zertifikat frei verfügbar ist. Da Nutzerzertifikate den Namen und die E-Mail Adresse des Zertifikatnehmers enthalten, sind diese Daten bei einer Zustimmung zur Veröffentlichung frei verfügbar.

Die Veröffentlichung eines Nutzerzertifikats ist vergleichbar mit einer Telefonnummer, die Sie in ein öffentliches Telefonverzeichnis eintragen lassen können. Stimmen Sie der Eintragung zu, so kann jeder (ob gewünscht oder ungewünscht) Sie ohne vorherige Kontaktaufnahme telefonisch erreichen.

Bitte beachten Sie:

  • Sie können Ihre Zustimmung zur Veröffentlichung Ihres Zertifikats jederzeit mit Wirkung für die Zukunft durch eine E-Mail an dfnpca@dfn-cert.de widerrufen. Nennen Sie uns in der E-Mail bitte die Seriennummer des Zertifikats und die ausstellende Zertifizierungsstelle. Diese Informationen sind aus den Zertifikatdetails ersichtlich.
  • Wenn Sie der Veröffentlichung Ihres Nutzerzertifikats nicht zustimmen, kann dies nachträglich nicht geändert werden. Sie müssen dann ein neues Zertifikat beantragen und dafür der Veröffentlichung zustimmen.

Für Serverzertifikate gilt:

Serverzertifikate werden in der DFN-PKI in Certificate Transparency Logs veröffentlicht. Dies sind von Dritten betriebene Systeme, die der Transparenz und damit der Sicherheit der Web-PKI dienen. Ohne die Veröffentlichung wären Serverzertifikate nicht mehr in Google Chrome funktionsfähig.

Die Veröffentlichung von Serverzertifikaten kann nicht zurückgenommen werden. Certificate Transparency Logs werden von Dritten betrieben, auf die der DFN keinen Einfluss hat. Darüber hinaus basiert Certificate Transparency auf Datenstrukturen, die durch digitale Signaturen inhärent gegen nachträgliche Änderungen gesichert ist.

Weitere Erläuterungen finden Sie im Blog der DFN-PKI.

16. Wie erreiche ich den Verzeichnisdienst der DFN-PKI?

Der Verzeichnisdienst der DFN-PKI für Nutzerzertifikate im Sicherheitsniveau Global ist durch folgenden LDAP-Server realisiert:

  • Hostname: ldap.pca.dfn.de
  • Basis-DN: ou=DFN-PKI,o=DFN-Verein,c=de
  • Port: 389
  • Suchfilter: (objectclass=*)

Für Nutzerzertifikate im Sicherheitsniveau Grid benutzen Sie statt dessen den

  • Basis-DN: o=GridGermany,c=de

17. Was sind "Extended Validation" Zertifikate?

Greift man mit einem Browser auf eine zertifikatgeschützte Webseite zu, erhält man einen Hinweis auf das Sicherheitsniveau, unter dem das entsprechende Zertifikat ausgestellt wurde. "Extended Validation (EV)" Zertifikate enthalten einen Verweis auf die Zertifizierungsrichtlinie des Ausstellers und können dadurch von Browsern speziell dargestellt werden, falls diese Zertifizierungsrichtlinie einer "strikteren" Prüfung unterliegt (so wird z.B. die URL-Leiste grün gefärbt und es erscheint der Name des Ausstellers in grün).

"Extended Validation" Zertifikate können in der DFN-PKI zur Zeit nicht ausgestellt werden. Das liegt u.a. daran, dass noch nicht abschließend klar ist, ob EV-Zertifikate in der Praxis wirklich Sicherheitsvorteile bringen oder ob diese doch eher unter kommerziellen Gesichtspunkten eingeführt wurden (ein EV-Zertifikat kostet derzeit mehrere hundert US$ pro Jahr). Gleichzeitig tragen die Browserhersteller zur Verunsicherung der Nutzer bei, indem bei Seiten ohne EV-Zertifikate Meldungen wie "Diese Website wird betrieben von (unbekannt)" angezeigt werden.

Der DFN-Verein beobachtet die Entwicklung zu EV-Zertifikaten und plant diese anzubieten, wenn sicherheitstechnischer Mehrwert und Kosten in einem angemessenen Gleichgewicht stehen.

18. Was sind PGP-Zertifikate?

Neben den im DFN als Standard etablierten X.509 Zertifikaten gibt es als Alternative PGP-Zertifikate. Zwischen beiden Strukturen existiert u.a. ein wesentlicher Unterschied: Erfolgt die Vertrauensbildung bei X.509 über ein hierarchisches System von Zertifizierungs- und Registrierungsstellen, so wird dies bei PGP über ein sogenanntes "Web of Trust" gebildet.

In der DFN-PKI werden aufgrund der Anforderungen der DFN-Anwender ausschließlich X.509 Zertifikate ausgestellt. Es bleibt jedem Nutzer unbenommen, sich sein eigenes PGP-Schlüsselpaar zu erzeugen und sich über das Web of Trust mit Zertifikaten zu versorgen.

19. Wie überprüfe ich den Fingerprint eines Wurzelzertifikats?

Den Fingerprint eines Wurzelzertifikats können Sie über den OpenSSL-Befehl

 

 openssl x509 -in <Dateiname des Wurzelzertifikats> -noout -fingerprint

 

ausgeben. Vergleichen Sie den Fingerprint mit dem von der CA veröffentlichten Fingerprint. Diese müssen gleich sein. Den von der CA veröffentlichten Fingerprint sollten Sie über einen anderen Weg beziehen als das Wurzelzertifikat - beispielsweise per Telefon.

20. Was sind Wildcard-Zertifikate?

Wildcard-Zertifikate sind spezielle Serverzertifikate, bei denen der FQDN im CN oder in einem alternativen Namen vom Typ 'DNS' an der am weitesten links stehenden Domain-Komponente einen Stern ("*") - die Wildcard - enthält.

Beispiel: CN=*.pki.dfn.de

Dadurch kann dieses Zertifikat für alle FQDNs unterhalb von pki.dfn.de verwendet werden, z.B. für pki1.pki.dfn.de und pki2.pki.dfn.de, allerdings nicht für längere FQDNs wie etwa www.pki1.pki.dfn.de oder kürzere wie pki.dfn.de selbst.

21. Wie können Wildcard-Zertifikate in der DFN-PKI genutzt werden?

Da Wildcard-Zertifikate für eine ganze Subdomain verwendet werden können, ist der potentielle Schaden bei einer Kompromittierung des privaten Schlüssels deutlich höher als bei Zertifikaten für genau spezifizierte FQDNs.

Daher dürfen Wildcard-Zertifikate in der DFN-PKI ausschließlich verwendet werden, wenn das Einsatzszenario dies technisch erzwingt. Beispielsweise gibt es Softwaresysteme, die dynamisch Host-Namen erzeugen (gerade im Bibliotheksumfeld), die mit herkömmlichen Zertifikaten schlicht nicht funktionieren. Beispiele für solche Software: EZProxy, Netman/HAN

Ein und dasselbe Wildcard-Zertifikat darf nicht auf verschiedenen Servern mit unterschiedlichen Diensten, Einsatzzwecken oder Schutzklassen verwendet werden. Aufgrund des höheren Schadenspotentials bei Kompromittierung sind Wildcard-Zertifikate kein probates Mittel der Arbeitsersparnis bei der Zertifikatbeantragung.

Wildcard-Zertifikate werden nur unterhalb von Sub-Domains oder Second-Level-Domains ausgestellt, die ausschließlich für einen klar abgegrenzten Zweck genutzt werden, also beispielsweise entweder für "*.roaming.dfn.de" oder für "*.dfnroaming.de", nicht aber für "*.dfn.de"

22. Wie können Wildcard-Zertifikate in der DFN-PKI beantragt werden?

Aufgrund des erhöhten Schadenspotentials können Wildcard-Zertifikate in der DFN-PKI nur auf Anfrage von handlungsberechtigten Personen bei der DFN-PCA dfnpca@dfn-cert.de beantragt werden.

23. Auf welchen Certificate Transparency Logs werden Serverzertifikate der DFN-PKI veröffentlicht?

Mit Stand Februar 2018 werden die folgenden Logs verwendet:

plausible.ct.nordu.net
mammoth.ct.comodo.com
sabre.ct.comodo.com
ct.googleapis.com/rocketeer
ct.googleapis.com/pilot

     aktualisiert am: 21.03.2018 |