Archiv des Autors: Juergen Brauckmann

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

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

    • Titel und Fußzeile: Versionsnummer und Datum.
    • 1.2: OIDs
    • 3.1.1: SN, GN, pseudonym; CN single-value
    • 3.1.2: SN, GN, pseudonym; CN single-value
    • 3.1.3: Attribut pseudonym
    •  4.2.1: Änderung der Frist zur Wiederverwendung von Daten über die Berechtigungsprüfung bei Domains und IP-Adressen auf 398 Tage ab 1.10.2021
    • 4.9.12: Methoden zum Nachweis der Kompromittierung eines privaten Schlüssels
    • 4.9: Tippfehler entfernt, 9.6.5: Tippfehler Kapitelüberschrift beseitigt, 3.1.2: Tippfehler entfernt

Die Version 9 der Erklärung zum Zertifizierungsbetrieb für das Sicherheitsniveau „Global“, Datum des Inkrafttretens ebenfalls 30.06.2021, beinhaltet folgende Änderungen:

      • Titel und Fußzeile: Versionsnummer und Datum
      • 1.2: OIDs

Die neuen Dokumente finden Sie unter den folgenden URLs:

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

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

Mit Änderungsmarkierungen:

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

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

(Jürgen Brauckmann, 14.06.2021)

Java RA-Oberfläche Version 3.6

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

guira-3.6.zip

guira-3.6.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

Gegenüber der Version 3.5.1 umfasst die Version 3.6 (25.05.2021) folgende Änderungen:

  • Unterstützung der DN-Attribute givenName, surname und pseudonym in Assistenten.
  • Fehlermeldung bei fehlender PKCS#11-Library beim Einrichten einer CA verbessert.
  • Fehler beim Sperren von Zertifikaten in Assistenten bei Verwendung des Kommandos ‚NewAndApprove‘ behoben.
  • Fehler beim Export von Zertifikaten (unter MacOS) behoben.

Systemvoraussetzungen

  • OpenJDK ab Version 11
  • Andere aktuelle Java Umgebungen können auch verwendet werden. Bitte beachten Sie hierzu: In unseren Abnahmetests verwenden wir ausschließlich OpenJDK.

Die enthaltenen Startskripte erwarten eine gesetzte Umgebungsvariable JAVA_HOME. Hinweise hierfür finden Sie in den Dateien README.txt und Anleitung_Windows.pdf.

Hinweise zum Bezug von Java finden Sie unter: https://blog.pki.dfn.de/2019/05/bezugsquellen-fuer-java-zum-betrieb-der-ra-oberflaeche

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.

(Jürgen Brauckmann, 07.06.2021)

Umstellung notwendig: Änderungen am SOAP-API

