Die Kommunikation zwischen den verschiedenen Rechnern einer UCS-Domäne erfolgt größtenteils TLS/SSL-verschlüsselt. Bei der TLS/SSL-Verschlüsselung werden ein Root-Zertifikat und für jeden Rechner ein Rechnerzertifikat benötigt. Das Root-Zertifikat hat nur einen bestimmten Gültigkeitszeitraum, ebenso wie die mit dem Root-Zertifikat erstellten Rechnerzertifikate. Ist dieser Zeitraum abgelaufen, funktionieren Dienste, die ihre Kommunikation mit TLS/SSL verschlüsseln (z.B. LDAP, UMC) nicht mehr. Es ist deshalb notwendig, die Gültigkeit der Zertifikate regelmäßig zu prüfen und ggf. neue Rechnerzertifikate zu erstellen.
Die folgende Befehle müssen auf einem UCS Master durchgeführt werden.
Die Überprüfung, wie lange ein Rechnerzertifikat noch gültig ist, kann mit univention-certificate erfolgen:
univention-certificate dump -name ucs01.intra.example.org
[...]
Validity
Not Before: Jun 19 10:40:13 2016 GMT
Not After : Jun 18 10:40:14 2018 GMT
[...]
Hierbei ist immer der FQDN des Rechnernamens (Rechnername + Domain) anzugeben. Eine Liste aller verfügbaren Zertifikate erhält man mit
univention-certificate list
Normalerweise haben die Zertifikate aller Rechner einer UCS-Domäne das gleiche Gültigkeitsintervall (Standard sind 5 Jahre ab Erstellung). Wenn das Root-Zertifikat abläuft, wird auch die ganze Zertifikatskette als ungültig betrachtet. Daher müssen alle Zertifikate erneuert werden, sobald das Root-Zertifikat droht sein Gültigkeit zu verlieren. Um neue Zertifikate zu erstellen, ist folgendermaßen vorzugehen:
Sicherung der alten Zertifikate:
cp -a /etc/univention/ssl /etc/univention/ssl_$(date +"%d%m%Y")
Erneuern der Zertifikate
Erneuerung des Root-Zertifikats, als Passwort ist der Inhalt der Datei /etc/univention/ssl/password anzugeben:
cd /etc/univention/ssl/ucsCA
openssl x509 -in CAcert.pem -out NewCAcert.pem -days "$(ucr get ssl/default/days)" \
-passin file:/etc/univention/ssl/password \
-signkey private/CAkey.pem \
-sha256
mv NewCAcert.pem CAcert.pem
Achtung: Bei UCS Systemen in einer Version älter als 2.0 lautet das Verzeichnis “/etc/univention/ssl/udsCA” statt “/etc/univention/ssl/ucsCA”.
Erneuerung aller Rechnerzertifikate:
eval "$(ucr shell)"
cd /etc/univention/ssl
for i in *".$domainname"; do univention-certificate renew -name "$i" -days "$(ucr get ssl/default/days)"; done
Im Moment werden die Berechtigungen für die Gruppe ‘DC Backup Hosts’ nicht automatisch mit angepasst. Damit die Backup Server die Zertifikate vom Master lesen können, muss die Berechtigung auf dem Master einmalig manuell angepasst werden:
chgrp -R 'DC Backup Hosts' /etc/univention/ssl/
Kopieren der Zertifikate
Kopieren der neuen Zertifikate auf die anderen Rechnersysteme (jedes UCS/UCC System, außer UCS Backups - hier am Beispielrechner ucs03):
eval "$(ucr shell)"
cd /etc/univention/ssl/
scp ucsCA/CAcert.pem root@ucs03:/etc/univention/ssl/ucsCA/
scp -r ucs03.$domainname root@ucs03:/etc/univention/ssl/
scp -r ucs03.$domainname/* root@ucs03:/etc/univention/ssl/ucs03/
Dieser Schritt ist auf UCS Backups nicht zwingend erforderlich, denn dort erfolgt das Kopieren auch automatisch per cron.
Um das neu erstellte Zertifikat allen Benutzern über die zentrale Verwaltungs-Webseite des UCS Masters zugänglich zu machen, kann der folgende Befehl verwendet werden:
cp /etc/univention/ssl/ucsCA/CAcert.pem /var/www/ucs-root-ca.crt
Nach dem Aktualisieren der Zertifikate werden die neuen Informationen noch nicht in der Univention Management Console (UMC) und im entsprechenden Monitoring-Check angezeigt.
Diese würden erst bei der nächsten regulären Prüfung aktualisiert, da der dafür angelegte Cronjob nur einmal am Tag ausgeführt wird.
Um die Gültigkeit der Zertifikate sofort prüfen zu können müssen die entsprechenden Univention Configuration Registry Variablen (ssl/validity/days) ausgewertet werden. Dies kann durch den Aufruf des folgenden Skriptes erfolgen:
/usr/sbin/univention-certificate-check-validity
Ein
update-ca-certificates --fresh
kann hier auch sinnvoll sein, damit die Symlinks erneuert werden.
Alle Dienste, die TLS/SSL-Verschlüsselung benutzen, müssen neu gestartet werden.
Alternativ kann ein Neustart des Systems durchgeführt werden, wenn nicht bekannt ist, welche Dienste mit TLS/SSL in Verbindung stehen.
SAML
Seit UCS 4.1 sind UCS Master und alle UCS Backup auch SAML Identity provider und jedes UCS System in der Domäne, auf dem die Univention Management Console (UMC) läuft ist ein SAML Service provider. Die SAML Implementierung in UCS verwendet ebenfalls TLS-Verschlüsselung sowie ein Zertifikat, das auf den DNS Alias ucs-sso.$domainname ausgestellt ist - dieses muss ebenfalls ersetzt werden.
Auf jedem SAML Identity provider (UCS Master und alle UCS Backups) muss folgendes ausgeführt werden:
eval "$(ucr shell domainname)"
cp "/etc/univention/ssl/ucs-sso.${domainname}/cert.pem" "/etc/simplesamlphp/ucs-sso.${domainname}-idp-certificate.crt"
cp "/etc/univention/ssl/ucs-sso.${domainname}/private.key" "/etc/simplesamlphp/ucs-sso.${domainname}-idp-certificate.key"
service univention-saml restart
SSO
Auf jedem UCS-System, einschließlich des primären DC in der Domäne, muss das neue Zertifikat neu installiert werden, damit das UMC Single Sign-On funktioniert.
Hinweis: Jeder mit UCS verbundene Dienstanbieter muss mit dem neuen Zertifikat aktualisiert werden. Siehe die jeweilige Dokumentation für jeden Dienstanbieter.
Simplesamlphp
rm -f /usr/share/univention-management-console/saml/idp/*.xml
eval "$(ucr shell ucs/server/sso/fqdn)"
ucr set umc/saml/idp-server="https://${ucs_server_sso_fqdn}/simplesamlphp/saml2/idp/metadata.php" || echo 'Failed!'
service univention-management-console-web-server restart
univention-run-join-scripts --force --run-scripts 92univention-management-console-web-server.inst
Keycloak
Note: Bitte prüfen Sie, ob Ihr Keycloak ucs-sso-ng heißt, andernfalls passen Sie den Namen entsprechend an.
rm -f /usr/share/univention-management-console/saml/idp/*.xml
ucr set umc/saml/idp-server="https://ucs-sso-ng.$(hostname -d)/realms/ucs/protocol/saml/descriptor" || echo 'Failed!'
service univention-management-console-web-server restart
univention-run-join-scripts --force --run-scripts 92univention-management-console-web-server.inst
O365 Connector
Wenn in der Domäne ein Office 365 Connector eingesetzt wird, bitte zusätzlich diesen Artikel durcharbeiten:
AD-Connector
Wenn der AD Connector im Einsatz ist, sollten auch hier die Zertifikate erneuert werden.
Die neuen Zertifikate können wie folgt kopiert werden.
cp /etc/univention/ssl/<FQDN of ad system>/{cert.pem,private.key} /var/www/univention-ad-connector/
chgrp www-data /var/www/univention-ad-connector/{cert.pem,private.key}
Hiernach stehen die neuen Zertifikate wieder in der UMC zum Download zur Verfügung.
RADIUS
Wird die RADIUS App (freeradius) eingesetzt, sind zusätzlich die Dateien cert.pem und private.key nach /etc/freeradius/ssl zu kopieren:
cp /etc/univention/ssl/"$(hostname -f)"/cert.pem /etc/freeradius/ssl/
cp /etc/univention/ssl/"$(hostname -f)"/private.key /etc/freeradius/ssl/
Im Anschluß muß Besitzer- und Gruppezugehörigkeit der kopierten Dateien auf dem Server angepasst werden
chown root:freerad /etc/freeradius/ssl/cert.pem
chown root:freerad /etc/freeradius/ssl/private.key
Docker-Container
Wenn eine App in einem Docker Container bereitgestellt wird, sollten auch hier die Zertifikate erneuert werden.
Die folgenden Kommandos beziehen sich auf UCS basierte Docker Container.
Hierfür verbindet man sich mit dem Docker Container und copiert die neuen Zertifikate via scp in den Container:
univention-app shell <app-name>
eval "$(ucr shell)"
cd /etc/univention/ssl/
scp $ldap_master:/etc/univention/ssl/ucsCA/CAcert.pem ucsCA
scp -r $ldap_master:/etc/univention/ssl/$hostname.$domainname .
scp -r $ldap_master:/etc/univention/ssl/$hostname .
Cyrus
Auf Rechnern, auf denen der cyrus-Mailserver läuft, sind zusätzlich die Dateien cert.pem und private.key nach /var/lib/cyrus/ zu kopieren:
cp /etc/univention/ssl/"$(hostname -f)"/cert.pem /var/lib/cyrus/
cp /etc/univention/ssl/"$(hostname -f)"/private.key /var/lib/cyrus/
Im Anschluß muß Besitzer- und Gruppezugehörigkeit der kopierten Dateien auf dem Mailserver angepasst werden
chown cyrus:mail /var/lib/cyrus/cert.pem
chown cyrus:mail /var/lib/cyrus/private.key
Zurückziehen der alten Zertifikate
Dieser Schritt ist optional. Laufen die Zertifikate zeitnah ab, kann man auch die Zeit für sich arbeiten lassen. Die Diagnose mahnt die alten Zertifikate aber folgerichtig immer noch an, da sie noch aktiv sind. Die Diagnose prüft nur das Ablaufdatum und nicht ob es für den Host ein neueres Zertifikat gibt.
Mit:
root@dc0:~ # univention-certificate list
List all certificates
01 dc0.reiherwald.intranet
02 ucs-sso.reiherwald.intranet
03 dc1.reiherwald.intranet
04 Memba1.reiherwald.intranet
09 guaca-61273611.reiherwald.intranet
0A gitla-73579361.reiherwald.intranet
0B jitsi-46557153.reiherwald.intranet
0C *.dc1.reiherwald.intranet
0D rocke-56708232.reiherwald.intranet
0F *.dc0.reiherwald.intranet
10 nextc-68323808.reiherwald.intranet
11 bitwa.reiherwald.intranet
12 passbo.reiherwald.intranet
13 bitwa-88313431.reiherwald.intranet
14 *.bitwa.reiherwald.intranet
15 passbo.reiherwald.intranet
werden die aktiven Zertifikate angezeigt. Nummer 12 und 15 sind für denselben Host ausgestellt. Mit:
root@dc0:~ # univention-certificate dump -id 12 |grep -P 'Subject:|Not'
Not Before: Mar 1 17:49:30 2022 GMT
Not After : Feb 27 17:49:30 2032 GMT
Subject: C = DE, ST = DE, L = DE, O = Reiherwald, OU = Univention Corporate Server, CN = passbo.reiherwald.intranet, emailAddress = ssl@reiherwald.intranet
kann das Start- und Enddatum, sowie das Object für das das Zertifikat gilt überprüft werden. Existieren zwei Zertifikate für das gleiche Subject kann eines davon (vorzugsweise das als erstes Abläuft) mit:
root@dc0:~ # univention-certificate revoke -id 12
zurückgezogen werden.