Problem with SSO Certificate


Dear Supporters and Forum Users

We do have an issue…

We have the sso enabled (for office 365) … now our wildcard certificate was outdated and every machine got the new certificate. Everything is working well… EXCEPT OF THE ucs-sso… The simplesaml does not use the default Certificate (including Chain) which is defined in the Apache conf.

THIS IS A HUGE PROBLEM because now, the SSO (for Office 365) is not working anymore.

is there any usable manual on how to replace the ucs-sso certificate with a valid, not selfsigned certificate?

Many Thanks in advance…



for the sso portal there is a dedicated ucr variable where the ssl certificate is stored:

$ ucr dump | grep saml/apache2/ssl/
saml/apache2/ssl/certificate: /etc/univention/letsencrypt/signed_chain.crt
saml/apache2/ssl/certificatechain: /etc/univention/letsencrypt/intermediate.pem
saml/apache2/ssl/key: /etc/univention/letsencrypt/domain.key


Hi fbartels

I’ve copied the certificate-paths I used in the apache/ssl/* configuration…

Do i now have to restart the saml service with :
service univention-saml restart




No, that is something in the Apache Webserver so you would need to restart this.



That worked, now we not have any certificate issues anymore. but Office365 logins are still not working.

It says:
5 STAT [9fac2bec35] user ‘xy’ has been sucessfulyy authenticated.
5 STAT [9fac2bec35] saml20-idp-SSO-first urn:federation:MicrosoftOnline NA
5 STAT [9fac2bec35] saml20-idp-SSO urn:federation:MicrosoftOnline NA

But on, it aways redirect to “enter your email address” so, no login possible…

Is this a Microsoft issue?


Office 365 is not really my product, so I cannot say :wink:

Just saw the easily answered question about the ssl certificates and went for it.

I would recommend to open a direct support case with Univention.


HI Fbartels

Tank you for the help… But the certificate is now correct. thats good (y)

Ticket can be closed



Sorry to bother you all again.

we have replaced all certificates as needed, added also de saml certificates…

but we cannot get any login to MS… and so on…

in Teams we are getting this error, after the successfull login on our ucs-sso:

<10676> – event – Microsoft_ADAL_api_id: 176, Microsoft_ADAL_correlationId: 34185ed5-7da2-464e-a454-f5b09caeff3e, Microsoft_ADAL_response_rtime: 7117, Microsoft_ADAL_api_error_code: caa20003, eventpdclevel: 2,
<10676> – info – Could not login user - status: caa20003 diag:1
<10676> – error – SSO: ssoerr - (Login Window) Could not login user - status: caa20003

Has Microsoft something changed?

Kind Regards


Through some ways, we got now the following error from Microsoft:

AADSTS5000811: Unable to verify token signature. The signing key identifier does not match any valid registered keys.

Additionally we tried the following link, but did not work eighter:


You have to tell Office365 about your new certificate.


Hi SirTux … we would like, but we have not any possiblity to conntect to MS, sadyl because we always get redirected…


Do you have tried to reset the setup with with the Office365 UCS app?


Hi SirTux

Not yet… we are waiting for a back-call from microsoft, to evaluate the exact reason.



Little Update

We are currently using the following configuration and versions:

UCS: 4.3.3 (latest package updates) , planned to upgrade do 4.4

Office365 Connector: Version 2.3

Is there any issue known to this versions used?




There are some things to consider, that I can think of:

Yes, Microsoft broke some APIs that rendered new installs not working. (you could not get federated setups to work anymore.) However already configured environments should not be affected. (look in the forums). The new app has been released for UCS 4.4 like last week or so which specifically addressed this issue.

During the O365 connector setup you had to import a certificate into Azure AD and that has now changed. You will have likely need to re-upload the new certificate as shown in the O365 config wizard in the UCS O365 connector app.

In order to login on Azure AD and Office online while the federation is broken, you will need a user that is not federated and only exists Azure AD (not in your UCS domain). Such users are identifiable by their user principal name suffix (username)

This user needs (AFAIR) global admin privileges on your Microsoft Azure AD tenant. Your very first user that you have created, should be such a admin and will not be redirected to your UCS SSO page.

If you have gone through a partner who has set up your tenant initially, they might be able to access your tenant and add such a global admin. - Keep these admin credentials in a safe space :slight_smile:


Hi all

We solved the issue… the problem was that, due to the fact, that we had to replace our Core-Certificates (Erneuern der TLS/SSL-Zertifikate). through that, our ucs-sso certificate got replaced too. This new Certificate was not matching the Cert on MS side.

So, because we installed the Office365 Connector later, than our UCS Master, the certificate of the sso had a longer/other expiry date.

This new created Certificate did not match to MS

PLEASE descripte this fact in your documentation , that you have to replace the SSO Certificate on Microsoft-Side, if you change the IDP Certificate.

Now, everything works again till 2022 (when the certificate really expires :slight_smile: )

Question: Is there any documentation or scripting, which does the Replacement for the IDP Certificat to Microsofts Azure AD, like a saml update (like saml_setup.bat) script on UCS?

Many thanks