Einige Anwender der DFN-PKI nutzen die SOAP-API (https://blog.pki.dfn.de/tag/soapclient-releases/) zur Entwicklung von eigenen Systemen. An diesen Eigenentwicklungen müssen nun bis spätestens November 2021 Anpassungen vorgenommen werden, um die folgenden Änderungen umzusetzen.

Nicht betroffen sind Anwender, die ausschließlich die Java RA-Oberfläche und die Web-Antragsseiten nutzen.

Änderungen bei newRequest()

Der Subject-DN im PKCS#10-Request, der bei newRequest() übergeben wird, muss für Nutzer-und Pseudonymzertifikat anders aufgebaut werden.

Für Nutzerzertifikate: Es müssen zusätzliche DN-Attributen SN (surname, Nachname) und GN (givenName, Vorname) übergeben werden. Beispiel:

CN=Martha Musterfrau,GN=Martha,SN=Musterfrau,O=Musterorganisation,L=Musterstadt,ST=Musterbundesland,C=DE

Anträge für Nutzerzertifikate ohne CN, GN und SN werden an November 2021 nicht mehr angenommen.

Für Pseudonymzertifikate: Es muss ein zusätzliches DN-Attribut pseudonym übergeben werden. Der Wert soll wie der CN sein, aber ohne das führende „PN:“ oder „PN – „. Beispiel:

CN=PN: Mein Pseudonym,pseudonym=Mein Pseudoynm,O=Musterorganisation,L=Musterstadt,ST=Musterbundesland,C=DE

Anträge ohne CN und pseudonym, wenn der CN mit „PN:“ oder „PN – “ beginnt, werden ab November 2021 nicht mehr angenommen.

Für Gruppenzertifikate (Kennzeichnung „GRP:“ bzw. „GRP – „) und Serverzertifikate ändert sich nichts.

Selbstverständlich müssen die neuen Regeln auch bei der Verwendung von setRequestParameters() bzw. setExtendedRequestParameters() beachtet werden.

Optionale Übergabe des Subject-DN als separatem Parameter

Als weitere Änderung kann newRequest() optional auch zusätzlich der Subject-DN übergeben
werden. Dieser Wert überschreibt dann den Subject-DN aus dem übergebenen PKCS#10-Request.

Änderungen bei newRevocationRequest()

Der Parameter Reason in newRevocationRequest() darf in Zukunft nur noch die Werte
1, 3, 4 oder 5 annehmen. Die Bedeutung:

1, keyCompromise: Dieser Sperrgrund signalisiert, dass der zum Zertifikat
gehörende geheime Schlüssel kompromittiert (offengelegt) wurde oder
andere Aspekte der durch den Zertifikatnamen (SubjectDN) beschriebenen
Entität kompromittiert wurden.

3, affiliationChanged: Dieser Sperrgrund signalisiert, dass der Zertifikatname
(SubjectDN) oder andere Informationen im Zertifikat nicht mehr den
aktuellen Tatsachen entsprechen, etwa weil sich Namen,
E-Mail-Adressen, Funktionsrollen oder Zugehörigkeiten geändert haben,
dass aber gleichzeitig kein Grund für einen Verdacht besteht, dass der
zum Zertifikat gehörende geheime Schlüssel kompromittiert wurde.

4, superseded: Dieser Sperrgrund signalisiert, dass das Zertifikat von
einem neueren Zertifikat abgelöst wurde, dass aber gleichzeitig kein
Grund für einen Verdacht besteht, dass der zum zu sperrenden
Zertifikat gehörende geheime Schlüssel kompromittiert wurde.

5, cessationOfOperation: Dieser Sperrgrund signalisiert, dass das Zertifikat
nicht länger für die Zwecke eingesetzt wird, für die es ausgestellt
wurde, dass aber gleichzeitig kein Grund für einen Verdacht besteht,
dass der zum Zertifikat gehörende geheime Schlüssel kompromittiert
wurde.

Im soapclient gibt es hierfür die folgende neue Methode:

DFNCERTPublic.newRevocationRequest(int RaID,
BigInteger Serial, de.dfncert.enums.RevocationReason Reason, String Pin)

bzw.

DFNCERTRegistration.newRevocationRequest(BigInteger Serial, de.dfncert.enums.RevocationReason Reason)

Die Sperrgründe werden als de.dfncert.enums.RevocationReason übergeben:

RevocationReason.KEY_COMPROMISE
RevocationReason.AFFILIATION_CHANGED
RevocationReason.SUPERSEDED
RevocationReason.CESSATION_OF_OPERATION

Diese eingeschränkten Sperrgründe müssen auch bei einem Aufruf von setRevocationInfo() berücksichtigt werden.

Zeitplanung

Die aktuelle Schnittstelle (Stand Februar 2021) ist noch voll abwärts-kompatibel. Ab November 2021 wird allerdings die Verwendung der neuen DN-Parameter in newRequest(), setRequestParamaters() und setExtendedRequestParameters() und der neuen Sperrgründe in newRevocationRequest() und setRevocationInfo() verpflichtend.

 

(Jürgen Brauckmann, 18.2.2021)

SOAP-Client Version 4.3

Das Bundle mit der Dokumentation und der Java-Client-Bibliothek der SOAP-Schnittstelle der DFN-PKI steht nun in einer neuen Version für JDK >= 11 bereit: https://info.pca.dfn.de/doc/soapclient-bundle-4.3.tar.gz

Änderungen der Version 4.3 gegenüber 4.0.2:

Neue Funktionen in der öffentlichen Schnittstelle:

  newRequest(int RaID, String PKCS10, String[] AltNames,
            String Role, String Pin, String AddName, String AddEMail,
            String AddOrgUnit, boolean Publish,String Subject)

Erstellt einen neuen Zertifikatantrag, wobei der Subject-DN separat übergeben wird. Dieser Subject-DN überschreibt den Wert aus dem übergebenen PKCS#10-Request.

  newRevocationRequest(int RaID, BigInteger Serial, RevocationReason Reason, String Pin)

Erstellt einen Sperrantrag, wobei der Sperrgrund als Typ RevocationReason übergeben wird.

Die bisherige Funktion newRevocationRequest(int RaID, BigInteger Serial, String Reason, String Pin) (Übergabe des Sperrgrunds als String) ist veraltet, steht bis voraussichtlich 11/2021 aber noch zur Verfügung.

Neue Funktion der Registrierungsstelle:

  newRevocationRequest(BigInteger Serial, RevocationReason Reason)

Erstellt einen Sperrantrag, wobei der Sperrgrund als Typ RevocationReason übergeben wird.

Die bisherige Funktion newRevocationRequest(BigInteger Serial, String Reason) (Übergabe des Sperrgrunds als String) ist veraltet, steht aber bis voraussichtlich 11/2021 noch zur Verfügung.

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, 18.02.2021)

