Schlagwort-Archive: PKCS#12

Ab jetzt: Neue Antragsseiten für Nutzerzertifikate – ohne Verwendung von LocalStorage im Browser

Wie bereits Ende Januar im Beitrag Neue Antragsseiten für Nutzerzertifikate, die Zweite angekündigt, haben wir die Beantragung von Nutzerzertifikaten nun so umgestaltet, dass Offline-Website-Daten (LocalStorage) nicht mehr vorausgesetzt werden. Diese neue Version ist ab sofort in Betrieb. Damit entfällt für neu gestellte Nutzerzertifikatanträge die häufig fehleranfällige Abhängigkeit von LocalStorage.

Diese Umgestaltung hat zur Folge, dass sich der Zertifikatsbeantragungsfluss ändert. Die zuvor im LocalStorage des Browsers gehaltenen Antragsdaten inklusive des privaten Schlüssels müssen nun am Ende des Prozesses als passwortgeschützte Antragsdatei auf dem Gerät der/des Beantragenden abgespeichert werden.

Sobald das Nutzerzertifikat dann ausgestellt ist, kann dieses über die Antragsseiten unter Verwendung der lokal bei der/dem Beantragenden gespeicherten Antragsdatei heruntergeladen und dabei mit dem privaten Schlüssel aus der Antragsdatei verbunden werden. Das Ergebnis ist dann wie bisher eine Zertifikatsdatei mit zugehörigem privaten Schlüssel und passenden CA-Zertifikaten der Zertifizierungskette im PKCS#12-Format mit der Dateiendung „.p12“.

Für ältere Nutzerzertifikatanträge, die noch im LocalStorage des Browsers gespeichert sind, gibt es Kompatibilitätsmechanismen, so dass diese auch weiterhin verwendet werden können.

(Reimer Karlsen-Masur, 11.03.2020)

Neue Antragsseiten für Nutzerzertifikate, die Zweite

Nachdem Anfang September 2019 auf Grund von technischen Änderungen in den Browsern relativ kurzfristig neue Antragsseiten für die Beantragung von Nutzerzertifikaten in Betrieb genommen wurden, steht demnächst eine weitere Neuerung in diesem Bereich an.

Durch den Wegfall der Unterstützung des <KEYGEN>-Tags zur lokalen Erzeugung von privaten Schlüsseln direkt im Browser wurde im September letzten Jahres der Umstieg auf Antragsseiten mit JavaScript WebCrypto-Technologie unter Nutzung von (Offline-)Website-Daten (sog. LocalStorage), welche ein Teil der Browser-Chronik sind, zur Speicherung der Antragsdaten (inkl. privaten Schlüssel) während des andauernden Zertfifizierungsvorgangs vollzogen.

Die Erfahrung zeigt nun, dass der LocalStorage dabei oft nicht langlebig genug ist, da dieser viel zu häufig durch Browser-Einstellungen oder bestimmte Browser-Updates, die die Browser-Chronik (regelmäßig automatisch) löschen, verloren geht und damit auch die Antragsdaten und insbesondere die darin lokal abgelegten privaten Schüssel zu den ausstehenden Zertifikatanträgen. Das führte dann in etlichen Fällen dazu, dass ausgestellte Nutzerzertifikate nicht mehr mit deren zugehörigen privaten Schlüsseln zusammen geführt und zur weiteren Nutzung abgespeichert werden konnten.

Die zukünftige Version des neuen Antragsformulars wird nun im Laufe des Frühjahrs ohne die Verwendung des flüchtigen LocalStorage erscheinen, um diese Schwierigkeiten zu umgehen. Daher wird sich der Beantragungsfluss wieder ändern. Antragsteller von Nutzerzertifikaten müssen in der künftigen Version ihre Antragsdaten (inkl. lokal im Browser erzeugten privaten Schlüssel) als Datei-Download aus dem Browser herunterladen und zwischenspeichern und dann wieder in den Browser herein laden, um schlussendlich das fertige Zertifikat abzuholen und zusammen mit dem privaten Schlüssel als PKCS#12-Datei (.p12) abspeichern zu können.

Aber irgendetwas ist ja immer 🙂

