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.
The following commands need to be performed on a UCS 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 FQDN of the computer name (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. To create new certificates, proceed as follows:
Create backups of the old certificates
cp -a /etc/univention/ssl /etc/univention/ssl_$(date +"%d%m%Y")
Renewal of the certificates
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/ucsCA” was 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
eval "$(ucr shell)"
cd /etc/univention/ssl
for i in *".$domainname"; do univention-certificate renew -name "$i" -days "$(ucr get ssl/default/days)"; done
At the moment, the read permission for the group ‘DC Backup Hosts’ is not set by default. This has to be done manually to make sure, the backup server can read the certificate from the master.
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)"
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/
scp -r ucs-slave.$domainname root@ucs-slave:/etc/univention/ssl/
scp -r ucs-slave.$domainname/* root@ucs-slave:/etc/univention/ssl/ucs-slave/
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:
scp -r "*.ucs-slave.$domainname" root@ucs-slave:/etc/univention/ssl/
scp -r "*.ucs-slave.$domainname"/* root@ucs-slave:/etc/univention/ssl/"*.ucs-slave"/
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.
cp 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
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 SSO
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)"
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
Every UCS system in the domain has to re-install the new certificate to make the UMC Single Sign On work:
eval "$(ucr shell ucs/server/sso/fqdn)"
rm /usr/share/univention-management-console/saml/idp/*.xml
ucr set umc/saml/idp-server="https://${ucs_server_sso_fqdn}/simplesamlphp/saml2/idp/metadata.php" || echo 'Failed!'
/etc/init.d/univention-management-console-web-server restart
univention-run-join-scripts --force --run-scripts 92univention-management-console-web-server.inst
Every serviceprovider connected to UCS must be updated with the new certificate. See the respective documentation for each serviceprovider.
Cyrus
On computers where the cyrus mail server is running, the cert.pem and private.key must also be copied to /var/lib/cyrus/
cp /etc/univention/ssl/"$(hostname -f)"/cert.pem /var/lib/cyrus/
cp /etc/univention/ssl/"$(hostname -f)"/private.key /var/lib/cyrus/
After that the permissions (owner) of the new files must be adjusted:
chown cyrus:mail /var/lib/cyrus/cert.pem
chown cyrus:mail /var/lib/cyrus/private.key
AD-Connector
If the ad connector is used, the certificates should be renewed as well.
The new certificates can be downloaded from the UMC:
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}
After that the new certificates can be downloaded from UMC and configured.
Freeradius
If freeradius is used, the cert.pem and private.key must also be copied to /etc/freeradius/ssl
cp /etc/univention/ssl/"$(hostname -f)"/cert.pem /etc/freeradius/ssl/
cp /etc/univention/ssl/"$(hostname -f)"/private.key /etc/freeradius/ssl/
After that the permissions (owner) of the new files must be adjusted:
chown root:freerad /etc/freeradius/ssl/cert.pem
chown root:freerad /etc/freeradius/ssl/private.key
Docker-Container
If an app within a docker container is used, the certificates should be renewed as well.
Starting with UCS 4.3-0 errata91, 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 errata91
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)"
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
# 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/
UVMM
On the Hosts you have to restart libvirtd, and on the mangeged nodes uvmmd.
Running VMS on the host server are not affected, if you restart libvirtd.
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"