Saml2: Azure AD client IDP signing certificates with dedicated certificate, throwing key not trusted error

[biddlem]

We have a client using Azure AD who is signing their assertions with a dedicated certificate that is different from their metadata x509 key data being published. I am getting the error:

Kentor.AuthServices.Exceptions.InvalidSignatureException: The signature verified correctly with the key contained in the signature, but that key is not trusted.

How should I setup the IDP data to handle this scenario?

[biddlem]

Also, we are loading idp data programmatically:

var provider = new IdentityProvider(providerId, CreateSPOptions())
            {
                MetadataLocation = "blahblah",
                AllowUnsolicitedAuthnResponse = true,
                Binding = Saml2BindingType.HttpPost
            };

            provider.LoadMetadata = true;

            //will try this...
            provider.SigningKeys.AddConfiguredKey(new X509Certificate2(GetMeMyCert()));

I am going to try using the signingkeys.addconfiguredKey() and see if that works, will update with outcome.

[AndersAbel]

Adding the key as a Configured key should work if the key remains the same.

But I'm a bit confused by the metadata not containing the right key. Did you download and save the metadata file? In that case it might be that Azure AD rotates keys automatically and your file contains a stale key. In that case you should set MetadataLocation to the address where the metadata is exposed so that AuthServices can load refresh metadata and keys as needed.

[biddlem]

I've set the metadatalocation to the url that Azure AD provides for our client, however they have chosen in the relying party setup to use a "dedicated certificate" for our application.

My understanding based on what I am seeing/reading is that the metadata is spitting out the certificate for the "standard" Azure AD service namespace certificate, but when the actual assertion is sent, it is using the "dedicated" certificate chosen by the client.

The cert info in the metadata does not match the cert info they provided us with.

[biddlem]

Here's the outcome for our situation:

1) The public metadata url Azure AD provides spits out some x509 certificate info
2) When an administrator sets up a Relying Party in Azure AD, it asks you if you want to configure using a certificate, if you choose this option you also get a link to download the customized metadata xml file

Our client provided us with the wrong metadata file, which is why there was a mis-match.

I'm not sure if there is some public url available to get the customized metadata, but at least the mis-match was solved.