(rkm, 27.01.2020)

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. Beenden Sie die ggf. 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 2, erkennbar an der Property namens caName mit dem Wert dfn-ca-global-g2, 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“>Anzeigename – etwa Uni Musterstadt CA G2 o.ä.</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 neu 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. Zusammen ergeben sich also die zwei Abschnitte wie folgt:

    <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“>Anzeigename – etwa Uni Musterstadt CA G2 o.ä.</property>
    <property name=“raType“>PKCS12</property>
    </node>

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

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

(rkm, 13.04.2018, 03.05.2019)

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)

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)

Sicherung von eigenen Nutzerzertifikaten aus Mozilla/Firefox

Die Zertifikateverwaltung von Mozilla/Firefox erlaubt die einfache Sicherung (Export) der eigenen Benutzerzertifikate, für die ein privater Schlüssel im Browser vorliegt, im PKCS#12-Format in eine .p12-Datei. Hierbei werden sowohl das eigentliche Nutzerzertifikat, der zugehörige private Schlüssel und ggf. in der Zertifikateverwaltung bekannte CA-Zertifikate der ausstellenden Zertifizierungsstellen bis einschließlich zum Wurzel-CA-Zertifikat gesichert.

PKCS#12-Sicherungsdateien von Teilnehmerservice-Operator-Zertifikaten der DFN-PKI werden im weiteren Verlauf für die Einrichtung der Java RA-Oberfläche benötigt und sind nebenbei auch als Backup der eigenen Benutzerzertifikate in Dateiform ganz nützlich.

Sicherung des eigenen Nutzerzertifikats in eine PKCS#12-Datei

Die Zertifikateverwaltung findet sich im Firefox-Browser unter dem Menüpunkt Bearbeiten->Einstellungen->Erweitert->Zertifikate->Zertifikate anzeigen.

Unter dem Karteireiter „Ihre Zertifikate“ werden die eigenen Nutzerzertifikate aufgelistet, für die auch die jeweiligen privaten Schlüssel im Browser vorhanden sind.

Zum Sichern des eigenen Nutzerzertifikats wird das betreffende Zertifikat markiert und dann mit Hilfe eines Assistenten, der durch einen Klick auf „Sichern …“ gestartet wird, in eine PKCS#12-Datei geschrieben. Hierbei wird vom Assistenten ein Passwort abgefragt, mit dem der private Schlüssel in der PKCS#12-Datei gesichert wird. Dieses Passwort sollte also den üblichen Qualitätsstandards für Passwörter von privaten Schlüsseln genügen und auch nicht vergessen, verloren, weitergegeben oder offen gelegt werden.

Aber Obacht, es gibt dabei zwei kleine aber wichtige Details zu beachten:

Für Nutzerzertifikate der neuen DFN-PKI Generation 2 die Sicherung des Cross-CA-Zertifikats ausschließen [Update]

Zunächst ist festzustellen, dass hierfür bei der Sicherung von Zertifikaten der alten DFN-PKI Generation 1 nichts zu tun ist.

Bei der Sicherung von Zertifikaten der neuen DFN-PKI Generation 2 ist folgendes zu beachten:

Die Existenz des Cross-CA-Zertifikats, das die DFN-PKI Generation 2 mit der DFN-PKI Generation 1 verbindet und damit einen alternativen bis zum 09.07.2019 gültigen Zertifizierungspfad für Zertifikate der neuen DFN-PKI Generation 2 CAs zum Wurzel-CA-Zertifikat der alten DFN-PKI Generation 1 herstellt, kann in einer PKCS#12-Datei zu unerwarteten Effekten führen. Daher sollte nach Möglichkeit das Cross-CA-Zertifikat nicht mit in die PKCS#12-Datei gesichert werden.

Dafür muss das Cross-CA-Zertifikat, sofern dieses im Firefox-Browser überhaupt schon bekannt ist, vor der Sicherung des eigenen Zertifikats aus der Zertifikateverwaltung des Firefox-Browsers gelöscht werden:

