SSL-Zertifikat und DNS-Alias

Wenn bei UCS 4.2einen neuen Rechner vom Typ IP-Managed-Client anlege, wird ja automatisch ein SSL-Zertifikat erzeugt und unter /etc/univention/ssl abgelegt.

Dabei wird leider nicht die erweitere Einstellung DNS-Alias berücksichtigt.
Wäre praktisch, wenn das erzeugte SSL-Zertifikat auch gleich für den Alias gelten würde.

1 Like

Moin,

eine sinnvolle Idee. Wenn Sie solche Erweiterungswünsche haben, so sollten Sie die als Ticket in der Forge erstellen. Dort ist der richtige Platz dafür.

Gruß,
mosu

1 Like

Ja gerne. Beim Bugzilla ist die Einstiegshürde allerdings höher, von daher sind Feature-Wünsche auch über das Feedback-Formular möglich. Aber auch hier im Forum ist sowas nicht fehl am Platz. Vor allem können sich so auch einfach andere User melden, die den gleichen Wunsch haben.

BTW: Zum konkreten Anliegen hat Kollege @stoeckigt schon was vorbereitet: https://forge.univention.org/bugzilla/show_bug.cgi?id=44639

2 Likes

Ist ja auch Bugzilla. Das wird praktisch überall eher verachtet als geliebt. :frowning:

Das Feedback-Formular kannte ich auch noch nicht. Gute Sache.

Hallo zusammen,

vor diesen Problem stehe ich auch gerade.
Mir würde es im Moment reichen, wenn ich wüsste wie ich ein solches Zertifikat mit Hand erzeuge.
Wenn man nach den SDB Artikel vorgeht kann man leider keine alternativen Namen angeben, oderr doch?

Thomas

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

Hallo Herr Bunkus,

bin leider erst gestern zum Testen gekommen.
Die Anleitung funktioniert super. Ich habe nach IP.1:x.x.x.x angefügt. Damit funktioniert die Zertifikatprüfung auch beim Aufruf über die IP.

Gruß Thomas

1 Like

Wie man das trotzdem mit univention-certificate hinbekommt, habe ich hier beschrieben:

Zertifikat erzeugen

Also hanging on the alias problem:

openssl req -in /etc/univention/ssl/xxx-nas-two.xxx.com/req.pem -noout -text  | grep -A1 'X509v3 Subject Alternative Name'
            X509v3 Subject Alternative Name: 
                DNS:xxx-nas-two.xxx.com, DNS:xxx-nas-two, DNS:doku, DNS:doku.xxx.com, DNS:doc, DNS:doc.xxx.com
univention-certificate renew -name xxx-nas-two.xxx.com -days 7300
Renew certificate: xxx-nas-two.xxx.com
Using configuration from /etc/univention/ssl/openssl.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'DE'
stateOrProvinceName   :PRINTABLE:'DE'
localityName          :PRINTABLE:'DE'
organizationName      :PRINTABLE:'xxx'
organizationalUnitName:PRINTABLE:'Univention Corporate Server'
commonName            :PRINTABLE:'xxx-nas-two.xxx.com'
emailAddress          :IA5STRING:'ssl@xxx.com'
Certificate is to be certified until Feb 24 14:13:14 2039 GMT (7300 days)

Write out database with 1 new entries
Data Base Updated
openssl x509 -in /etc/univention/ssl/xxx-nas-two.xxx.com/cert.pem -noout -text  | grep -A1 'X509v3 Subject Alternative Name'
            X509v3 Subject Alternative Name: 
                DNS:xxx-nas-two.xxx.com, DNS:xxx-nas-two

Why alias is ignored? Same problem on new (instead of renew)

Thanks for help,
meg

Hello,
as far as I understand https://forge.univention.org/bugzilla/show_bug.cgi?id=44469 and http://errata.software-univention.de/ucs/4.3/297.html certificates should contain the CNAMEs as SAN now? I ask because I have the problem that both the initially created and a “renewed” certificate for a domain master do not contain any SAN entry (and I just checked, the CNAME is set properly).
In the corresponding .cnf the additional names are not mentioned.
Somebody with an idea what I did wrong?
Thanks!

1 Like

Anybody with a hint on this? Thanks!

Good Question… Not sure if its already implemented. Seems not.

@Moritz_Bunkus @Grandjean wie ist denn hier der aktuelle Stand?

Still the same with 4.4-8 errata1067 :frowning:

Same on 5.X :’( Which is bad, cause Renewing the SSL certificates will kill all the handwork :frowning:

Da dies leider seit 6 Jahren nicht funktioniert, lässt sich mit einem direkten Aufruf von
openssl x509 -req -in req.pem -out cert.pem -extfile openssl.cnf -extensions v3_req -signkey private.key
ein funktionierendes Zertifikat erzeugen.

Gibt es hier denn keine gangbare Lösung?

I just came across this problem again. Still no “official” solution?

Mastodon