SSL-Zertifikat und DNS-Alias

UCS - Univention Corporate Server
, , , ,
7

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:

  1. Den gewünschten Namen in der zum Client gehörenden openssl.cnf eintragen,
  2. einen neue Zertifikatsantrag (“certificate request”) für den Client erzeugen,
  3. 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.

6 Likes