SSL-Verschlüsselung mehrere Domains und 2048 Key-Länge

german

#1

Hallo,

ich möchte gerne die Sicherheit meiner SSL-Verbindungen erhöhen und gleichzeitig zusätzliche alternative Domain-Namen zum Zertifikat hinzufügen.

Zunächst zur Sicherheit:
Unter
sdb.univention.de/1000
wird erläutert, wie man seine SSL-Zertifikate erneuert. Das habe ich auch schon einmal erfolgreich durchgeführt. Was mich stört, ist dass das Zertifikat einen Privaten Schlüssel mit nur 1024 bit Länge verwendet. Ich würde gerne 2048 bit haben. Außerdem würde mich interessieren, ob jemand Erfahrung mit SHA-2 hat.

Wie man einen neuen privaten Schlüssel erstellt, weiß ich im Prinzip (akadia.com/services/ssh_test … icate.html). Ich würde aber ungern damit mein System zerschießen, deshalb interessiert mich, wie ich es “the Univention way” am besten mache.

Ein weiteres Thema ist, dass ich das Zertifikat für mehrere Domain-Namen ausstellen will. Das geht über
/etc/ssl/openssl.cnf (rtcamp.com/wordpress-nginx/tuto … ive-names/)

Kann ich über die Config auch die RSA-Schlüssellänge beeinflussen? Werden die dort getroffenen Einstellungen berücksichtigt, wenn ich über Web-Admin ein neues Root-Zertifikat mache?

Vielen Dank!

Grüße

mereh


Eigenes Zertifikat Apache
#2

Hallo,

theoretischer Lösungsansatz:
Das, was Sie beeinflussen wollen, steht hier in /etc/univention/ssl/openssl.cnf sowie für jeden Host in der openssl.cnf im entsprechenden Unterverzeichnis. Diese Konfigurationen werden durch das Skript /usr/share/univention-ssl/make-certificates.sh aus den UCR-Variablen und im Falle von z.B. “default_bits” hartkodiert erzeugt. Die UCRV “ssl/default/hashfunction” existiert, also kann man wohl davon ausgehen, dass schon mal jemand etwas anderes als SHA1 benutzt hat.
Renewing the complete SSL certificate chain beschreibt die komplette Neueinrichtung der Zertifikatskette. Einer der ersten Schritte ist ein re-install des Paketes “univention-ssl”. In dessen Postinst wird das u.a. make-certificates.sh -Skript gerufen und das Zertifikat vom Master erstellt.
Man könnte somit das Skript wie benötigt anpassen und in Anlehnung an den SDB-Artikel und dem Postinst von univention-ssl versuchen, eine Kette nach eigenem Gusto bauen.

Viele Grüße,
Dirk Ahrnke

EDIT: SDB-Link repariert


#3

Ich habe es ausprobiert. Leider ist das Erneuern der SSL-Kette schief gegangen, ich habe alles wie beschrieben gemacht, allerdings lässt sich slapd nicht mehr starten: es fehlen irgendwelche daten.

Zum Glück war es nur ein Testsystem, aber da geht gar nichts mehr, auch das webinterface ist tot.

[quote=“ahrnke”]Hallo,

theoretischer Lösungsansatz:
Das, was Sie beeinflussen wollen, steht hier in /etc/univention/ssl/openssl.cnf sowie für jeden Host in der openssl.cnf im entsprechenden Unterverzeichnis. Diese Konfigurationen werden durch das Skript /usr/share/univention-ssl/make-certificates.sh aus den UCR-Variablen und im Falle von z.B. “default_bits” hartkodiert erzeugt. Die UCRV “ssl/default/hashfunction” existiert, also kann man wohl davon ausgehen, dass schon mal jemand etwas anderes als SHA1 benutzt hat.
Renewing the complete SSL certificate chain beschreibt die komplette Neueinrichtung der Zertifikatskette. Einer der ersten Schritte ist ein re-install des Paketes “univention-ssl”. In dessen Postinst wird das u.a. make-certificates.sh -Skript gerufen und das Zertifikat vom Master erstellt.
Man könnte somit das Skript wie benötigt anpassen und in Anlehnung an den SDB-Artikel und dem Postinst von univention-ssl versuchen, eine Kette nach eigenem Gusto bauen.

