The routine throwing this exception has some hints what it does and what to check including some topics on help.univention.com which are related to the renewal.
From/usr/share/pyshared/univention/management/console/modules/diagnostic/plugins/04_saml_certificate_check.py:
def test_service_provider_certificate():
# compare /etc/univention/ssl/$(hostname -f)/cert.pem with
# univention-ldapsearch -LLL "(&(serviceProviderMetadata=*)(univentionObjectType=saml/serviceprovider)(SAMLServiceProviderIdentifier=https://$(hostname -f)/univention/saml/metadata))" serviceProviderMetadata | ldapsearch-wrapper | ldapsearch-decode64
# If it fails: /usr/share/univention-management-console/saml/update_metadata
#
# fails because https://help.univention.com/t/renewing-the-ssl-certificates/37 was not used. https://help.univention.com/t/renewing-the-complete-ssl-certificate-chain/36
lo = univention.uldap.getMachineConnection()
certs = lo.search(filter_format('(&(serviceProviderMetadata=*)(univentionObjectType=saml/serviceprovider)(SAMLServiceProviderIdentifier=https://%s/univention/saml/metadata))', ['%s.%s' % (ucr.get('hostname'), ucr.get('domainname'))]), attr=['serviceProviderMetadata'])
with open('/etc/univention/ssl/%s.%s/cert.pem' % (ucr.get('hostname'), ucr.get('domainname'))) as fd:
for cert in certs:
cert = find_node(fromstring(cert[1]['serviceProviderMetadata'][0]), '{http://www.w3.org/2000/09/xmldsig#}X509Certificate')
if cert.text.strip() not in fd.read():
raise Critical(_('The certificate of the SAML service provider does not match.'))
yes, I did install letsencrypt on the DC Master, later I removed it again because I realised that this is not needed. After I had many errors that I could fix. but this one SAML error not.
Below the result of the script:
root@ucs-4:/home/Administrator# /usr/share/pyshared/univention/management/console/modules/diagnostic/plugins/04_saml_certificate_check.py
error, connecting
error, connecting
Traceback (most recent call last):
File "/usr/share/pyshared/univention/management/console/modules/diagnostic/plugins/04_saml_certificate_check.py", line 119, in <module>
run(0)
File "/usr/share/pyshared/univention/management/console/modules/diagnostic/plugins/04_saml_certificate_check.py", line 77, in run
test_service_provider_certificate()
File "/usr/share/pyshared/univention/management/console/modules/diagnostic/plugins/04_saml_certificate_check.py", line 114, in test_service_provider_certificate
raise Critical(_('The certificate of the SAML service provider does not match.'))
univention.management.console.modules.diagnostic.Critical: The certificate of the SAML service provider does not match.
root@ucs-4:/home/Administrator#
I dont believe that Lets Encrypt is related to this issue anyhow.
Unfortunately the screenshot you tried to upload got lost, so I dont know about the current error.
In general the critical related point is the “SAML SSO” section in Renewing the SSL certificates. In addition I want to point to the hint in the test_service_provider_certificate function quoted above (run the script /usr/share/univention-management-console/saml/update_metadata).
Now that the screenshot is visible I can only ask if also the steps from “Renewing the SSL certificates” have been followed after “Renewing the complete SSL certificate chain” according to the last hint?
The screenshot looks like that there might also a required service restart to pick-up the new certificates be missing.
The remaining part, the missing ucs-sso… directory could be related to the first and critical issue as the files from this directory are copied to /etc/simplesamlphp when following the instructions to renew the certificates.
I’d check carefully what happens during the step “ucs-sso requires a separate handling” from Renewing the complete SSL certificate chain. This includes the review of the join.log and the proof that the directory and its files will exist afterwards. (note: I havent verified that this is the step where it happens but following the docs it looks like that).
The S4 reject seems to be unrelated but needs separate handling.
I wouldnt necessarily trust that “done” always means “succesfully executed”, hence checking /var/log/univention/join.log is a good idea.
In additon some remarks regarding the creation of the certificate during 91univention-saml.inst.
There will be a new certifcate created only when:
the file referenced by UCRV saml/idp/certificate/certificate does not exist
on a DC master the UCRV ucs/server/sso/certificate/generation is set to true or unset
The certificate should then be created to the hostname taken from UCRV ucs/server/sso/fqdn.
The Warning “cannot append … value exists” appears when the cli-tool udm is called to create or modify an entry which already exists (sic) and can or should not be altered. Here it might be that the new certificate is not added into LDAP.
Please have a look at the first lines in the function test_service_provider_certificate() from the check routine and compare the certificates manually.
In case these certificates really differ you might consider removing the saml/serviceprovider entry from LDAP (using UMC) and run the joinscript again.
I still have some S4 connector error on the DC master and some SSL certificate error on the DC backup.
But I will address this later, because it seams not to affect anything urgent.
All the other servers after doing a domain re-join are without errors.