Java RA-Oberfläche Version 3.5.1

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

guira-3.5.1.zip

guira-3.5.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

Gegenüber der Version 3.5 umfasst die Version 3.5.1 (16.02.2021) folgende Änderungen:

  • Fehler beim Sperren von Zertifikaten über das Kontext-Menü behoben

Systemvoraussetzungen

  • OpenJDK ab Version 11
  • Andere aktuelle Java Umgebungen können auch verwendet werden. Bitte beachten Sie hierzu: In unseren Abnahmetests verwenden wir ausschließlich OpenJDK.

Die enthaltenen Startskripte erwarten eine gesetzte Umgebungsvariable JAVA_HOME. Hinweise hierfür finden Sie in den Dateien README.txt und Anleitung_Windows.pdf.

Hinweise zum Bezug von Java finden Sie unter: https://blog.pki.dfn.de/2019/05/bezugsquellen-fuer-java-zum-betrieb-der-ra-oberflaeche

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.

(Jürgen Brauckmann, 16.02.2021)

Java RA-Oberfläche Version 3.5

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

guira-3.5.zip

guira-3.5.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

Gegenüber der Version 3.3 umfasst die Version 3.5 (02.02.2021) folgende Änderungen:

  • Unterstützung der DN-Attribute givenName (GN), surname (SN) und pseudonym
  • Beim Sperren von Zertifikaten können nur noch standardisierte Sperrgründe ausgewählt werden.
  • Behebung kleinerer Fehler
  • Ergänzung der internen Mechanismen von Assistenten

Systemvoraussetzungen

  • OpenJDK ab Version 11
  • Andere aktuelle Java Umgebungen können auch verwendet werden. Bitte beachten Sie hierzu: In unseren Abnahmetests verwenden wir ausschließlich OpenJDK.

Die enthaltenen Startskripte erwarten eine gesetzte Umgebungsvariable JAVA_HOME. Hinweise hierfür finden Sie in den Dateien README.txt und Anleitung_Windows.pdf.

Hinweise zum Bezug von Java finden Sie unter: https://blog.pki.dfn.de/2019/05/bezugsquellen-fuer-java-zum-betrieb-der-ra-oberflaeche

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.

(Jürgen Brauckmann, 15.02.2021)

Überwachen der Zertifikate zu eigenen Domains mit Certificate Transparency

[Update 21.01.2021: Hinweise zu Limitierungen bei der Ergebnisgröße; showSQL=Y]

Certificate Transparency ist ein seit einigen Jahren etablierter Mechanismus, um die in der sog.  Web-PKI verwendeten Zertifikate sichtbar zu machen.

Kern des Systems sind öffentlich zugängliche Certificate Transparency Logs, die von Organisationen wie Google, Cloudflare oder kommerziellen CAs betrieben werden. In diese Logs wird üblicherweise direkt bei Erstellung eines Zertifikats ein sogenanntes „Precertificate“ mit allen relevanten Daten geschrieben und öffentlich wieder abrufbar gemacht. Aktuell gibt es 30 Logs, die vom Chrome-Browser akzeptiert werden: https://www.certificate-transparency.org/known-logs

Die DFN-PKI nutzt dieses System seit 2018, siehe auch https://blog.pki.dfn.de/2018/01/certificate-transparency-in-der-dfn-pki/

Inzwischen ist davon auszugehen, das praktisch jedes weltweit ausgestellte Serverzertifikat mit Browser-Verankerung  in den Logs erscheinen wird. Dies kann man sich zunutze machen, um neu ausgestellte Zertifikate für die eigene Domain zu überwachen. Dies kann z.B. für die folgenden Zwecke geschehen:

  • Weitere Datenbasis für das Organisations-eigene Zertifikatmanagement
  • Schnelle Erkennung von fälschlich oder betrügerisch ausgestellten Zertifikaten, z.B. durch eigene Fehler oder Fehler/Schwachstellen bei der CA  (Bedingung: Die Mechanismen der CA zum Schreiben in die CT Logs wurden vom Angreifer nicht überwunden)
  • Zentrales Monitoring über die in der Organisation eingesetzten CAs
  • Erkennen von zusätzlichen Zertifikaten im Zusammenhang mit CDN- oder Cloud-Diensten