Viele Grüße,
Dirk Ahrnke

EDIT: SDB-Link repariert[/quote]


#4

Hallo,

bislang war mein Post dazu noch kein Howto, aber wenn Sie Ihre Schritte aufschreiben und die Fehlermeldungen beim Start des slapd heraussuchen, hätten wir ggf. gemeinsam die Chance, etwas in der Art zu entwickeln.

Viele Grüße,
Dirk Ahrnke


#5

Hallo,

ich klink mich hier mal ein: ich seh gerade nicht so recht den Sinn einer Unterscheidung zwischen sdb.univention.de/1183
Vor allem steht im ersten Artikel ja noch was von udsCA was ja laut zweitem Artikel nur bei einem UCS < 2.0 richtig wäre.

mereh, vielleicht hilft dir ja der zweite SDB-Artikel? Den habe ich auf jeden Fall schonmal erfolgreich durchgearbeitet. Und wenn man da statt “univention-certificate renew” einfach “univention-certificate new” nimmt, werden auch komplett neue Host-Zertifikate erstellt und Änderungen in openssl.cnf berücksichtigt.

Und zum Thema mehrere Domain-Namen im Zertifikat (Subject Alternative Names) habe ich noch diese UCR-Variable gefunden:

ssl/host/extensions

Damit kann man sich wohl eigene Extensions für openssl.cnf bauen. Der Info-Text dazu verweist auf /usr/share/doc/univention-ssl/extensions-example.sh und das Beispiel dort deckt passenderweise auch Subject Alternative Names ab:

...
# alternative name
subjectAltName = DNS:$fqdn, DNS:$hostname
...

Da wird also schonmal der FQDN und der Hostname gesetzt. Das könnte man vermutlich beliebig erweitern, getestet habe ich das aber nicht.


#6

Ich habe jetzt eine Zwischenlösung, die funktioniert:

StartSSL-Zertifikat mit 4096bit Private Key erstellt und zusammen mit Zertifikat und Chain auf den Server kopiert.

Passwort aus Key entfernt
wiki.apache.org/httpd/RemoveSSLCertPassPhrase

Zertifikat in Apache eingebaut
sdb.univention.de/1191
plus
startssl.com/?app=21

wegen der Chain.

Läuft, allerdings sind Email und meine alternative Domain noch nicht in die Lösung integriert.


#7

Das ist einfach.

ucr search zarafa | grep ssl


#8

Im Moment habe ich leider ein anderes Problem, mein UMC login geht nicht mehr. Ich habe schon debugging betrieben.

Dieser Thread
sdb.univention.de/content/18/172 … tification

hat mir leider nicht geholfen, ich konnte das Problem aber eingrenzen.

kinit Administrator
Administrator@MEREH.DE’s Password:
kinit: krb5_get_init_creds: Client (Administrator@MEREH.DE) unknown

host -t SRV _kerberos._tcp.$domainnameCheck
Host _kerberos._tcp. not found: 3(NXDOMAIN)

/var/log/heimdal-kdc.log ist leer.

kadmin -l get Administrator@mereh.de: Principal does not exist

ps waux|grep bind
root 1357 0.0 0.0 164 4 ? Ss Sep21 0:00 runsv univention-bind-proxy
root 1359 0.0 0.0 164 4 ? Ss Sep21 0:00 runsv univention-bind-samba4
root 1361 0.0 0.0 164 4 ? Ss Sep21 0:00 runsv univention-bind
root 1445 0.0 1.5 536944 60356 ? Sl Sep21 0:08 /usr/sbin/named -c /etc/bind/named.conf.samba4 -f -d 0
root 6089 0.0 0.0 12200 844 pts/0 S+ 20:17 0:00 grep bind

ps waux|grep heimdal
root 6132 0.0 0.0 12196 848 pts/0 S+ 20:18 0:00 grep heimdal

