Communication between the different systems in a UCS domain is largely SSL encrypted. A root certificate and host certificate for each computer are required for the SSL encryption. The root certificate is only valid for a specified period of time, as are the host certificates created with the root certificate. Once this period of time elapses, services which encrypt their communication with SSL (e.g., LDAP) no longer function. It is thus essential to verify the validity of the certificates and create new host certificates as necessary.
Introductions
The following commands need to be performed on the UCS Primary/Master.
univention-certificate can be used to check how long a computer certificate will remain valid:
# univention-certificate dump -name ucs-master.univention.de
[...]
Validity Not Before: Jun 19 10:40:13 2013 GMT
Not After : Jun 18 10:40:14 2018 GMT
[...]
When doing so, the fully qualified host name (FQHN) (computer name + domain) must be entered. A list of all available certificates can be called up with
univention-certificate list
To see a list of all certificates [also Expired and Revoked] you might call
univention-certificate list-all
The certificates for all the computers in a UCS domain usually have the same expiry date.
Renewal of the certificates
Before you begin create backups of the old certificates
cp -a /etc/univention/ssl /etc/univention/"ssl_$(date +%Y%m%d)"
Renew the root certificate
Renew the root certificate entering the contents of the /etc/univention/ssl/password file as the password:
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
Attention: On UCS-Systems in version smaller than 2.0 the folder
/etc/univention/ssl/ucsCAwas named/etc/univention/ssl/udsCA
Attention: When changing your RootCA all certificates, that are signed with the old RootCA (if expired or revoked), become invalid and must be renewed as well!
Renewing all computer certificates
This has at least to be done on the master.
eval "$(ucr shell domainname ssl/default/days)"
cd /etc/univention/ssl
for i in *".${domainname}"
do
univention-certificate renew -name "$i" -days "${ssl_default_days}"
done
At the moment, the read permission for the group ‘DC Backup Hosts’ might not set by default in all cases. This has to be done manually to make sure, the backup server can read the certificate from the master:
chgrp -R -h "DC Backup Hosts" /etc/univention/ssl
Copy the new certificates
Copying of the new root certificate and client certificates onto the other computer systems (each UCS/UCC system except DC backups - here using ucs-slave as an example computer)
eval "$(ucr shell domainname)"
cd /etc/univention/ssl/
# next step is only needed if root cert is also renewed
scp ucsCA/CAcert.pem root@ucs-slave:/etc/univention/ssl/ucsCA/
rsync -a "ucs-slave.${domainname}" root@ucs-slave:/etc/univention/ssl/
The last step is not required on a UCS backup computer as it occurs automatically via cron.
Since UCS 4.4-2, computers may request to get a wildcard certificate from the UCS master (this can be triggered by Apps, for example). In this case, another certificate exists, that needs to be copied as well:
rsync -a "*.ucs-slave.${domainname}" root@ucs-slave:/etc/univention/ssl/
It is now mandatory to make the newly created certificate available to all users via the UCS master’s central administration website.
The following command can be used to make the newly created certificate available to all users.
install -o root -g root -m 0644 ucsCA/CAcert.pem /var/www/ucs-root-ca.crt
After the certificates have been updated, the new information is not yet displayed in Univention Directory Manager. It would only be updated during the next, regular check, as the cronjob set up for this purpose is only run once every day. To be able to verify the validity of the certificates immediately, the corresponding Univention Configuration Registry variables need to be evaluated. This can be done by running the following script
/usr/sbin/univention-certificate-check-validity
You should also execute
update-ca-certificates -f
to clear all certificate symbolic links and renew them.
You should also run the command on the other UCS systems, which received the new certificate, otherwise the systemdiagnostic may fail.
Hint
Attention: All the services which use the SSL encryption need to be restarted. Alternatively, the system can be restarted if it is not known exactly which services employ SSL.
SAML
Since UCS 4.1 every UCS Master and UCS Backup is also a SAML Identity provider and every UCS system in the domain running the Univention Management Console (UMC) is a SAML Service provider. The SAML implementation for UCS uses also TLS encryption and a certificate for the DNS alias ucs-sso.$domainname - this needs to be replaced, too.
On every SAML Identity provider (UCS Master and all UCS Backups), execute the following:
eval "$(ucr shell domainname)"
install -o root -g samlcgi -m 0644 /etc/univention/ssl/"ucs-sso.${domainname}"/cert.pem /etc/simplesamlphp/"ucs-sso.${domainname}-idp-certificate.crt"
install -o root -g samlcgi -m 0640 /etc/univention/ssl/"ucs-sso.${domainname}"/private.key /etc/simplesamlphp/"ucs-sso.${domainname}-idp-certificate.key"
service univention-saml restart
SSO
On each UCS system including the primary DC in the domain has to re-install the new certificate to make the UMC Single Sign On work.
Note: Every service provider connected to UCS must be updated with the new certificate. See the respective documentation for each service provider.
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: Please check if your Keycloak is named ucs-sso-ng, otherwise adjust accordingly.
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
Dovecot IMAP
By default /etc/univention/ssl/<FQHN>/{cert.pem,}private.key are used unless alternative certificates have been configured via UCR variables mail/dovecot/ssl/certificate, mail/dovecot/ssl/key respective `
Cyrus IMAPd (up to UCS 4.2-5)
On computers where the Cyrus mail server is running, the files cert.pem and private.key must also be copied to /var/lib/cyrus/:
install -o cyrus -g mail -m 0644 /etc/univention/ssl/"$(hostname -f)"/cert.pem /var/lib/cyrus/
install -o cyrus -g mail -m 0640 /etc/univention/ssl/"$(hostname -f)"/private.key /var/lib/cyrus/
O365 Connector
If you have installed an O365 connector, please do also all steps in this article:
AD-Connector (before UCS 4.1-1 erratum173)
If the AD Connector is used, the certificates should be renewed as well.
The new certificates can be downloaded from the UMC:
install -o root -g www-data -m 0644 /etc/univention/ssl/<FQHN-of-AD-system>/cert.pem /var/www/univention-ad-connector/
install -o root -g www-data -m 0640 /etc/univention/ssl/<FQHN-of-AD-system>/private.key /var/www/univention-ad-connector/
After that the new certificates can be downloaded from UMC and configured.
FreeRADIUS
If FreeRADIUS is used, the files cert.pem and private.key must also be copied to /etc/freeradius/ssl:
install -o root -g freerad -m 0644 /etc/univention/ssl/"$(hostname -f)"/cert.pem /etc/freeradius/ssl/
install -o root -g freerad -m 0640 /etc/univention/ssl/"$(hostname -f)"/private.key /etc/freeradius/ssl/
Docker container
If an app within a docker container is used, the certificates should be renewed as well.
Starting with UCS 4.3-0 erratum91, run the following command on the Docker host to update the certificates for all installed (docker) apps:
univention-app update-certificates
Restart the affected app that the changes become active i.e. univention-app restart horde
Prior to UCS 4.3-0 erratum91
You have to connect to the docker container shell first and copy the certificates via scp in the container. The following commands work for a UCS based container only.
univention-app shell <app-name>
eval "$(ucr shell hostname domainname ldap/master)"
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" .
For other Apps you might use
# to list all containers with their ID
docker ps
CONTAINER=…
# to get hostname of specific container
docker_hostname=$(docker exec "$CONTAINER" hostname)
cd /etc/univention/ssl/
docker cp /etc/univention/ssl/ucsCA/CAcert.pem "$CONTAINER":/etc/univention/ssl/ucsCA/
docker cp /etc/univention/ssl/"${docker_hostname}.$(dnsdomainname)" "$CONTAINER":/etc/univention/ssl/
docker cp /etc/univention/ssl/"${docker_hostname}" "$CONTAINER":/etc/univention/ssl/
Virtual Machine Manager (up until UCS 4.4)
UVMM
On the managing node uvmmd has to be restarted:
service univention-virtual-machine-manager-daemon restart
KVM
On the hosts, where your VMs are running, you have to restart libvirtd. Running VMs are not affected by that restart.
service libvirtd restart
You can also check first if libvirtd` uses the new certificates:
# grep --color -n _file /etc/libvirt/libvirt*.conf
/etc/libvirt/libvirtd.conf:198:key_file = "/etc/univention/ssl/dc0.schein.ig/private.key"
/etc/libvirt/libvirtd.conf:202:cert_file = "/etc/univention/ssl/dc0.schein.ig/cert.pem"
/etc/libvirt/libvirtd.conf:206:ca_file = "/etc/univention/ssl/ucsCA/CAcert.pem"
/etc/libvirt/libvirtd.conf:211:#crl_file = "/etc/univention/ssl/CA/crl.pem"
Revoke old certificates
This step is optional. If the certificates expire promptly, you can also let time work for you. However, the diagnostic logically still reminds the old certificates because they are still active. The diagnostic only checks the expiration date and not whether there is a newer certificate for the host.
With univention-certificate list a list of all certificates is displayed, which have not yet expired or revoked:
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 rock-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 <=====
In this example entry 12 and 15 are issued for the same host. With:
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
the start and end date as well as the object for which the certificate is valid can be checked. If two certificates exist for the same subject, one of them (preferably the one that expires first) can be revoked with:
univention-certificate revoke -id 12