Zertifikate aus internen CAs, die nicht per Default im Browser oder Betriebssystem als vertrauenswürdig erscheinen, werden mit Certificate Transparency nicht erfasst.

Inzwischen gibt es einige Angebote, die Certificate Transparency Logs abfragen, die Informationen aufbereiten und zur Verfügung stellen, beispielsweise von Censys.io, Cloudflare,  sslmate, Sectigo (crt.sh), Google und Facebook (teilweise auch kostenpflichtig).

Prinzipiell ist es möglich, die 30 Certificate Transparency Logs direkt selbst zu untersuchen. Mit certspotter steht hierfür sogar eine fertige Software zur Verfügung: https://github.com/SSLMate/certspotter

Leider ist hierfür ein relativ hoher betrieblicher Aufwand notwendig: Aufgrund der Menge der weltweit ausgestellten Serverzertifikate kann der Ressourcen-Bedarf von certspotter, insbesondere in Bezug auf die nötige Bandbreite, beträchtlich sein. Schlimmer noch: Einige der Logs wachsen um mehrere hundert Zertifikate pro Sekunde, liefern mitunter aber nicht in entsprechender Rate aus, so dass es teilweise gar nicht möglich ist, die im Log vorhandenen Zertifikate kontinuierlich zu monitoren.

crt.sh

Ein anderer Weg macht sich den Dienst von https://crt.sh zu nutze. crt.sh fragt kontinuierlich alle relevanten CT Logs ab, und bereitet die Daten in einer leicht konsumierbaren Form auf. Der Dienst wird von Sectigo, einem CA-Anbieter, betrieben, und ist öffentlich zugänglich.

crt.sh bietet ein einfaches API an, um zu einer Domain ausgestellte Zertifikate zu erhalten. Die Ergebnisse werden auf Wunsch als JSON zurückgegeben.

Abfrage (unter Ausschluss von abgelaufenen Zertifikaten):
https://crt.sh/?q=%.example.org&exclude=expired&output=json

Ausgabe:

