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.
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
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
Ist ja auch Bugzilla. Das wird praktisch überall eher verachtet als geliebt. 
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:
openssl.cnf eintragen,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).
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.
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'
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.
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
Wie man das trotzdem mit univention-certificate hinbekommt, habe ich hier beschrieben:
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!
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 
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?