Die Detailansicht des eigenen Nutzerzertifikats verrät leider nicht zuverlässig, ob der Firefox-Browser das Cross-CA-Zertifikat kennt und dieses möglicherweise bei der Sicherung mit in die PKCS#12-Datei speichert. Aus der Praxis sind Fälle bekannt, bei denen in der Detailansicht des eigenen Nutzerzertifikats die vollständige CA-Zertifikatkette mit dem Wurzelzertifikat der neuen DFN-PKI Generation 2 „T-TeleSec GlobalRoot Class 2“ endete, wo aber die gespeicherte PKCS#12-Datei letztlich den alternativen Zertifizierungspfad über das Cross-CA-Zertifikat enthielt.

Es wird also in der Zertifikateverwaltung vom Firefox-Browser unter dem Karteireiter „Zertifizierungsstellen“ unterhalb von „Deutsche Telekom AG“ das Zertifikat „T-TeleSec GlobalRoot Class 2“ mit der Seriennummer 11:9C:14:8C:C1:AC:0E:95 ausgestellt am 25.04.2016 gesucht, und falls vorhanden, markiert und durch einen Klick auf „Löschen oder Vertrauen entziehen …“ sowie im weiteren Verlauf mit einem Klick auf „OK“ gelöscht. Aufgepasst: Es gibt auch unterhalb von „T-Systems Enterprise Services GmbH“ ein Zertifikat mit dem Namen „T-TeleSec GlobalRoot Class 2“ ausgestellt am 01.10.2008. Dieses Zertifikat mit der Seriennummer 01 muss bleiben, denn es ist das Wurzel-CA-Zertifikat der neuen DFN-PKI Generation 2.

Vollständige CA-Zertifikatkette vs. unvollständige CA-Zertifikatkette

Ältere Firefox-Versionen haben bei der Sicherung von eigenen Nutzerzertifikaten bisher immer die vollständige CA-Zertifikatkette bis einschließlich des Wurzel-CA-Zertifikats mit in die PKCS#12-Datei geschrieben, sofern die betreffenden CA-Zertifikate in der Zertifikateverwaltung bekannt waren.

Dieses Verhalten hat sich in neueren Firefox-Versionen geändert!

In neueren Firefox-Versionen werden ausgehend vom eigenen Nutzerzertifikat nur die CA-Zertifikate der CA-Zertifikatkette mit in die PKCS#12-Datei gesichert, für die im Browser kein explizit gesetztes Vertrauen eingestellt ist, sowie zusätzlich nur noch das erste CA-Zertifikat für welches im Browser dann wieder explizites Vertrauen gesetzt ist.

Das kann im Einzelfall dazu führen, dass in der gesicherten PKCS#12-Datei eine unvollständige CA-Zertifikatkette vorliegt, d.h. dass ein Zwischen-CA-Zertifikat oder das Wurzel-CA-Zertifikat in der Datei fehlen. Das ist für die spätere Verwendung der PKCS#12-Datei in der Java RA-Oberfläche der DFN-PKI ungünstig, die eben die vollständige CA-Zertifikatkette in der PKCS#12-Datei voraussetzt.

Werden in den Firefox-Browser manuell CA-Zertifikate importiert, z.B. über spezielle Links oder die „Importieren…“-Funktion für Zertifizierungsstellen in der Zertifikateverwaltung, so bietet der entsprechende Import-Assistent an, dem gerade importierten CA-Zertifikat explizite Vertrauenseigenschaften („Website“, „Mail-Benutzer“ und/oder „Software-Hersteller“) zuzuweisen. Das explizite Setzen dieser Eigenschaften kann manchmal nützlich oder nötig sein, allerdings führt das im Falle der bereits öffentlich vertrauten DFN-PKI Global Hierarchie (neue und alte Generation) in neueren Firefox-Versionen dazu, dass bei der Sicherung von eben deren Nutzerzertifikaten keine vollständige CA-Zertifikatkette mehr mit in die PKCS#12-Datei geschrieben wird.

Wird z.B. durch eine Fehlermeldung der Java RA-Oberfläche festgestellt, dass in der konfigurierten PKCS#12-Datei, die durch eine Sicherung aus dem Firefox erstellt worden ist, keine vollständige CA-Zertifikatkette vorhanden ist, so kann das an diesem neuen Verhalten vom Firefox liegen.

