I have looked at many questions including https://stackoverflow.com/a/25384924/1317559. I have the IdP metadata and certificate, but can't seem to get Spring so see it.
Added the certificate to the keystore: keytool -importcert -alias adfssigning -keystore samlKeystore.jks -file certificate.crt
In the metadata there are multiple certificates (2 different ones) and a SignatureValue.
I tried to add the signature value with the same keytool command, but it is not a certificate.
I tried to add the 2 certificates found in the metadata also.
I enabled debugging log and this is what I get:
Successfully verified signature using KeyInfo-derived credential
Attempting to establish trust of KeyInfo-derived credential
Supplied trusted names are null or empty, skipping name evaluation
Attempting PKIX path validation on untrusted credential: [subjectName='O=novell,OU=accessManager,CN=test-signing']
PKIX path construction failed for untrusted credential: [subjectName='O=novell,OU=accessManager,CN=test-signing']: unable to find valid certification path to requested target
Signature trust could not be established via PKIX validation of signing credential
Failed to establish trust of KeyInfo-derived credential
Failed to verify signature and/or establish trust using any KeyInfo-derived credentials
PKIX validation of signature failed, unable to resolve valid and trusted signing key
Signature trust establishment failed for metadata entry http://idp.ppd.com/nidp/saml2/metadata
Error filtering metadata from http://idp.ppd.com/nidp/saml2/metadata
org.opensaml.saml2.metadata.provider.FilterException: Signature trust establishment failed for metadata entry
at org.opensaml.saml2.metadata.provider.SignatureValidationFilter.verifySignature(SignatureValidationFilter.java:312)
The Spring SAML manual describes metadata trust verification in chapter 7.2.4. One option is to disable the trust check, or manually remove the signature XML from metadata. Just like you found out, the certificate to import to samlKeystore.jks is the one used to produce the metadata signature, not the signing/encryption certificates for specific SP or IDP entities.
Also worth noting: Don't change the signed file - happened to me when I reformatted the ADFS generated one-liner.
Obviously changes the file's signature.
This problem was fixed. There were many problems in fact. I am using the Spring SAML sample application:
Need to add the public certificate (the first one after the signature, in the idp metadata) to the samlKeystore.jks under Other sources, security.
The password is nalle123 .
Don't put anything in the securityContext.xml file.
Related
What I've done is the following:
Creating a ca.key and ca.cert
Creating a server.key and server.csr
Signing the CSR with the CA, creating a server.cert
Creating a pfx using the server.cert and server.key
All this using OpenSSL.
Now I want to sign a JAR file with this PFX file using jarsigner.
$ jarsigner -storetype pkcs12 -keystore certificate.pfx myJAR.jar my-alias
And I get:
jar signed.
Warning:
The signer's certificate chain is invalid. Reason: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
No -tsa or -tsacert is provided and this jar is not timestamped. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (2022-05-12) or after any future revocation date.
The signer certificate will expire on 2022-05-12.
I also get this when I verify the jar. I'm guessing that this is due to the fact that nothing tells the JRE to trust the CA that signed the certificate that signed this JAR, but I'm not sure. What is a certificate chain anyway?
Please help.
An X.509 certificate can be used for various purposes. The keyUsage and extendedKeyUsage extensions in the certificate identify what its intended uses are. When a certificate is issued with certain keyUsage's, you can only perform those cipher operations with its public key. If you are trying to do any other operation that is not supported, the library that is doing the cipher operation will complain so. You can find the standard key usages here.
A certificate that is to be used for code-signing purposes should contain the digitalSignature key usage. You can read more about this here.
So in your case, it is either one of these:
You didn't ask the CA to issue the certificate with digitalSignature keyUsage, (or)
If you see digitalSignature keyUsage added, then the CA is not configured properly to issue the digital signature certificate (probably missed to add the necessary attributes required).
If you are using a well-known CA, then you don't have to worry about the point (2), it will be taken care of and you can focus on point (1).
There are two ways to do that, if the CA is honoring the extensions from your CSR, then you need to add the digitalSignature extension in the keyUsage of your CSR (or) if the CA isn't honoring the extensions from your CSR, then you need to figure out how to ask the CA for a digitalSignature certificate.
A certificate is simply a trusting relation between two entities, the issuer (who sign on the certificate) and the subject.
Example:
Gov. of Merryland (Issuer) (Root-CA)
+ certificateA
+ Tot The Diplomatist (Subject)
+ certificateB (contains copy of certificateA in a chain)
+ Dot The Diplomatists Secretary
So we have a certificate chain. (Id painted this as a tree because on a certificate can theoretically be signed by multiple issuers).
Each certificates have the signature of one Issuer in this example:
The issuer of CertificateA is the Gov. of Merryland.
The issuer of CertificateB is Tot The Diplomatist.
Now assuming the Diplomatists Secretary arrives in Oogaboo showing its CertificateB (Having the CertificateA in the "Chain"). The Government of Oogaboo try to verify the authenticy of the Secretary using the "Chain" of the certificates.
What the message
unable to find valid certification path to requested target
sais is that Gov. of Oogaboo do not trust any of the Issuers.
I am trying to implement a SAML Service Provider in order to allow for SSO to a cloud-based application, this application can host multiple tenants or companies. Normally, the user enters an e-mail address (which acts as their User ID) and their password to log in (the tenant would be identified by a URL parameter).
The SAML assertion that is received has the X509 certificate embedded in the payload, which is used to validate the signature of the SAML. While the signature can be used to verify that the assertion is valid, there is concern that someone other than the Identity Provider can generate their own public/private keys, sign their own assertion with a correctly "guessed" valid tenant ID and user e-mail address, then potentially gain access to the application.
What is a mechanism or technique used to identify that an assertion and its embedded certificate came from a specific identity provider other than the information contained inside the SAML payload? While I have read that certificates could be downloaded from identity providers, there is concern that those certificates would expire or become revoked, and additionally, we would also have to store them on our side. There is a legitimate concern that these scenarios would cause downtime for users.
One other small question, as we require a tenant ID to determine which tenant is signing on a particular user account, is it common (or proper) to provide that identifier through the URI, such as in the URL path or as a parameter on our endpoint receiving the SAML assertion?
SAML Trust
When you implement your SAML SP, you will be asked to pre-configure the signing certificate of your target SAML IdP. Therefore, your SP will only trust any incoming assertions signed with that particular signing certificate.
SAML Configuration
Configuration of a SAML SP can be done by setting up all IdP parameters including signing certificate manually, or by specifying a metadata file which contains all IdP parameters, including the signing certificate.
You may download the metadata file from IdP and use it locally in your SAML SP, or specify the URL of the metadata file and let your SAML SP to download and use it.
You may refer to Azure AD's SAML metadata URL as an example:
https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml
Obviously, this URL should be TLS/SSL protected and its content should only be modified by the IdP.
SAML Signing Certificate Rotation
When a signing certificate is rotated, the trust between IdP and SP is lost. You will need to re-configure your SP to trust the new certificate directly or refreshing the metadata file.
If you choose to configure your SAML SP by specifying an IdP metadata URL, you may consider configuring your SAML SP library to download and refresh the metadata regularly from IdP.
In this way, your SAML SP will have a trusted way to validate the latest signing certificate even though the certificate might be changed.
I am new to certificates and keystores.
What is the importance & working of keystores, and certificates for SAML SSO (in context of Spring boot SAML SSO)?
I see .jks, .pem, .cer, .der, etc. in use. What are these?
What is the importance & working of KeyStore, and certificates for SAML SSO (in context of Spring boot SAML SSO)?
These are used for Security implications for signing SAML assertions,
SAML protocol request and response.
Certificates in SAML SSO will be used to digitally sign the SAML
assertion/request/response and KeyStore is the persistent storage to
store the keys/certificates.
An assertion signed by the asserting party supports assertion
integrity, authentication of the asserting party to a SAML relying
party, and, if the signature is based on the SAML authority’s
public-private key pair, non-repudiation of origin.
A SAML protocol request or response message signed by the message
originator supports message integrity, authentication of message
origin to a destination, and, if the signature is based on the
originator's public-private key pair, non-repudiation of origin.
Certificates are also used for secure channel establishment
(SSL/TLS).
What are the .jks, .pem, .cer, .der, etc.?
.jks is extension to JAVA's proprietary KeyStore (JKS) format. JKS is
the database format for both the private key, and the associated
certificate or certificate chain. Till JAVA 8, by default, as
specified in the java.security file, keytool uses JKS as the format
of the key and certificate databases (KeyStore and TrustStores).
Since JAVA 9 the default KeyStore format has been changed to
PKCS12(extension .pkcs).
.pem, .cer, .der are the certificate/key types/extensions:
.PEM : The PEM extension is used for different types of X.509v3 files
which contain ASCII (Base64) armored data prefixed with a “—– BEGIN
…” line.
.DER : The DER extension is used for binary DER encoded certificates.
These files may also bear the CER or the CRT extension. Proper
English usage would be “I have a DER encoded certificate” not “I have
a DER certificate”.
.CRT : The CRT extension is used for certificates. The certificates
may be encoded as binary DER or as ASCII PEM. The CER and CRT
extensions are nearly synonymous. Most common among *nix systems.
CER : alternate form of .crt (Microsoft Convention) You can use MS to
convert .crt to .cer (.both DER encoded .cer, or base64[PEM] encoded
.cer) The .cer file extension is also recognized by IE as a command
to run a MS cryptoAPI command (specifically rundll32.exe
cryptext.dll,CryptExtOpenCER) which displays a dialogue for importing
and/or viewing certificate contents.
.KEY : The KEY extension is used both for public and private PKCS#8
keys. The keys may be encoded as binary DER or as ASCII PEM.
I have an Enterprise App which is acting as SP(Service Provider) and an OpenAm app acting as IdP(Identity Provider).
In SP, I have created a self-signed certificate for digital signature to communicate with OpenAM for SSO.
SP digitally signs and initiates the request, but In OpenAm i am getting 'The SAML Request is invalid' error. I think this is because of the absence of certificate in OpenAM tomcat server.
I have already tried creating the Key Store and adding my Self Signed certificate to it.
Questions
How to import SP self-signed certificate in tomcat for digital signature validation?
How validation is happening in OpenAm?
Check yr openam config directory (eg ~/openam/openam). This directory contains the keystore file used by OpenAM.
keytool -list -keystore ~/openam13/openam/keystore.jks
I would like to ask when is the purpose of a certificate, like Server Authentication, Client Authentication, set for the certificate.
Is it when we generate the CSR or when it is signed by the CA?
The CSR is a Certificate Signing Request. If it is a PKCS#10 request (by far the most common type) it can indicate which extensions are requested and that can include the Extended Key Usage (aka purpose). But the CA ultimately decides what to include when it creates and signs the cert. It could choose not to issue a cert. It could issue a cert with a subset of the requested attributes. It could issue a cert that is completely different. It could issue a cert that is exactly what the CSR requested.