Archiv des Autors: Reimer Karlsen-Masur

Nächste Phase der SHA-1-Abschaltung durch die Web-Browser ab Anfang 2017

Die nächste Phase der SHA-1-Abschaltung durch die Web-Browser steht ab Anfang 2017 ins Haus:

Konkret bedeutet das, dass nach dem jeweiligen Stichtag Microsoft-Systeme bzw. Mozilla/Firefox und Google/Chrome Web-Browser (jeweils aktuelle Software vorausgesetzt) mit einer Zertifikatsfehlermeldung vor TLS/SSL-Verbindungen zu Servern warnen, falls diese immer noch ein altes SHA-1-Server-Zertifikat oder SHA-1-Zwischen-CA-Zertifikat der öffentlich vertrauten DFN-PKI „Global“ präsentieren.

Das mit einer SHA-1-Selbstsignatur versehene Wurzel-CA-Zertifikat „Deutsche Telekom Root CA 2“ der ersten DFN-PKI Global Generation muss auch weiterhin nicht ausgetauscht werden (siehe Erläuterung in der FAQ). Das Wurzel-CA-Zertifikat „T-TeleSec GlobalRoot Class 2“ der neuen DFN-PKI Global Generation trägt bereits eine SHA-256-Selbstsignatur.

Weiteres zum Thema:

(rkm, 02.12.2016)

Ausweis-Scan bei „POSTIDENT durch Postfiliale“

In der DFN-PKI müssen Personen mit bestimmten Funktionsrollen regelmäßig persönlich identifiziert werden.

Die DFN-PKI nutzt seit einigen Jahren zusätzlich zur persönlichen Identifizierung in den DFN-Geschäftsstellen oder bei der DFN-CERT Services GmbH auch das „POSTIDENT Basic“-Verfahren der Deutschen Post AG. Das POSTIDENT-Verfahren ermöglicht eine Identifizierung am Ort und hilft dabei, aufwendige Dienstreisen zu vermeiden.

Ende 2015 hat die Post ihre POSTIDENT-Produkte umbenannt und den Umfang ergänzt. Das altbekannte „POSTIDENT Basic“ ist jetzt im „POSTIDENT durch Postfiliale“ aufgegangen. Zusätzlich zur bewährten Identifizierung scannt die Post nun bei einer Identifizierung in der Filiale auch noch den vorgelegten Ausweis. Dies ist der Post, die mit den POSTIDENT-Verfahren hauptsächlich eine Geldwäsche- und Signaturgesetz-konforme Methode zur Identifizierung von Personen anbietet, nach dem deutschen Geldwäschegesetz erlaubt.

Für die zu identifizierenden Personen und den DFN-Verein gibt es leider keine Möglichkeit mehr, POSTIDENT ohne diesen Ausweis-Scan durchführen zu lassen.

Der Ausweis-Scan liegt der Post nur in digitaler Form vor und wird dem Auftraggeber der Identifizierung erst auf gesonderte Vereinbarung zugänglich gemacht. Der DFN-Verein hat mit der Post keine Vereinbarung hierüber geschlossen und dementsprechend auch keinen Zugriff auf die Ausweis-Scans. Der DFN-Verein erhält wie gehabt ausschließlich das von der/dem Identifizierten in der Filiale unterschriebene Papierformular.

Nach Aussage der Post werden die Daten ausschließlich auf deutschen Servern gespeichert. Die Daten werden im Fall des DFN-Vereins von der Post nach der kürzest möglichen Speicherdauer von zwei Tagen gelöscht, ohne dass dieser Zugriff auf die digitalen Daten erhält.

Leider gibt es keine in der DFN-PKI nutzbare POSTIDENT-Variante in der Postfiliale/-Agentur ohne Ausweis-Scan. Wenn Sie nicht wünschen, dass Ihr Ausweis von der Post eingescannt wird, können wir Sie auf die selbstverständlich immer mögliche persönliche Identifizierung direkt in den Geschäftsstellen des DFN-Vereins (Berlin oder Stuttgart) bzw. in den Räumlichkeiten der DFN-CERT Services GmbH (Hamburg) verweisen. Alternativ bietet sich auch ein Treffen bei einer Veranstaltung mit DFN-Beteiligung (z.B. Betriebstagungen, Konferenzen etc.) an.

