Schlagwort-Archive: openssl

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)

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)