LDAPS Zertifikat erneuern


#1

Hallo,

Leider habe ich ein abgelaufenes LDAPS-Zertifikat und finde keine Anleitung wie ich es erneuern kann.

Das SSL-Zertifikat ist gültig, überprüft mit https://ssl-trust.com/SSL-Zertifikate/check . Der Server ist fps.info.tm

In der KnowlageBase finde ich nur Anleitungen das Root-Zertifikat zu erneuern: Renewing the SSL certificates

Aber das ist gültig:
univention-certificate check -name fps.info.tm
Certificate “fps.info.tm” with serial number 02 is valid

Für verschiedene Dienste gibt es dort auch eine Anleitung wohin dies zu kopieren ist, nur leider nicht für LDAP.

Übersehe ich da was oder kann mir sonst jemand helfen?
Mit freundlichem Gruß
Holger Jessen-Thiesen


#2

Hallo Holger

Der Test auf ssl-trust.com überprüft nur das Zertifikat das Webservers, welches ein Let’s Encrypt Zertifikat benutzt. Für LDAP benutzt UCS eigentlich immer Zertifikat der internen CA.

Du kannst dir entweder mit openssl das Zertifikat an Port 7636 und 636 (mit Samba 4) anzeigen lassen und es danach manuell prüfen.

# Zertifikate anzeigen
openssl s_client -connect <ldap server>:7636 -showcerts 

# Danach output der einzelnen BEGIN/END CERTIFICATE blöcke in Textdateien kopieen und
# mit Openssl decodieren
openssl x509 -in <servercert.pem> -noout -text
openssl x509 -in <cacert.pem> -noout -text

Damit kannst du sehen, welches genau abgelaufen ist. Meistens erstellt UCS ein Zertifikat, welches so lange gültig wie die root CA selber ist (und was weniger optimal) teils länger, als das CA Zertifikat selber.

Alternativ kann ich auch check_ssl_cert von Matteo Corti empfehlen, aktuelle Versionen unterstützen LDAP+StartTLS (was OpenSSL 1.1.1 voraussetzt, leider nicht in UCS 4.4), aber LDAPS kannst du bis zum nächsten Release über einen Kniff wie folgt testen, z.B.:

./check_ssl_cert --host <myucsserver> --port 636 \
 --protocol pop3s --rootcert-file /etc/univention/ssl/ucsCA/CAcert.pem --verbose

Die “richtige” Option für “–protocol ldaps” könnte demnächst eingeführt werden, es gibt einen offenen pull request dazu, es ist nur ein kosmetisches Problem.


#3

Danke, es lag an dem stunnel.

Nikö Stöckigt hatte empfohlen:
Ich empfehle hier den Dienst mal neu zu starten

root@ucs:~# systemctl restart stunnel4.service

Danach funktionierte es wieder.