/var/log/auth.log:
Sep 22 20:09:07 mailserver python2.6: pam_unix(univention-management-console:auth): check pass; user unknown
Sep 22 20:09:07 mailserver python2.6: pam_unix(univention-management-console:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
Sep 22 20:09:07 mailserver python2.6: pam_krb5(univention-management-console:auth): authentication failure; logname=Administrator uid=0 euid=0 tty= ruser= rhost=

System ist up to date, keine Installationsfehler. Lief ein Jahr problemlos.

Zu den letzten Änderungen am System gehörte das Ändern der SSL Zertifikate für den Apache, was ich über die entsprechenden UCS Config Registry-Einträge gemacht habe.

Der Server läuft ansonsten noch ohne Schwierigkeiten, ist aber als Mailserver im produktiven Betrieb. Deswegen wäre ich für Lösungsvorschläge sehr dankbar.

Gruß

mereh


#9

Haben Sie wirklich geprüft ob der LDAP-Server läuft?


#10

Folgendes output bekomme ich:

root@mailserver:/home/mr# eval $(ucr shell)
root@mailserver:/home/mr# ldapsearch -x -ZZZ -s base -h $hostname.$domainname

extended LDIF

LDAPv3

base <dc=mereh,dc=de> (default) with scope baseObject

filter: (objectclass=*)

requesting: ALL

search result

search: 3
result: 1 Operations error
text: 00002020: Operation unavailable without authentication

numResponses: 1


#11

Hallo,

univention-ldapsearch

wäre besser. Der SDB-Artikel bräuchte Überarbeitung.

Meldungen des LDAP-Servers findet man in /var/log/debug und /var/log/messages.

Ich habe eigentlich auch nur auf den LDAP wegen “user unknown” getippt. Ich erhalte dieselbe Meldung beim kinit wenn ich den slapd gezielt abschiesse.

Viele Grüße,
Dirk Ahrnke


#12

Ldap scheint zu laufen. Habe auch schon versucht slapd neuzustarten, geht einwandfrei.

univention-ldapsearch:

(…ganz viel text…)

search result

search: 3
result: 0 Success

numResponses: 368

numEntries: 367


#13

Noch ein paar Infos: Kerberos scheint den Benutzer Administrator nicht zu kennen:

[code]root@mailserver:/# kinit Administrator
Administrator@MEREH.DE’s Password:
kinit: krb5_get_init_creds: Client (Administrator@MEREH.DE) unknown

root@mailserver:/# ucr search --brief kerberos
kerberos/adminserver: mailserver.mereh.de
kerberos/adminusers:
kerberos/afscell:
kerberos/allow/weak/crypto:
kerberos/autostart: no
kerberos/defaults/debug:
kerberos/defaults/dns_lookup_kdc:
kerberos/defaults/dns_lookup_realm:
kerberos/defaults/enctypes/permitted:
kerberos/defaults/enctypes/tgs:
kerberos/defaults/enctypes/tkt:
kerberos/defaults/forwardable:
kerberos/defaults/kdc_timesync:
kerberos/defaults/proxiable:
kerberos/domain_realms:
kerberos/kadmin/default/keys:
kerberos/kdc: 127.0.0.1
kerberos/kpasswdserver: 127.0.0.1
kerberos/password/quality/check: yes
kerberos/realm: MEREH.DE

root@mailserver:/var/log/univention# ldapsearch -Y GSSAPI
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text) (open(/tmp/krb5cc_0): No such file or directory)

Bevor der Probleme auftauchten, habe ich
apache2/ssl/certificate
apache2/ssl/certificatechain
apache2/ssl/key[/code]

Angepasst um ein Zertifikat von StartSSL einzubauen. Könnte das die Ursache sein dafür, dass jetzt der Admin-Login an der UMC nicht mehr geht?

Danke

Gruß

Mereh


#14

Hallo,

die Einbindung des Zertifikates für den Apache allein mit den 3 erwähnten UCR-Variablen ist sehr wahrscheinlich nicht die Ursache. Das betreibe ich auf mehreren unabhängigen Systemen ohne Probleme. Sogar mit einem StartSSL Class2-Zertifikat.

