I can see all the valid certificates and they haven't got expired but all of sudden everybuild started failing on Failed to sign error in Jenkins. We are just using MSBuild and provided pfx and thumbprint in CSProject.
I've tried to grant access to user admin access to fetch the certificates.
Tried to debug and found
After EKU filter, 1 certs were left.
After expiry filter, 1 certs were left.
After Private Key filter, 0 certs were left.
SignTool Error: No certificates were found that met all the given criteria.
After EKU filter, 1 certs were left.
After expiry filter, 1 certs were left.
After Private Key filter, 0 certs were left.
SignTool Error: No certificates were found that met all the given criteria.
I don't get how all of sudden something has changed to the certificates and even there is nothing in the event logs.
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'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?
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.
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.