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.
Related
When creating an intermediate root certificate, do you set the "IsCA" property of the certificate template? What exactly does this property do?
I'm creating a certificate chain for an application. In this application I need to use intermediate certificates to sign some client certificates. I've found some guides on creating Root CA certificates and they indicate to set IsCA = true when creating the certificate template, but I cannot find any information on creating intermediate roots. Does the IsCA property still need to be set? Are there any other changes to the certificate template when creating an intermediate certificate vs. a root certificate?
You must set the cA basic constraint for intermediate certificates. This bool indicates that a certificate can be used to verify other certificate signatures.
A certificate without cA set to true is a leaf certificate.
Here is the relevant portion of the "basic constraints" section of RFC 5280:
The cA boolean indicates whether the certified public key may be used
to verify certificate signatures. If the cA boolean is not asserted,
then the keyCertSign bit in the key usage extension MUST NOT be
asserted. If the basic constraints extension is not present in a
version 3 certificate, or the extension is present but the cA boolean
is not asserted, then the certified public key MUST NOT be used to
verify certificate signatures.
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 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.
I am currently developing an application that validates signature certificates (like in a pdf) with OCSP or CRL. These will most likely be leaf certificates, without the entire chain. Getting the url to either validation services proved simple enough.
To my understanding, both OCSP and CRL require the issuer of the certificate to validate it. So now I'm stuck because that is not included in the input. The AIA extension might include a URL to a CA certificate, but unfortunately this is the CA of the issuing certificate and not the certificate itself.
Is there any other way to get the issuer's certificate given only the leaf? Or are there some cases in which OCSP/CRL can validate without it?
Have a look at https://www.ietf.org/rfc/rfc2560.txt which details the requirements for an OCSP response to be considered valid:
The key
used to sign the response MUST belong to one of the following:
-- the CA who issued the certificate in question
-- a Trusted Responder whose public key is trusted by the requester
-- a CA Designated Responder (Authorized Responder) who holds a
specially marked certificate issued directly by the CA, indicating
that the responder may issue OCSP responses for that CA
The first and third option both require the issuer cert. The second option does not. However I dont think that option is applicable to you situation. The link https://wiki.mozilla.org/CA:OCSP-TrustedResponder has details on what a trusted responder is and when it can actually be used.
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.