[{"issuer_ca_id":185756,"issuer_name":"C=US, O=DigiCert Inc, CN=DigiCert TLS RSA SHA256 2020 CA1",
"common_name":"www.example.org",
"name_value":"example.org\nwww.example.org,
"id":3704614715,
"entry_timestamp":"2020-11-27T13:49:06.706",
"not_before":"2020-11-24T00:00:00","not_after":"2021-12-25T23:59:59",
"serial_number":"0fbe08b0854d05738ab0cce1c9afeec9"},
....

Mit Hilfe des Eintrags "id" aus der Ausgabe kann das entspr. Zertifikat mit der Abfrage https://crt.sh/?id=<Wert von id> direkt betrachtet werden, z.B. https://crt.sh/?id=3704614715

Großer Nachteil dieser Lösung: Die Anzahl der zurückgelieferten Zertifikate ist limitiert. Daher können auf diesem Wege nur Domains oder Subdomains mit weniger als ca. 1000 Zertifikaten überwacht werden.

Es gibt keine Möglichkeit, das Ergebnis auf einen bestimmten Zeitraum einzuschränken. Für eine eigene Monitoring-Lösung muss man also eine eigene Datenbank mit bereits bekannten Zertifikaten aufbauen, und die Ergebnisse gegen diese abgleichen.

crt.sh ist ein sehr belasteter Dienst, und es kommt gelegentlich vor, dass eine Abfrage mit einem HTTP Status 502 abbricht. In diesem Fall empfiehlt sich eine kleine Wartezeit und ein erneuter Versuch.

„leaf certificate“ und „Precertificate“

Häufig wird man zu einem existierenden Zertifikat zwei Einträge finden. Im o.g. Beispiel:
https://crt.sh/?id=3692510597
https://crt.sh/?id=3704614715

Die beiden Einträge meinen das gleiche Zertifikat mit identischen Daten und identischer Seriennummer, aber einmal als normales „leaf certificate“ und einmal als „Precertificate“ (Zeile „Summary“ ganz am Anfang der Darstellung bei crt.sh). Dies ist nicht ungewöhnlich und kein Grund zur Sorge. Ein Precertificate ist, grob gesagt, ein Artefakt mit dem die CA vor der Ausstellung des korrekten „echten“ Zertifikats einen Beweis für die Aufnahme in CT Logs generieren kann. Eine genauere Beschreibung von Precertificates findet sich in Kapitel 3.1 des RFC: https://tools.ietf.org/html/rfc6962#section-3.1

Fügt man zur Abfrage den Parameter deduplicate=Y hinzu, erhält man nicht mehr sowohl leaf als auch Precertificate in der Ausgabe.

crt.sh Datenbank

Neben der Abfrage per HTTP ist auch die zugrunde liegende postgresql-Datenbank von crt.sh direkt ansprechbar:

$ psql -h crt.sh -p 5432 -U guest certwatch

Eine Beispiel-Abfrage zum Abruf der nicht abgelaufenen Zertifikate der Domain example.org (Quelle):

SELECT ci.ISSUER_CA_ID,
        ca.NAME ISSUER_NAME,
        ci.NAME_VALUE NAME_VALUE,
        min(c.ID) MIN_CERT_ID,
        min(ctle.ENTRY_TIMESTAMP) MIN_ENTRY_TIMESTAMP,
        x509_notBefore(c.CERTIFICATE) NOT_BEFORE,
        x509_notAfter(c.CERTIFICATE) NOT_AFTER
    FROM ca,
        ct_log_entry ctle,
        certificate_identity ci,
        certificate c
    WHERE ci.ISSUER_CA_ID = ca.ID
        AND c.ID = ctle.CERTIFICATE_ID
        AND reverse(lower(ci.NAME_VALUE)) LIKE reverse(lower('%.example.org'))
        AND ci.CERTIFICATE_ID = c.ID
        AND x509_notAfter(c.CERTIFICATE) > statement_timestamp()
    GROUP BY c.ID, ci.ISSUER_CA_ID, ISSUER_NAME, NAME_VALUE, c.CERTIFICATE
    ORDER BY MIN_ENTRY_TIMESTAMP DESC, NAME_VALUE, ISSUER_NAME;

Die Datenbank ist allerdings durchaus nicht-trivial. Viele Daten sind nicht als gewöhnliche Spalten verfügbar, sondern müssen über Funktionen abgefragt werden. Auch die postgresql-Datenbank ist hoch belastet; Verbindungsfehler oder Timeouts sind nicht ungewöhnlich.

showSQL=Y

Um eine Ausgangsbasis für mögliche Abfragen in der Datenbank zu erhalten, kann man wieder die Webseite https://crt.sh verwenden: Fügt man an das Ende einer Suche den Parameter showSQL=Y an, zeigt crt.sh die zugehörige Datenbankabfrage.

Beispiel:

https://crt.sh/?dNSName=%25.example.org&exclude=expired&deduplication=Y&showSQL=Y

(Jürgen Brauckmann, 11.01.2021)

ETSI-Audit 2020 abgeschlossen

Auch dieses Jahr wurde die DFN-PKI auditiert, um die Erfüllung der Anforderungen von ETSI EN 319 411-1 und den Baseline Requirements des CA/Browserforums nachweisen zu können. Wie bei jedem Audit, der bisher durchgeführt wurde, wurde bei einer geringen Anzahl von Teilnehmern die Arbeit des Teilnehmerservice untersucht.

Wir bedanken uns bei allen Einrichtungen, die wie auch in den letzten Jahren mit ihrer guten Arbeit ein erfolgreiches Audit der DFN-PKI  ermöglicht haben!

Die zugehörige Zertifizierungsurkunde ist Anfang Dezember vom TÜViT veröffentlicht worden:  https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/67133UD.pdf

(Jürgen Brauckmann, 10.12.2020)

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

Ab 07.10.2020 werden wir, wie auf der Betriebstagung des DFN-Vereins angekündigt und mit der Zertifizierungsrichtline der DFN-PKI im Sicherheitsniveau „Global“ in Version 6 vorbereitet, die Validierung von IP-Adressen, die in Zertifikate für Datenverarbeitungssysteme aufgenommen werden sollen, erneut umstellen.

Das nun umgesetzte Verfahren nach den Baseline Requirements des CA/Browser-Forums, Kap. 3.2.2.5.3, sieht vor, dass zu jeder IP-Adresse, die aufgenommen werden soll, ein Reverse Lookup durchgeführt wird. Ist einer der Namen, die als Ergebnis geliefert wurden, über eine bestehende Domain-Freischaltung im zuständigen Teilnehmerservice zugelassen, so kann auch die IP-Adresse in das Zertifikat aufgenommen werden.

Das bisherige Verfahren mit einer statischen Whitelist auf unseren Systemen, die per Hand gepflegt und mit Whois abgeglichen wurde, wird eingestellt.

Bestehende Zertifikate mit IP-Adressen, die nach der alten Methode geprüft wurden, bleiben natürlich unverändert gültig.

Bevor Sie sich die Mühe machen, eine IP-Adresse in einen Request aufzunehmen, 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.

(Jürgen Brauckmann, 05.10.2020)