Archiv für den Monat: November 2015

Alternative Import-Möglichkeit für eigene Nutzerzertifikate in Firefox und Internet Explorer

[Update 13.05.2020, Jürgen Brauckmann: Ab Firefox Release 76 steht diese alternative Möglichkeit nicht mehr zur Verfügung, da der Import von Zertifikaten per MIME-Typ entfernt wurde.]

tl;dr Falls der direkte Import des eigenen Nutzerzertifikats über den speziellen Link von den DFN-PKI-Web-Servern in den Zertifikatspeicher des Firefox‘ oder Internet Explorers nicht möglich ist, gibt es für den Import eine weitere Alternative mittels Web-Formular mit lokalem JavaScript bzw. ActiveX, Zertifikatsdatei im PEM-Format und Copy&Paste.

Bei der Beantragung von Nutzerzertifikaten aus der DFN-PKI wird der Browser in der Regel dazu benutzt, sowohl das kryptografische Schlüsselpaar auf dem eigenen Rechner als auch den eigentlichen Zertifikatantrag in den DFN-PKI-Systemen zu erzeugen. Hierbei wird das Schlüsselpaar bestehend aus privatem und öffentlichem Schlüssel durch den Browser auf dem Rechner der Beantragenden erzeugt. Der private Schlüssel verbleibt auf dem Rechner der Beantragenden. Der öffentliche Schlüssel wird zusammen mit den übrigen Antragsdaten auf das DFN-PKI-System hochgeladen, um schließlich das Nutzerzertifikat zu beantragen.

Bevor das Nutzerzertifikat nun im Browser zur Client-Authentisierung genutzt oder aus dem Browser, z. B. für eine weitere Nutzung in einem E-Mail-Programm, heraus exportiert werden kann, müssen auf dem Rechner der Beantragenden der private Schlüssel und das fertig ausgestellte Nutzerzertifikat wieder zusammengeführt werden. Der Weg des Zertifikats zum zugehörigen privaten Schlüssel im Zertifikatspeicher des Browsers ist technisch entweder an den speziellen MIME-Typ application/x-x509-user-cert (Firefox) oder den Einsatz bestimmter ActiveX-Funktionen für das Zertifikat-Enrollment (Internet Explorer) gebunden. Und es kann mitnichten einfach eine vorhandene Datei mit dem Zertifikat in den Browser importiert werden, da hierbei entweder die nötige spezielle MIME-Typ-Information oder die ActiveX-Funktionen fehlen, die im Browser die technischen Mechanismen zur Zusammenführung von privatem Schlüssel und Zertifikat anstoßen.

Stattdessen enthalten die Zertifikatauslieferungs-E-Mails der DFN-PKI für Nutzerzertifikate einen speziellen Link zum direkten Import des Nutzerzertifikats vom DFN-PKI-Web-Server in den Browser bei dem der Web-Server eben diese nötige MIME-Typ-Information im HTTP-Header zusammen mit dem Nutzerzertifikat mitliefert bzw. die ausgelieferte Web-Seite die ActiveX-Funktionen für das Zertifikat-Enrollment nutzt und der Importvorgang dadurch erfolgreich angestoßen und durchgeführt werden kann.

Manchmal ist es allerdings keine Option, das eigene Nutzerzertifikat direkt vom DFN-PKI-Web-Server herunterzuladen. Falls dieses Nutzerzertifikat in Form einer PEM-formatierten Datei vorliegt, kann es in diesen Fällen hilfreich sein, das Zertifikat per Copy&Paste über ein Web-Formular in den Browser zu importieren. Hierbei setzt das Web-Formular die benötigte MIME-Typ-Information bzw. nutzt die ActiveX-Funktionen für das Zertifikat-Enrollment. Diese Alternative funktioniert nur, sofern der zum Nutzerzertifikat zugehörige private Schlüssel schon im Zertifikatspeicher des Browsers vorhanden ist und auch nur mit dem Firefox und dem Internet Explorer. Unter Chrome funktioniert dieses Web-Formular nicht.

Ein Hinweis zur eingesetzten Technik im Web-Formular: Das in das Formularfeld kopierte Zertifikat wird ausschließlich durch den Einsatz von lokalem JavaScript bzw. ActiveX-Funktionen für das Zertifikat-Enrollment auf der Web-Seite in den lokalen Zertifikatspeicher des Browsers importiert. Zertifikate oder gar private Schlüssel werden bei diesem Vorgang nicht an DFN-PKI-Server oder gar Dritte übertragen.

