Moin,
nein, das Tool univention-certificate unterstützt momentan noch nicht die Angabe von alternativen Namen, die dann im Zertifikat als subjectAltName aufgenommen werden. Also ist Handarbeit angesagt.
Grob sieht der Prozess wie folgt aus:
- Den gewünschten Namen in der zum Client gehörenden
openssl.cnf eintragen,
- einen neue Zertifikatsantrag (“certificate request”) für den Client erzeugen,
- diesen Zertifikatsantrag unterschreiben lassen.
Im Detail:
Für jeden Client, genauer, für jedes mit univention-certificate erzeugte Zertifikat, gibt es auf dem DC Master ein gleichnamiges Unterverzeichnis in /etc/univention/ssl. Dort liegen mehrere Dateien: openssl.cnf, req.pem (der Zertifikatsantrag), cert.pem (das eigentliche Zertifikat) und private.key (der zum Zertifikat gehörende private Schlüssel).
Schritt 1: gewünschten Namen in Konfiguration eintragen
In der openssl.cnf stehen nun die Angaben für neu zu erstellende Zertifikatsanträge. Bearbeiten Sie die Datei mit einem beliebigen Texteditor und suchen Sie den Abschnitt [ v3_req ]. Dort finden Sie das Attribut subjectAltName. Es sollte standardmäßig auf zwei Namen gesetzt sein: den vollständigen Domänennamen sowie die Kurzform. Beispiel:
[ v3_req ]
…
subjectAltName = DNS:test-client.mbu-test.intranet, DNS:test-client
Hier können Sie nun die gewünschten Namen anhängen, mit Kommata getrennt, und jeweils mit DNS: als Präfix. Beispiel:
subjectAltName = DNS:test-client.mbu-test.intranet, DNS:test-client, DNS:muhkuh.mbu-test.intranet, DNS:muhkuh
Speichern Sie die Datei.
Schritt 2: neuen Zertifikatsantrag erzeugen
Das geht mit openssl, das sich die ganzen Daten aus der openssl.cnf holt, wenn man es richtig aufruft. Allerdings werden einige Umgebungsvariablen in openssl.cnf abgefragt, die wir manuell anhand von Angaben in der Univention Config Registry setzen müssen (das macht das Tool univention-certificate ansonsten schon für uns):
DEFAULT_CRL_DAYS="$(/usr/sbin/univention-config-registry get ssl/crl/validity)"
: ${DEFAULT_CRL_DAYS:=10}
DEFAULT_DAYS="$(/usr/sbin/univention-config-registry get ssl/default/days)"
: ${DEFAULT_DAYS:=1825}
DEFAULT_MD="$(/usr/sbin/univention-config-registry get ssl/default/hashfunction)"
: ${DEFAULT_MD:=sha256}
DEFAULT_BITS="$(/usr/sbin/univention-config-registry get ssl/default/bits)"
: ${DEFAULT_BITS:=2048}
export DEFAULT_MD DEFAULT_BITS DEFAULT_CRL_DAYS
cd /etc/univention/ssl/my-client
openssl req -new -config openssl.cnf -key private.key -out req.pem
Prüfen Sie, ob die Angaben im Antrag richtig sind:
openssl req -in req.pem -noout -text | grep -A 1 'X509v3 Subject Alternative Name'
Schritt 3: Antrag unterschreiben und damit Zertifikat erzeugen
Das geht dann glücklicherweise wieder mit dem Tool univention-certificate, und zwar mit der Unterfunktion renew:
univention-certificate renew -name test-client.mbu-test.intranet -days 7300
Anschließend ist das Zertifikat cert.pem erzeugt. Auch das können wir prüfen:
openssl x509 -in cert.pem -noout -text | grep -A 1 'X509v3 Subject Alternative Name'
Alle nachfolgenden Erneuerungen werden die modifizierten Namen enthalten, weil univention-certificate die Datei openssl.cnf und den Antrag req.pem nur beim Neuerstellen (univention-certificate new …) anlegt, bei einem renew allerdings nicht anfasst. Das gleiche gilt für den privaten Schlüssel, der während der ganzen Prozedur nicht verändert wurde.