Explizit gesetztes Vertrauen zurücknehmen, implizites Vertrauen aktivieren

Abhilfe schafft das Wegnehmen von explizit in die Zwischen-CA-Zertifikate der CA-Zertifikatkette gesetztem Vertrauen im Firefox und die erneute Sicherung des eigenen Nutzerzertifikats in eine PKCS#12-Datei, die dann die vollständige CA-Zertifikatkette enthält. Das nötige Vertrauen wird dann automatisch implizit vom vertrauten Wurzel-CA-Zertifikat in die gesamte CA-Zertifikatkette hinein vererbt:

Hierzu werden in der Zertifikateverwaltung vom Firefox-Browser unter dem Karteireiter „Zertifizierungsstellen“ die Vertrauenseinstellungen der beiden relevanten Zwischen-CA-Zertifikate kontrolliert (CA markieren und dann auf „Vertrauen bearbeiten…“ klicken) und ggf. geändert (alle evtl. gesetzten Häkchen vor „Website“, „Mail-Benutzer“ und „Software-Hersteller“ wegnehmen, mit Klick auf „OK“ speichern).

Für Nutzerzertifikate aus der neuen DFN-PKI Generation 2 sind in der Regel die beiden Zwischen-CA-Zertifikate

  • „DFN-Verein Certification Authority 2“, zu finden unterhalb von „T-Systems Enterprise Services GmbH“, und
  • „DFN-Verein Global Issuing CA“, zu finden unterhalb von „Verein zur Foerderung eines Deutschen Forschungsnetzes e. V.“

relevant.

Sollte das zu Nutzerzertifikat aus der DFN-PKI Generation 2 nicht von der „DFN-Verein Global Issuing CA“ ausgestellt worden sein, so kann in der Zertifikatansicht des Nutzerzertifikats unter dem Karteireiter „Details“ nachgeschaut werden, von welcher Zertifizierungsstelle das Nutzerzertifikat ausgestellt wurde. Zu finden ist das entsprechende Zwischen-CA-Zertifikat dann wiederum unter dem Karteireiter „Zertifizierungsstellen“ unterhalb von „Verein zur Foerderung eines Deutschen Forschungsnetzes e. V.“.

Für Nutzerzertifikate aus der alten DFN-PKI Generation 1 sind das Zwischen-CA-Zertifikat

  • „DFN-Verein PCA Global – G01“ mit der Seriennummer 50:4E:C6:F5:3D:11:B4:64 ausgestellt am 22.07.2014, zu finden unterhalb von „Deutsche Telekom AG“,

sowie das jeweilige Zwischen-CA-Zertifikat der teilnehmenden Einrichtung (zu finden unterhalb von „DFN-Verein“) relevant.

In der Zertifikatansicht des Nutzerzertifikats kann unter dem Karteireiter „Details“ nachgeschaut werden, von welcher Zwischen-CA das Nutzerzertifikat ausgestellt wurde. Zu finden ist das entsprechende Zwischen-CA-Zertifikat dann wiederum unter dem Karteireiter „Zertifizierungsstellen“ unterhalb von „DFN-Verein“.

Nun noch die Sicherung durchführen

Sind die Vertrauenseinstellungen für die Zwischen-CA-Zertifikate der CA-Zertifikatkette kontrolliert und ggf. entsprechend dieser Anleitung angepasst worden, so muss das eigene Nutzerzertifikat wie oben beschrieben erneut in eine PKCS#12-Datei gesichert werden, dieses Mal dann mit der vollständigen CA-Zertifikatkette (und ohne das Cross-CA-Zertifikat).

Oder doch lieber ein bisschen PKCS#12-Akrobatik mit openssl?

Steht das Kommandozeilenwerkzeug openssl zur Verfügung und liegt bereits eine „unpassende” PKCS#12-Datei mit dem gesicherten Nutzerzertifikat vor, so kann auch einfach nach PKCS#12-Akrobatik vorgegangen werden. Das erspart eine Menge Klickarbeit.

(rkm, 25.07.2017, aktualisiert (Info zum Cross-CA-Zertifikat) am 28.09.2017, aktualisiert am 09.02.2018)