Signature trust establishment failed for SAML metadata entry

Asked 18/8, 2014 at 12:47 Answered 12/12, 2022 at 13:15

Solved java spring spring-security saml-2.0 spring-saml

In order to fetch metadata from a remote source, I defined an ExtendedMetadataDelegate bean as follows:

@Bean
@Qualifier("replyMeta")
public ExtendedMetadataDelegate replyMetadataProvider() throws MetadataProviderException {
    String metadataURL = "https://ststest.mydomain.it/FederationMetadata/2007-06/FederationMetadata.xml";
    final Timer backgroundTaskTimer = new Timer(true);
    HTTPMetadataProvider provider = new HTTPMetadataProvider(
            backgroundTaskTimer, httpClient(), metadataURL);
    provider.setParserPool(parserPool());
    ExtendedMetadataDelegate emd = new ExtendedMetadataDelegate(
            provider, new ExtendedMetadata());
    return emd;
}

To ensure the signature trust establishment, I added the related key both in JDK keystore and application keystore (the second step might not be enough); despite that, an error occurs by running the webapp.

[2014-08-18 14:36:47.200] boot - 6000 DEBUG [localhost-startStop-1] --- SignatureValidator: Attempting to validate signature using key from supplied credential
[2014-08-18 14:36:47.200] boot - 6000 DEBUG [localhost-startStop-1] --- SignatureValidator: Creating XMLSignature object
[2014-08-18 14:36:47.206] boot - 6000 DEBUG [localhost-startStop-1] --- SignatureValidator: Validating signature with signature algorithm URI: http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
[2014-08-18 14:36:47.207] boot - 6000 DEBUG [localhost-startStop-1] --- SignatureValidator: Validation credential key algorithm 'RSA', key instance class 'sun.security.rsa.RSAPublicKeyImpl'
[2014-08-18 14:36:47.329] boot - 6000 DEBUG [localhost-startStop-1] --- SignatureValidator: Signature validated with key from supplied credential
[2014-08-18 14:36:47.329] boot - 6000 DEBUG [localhost-startStop-1] --- BaseSignatureTrustEngine: Signature validation using candidate credential was successful
[2014-08-18 14:36:47.330] boot - 6000 DEBUG [localhost-startStop-1] --- BaseSignatureTrustEngine: Successfully verified signature using KeyInfo-derived credential
[2014-08-18 14:36:47.330] boot - 6000 DEBUG [localhost-startStop-1] --- BaseSignatureTrustEngine: Attempting to establish trust of KeyInfo-derived credential
[2014-08-18 14:36:47.330] boot - 6000 DEBUG [localhost-startStop-1] --- BasicX509CredentialNameEvaluator: Supplied trusted names are null or empty, skipping name evaluation
[2014-08-18 14:36:47.331] boot - 6000 DEBUG [localhost-startStop-1] --- MetadataCredentialResolver: Attempting PKIX path validation on untrusted credential: [subjectName='CN=ADFS Signing - ststest-replynet.reply.it']
[2014-08-18 14:36:47.346] boot - 6000 ERROR [localhost-startStop-1] --- MetadataCredentialResolver: PKIX path construction failed for untrusted credential: [subjectName='CN=ADFS Signing - ststest-replynet.reply.it']: unable to find valid certification path to requested target
[2014-08-18 14:36:47.347] boot - 6000 DEBUG [localhost-startStop-1] --- PKIXSignatureTrustEngine: Signature trust could not be established via PKIX validation of signing credential
[2014-08-18 14:36:47.347] boot - 6000 DEBUG [localhost-startStop-1] --- BaseSignatureTrustEngine: Failed to establish trust of KeyInfo-derived credential
[2014-08-18 14:36:47.347] boot - 6000 DEBUG [localhost-startStop-1] --- BaseSignatureTrustEngine: Failed to verify signature and/or establish trust using any KeyInfo-derived credentials
[2014-08-18 14:36:47.347] boot - 6000 DEBUG [localhost-startStop-1] --- PKIXSignatureTrustEngine: PKIX validation of signature failed, unable to resolve valid and trusted signing key
[2014-08-18 14:36:47.347] boot - 6000 ERROR [localhost-startStop-1] --- SignatureValidationFilter: Signature trust establishment failed for metadata entry http://ststest-replynet.reply.it/adfs/services/trust
[2014-08-18 14:36:47.349] boot - 6000 ERROR [localhost-startStop-1] --- AbstractReloadingMetadataProvider: Error filtering metadata from https://ststest-replynet.reply.it/FederationMetadata/2007-06/FederationMetadata.xml
org.opensaml.saml2.metadata.provider.FilterException: Signature trust establishment failed for metadata entry

