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.
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 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 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.