Our ADFS acts as an Federation Provider between the customer (IdP; using Azure AD) and our application (SP).
I created a new Claims Provider Trust in our AD FS using the provided metadata URL the client gave to me. This includes the used token signing certificate. So far so good. But when I take a look at the certificates-tab it states:
This CA Root certificate is not trusted. To enable trust, install this certificate in the Trusted Root Certification Authorities store.
What confuses me about this: The trust relationship works anyways. Meaning: I can smoothly reach the SP by starting from the client's portal. The token that's issued by the IdP gets flawlessly validated by our ADFS although the certificate chain cannot be validated.
The tokensigning certificate seems to be a self-signed certificate that has been issued by AzureAD when the client set up the trust relationship on his side. To use these self-signed certificates seems to be a best practice even for cases where ADFS acts as IdP (see here):
By default, AD FS creates a self-signed certificate with 2048 bit keys. [...] AD FS automatically renews these self-signed certificates before they expire, first configuring the new certificates as secondary certificates to allow for partners to consume them, then flipping to primary in a process called automatic certificate rollover. We recommend that you use the default, automatically generated certificates for token signing.
But what to do? Is it acceptable that at our side (FP) I cannot validate the certificate chain? Or should the certificate be installed in the Trusted Root Certification Authorities store as the warning message states? But if I install it: What happens when the certificate gets renewed? The new one won't be automatically installed rendering the process effectively useless in my eyes...
