I've got two binaries, one builded ~4 days after first, and signed with the same certificate (same Serial number, issued by Thawte), but, when I'm checking the certificate, on one there is error message Revocation Status : The revocation function was unable to check revocation because the revocation server was offline.
, the second works well. Is it possible, that the revocation server was offline at the time of signing, and that causes this problem? I'm not sure if there is other way how one certificate could have different revocation servers.
Another think I may think of is, that the second one was signed few days (< month) before certificate's expiration. Could this be the case?
What format is the certificate in? If you can get into a suitable format, you can use the "openssl" command line unix tool to investigate the certificate. Openssl works on windows, too.
Here's a sample run:
openssl x509 -in usertrust.pem -inform PEM -noout -text
And here's the output:
Version: 3 (0x2)
Serial Number:
07:74:8d:73:00:00:00:00:00:94
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network
Validity
Not Before: Apr 5 18:35:06 2005 GMT
Not After : Mar 6 03:22:04 2007 GMT
Subject:C=US, ST=UT, L=Salt Lake City, O=USERTRUST, CN=www.usertrust.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:d7:21:6d:f8:58:e7:ed:52:5a:3e:fe:e5:bf:92:
32:41:38:f1:ee:61:6f:da:6c:83:39:c8:b4:b1:fd:
77:4a:35:a8:e8:3f:0b:bf:ff:2d:0b:b5:ed:56:80:
d7:ca:89:c3:63:8b:a5:06:ed:b0:22:82:8d:a1:c6:
ed:c8:d4:06:8d:be:d1:69:83:31:a7:13:2b:17:27:
72:a4:85:97:55:fc:f7:ca:eb:c9:af:be:19:78:67:
35:d1:7f:af:2d:3c:d3:86:c4:1e:fd:02:e4:ab:10:
ea:d1:bb:63:19:fb:9a:61:ed:30:7e:88:0e:1a:1e:
a7:a6:d5:8d:02:20:af:be:b0:0e:f5:30:44:e0:d5:
b9:ab:b1:76:65:94:03:fc:c8:55:80:6d:a8:fa:b1:
94:38:be:e2:78:45:8d:b5:7e:cf:e7:de:a1:09:46:
a3:8b:ab:76:50:85:50:5d:58:91:78:21:a3:a2:dd:
1d:c3:dc:0b:18:9d:fc:84:b2:17:f8:a7:48:e5:aa:
c1:d3:43:83:49:ea:35:5f:e1:28:6c:33:a9:2f:ac:
62:22:1d:6f:44:94:bb:09:be:7d:fd:c5:e4:fc:ff:
92:4c:63:97:56:53:fe:77:5c:53:5b:ae:ab:7d:8b:
af:74:ac:ea:30:80:b1:6e:08:57:85:01:7d:b4:3d:
26:65
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage:
Digital Signature, Key Encipherment, Data Encipherment, Key Agreement
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Subject Key Identifier:
A0:3C:DC:84:FF:51:06:AC:C6:CB:21:EB:CB:05:07:D7:10:C2:68:E6
X509v3 Authority Key Identifier:
keyid:75:01:28:97:C6:46:1B:34:6E:E8:A0:91:15:71:92:79:EE:B7:03:CE
serial:15:6C:27:1A:54:FE:B3:82:BE:AF:54:FE:F4:A2:8B
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 CRL Distribution Points:
URI:http://crl.usertrust.com/USERTRUST-ServerAuthentication.crl
URI:http://www.utnsecurity.com/USERTRUST-ServerAuthentication.crl
X509v3 Certificate Policies:
Policy: 1.2.840.114015.1.1
CPS: http://www.usertrust.com/CPS
User Notice: Explicit Text: ...
Signature Algorithm: sha1WithRSAEncryption
cf:66:95:18:8b:a3:73:e7:04:a8:fa:16:f3:62:60:4a:26:f1:
b5:37:b3:cd:7a:d4:9d:63:3f:a1:ee:52:30:29:9e:7a:b2:e7:
ba:a0:f9:bf:4f:95:63:63:bb:a9:cf:c5:b9:18:bd:6a:e5:82:
cd:3a:bf:37:ea:9c:57:bc:d8:20:d8:be:1a:8c:f5:00:9e:ad:
c4:66:d3:60:92:dd:22:66:61:88:49:0c:05:72:05:03:9d:82:
78:2f:9e:9c:f3:8b:d7:96:b7:8b:4b:6c:40:0f:7a:cb:f9:77:
88:13:f7:74:f0:e7:31:2e:94:81:b9:d4:0a:7c:d1:1d:f3:8b:
4c:e7:ae:21:12:40:f9:6a:1f:7d:a8:96:dc:90:11:6a:44:d7:
fc:f5:98:a3:5b:bc:4f:51:ab:db:84:64:ad:69:e6:82:bd:d9:
65:7a:44:43:65:8b:69:a7:01:8c:94:0d:4b:c3:be:29:ef:81:
a9:80:0c:33:46:d7:37:be:4c:9a:e0:bb:3f:15:9e:dd:ef:f4:
7f:70:e9:0b:5f:e3:18:a7:a4:80:8b:e1:ac:1c:46:33:e7:90:
02:11:43:61:15:4e:97:ea:c2:24:84:58:31:a8:37:b4:84:bf:
c0:70:a0:95:f9:64:c9:d2:94:86:5c:21:5d:51:b3:c6:b0:f4:
02:cb:77:24
In particular, notice these:
X509v3 CRL Distribution Points:
URI:http://crl.usertrust.com/USERTRUST-ServerAuthentication.crl
URI:http://www.utnsecurity.com/USERTRUST-ServerAuthentication.crl
Those are the CRL's (for this particular certificate), and you can visit them with a regular browser to see what the problem is! Note: some certificates use OCSP for revocation instead, so look for OCSP and CRL in the output.
First off you should check the MSDN documentation about how to validate signed binaries here. The error responce will be much more informative.
This blogger has a workaround, and if your having issues with the revokation server for your own keys, you will know if it's been revoked :). Also, as this key is expired now it may not be a big deal to configure this setting.
If you post the detailed error codes I can look at it a bit more but this should work for you for now.
Certificate signing is not dependent on checking for certificate revocation, only verification is. This sounds like there was a temporary network glitch when you were verifying the certificates. Is this problem repeatable?
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.
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.
Here I have a question about the principle of SignedXml.CheckSignature.
As we know, if we call the function with verifySignatureOnly = false, it can verify the certificate.
[ComVisibleAttribute(false)]
public bool CheckSignature(
X509Certificate2 certificate,
bool verifySignatureOnly
)
But how can it verify?
According to my understanding, certificate should be a public key encrypted by CA private key. so CheckSignature can get the CA public key, then decrypt the certificate?
I want to know how it works. Hope some one can help.
It uses windows certificate store to build a certificate chain up to trusted root authority. When it is building the chain the method also verifies revocation status of the certificates (usually from CRLs of all authorities in the chain) to check if any of the certificates in the chain are still valid.
If there are links to OCSP in the certificates then the method could prefer to check OCSP status of these certificates but it depends on OS you are using (I think Win Xp didn't use OCSP but win 7+ does it by default).
If any of the checks the method performs fails, i.e. CRL not available or chain could not be built to a trusted root authority or certificate is revoked, then method returns false.
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.