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.
Related
I can encrypt a message in windows given a certificate with a private key with CryptMsgOpenToEncode and CryptMsgUpdate. This returns an ASN1 signature which contains the signature and the certificate enclosed in a full ASN1 message.
My problem now is that I am forced to use an external signing Web API site. Upon signing, the returned string from this Web site is the signature and the certificates in two separated messages, not within an ASN1.
The question is how to to build the message into a proper detached PKCS#7 signature (which would be put in a PDF file).
Must I build the ASN1 manually? I'm already using ASNC but I'm not sure how to build the complete message. Can I use openssl to combine certs + signature into a PKCS#7?
Thanks.
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'm trying to create a LTV Enabled PDF Signature using Apache's PDFBox Detached Signature and the BouncyCastle API for the cryptographic signature itself.
So far I was able to make Adobe Reader display the "Signature is LTV enabled" message following these steps:
Retrieve revocation info (both CRLs and OCSP Responses, except for root certificates of course) for the signing certificate's full chain and for the timestamp authority certificate's full chain (used to add the signature's timestamp in step #4)
Include revocation info retrieved in step #1 as a signed attribute for the signature to be computed in Adobe OID "1.2.840.113583" format:
adbe-revocationInfoArchival OBJECT IDENTIFIER ::= {
adbe(1.2.840.113583) acrobat(1) security(1) 8 }
RevocationInfoArchival ::= SEQUENCE {
crl [0] EXPLICIT SEQUENCE of CRLs OPTIONAL,
ocsp [1] EXPLICIT SEQUENCE of OCSP Responses OPTIONAL,
otherRevInfo [2] EXPLICIT SEQUENCE of OtherRevInfo OPTIONAL
}
OtherRevInfo ::= SEQUENCE {
Type OBJECT IDENTIFIER
ValValue OCTET STRING
}
Perform the signature
Embed a qualified timestamp in the signature generated in the step #3
The previous steps' output gives me the "LTV Enabled" status in Adobe Reader:
When I check which data Adobe Reader used to validate the certificate chain validity it presents the expected "The selected certificate is considered valid because it has not been revoked as verified using the Online Certificate Status Protocol (OCSP) response that was embedded in the signature."
However, when I perform the same check for the Timestamp Authority's certificate chain it presents "The selected certificate is considered valid because it has not been revoked as verified in real-time using the Online Certificate Status Protocol (OCSP) obtained on-line."
The Signer's chain embedded CRLs/OCSPs are successfully used but the embedded TSA's chain CRLs/OCSPs are not.
This begs some questions that need to be answered:
Why are not the TSA embedded CRLs/OCSPs embedded used?
Do I have to place them elsewhere? If so, where?
Or do I have to ask the Timestamping authority to return the CRLs and/or OCSP responses as signed attribute within the timestamp token?
How can I check if a x509 certificate matches a CSR (if the certificate was generated based on a specific CSR) in Go? Do I need to generate a new certificate from the CSR and compare them?
If your signing request is in the DER format there's a couple of functions in the standard library you can use; first to parse the CSR (https://golang.org/pkg/crypto/x509/#ParseCertificateRequest) and then the certificate (https://golang.org/pkg/crypto/x509/#ParseCertificate). Once parsed you can compare the public key values.
Standard but important security note:
Please note that this DOES NOT validate the certificate in anyway. It may or may not be safe to use, and could have been substituted or altered.
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.