(rkm, 26.11.2015)

VMware 5.5: CSRs ohne IP-Adressen und kurzen Host-Namen mit dem „SSL Certificate Automation Tool“ erzeugen

Das „SSL Certificate Automation Tool“ von VMware 5.5 unterstützt die VMware-Administration dabei, die für die VMware-Installation nötigen SSL-Zertifikate zu beantragen und zu installieren. Inbesondere erzeugt das Werkzeug die zur Zertifikatantragstellung nötigen Certificate Signing Requests (CSRs).

Allerdings akzeptieren die RA-Oberflächen und -Schnittstellen der DFN-PKI seit dem 1. November 2015 keine CSRs mehr, die interne Domain-Namen,  „kurze“ Host-Namen (also Host-Namen ohne den abschließenden Domain-Anteil) oder für den privaten Gebrauch reservierte IP-Adressen beinhalten. Der Hintergrund hierfür ist eine Entscheidung des CA/Browser-Forums, über die hier schon im Beitrag Interne Domainnamen ausführlich berichtet wurde.

Da in VMware-Installationen aus verschiedenen Gründen auch gerne auf die für den privaten Gebrauch reservierten IP-Adressen (z. B. 10.x.y.z, siehe auch RFC 1918) zurückgegriffen wird und das „SSL Certificate Automation Tool“ außerdem sowohl diese IP-Adressen als auch die kurzen Host-Namen (VMware-Terminologie „short name“) mit in die erzeugten CSRs aufnimmt, kommt es bei der Zertifikatantragstellung bei der DFN-PKI zu Fehlermeldungen über im CSR enthaltene nicht erlaubte Namen. Zertifikatanträge mit derartigen CSRs werden schon im Vorfeld aussortiert und nicht angenommen.

Je nach lokaler Situation kann nun das zum „SSL Certificate Automation Tool“ gehörende Skript ./tools/generate-cdr.bat dahingehend angepasst werden, dass die erzeugten CSRs wieder in Zertifikatanträgen angenommen werden.

Im Skript generate-cdr.bat muss die Zeile 33 (Stand: Version 5.5)

echo subjectAltName = IP:%gen_cert_server_ip%, DNS:%gen_cert_server_short_name%, DNS:%gen_cert_server_fqdn% >> %csr_config_file_name%

folgendermaßen angepasst werden:

In jedem Fall muss der Teil DNS:%gen_cert_server_short_name%, entfernt werden, damit keine kurzen Host-Namen mehr in die erzeugten CSRs aufgenommen werden.

Falls die VMware-Server IP-Adressen aus den für den privaten Gebrauch reservierten IP-Adressbereichen benutzen, so muss ebenfalls der Teil IP:%gen_cert_server_ip%, aus der Zeile entfernt werden, damit diese IP-Adressen nicht mehr in die erzeugten CSRs aufgenommen werden.

In letzterem Fall sieht die geänderte Zeile 33 im Skript generate-cdr.bat dann wie folgt aus:

echo subjectAltName = DNS:%gen_cert_server_fqdn% >> %csr_config_file_name%

(rkm, 23.11.2015)

Endgültiges Ende von SHA-1 in der DFN-PKI Global

Seit Mitte 2014 ist SHA-2 der Standard-Algorithmus für Signaturen in Zertifikaten der DFN-PKI. Der inzwischen veraltete Algorithmus SHA-1 wird nur noch ausnahmsweise verwendet, insbesondere aus Kompatibilitätsgründen für älteren Geräte.

In Übereinstimmung mit den Regeln des CA/Browser-Forums ist ab 30.12.2015 die Verwendung von SHA-1 zur Signatur von Zertifikaten im Sicherheitsniveau Global in der DFN-PKI auch ausnahmsweise nicht mehr möglich.

Bitte beachten Sie auch, dass insbesondere Google Chrome die Warnmeldungen in der Adresszeile beim Auftreten eines SHA-1-signierten Zertifikats in der Zertifizierungskette eines Servers in letzter Zeit deutlich verschärft hat.

Wir raten dringend dazu, noch in Betrieb befindliche SHA-1-Serverzertifikate auszutauschen. Dabei muss auch die gesamte Zertifizierungskette auf dem betreffenden Server mit ausgetauscht werden.

Weitere Informationen: https://www.pki.dfn.de/faqpki/faqpki-sha2/

(jbr, 13.11.2015)