How to and issues during SSL certificates upgrade

UCS - Univention Corporate Server
,
1

Hallo - I noticed an information, that my current version 4.4-9 errata1229 will get in trouble after 01.08.2022 - because the root certificate will expire.

I followed the link:
https://help.univention.com/t/renewing-the-ssl-certificates/37

I’m just a simple user via web-interface - so I’m a bit lost.

I’m currently preparing the upgrade to version 5.x.

And now the question - would an upgrade to version 5.x fix the certificate issues?

FYI: I’m working with currently 5 ucs servers:

  • Domaincontroller Master
  • Domaincontroller Backup
  • Domaincontroller Slace (3 times)
  • (plus about 15 IP based systems where UCS is managing the system accounts)

Thank you in advance

Pepe.

2

Sorry, but an upgrade to UCS 5.0 will not re-new the certificates. You have to do that manually.

3

Thank you for the feedback - even if I would like to see a different answer :wink:

OK I will start right now by following the instructions of the artikel:

https://help.univention.com/t/renewing-the-ssl-certificates/37

I hope there is someone in case questions are comming up.

Fingers-X

4

First question:

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.

How? What are the commands or steps to perform?

5

The part of the root certificate I think is done - just the question 1 is open (as fare as I see).

Second question:
I followed the instruction for SAML SSO renew.

  • I started with master
  • followed with backup server
  • and all 3 slaves

On all 3 slaves - there is no warning message if I run “Systemdiagnose” via the UCS web management.

On master and backup is still a warning message:
grafik

I have rebooted both system already twice - but no difference.

What is it that I’m missing/overseeing?

Thank you in advance

6

Hi - I changed the titel a bit because I haven’t had yet any feedback on the mentioned “issues”.

7

No one with a feedback???

8

I guess you can ignore it as /usr/sbin/univention-certificate already contains the relevant part to update the file ownership and permission:

chgrp -R "DC Backup Hosts" "$SSLBASE/$name"
chmod -R g+rX "$SSLBASE/$name"

In the past there were some problems with this as “DC Backup Hosts” is an LDAP group; if you try to lookup that group on a host which is not yet joined or connection to the LDAP server does not work (because it is currently not running or its SSL certificate expired :wink: ) the lookup fails and the permissions are not changed.

Basically all files below /etc/univention/ssl/ should be owned by user root and group “DC Backup Hosts”, but some are not; this is known Bug #50807.

9

The diagnostics module 04_saml_certificate_check.py might be buggy: Bug #49417

After you updated the host certificate it must be also included in some local XML file /usr/share/univention-management-console/saml/idp/${FQHN}.xml but also uploaded into the LDAP server. The above mentiond help article includes univention-run-join-scripts --force --run-scripts 92univention-management-console-web-server.inst for that, which should have done it but it looks like it did not work for you.
Try to execute /usr/share/univention-management-console/saml/update_metadata locally as user root to just update the certificate in LDAP. Repeat that for your Backup.

If it still does not work please post the output of the following two commands here:

  • Your local certificate: cat /etc/univention/ssl/$(hostname -f)/cert.pem
  • The certificates currently stored in LDAP: univention-ldapsearch -LLL '(&(serviceProviderMetadata=*)(univentionObjectType=saml/serviceprovider))' serviceProviderMetadata

The later requires post-processing as it is a base64-encoded XML document containing among others your base64-encoded certificate.

10

Hi!

Same problem over here as well. SAML is working, though, which seems to confirm the problem is with the diagnostic script.

When follwing your instructions you can see that the SSL certs are different (output shortened):

root@ucs:~# cat /etc/univention/ssl/$(hostname -f)/cert.pem | tail -n 3
2PzEo6pfUXwiRIcpL3cz1dgJF0CLOs4QmARm7NU33Of1Tbt3bmiuUCGLJ0+ixVRb
v8dZm2m4D1zimKmOep49
-----END CERTIFICATE-----

root@ucs:~# univention-ldapsearch -LLL "(&(serviceProviderMetadata=*)(univentionObjectType=saml/serviceprovider)(SAMLServiceProviderIdentifier=https://$(hostname -f)/univention/saml/metadata))" serviceProviderMetadata  | ldapsearch-wrapper | ldapsearch-decode64 | grep -B3 "</ds:X509Certificate>" | head -n 3
PLCzCDuTpMEUjenRKPG1HrP9heWiehVQTu8G/GZynfw+FbLgQ20Q33AH4bVM4EX1
sad+UWAzRIFkhkkO8wk0gq7XA+9tYr/ZEgh8bf300A9lZpQsLTQQSRA+6W0rIaaS
oBZmiSV1wOcxgCVd+UpTV+lOw5KRULHbKZog4P2AHMZ9LgBWIVq7

Neither /usr/share/univention-management-console/saml/update_metadata nor univention-run-join-scripts --force --run-scripts 92univention-management-console-web-server.inst do help and the problem persist.

I’ve seen this kind of issue in 3 installations, 2 of them were upgraded to 5.0(-2) within the last two weeks.
No hard proof for his, but when I set up SAML SSO under UCS v5.0-1 with Windfluechter/setupSSO.sh: Small script to setup SAML SSO for Univention UCS - setupSSO.sh - Codeberg.org I don’t remember that System Diagnostics showed any issues with SAML. Maybe something changed with the last errata updates? But no idea, though…