The error disappears by setting:

emd.setMetadataTrustCheck(false);

... but I'd like to check used metadata.

Is there a way to resolve this error?

Update:

I tried to setup the ExtendedMetadata as follows but the error persists.

em.setAlias("defaultAlias");
em.setSigningKey("*.mydomain.it (Go Daddy Secure Certification Authority)");

Phytology answered 18/8, 2014 at 12:47 Comment(3)

Look like that's because of unable to find valid certification path to requested target - do you have all needed certficates in your truststore? More info here #24699414 – Router 18/8, 2014 at 13:37

I added the certificate into the JDK (jre/lib/security/cacerts) and also into samlKeystore.jks. – Phytology 18/8, 2014 at 13:48

emd.setMetadataTrustCheck(false); worked for me thanks! ... My trust was invalid and out of my control – Swen 24/8, 2016 at 18:39

You have most likely imported the HTTPS certificate, but not the certificate which is used to create the signature - they differ. You should:

Create file signature.cer with the following content taken from the metadata:

Import the certificate to your samlKeystore.jks with:

keytool -importcert -alias adfssigning -keystore samlKeystore.jks -file signature.cer

This should be all you need, just restart Tomcat and your metadata loading should now pass.

You don't need to include the HTTPS certificate in your JDK's cacerts in case you include the following bean which configures the HTTP client (available in Spring SAML 1.0.0.RELEASE):

<bean class="org.springframework.security.saml.trust.httpclient.TLSProtocolConfigurer"/>

Suffuse answered 19/8, 2014 at 13:39 Comment(4)

how did you generate the signature.cer ? – Generalize 7/1, 2019 at 13:51

@Generalize you can get the certificate from the metadata the identity provider shares. You probably can get it from a certain endpoint like : idp.hostname/saml2/idp/metadata.php , ask the admin of the IPS you are using. Just drop it in an empty file between the BEGIN / END CERTIFICATE tags – Betthezul 12/2, 2019 at 15:23

Even after adding signing.cer into my keystore, I am getting same error.. Any idea? – Loincloth 11/5, 2019 at 10:41

is there a sample code in spring or java to quickly match the edited .cer and .jks and match with metadata, i am restarting server to retest and all and its taking me ages and then to remove an extra tab or newline and then again restarting server. – Flotation 24/8, 2019 at 10:35

I'm posting this just in case if it may be helpful even after everything you did like accepted answer for this question and still get the same error.

I too had this problem, I have added IDP's metadata file and imported their certificate into my app keystore. But still had Signature trust verification problem. I did format the metadata.xml from IDP in Intellij, that did some screw up. Once I imported their metadata file as it without formatting, everything went ok.

Loincloth answered 11/5, 2019 at 16:18 Comment(2)

Thank you very much, This saved me a lot of time. I still do not understand how formatting messed up the signature. First I thought it was because of the spaces that were added before and after the signature but it was not because of that. Maybe there are other spaces on other attributes from the XML that messed it up – Canst 3/7, 2020 at 11:24

"Signature is first checked for validity by comparing digital hash included as part of the signature with value calculated from the content." -> Formatting the file means changing its content and that is why the signature verification fails. Ref docs.spring.io/spring-security-saml/docs/current/reference/html/… – Canst 3/7, 2020 at 11:54

I was facing the same issue.Steps that I have follwoed to resolve the same

extract from IDP metdata fille
copy the certificate in text file and save as.crt. e.g idp.crt
import the crt file in key Store keytool -import -alias adfscert -file idp.crt -keystore samlKeystoreold.jks -storepass keystorepassword
it will ask for is you trust this crt.. say yes
for some cases it will ask to use in pkcs12 format add in warning message do the same
try running your application it should work :)

Unveiling answered 24/3, 2021 at 12:1 Comment(0)

In my case I had to add the alias of the import certificate in metadataTrustedKeys prop of ExtendedMetadataDelegate emd

if you import using the example of Vladimír Schäfer above

keytool -importcert -alias adfssigning -keystore samlKeystore.jks -file signature.cer

you have to write

emd.setMetadataTrustedKeys(Collections.singleton("adfssigning"));

Schlesinger answered 12/12, 2022 at 13:15 Comment(0)

Update:

Recommended topics

Hot tags