Bei der kerberos UCR-Variablen seheh ich auf den ersten Blick auch nichts.

Interessant wäre ggf. mal noch zu sehen, ob denn der Administrator mit ldapsearch gefunden wird.:

univention-ldapsearch uid=Administrator

Viele Grüße,
Dirk Ahrnke


#15

Hallo,

vielen Dank für die Rückmeldung. Da kommt folgendes raus:

[code]root@mailserver:/home/mr# univention-ldapsearch uid=Administrator

extended LDIF

LDAPv3

base <dc=mereh,dc=de> (default) with scope subtree

filter: uid=Administrator

requesting: ALL

search result

search: 3
result: 0 Success

numResponses: 1[/code]


#16

Hallo mereh,

ich will Dirk Ahrnke nicht vorgreifen, aber das sieht nicht gesund aus :confused:
Da sollte eigentlich das komplette LDAP-Objekt des Administrators zurückgegeben werden. Bei dir sieht das so aus, als sei der Administrator nicht mehr im LDAP vorhanden. Du hast deinen Administrator nicht zufällig mal umbenannt?

Du kannst mal noch folgendes probieren:

univention-ldapsearch cn='Domain Admins' uniqueMember -LLL

Das wird dir alle Mitglieder der Gruppe ‘Domain Admins’ ausgeben.

Ist dein Host ‘mailserver’ auch gleichzeitig der DC Master? Wenn nicht, lohnt es sich vermutlich die univention-ldapsearch Befehle auch auf dem DC Master nochmal auszuführen. Ist der Administrator dann immer noch nicht zu finden, würde ich auf dem DC Master mal die täglichen LDAP-Dumps unter /var/univention-backup/ durchsuchen und prüfen wann der Administrator dort verschwindet:

zgrep 'cn=Administrator' /var/univention-backup/ldap-backup_2014*

#17

Hallo CoffePad,

hoffentlich lässt sich das richten.

Folgendes kommt heraus bei den von Dir angegebenen Aufrufen:

univention-ldapsearch cn=‘Domain Admins’ uniqueMember -LLL
(nichts)

zgrep ‘cn=Administrator’ /var/univention-backup/ldap-backup_2014*
/var/univention-backup/ldap-backup_20141004.ldif.gz:dn: cn=Administrators,cn=groups,dc=mereh,dc=de
(jeweils für jeden Tag des Jahres)

ich glaube man müsste irgendwie anders filtern.

Der Befehl
zgrep ‘uid=Administrator’ /var/univention-backup/ldap-backup_2014*

zeigt, dass
dn: uid=Administrator,cn=users,dc=mereh,dc=de

zuletzt am 20.09. auftauchte, was in etwa dem Zeitpunkt entspricht seit dem ich keinen Zugriff mehr auf die UMC habe. Kann ich den Admin irgendwie neu anlegen oder aus dem Backup zurückholen bzw. einen anderen User zum Admin machen?


#18

Hallo mereh,

stimmt natürlich, das cn= in dem grep-Befehl war falsch von mir, es muss (wie du schon erkannt hast) uid=Administrator heißen. Andernfalls findet der grep-Befehl nur die Gruppe cn=Administrators.

Bei dir sieht es also so aus, dass der Administrator-Benutzer am 20.09. im Laufe des Tages irgendwie gelöscht wurde (die LDAP-Dumps werden afaik immer um 0:00 Uhr gemacht). Das Beste wäre vermutlich den Benutzer per ldapmodify/ldapadd wieder einzuspielen. Ein Anlegen z.B. per udm wäre vermutlich auch möglich, aber da man da dann alle IDs etc. sowieso im Backup nachschauen müsste, kann man sich den Umweg wahrscheinlich sparen.

Ich habe das folgende bislang nur mit einem Testuser gemacht und nie mit dem Administrator, kann also keine Garantie geben, dass es funktioniert:

