Frisch aufgesetzter UCS 2.2 inkompatibel mit Lenny und Hardy

german
feedback

#1

Hallo,

ein langes Wochenende… wir haben jetzt erstmal SSL ausgeschaltet, aber das
ist kein Dauerzustand. Leider ist die FSF ein Politikum…

Problem:

$ ldapsearch -x # geht
$ ldapsearch -x -ZZ # geht auf etch, geht nicht auf lenny und hardy
$ openssl s_client -CApath /etc/ssl/certs -connect ucs:ldaps # geht auf allen

OpenLDAP in Debian (und Kubuntu) verwendet GnuTLS statt OpenSSL, aus
politischen Gründen. Das Zertifikat vom UCS wurde mit RSA-MD5 erzeugt,
wo Anfang 2009 die große Unsicherheit entdeckt wurde; die GnuTLS-Leute
sind direkt übers Ziel hinausgeschossen, indem sie Verbindungen zu diesen
Zertifikaten mit einer generischen „Zertifikat wird nicht vertraut“-Meldung ab-
lehnen.

Mehr Infos: bugs.debian.org/514578

Jetzt müssen wir also unsere komplette Zertifikatskette erneuern… seufz
Es wäre nett, wenn Sie im nächsten Update zumindest RSA-SHA1 verwenden.


#2

This seems to work for me. Note that supported digests are
md4, md5 (not to be used), mdc2 (not an “export” cipher),
sha1 (will be deprecated really soon), but sha2 isn’t :frowning:

--- /usr/share/univention-ssl/make-certificates.sh.orig	2009-05-10 16:39:55.000000000 +0200
+++ /usr/share/univention-ssl/make-certificates.sh	2009-05-10 16:44:12.000000000 +0200
@@ -34,6 +34,7 @@
 
 SSL_BASE=/etc/univention/ssl
 CA=ucsCA
+digest=sha1
 DEFAULT_DAYS=$(/usr/sbin/univention-baseconfig get ssl/default/days)
 if [ -z "$DEFAULT_DAYS" ]; then
 	DEFAULT_DAYS=730
@@ -93,7 +94,7 @@ x509_extensions     = ${CA}_ext
 crl_extensions     = crl_ext
 default_days        = $days
 default_crl_days    = 30
-default_md          = md5
+default_md          = $digest
 preserve            = no
 
 policy              = policy_match
@@ -277,7 +278,7 @@ init () {
 	move_cert ${CA}/newcerts/00.pem
 
 	# generate root ca request
-	openssl x509 -x509toreq -in ${CA}/CAcert.pem -signkey ${CA}/private/CAkey.pem -out ${CA}/CAreq.pem -passin pass:$PASSWD
+	openssl x509 "-$digest" -x509toreq -in ${CA}/CAcert.pem -signkey ${CA}/private/CAkey.pem -out ${CA}/CAreq.pem -passin pass:$PASSWD
 
 	find ${CA} -type f | xargs chmod 600
 	find ${CA} -type d | xargs chmod 700
@@ -285,7 +286,7 @@ init () {
 	chmod 755 ${CA}
 	chmod 644 ${CA}/CAcert.pem
 	#generate empty crl at installation time	
-	openssl ca -config openssl.cnf -gencrl -out ${CA}/crl/crl.pem -passin pass:"$PASSWD"
+	openssl ca -md "$digest" -config openssl.cnf -gencrl -out ${CA}/crl/crl.pem -passin pass:"$PASSWD"
 	openssl crl -in ${CA}/crl/crl.pem -out /var/www/${CA}.crl -inform pem -outform der
 
 	cd $OPWD
@@ -335,7 +336,7 @@ renew_cert () {
 	revoke_cert $1
 	
 	# sign the request
-	openssl ca -batch -config openssl.cnf -days $days -in "$1/req.pem" -out "$1/cert.pem" -passin pass:"$PASSWD"
+	openssl ca -md "$digest" -batch -config openssl.cnf -days $days -in "$1/req.pem" -out "$1/cert.pem" -passin pass:"$PASSWD"
 	
 	# move the new certificate to its place
 	move_cert ${CA}/newcerts/*;
@@ -358,8 +359,8 @@ revoke_cert () {
 		echo "no certificate for $1 registered" 1>&2;
 		return 1;
 	fi;
-	openssl ca -config openssl.cnf -revoke ${CA}/certs/${NUM}.pem -passin pass:"$PASSWD"
-	openssl ca -config openssl.cnf -gencrl -out ${CA}/crl/crl.pem -passin pass:"$PASSWD"
+	openssl ca -md "$digest" -config openssl.cnf -revoke ${CA}/certs/${NUM}.pem -passin pass:"$PASSWD"
+	openssl ca -md "$digest" -config openssl.cnf -gencrl -out ${CA}/crl/crl.pem -passin pass:"$PASSWD"
 	openssl crl -in ${CA}/crl/crl.pem -out /var/www/${CA}.crl -inform pem -outform der
 
 	cd "$OPWD";
@@ -390,7 +391,7 @@ gencert () {
 	yes '' | openssl req -config "$name/openssl.cnf" -new -key "$name/private.key" -out "$name/req.pem"
 
 	# sign the key
-	openssl ca -batch -config openssl.cnf -days $days -in "$name/req.pem" -out "$name/cert.pem" -passin pass:"$PASSWD"
+	openssl ca -md "$digest" -batch -config openssl.cnf -days $days -in "$name/req.pem" -out "$name/cert.pem" -passin pass:"$PASSWD"
 
 	# move the new certificate to its place
 	move_cert ${CA}/newcerts/*;

#3

Hallo,

dieses Problem ist uns bekannt und es besteht bereits ein Eintrag in unserem Bug-Tracking-System. Unsere Entwicklung wird sich dem Problem annehmen, um im Zuge der Weiterentwicklung von Univention Corporate Server eine Lösung zu implementieren.

Wir werden dieses Verfahren mit der Veröffentlichung der nächsten UCS Installations-DVD umstellen.

Als Workaround könnten Sie die Umstellung der Zertifikatstruktur manuell vornehmen. Wie Sie dazu vorgehen können ist im letzten Beitrag des folgenden Foren Artikels beschrieben: [url]SSL Schlüssel aktualisieren]

Mit freundlichen Grüßen
Murat Odabas


#4

Danke, aber es handelt sich um ein völlig anderes Problem, welches mit dem
von mir oben angegebenen Patch erledigt ist:

Die Zertifikate, die die ucsCA erzeugt, werden mit MD5 statt mit SHA1 sig-
niert, welches aktuelle Versionen von GnuTLS sich weigern als gültig an-
zuerkennen, weil für solchartige Zertifikatssignaturen Exploits bekanntge-
worden sind.

Das von Ihnen verlinkte Topic behandelt hingegen den infamous Debian
entropy bug.


#5

Hallo,

wir werden in den nächsten Tagen aktualisierte Installations-DVDs für UCS 2.2-0 veröffentlichen. Mit den aktualisierten DVDs wird unter anderem auch das Problem mit der RSA-MD5 Signierung der Zertifikate behoben.

Mit freundlichen Grüßen
Murat Odabas


#6

Hallo,

wie bereits angekündigt wurden die Installations-DVDs für UCS 2.2-0 mittlerweile veröffentlicht. Nähere Angaben zum Download und weitere Informationen zu den Installations-DVDs finden Sie im folgenden Forum Artikel:
[url]Aktualisierte Installations-Images für UCS 2.2]

Mit freundlichen Grüßen
Murat Odabas