[POSTIDENT AGBs]

(rkm, 17.03.2016)

openssl: CSR für ein SSL-Server-Zertifikat mit mehreren Host-Namen erzeugen

Um ein SSL-Server-Zertifikat auf einem Server unter mehreren Host-Namen einsetzen zu können, muss das Zertifikat alle diese Host-Namen als sogenannte alternative Namen (SubjectAlternativeName, SAN) enthalten. Häufig davon betroffen sind Zertifikate für die Haupt-Web-Präsenz einer Einrichtung, die sowohl unter dem Host-Namen mit dem traditionellen www im Host-Namen als auch einfach unter der „blanken“ Haupt-Domain zu erreichen ist, z. B. unter www.example.org und example.org. Entsprechende Zertifikatanträge benötigen daher am besten einen Certificate Signing Request (CSR), der schon alle benötigten alternativen Namen enthält. Wird zum Erzeugen des CSRs das Kommandozeilenwerkzeug openssl genutzt, so sind diese Art von CSRs nur mit einer speziellen openssl-Konfigurationsdatei zu erzeugen.

Unten eine Beispielkonfigurationsdatei für openssl, deren Aufruf mit dem angegebenen Kommando sowohl das Schlüsselmaterial als auch den CSR mit dem angegebenen SubjectDN und den alternativen Namen erzeugt:

#
# Filename: openssl-www.example.org.conf
#
# Sample openssl configuration file to generate a key pair and a PKCS#10 CSR
# with included requested SubjectAlternativeNames (SANs)
#
# Sample openssl commandline command:
#
# openssl req -config ./openssl-www.example.org.conf -new -keyout www.example.org-key.pem -out www.example.org-csr.pem
#
# To remove the passphrase from the private key file use
#
# openssl rsa -in www.example.org-key.pem -out www.example.org-key.pem
#
# This eases automatic startup of the SSL/TLS-server when restarted or
# rebooted. Check for secure file access permissions on the private key file.
# Do not transfer the private key unencrypted over network connections.
#
# If generated directly on a secure filesystem with proper secure file access
# permissions on the server system add option -nodes to omit setting the
# secret key's passphrase protection - this eases automatic startup of the
# SSL/TLS-server when restarted or rebooted.
#
# To set an AES256 passphrase on the private key file use
#
# openssl rsa -aes256 -in www.example.org-key.pem -out www.example.org-key.pem
#

RANDFILE=/dev/urandom

[ req ]
default_bits       = 4096 # key length 4096 bits RSA
distinguished_name = req_distinguished_name
req_extensions     = req_cert_extensions
default_md         = sha256
dirstring_type     = nombstr
prompt             = no

[ req_distinguished_name ]

# requested SubjectDN
#
C   = DE
ST  = Bundesland
L   = Stadt
O   = Einrichtung
1.OU= Abteilung
2.OU= Team
CN  = www.example.org

[req_cert_extensions]

subjectAltName=@subject_alt_name

[ subject_alt_name ]

# requested SubjectAlternativeNames (SANs)
#
# SANs of type DNS
# change those FQDNs to real FQDNs in domains registered to your organisation
#
DNS.1=www.example.org
DNS.2=example.org
DNS.3=www.example.net
DNS.4=example.net

# SANs of type IP
# IP#s are normally not needed in certificates
# change those RFC 1918 IP#s to real IP#s assigned to your organisation
#
#IP.1=10.11.12.13
#IP.2=192.168.2.42

Ein äquivalenter Einzeiler für die Linux-Kommandozeile ist:

#> openssl req -newkey rsa:4096 -sha256 -keyout www.example.org-key.pem -out www.example.org-csr.pem -batch -subj "/C=DE/ST=Bundesland/L=Stadt/O=Einrichtung/OU=Abteilung/OU=Team/CN=www.example.org" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:www.example.org,DNS:example.org,DNS:www.example.net,DNS:example.net"))

Beispielangaben für den SubjectDN, die Host-Namen und ggf. IP-Adressen sind natürlich an die lokalen Gegebenheiten anzupassen.

(rkm, 01.12.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)