[ol]
[li]Suche im LDAP-Dump vom 20.09. das LDAP-Objekt des Administrator-Benutzers (z.B. mit zless), es sollte mit dn: uid=Administrator,cn=users,… anfangen. Eine Leerzeile schließt ein Objekt ab.[/li]
[li]Kopiere das komplette Objekt in eine eigene Datei (z.B. Administrator.ldif)[/li]
[li]Einige Zeilen musst du entfernen, da das interner Kram von slapd ist und beim Importieren zu “Constraint violation”-Fehlern führen würde:
entryUUID:
entryCSN:
createTimestamp:
creatorsName:
modifiersName:
modifyTimestamp:
structuralObjectClass:[/li]
[li]Anschließend kannst du das .ldif-File mit folgendem Befehl auf dem DC Master wieder einspielen:

ldapadd -x -D "cn=admin,$(ucr get ldap/base)" -w $(cat /etc/ldap.secret) -f Administrator.ldif

[li]Damit sollte zumindest der Benutzer wieder auftauchen. Teste die univention-ldapsearch-Befehle von oben nochmal.[/li]
[li]Vermutlich fehlen dir dann noch die Gruppenmitgliedschaften und damit auch die entsprechenden Berechtigungen. Dein ‘Administrator’ sollte mindestens Mitglied der Gruppen Domain Users, Domain Admins und DC Backup Hosts sein:

udm groups/group modify --dn "cn=Domain Admins,cn=groups,$(ucr get ldap/base)" --append "users=uid=Administrator,cn=users,$(ucr get ldap/base)"

udm groups/group modify --dn "cn=Domain Users,cn=groups,$(ucr get ldap/base)" --append "users=uid=Administrator,cn=users,$(ucr get ldap/base)"

udm groups/group modify --dn "cn=DC Backup Hosts,cn=groups,$(ucr get ldap/base)" --append "users=uid=Administrator,cn=users,$(ucr get ldap/base)"

Ist der jeweilige udm-Befehl erfolgreich, wird das mit einem Object modified: … quittiert. Überprüfen kannst du das dann z.B. mit udm groups/group list --filter “cn=Domain Admins”[/li][/ol]

Wenn das alles so geklappt hat, wie ich mir das vorstelle hast du nun wieder einen funktionierenden Administrator.


#19

Hallo CoffeePad,

ich wollte mich nochmal für Deinen maßgeschneiderten Lösungsansatz bedanken. Es hat eine ganze Weile gedauert, bis ich mich da ran getraut habe. Vorher habe ich auf eine Testsystem die ganze Prozedur durchgespielt. Dort hat es perfekt funktioniert, wie beschrieben (ich habe erfolgreich einen zweiten ‘Administrator1’ hinzugefügt, der dann auch auf die UMC kam und die richtigen Rechte hatte). Auf dem live-System lief es leider nicht glatt. Der Import hat funktioniert, der Administrator ist angelegt, nur mit den Gruppenmitgliedschaften gibt es Probleme. Beim Ausführen von

udm groups/group modify --dn "cn=Domain Admins,cn=groups,$(ucr get ldap/base)" --append "users=uid=Administrator,cn=users,$(ucr get ldap/base)"

erhalte ich die Meldung:

E: object not found

Interessant ist aber, dass ich mich jetzt wieder als der Administrator an der UMC anmelden kann, nur erhalte ich dort die Meldung:

‘Für den angemeldeten Benutzer Administrator ist kein Modul verfügbar.’

was vermutlich auf die fehlenden Berechtigungen zurück zu führen ist. Frage ist nur was bei group modify falsch läuft. Immerhin war es bis jetzt ein Teilerfolg, ich hoffe das mit den Berechtigungen ist irgendwie zu schaffen… ?

Vielen Dank im Voraus!!



#20

Ergänzung:

Ich habe die Gruppe “Domain Admins” ebenfalls aus dem Backup wiederhergestellt und voila: Der hat Administrator hat wieder alle seine Funktionen in der UMC-Console!

Jetzt hoffe ich dass das Problem gelöst ist. Mysteriös ist das ja schon alles.

Vielen Dank nochmal!