The signature verified correctly with the key contained in the signature, but that key is not trusted.

[martinothamar]

https://github.com/KentorIT/authservices/blob/master/Kentor.AuthServices/XmlHelpers.cs#L247

This exception is thrown when the idp I'm integrating with has redirected the user to our site (/Acs). I've generated a self-signed serviceCertificate. At first I thought there was an issue with it, but does that make sense for the acs-endpoint (this is when logging in)? Is it the idp-certificate that isn't being trusted? I'm guessing the latter, but this exceptions wasn't being thrown on the staging-server, whereas the only difference is that the staging-server doesn't use https, so I don't quite know where to start. Any help is appreciated.

[AndersAbel]

It's the Idp certificate that's not trusted. There's something wrong in the configuration of the IdentityProvider/Federation. You're correct in that the serviceCertificate is not involved for the ACS endpoint.

[martinothamar]

    <identityProviders>
      <add entityId="id" metadataLocation="url" signOnUrl="url" logoutUrl="url" allowUnsolicitedAuthnResponse="true" binding="HttpRedirect">
        <signingCertificate fileName="~/App_Data/idp.crt" />
      </add>
    </identityProviders>

Do you mean that configuration? Does the certificate have to be imported somewhere on the server? What confuses me is that this configuration worked on staging. Thanks for the quick response!

[AndersAbel]

Yes, that's the configuration. The error message says that the certificate used by the Idp to sign the response is not the one you've configured in ~/App_Data/idp.crt. Are you using the same Idp in both environments? If it is a single idp, is it using different certificates for different SPs? (seems unlikely).

[martinothamar]

I finally realized they probably have 2 separate certificates, as they have 2 separate idp's (one for test, one for production). Just replaced the old test-.crt, thanks!

[agricfowl]

Hi

I wonder what using a wildcard certificate would have in this scenario?
It is surely an easy way to ensure that sub-domains can use the same certificate (test,staging and live).

Regards
Derrick

Sent from my iPad

On 6 Jun 2016, at 14:24, Martin Othamar notifications@github.com wrote:

I finally realized they probably have 2 separate certificates, as they have 2 separate idp's (one for test, one for production). Just replaced the old test-.crt, thanks!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[AndersAbel]

@agricfowl AuthServices doesn't care what name there is in the certificate. AuthServices only cares about the public key and ensures it is the one that was used to sign any data from the IDp. You can use a wildcard cert if you want. Or a cert for another site you have. But I would really recommend using a unique signing key for SAML, that is not used for anything else in your setup.

[lewis-mosaique]

I'm having a similar problem but am not sure about the contents of the signingCertificate file - is this a certificate file or a plain text type with ---- BEGIN CERTIFICATE ---- ... etc.

How do I get the public key? Is this something I should be able to get from the IdP or is this something I can extract from the SAML response itself?

I would very much appreciate any help with this.

[AndersAbel]

@lewis-mosaique The Idp should provide you with the certificate. The easiest way is if the Idp provides you with metadata, then you can load that, which will include the cert.

Otherwise you can extract the certificate from metadata or an existing response with a signature (make sure that you really extract it from a legit response though) and just save the ---- BEGIN CERTIFICATE --- parts to a file.

[lewis-mosaique]

AndersAbel - Thanks I have built a certificate using the X509 information from the SAML message itself, formatted it and saved it. This file is then reference via the signingCertificate - all now works! The X509 node from the IdP provided metadata does not match that in the SAML message!

[dev4201]

@AndersAbel - I'm running into the same issue (MVC - .NET4.5 - Kentor Version 0.19)
Everything works great with my in DEV and QA env servers configured against dev IDP.

When I set it up for prod against production IDP it failed, so I realized that I need to change the certificate and reference the one for prod and it still did not work.

To replicate the issue, I pointed my dev server SAML configuration to production IDP using prod certificated and this works, but it fails with the same certificate in prod server - I do get a Successful response from IDP so I'm not sure what else could be wrong.

[AndersAbel]

@dev4201 Upgrade to latest version first, to make sure you get accurate error messages. Then enable logging.

[dev4201]

@AndersAbel I upgraded to the latest version 0.22 and since I'm on .NET 4.5 I also added Kentor.AuthServices.Configuration.Options.GlobalEnableSha256XmlSignatures() to the application start.

Would you be able to point me how to enable verbose logging for this?

[jbreuer]

I also get this exception when I try to run SampleIdentityServer4: https://github.com/Sustainsys/Saml2/tree/netstandard/Samples/SampleIdentityServer4

InvalidSignatureException: The signature verified correctly with the key contained in the signature, but that key is not trusted.
Kentor.AuthServices.XmlHelpers.VerifySignature(IEnumerable<AsymmetricSecurityKey> signingKeys, SignedXml signedXml, XmlElement signatureElement, bool validateCertificate) in XmlHelpers.cs, line 315

Should I use a different certificate at this line? https://github.com/Sustainsys/Saml2/blob/netstandard/Samples/SampleIdentityServer4/Startup.cs#L56

Or should I add another certificate?

[jbreuer]

Got it fixed by also copying the X509Certificate from https://stubidp.sustainsys.com/Metadata/BrowserFriendly. That was different from what was in Kentor.AuthServices.StubIdp.cer.