Description Tim Petersen 2012-09-13 14:16:07 CEST

Aufgefallen an Ticket #2012091121000786:

Der Kunde hatte fälschlicherweise ein Zertifikat für "hostname" statt "fqdn" erzeugt und wollte dies revoken. Da "fqdn" hier dann logischerweise als Zertifikatsname nicht matched wurde "hostname" verwendet - das schlägt fehl.

Der Grund hierfür liegt im Code der Library "/usr/share/univention-ssl/make-certificates.sh":

Der Code grept den Parameter (hostname, im Code $1) in der index.txt um den Identifier zu bestimmen und findet beim Kunden 5 Einträge die matchen, da der hostname-String Substring weiterer FQDN's ist.

"
[...]
local NUM=`list_cert_names | grep "$1" | sed -e 's/^\([0-9A-Fa-f]*\).*/\1/1'`;
    if [ -z "$NUM" ]; then
        echo "no certificate for $1 registered" 1>&2;
        return 1;
    fi;
    openssl ca -config openssl.cnf -revoke ${CA}/certs/${NUM}.pem -passin pass:"$PASSWD"
[...]
"

Dieses simple "greppen" wird bei FQDN's natürlich nur in den seltensten Fällen irgendwo doppelt matchen (dazu müsste am Anfang oder am Ende etwas appended werden), aber unschön ist das dennoch.

Kurzes Beispiel:
Existieren Zertifkate für folgende beiden FQDN's in der index.txt:
- test.domain.local
- 1test.domain.local

so wird das revoken für "test.domain.local" fehlschlagen, da kein eindeutiger Match in der index.txt zustandekommt - in der Folge wird dem openssl-Befehl als Argument unescaped die Bash-Liste übergeben, also ein String mit Leerzeichen...das schlägt natürlich fehl.