For example - let's take jks which contains Comodo CA root cert, few intermediate certs and own server signed cert:
# keytool -list -keystore akira.jks
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 5 entries
comodoutnsgcca, Jan 16, 2014, trustedCertEntry,
Certificate fingerprint (MD5): C7:1E:D8:79:91:4C:01:AC:ED:ED:00:30:4C:47:F0:E4
akira, Jan 16, 2014, PrivateKeyEntry,
Certificate fingerprint (MD5): A6:90:2D:8A:0E:4B:A3:0A:B5:50:9A:E3:F9:B8:E5:AC
essentialsslca_2, Jan 16, 2014, trustedCertEntry,
Certificate fingerprint (MD5): B5:1A:6D:2D:44:CC:72:D6:C6:2A:1B:97:5A:18:3D:91
utnaddtrust, Jan 16, 2014, trustedCertEntry,
Certificate fingerprint (MD5): 55:07:0F:1F:9A:E5:EA:21:61:F3:72:2B:8B:41:7F:27
addtrustexternalcaroot, Jan 16, 2014, trustedCertEntry,
Certificate fingerprint (MD5): 1D:35:54:04:85:78:B0:3F:42:42:4D:BF:20:73:0A:3F
How can I see exactly viewing cert's entry - that it require other cert in chain?
If I run -list with -v option - I see a lot of info like "Extensions", "#1: ObjectId" and so on.
So - which one line there describes the dependencies?
So, here is an answer:
# openssl s_client -connect localhost:8443
CONNECTED(00000003)
depth=4 /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/OU=Domain Control Validated/OU=Hosted by LeaderTelecom Ltd./OU=Free SSL/CN=akira.setevoy.kiev.ua
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=EssentialSSL CA
1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=EssentialSSL CA
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO Certification Authority
2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO Certification Authority
i:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN - DATACorp SGC
3 s:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN - DATACorp SGC
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
4 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
Here is full chain - from local signed cert (CN=akira.setevoy.kiev.ua) till root CA - (CN=AddTrust External CA Root).
s here is "subject" - "name" of cert and i is issuer - who issued this cert.
So Root have name AddTrust External CA Root and it's issued by AddTrust External CA Root.
Other way - use online tools like SSL Checker.
Related
I have 3 certificates rootca.pem, intermediateca.pem and server.pem
Openssl verify intermediateca by root is fine
openssl verify -verbose -CAfile rootca.pem intermediateca.pem
intermediateca.pem: OK
Server certificate, signed by intermediate - verification failed
openssl verify -verbose -CAfile rootca.pem -untrusted intermediateca.pem server.pem
CN = 2ip.ru
error 20 at 0 depth lookup: unable to get local issuer certificate
error server.pem: verification failed
I check hash subject-issuer of rootca intermediateca and intermediateca server. hash correct
I paste my certificate chain here
The Authority Key Identifier (AKI) is messed up in the certificates, which causes it to fail to build the trust path. Both the leaf certificate and the intermediate certificate have the AKI point to the root certificate:
# leaf
Issuer: C = RU, O = JSC Sberbank-AST, CN = int_ca
AKI: keyid:6C:C5:5B:22:4B:2D:CA:EC:C1:15:03:F6:5D:AD:C4:E8:4C:1D:06:89
# intermediate
Issuer: DC = ru, DC = sberbank-ast, CN = sberbank-ast-SUN-CA
AKI: keyid:6C:C5:5B:22:4B:2D:CA:EC:C1:15:03:F6:5D:AD:C4:E8:4C:1D:06:89
As can be seen, both leaf certificate and intermediate certificate wrongly claim to be issued by the same CA based on the Authority Key Identifier, while they correctly claim to be issued by different CA using the Issuer field.
But not only the Issuer field must match the Subject field of the issuer, the Authority Key Identifier must match the Subject Key Identifier of the issuer. While this is true for the relation between intermediate CA and root CA it is not true for the relation between leaf certificate and intermediate CA - and thus verify fails here.
Important Note: The method of validating certificates in my question below is incorrect, and will result in both false positives and false negatives. See my answer for the correct method.
I'm in the process of testing a tool I wrote to test all of the certificates in our environment, and I've run into an issue where OpenSSL doesn't seem to recognize a particular GoDaddy root certificate.
The error text:
$ openssl verify -CAfile bundle.txt cert.txt
cert.txt: C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", CN = Go Daddy Root Certificate Authority - G2
error 2 at 2 depth lookup:unable to get issuer certificate
But that certificate is definitely in both /etc/pki/tls/certs/ca-bundle.crt and ca-bundle.trusted.crt. I've manually verified that the Issuer and Subject keys in the x509v3 extensions match up back to KeyID D2:C4:B0:D2:91:D4:4C:11:71:B3:61:CB:3D:A1:FE:DD:A8:6A:D4:E3 in the trusted bundles.
Am I missing something?
Certificate details:
Certificate:
Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=http://certs.godaddy.com/repository/, CN=Go Daddy Secure Certificate Authority - G2
X509v3 Subject Key Identifier:
28:3C:0E:1A:82:3E:7F:22:A6:DD:22:8C:45:78:BF:F6:40:47:4F:8A
X509v3 Authority Key Identifier:
keyid:40:C2:BD:27:8E:CC:34:83:30:A2:33:D7:FB:6C:B3:F0:B4:2C:80:CE
Bundle1:
Subject: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=http://certs.godaddy.com/repository/, CN=Go Daddy Secure Certificate Authority - G2
Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2
X509v3 Subject Key Identifier:
40:C2:BD:27:8E:CC:34:83:30:A2:33:D7:FB:6C:B3:F0:B4:2C:80:CE
X509v3 Authority Key Identifier:
keyid:3A:9A:85:07:10:67:28:B6:EF:F6:BD:05:41:6E:20:C1:94:DA:0F:DE
Bundle2:
Subject: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2
Issuer: C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certification Authority
X509v3 Subject Key Identifier:
3A:9A:85:07:10:67:28:B6:EF:F6:BD:05:41:6E:20:C1:94:DA:0F:DE
X509v3 Authority Key Identifier:
keyid:D2:C4:B0:D2:91:D4:4C:11:71:B3:61:CB:3D:A1:FE:DD:A8:6A:D4:E3
Trusted:
Subject: C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certification Authority
X509v3 Subject Key Identifier:
D2:C4:B0:D2:91:D4:4C:11:71:B3:61:CB:3D:A1:FE:DD:A8:6A:D4:E3
X509v3 Authority Key Identifier:
keyid:D2:C4:B0:D2:91:D4:4C:11:71:B3:61:CB:3D:A1:FE:DD:A8:6A:D4:E3
DirName:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
serial:00
Edit
To add to the WTFery in play, opening a connection to the server in question using openssl s_client shows the certificate verifying just fine.
$ openssl s_client -servername www.foo.com -connect www.foo.com:443
Certificate chain
0 s:/OU=Domain Control Validated/CN=*.foo.com
i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
2 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
...yadda yadda yadda...
Verify return code: 0 (ok)
The naming of the openssl verify flags can be a bit counter-intuitive, and none of the documentation I found does much to address that. As x539 touched on I was using the -CAfile option incorrectly, and additionally I was missing the -untrusted option to specify the intermediate certificates.
I've found that the reason that the validation passed for most certificates is that most CAs have begun including the root certificate in the CA bundle, and the -CAfile option essentially defines what should comprise the trusted portion of the chain, including the root certificate. It was in the case that the intermediate bundle did not contain the root that my initial, incorrect method of validation failed.
Now I was under the misconception that -untrusted implied something like "never use these certificates!", but is rather intended to specify a chain of non-trusted certificates that leads back to a root in the "trusted" -CAfile bundle.
So the correct way to validate a certificate by using its intermediate certificate[s] and a trusted root bundle is:
openssl verify -CAfile /etc/pki/tls/certs/ca-bundle.crt -untrusted bundle.crt certificate.crt
If you specify -CAfile openssl only checks the given file for issuers, which in your case probably only contains the intermediate Certificates.
I have a newly purchased GeoTrust domain certificate and a matching CA file and would like to verify with openssl.
openssl verify -verbose -purpose any
-CAfile /full/path/sub.domain.com-geotrust.crt /full/path/sub.domain.com.crt
From this page: https://secure.marumoto.us/motowiki/tiki-index.php?page=Verify+a+Certificate+Chain
The issuer of each certificate in the chain should match the subject of the next certificate in the chain. For example the issuer of myserver.mydomain.com.cert should match the subject of myintermediate_ca.cert, and the issuer of myintermediate_ca.cert should match the subject of myroot_ca.cert. You can use the following command to view a certificate in .pem or base64 format.
From
openssl x509 -text -in sub.domain.crt and
openssl x509 -text -in sub.domain-geotrust.crt (CA root file)
sub.domain.com
Subject: OU=GT44865949,
OU=See www.geotrust.com/resources/cps (c)15,
OU=Domain Control Validated - QuickSSL(R),
CN=sub.domain.com
Issuer:
commonName = GeoTrust DV SSL CA - G4
organizationalUnitName = Domain Validated SSL
organizationName = GeoTrust Inc.
countryName = US
Intermediate:
Subject:
commonName = GeoTrust DV SSL CA - G4
organizationalUnitName = Domain Validated SSL
organizationName = GeoTrust Inc.
countryName = US
Issuer:
commonName = GeoTrust Global CA
organizationName = GeoTrust Inc.
countryName = US
Root:
Subject:
commonName = GeoTrust Global CA
organizationName = GeoTrust Inc.
countryName = US
Issuer:
organizationalUnitName = Equifax Secure Certificate Authority
organizationName = Equifax
countryName = US
It appears my Issuer and Subject fields are matching up properly but I am getting the following error with openssl:
error 20 at 0 depth lookup:unable to get local issuer certificate
/full/path/sub.domain.com.crt: /OU=GT44865949/OU=See www.geotrust.com/resources/cps (c)15/OU=Domain Control Validated - QuickSSL(R)/CN=sub.domain.com
error 20 at 0 depth lookup:unable to get local issuer certificate
I'd like to use this and a similar GeoTrust certificate at a different subdomain to do two-way SSL authentication at a restful web url but the certs won't verify with 'openssl verify' against the CA files issued with them. Any suggestions much appreciated.
As per discussion, it is a matter of allowing openssl to see the entire validation chain: with both GeoTrust CA intermediates and the root.
openssl should be run with CADir parameter containing all the 3 CAs in PEM format. The actual root for GeoTrust can either be extracted from your favourite browser, or here: filedropper.com/geotrustglobalca.
When you configure your actual server, just make sure that you send the intermediates on the Server Hello, some sites don't do that and break clients that do not have the intermediates cached.
Following on from RomanK's answer, you can get the GeoTrust Global CA from their root certificate store. They have a number of primary/universal/global certificates listed there, so make sure to get the right one for your intermediate certificate.
As per the chain display, the root certificate is not self signed . Its shows its issued by Equifax. Openssl will continue giving the error "local issuer certificate not found" till it gets a self signed root certificate. When it comes across a root self signed then it's able to verify the certificate chain as complete.
Suppose a PKI hierarchy like below.
root CA ==> inter-1 CA ==> user-1
\
\======> inter-2 CA ==> user-2
My question is: does root CA also need to periodically download CRL from its children: inter-1 and inter-2?
Since user-1 and user-2 can authenticate each other, if user-2's certificate is revoked by inter-2, inter-2 should let root know and then propagate to inter-1 and user-1, right?
If so, it seems quite complicated. Is there any tool to use for managing the revocation logic? Thanks a lot.
No, revocation of certificate is not propagated across the CA tree. Each CA (root and intermediate in your case) is responsible of the publication of the CRL containing the list of only the revoked certificates that were issued by this CA.
An example:
Root CA publishes a CRL for the certificates issued by Root CA: inter-1 CA and inter-2 CA. Root CA is not aware of the user-1 and user-2 certificates or their revocation status.
inter-1 CA (resp inter-2 CA) publishes a CRL containing the list of revoked certificates issued by inter-1 CA (resp inter-2 CA) and only these certificates.
CRL Root CA CRL inter-1 CA
^ ^
| |
root CA ==> inter-1 CA ==> user-1
|
| CRL inter-2 CA
| ^
\ |
\======> inter-2 CA ==> user-2
if user-1 certificate is revoked, this certificate (actually its serial number) will only appear in the CRL published by inter-1 CA.
When someone wants to check the validity the user-1 certificate the process is as follows:
build the certificate chain between the certificate and a trusted CA: user-1 / inter-1 CA / root CA
fetch the CRL for the first certificate in the list
verify the signature of the CRL
check the status of the first certificate in the list against this CRL
if the status is not revoked, remove the certificate from the list and go to 2. otherwise fail
if the list contains only the trusted CA, check the chain of signature of the certificates (a certificate must be signed by the following certificate in the list)
if all signature have been checked and are valid, the user-1 certificate is valid.
Note that validating the CRL signature can trigger a validation of another certificate chain : i.e. this algorithm can be recursive. Actually the X.509 certificate validation algorithm is (very) complex and I just summarize the principles here.
I have a certificate (for example this one) saved in a local file. Using openssl from the command line, how can I display the entire chain from this certificate to a root CA? I tried:
openssl verify -verbose -purpose sslserver -CApath /etc/ssl/certs InCommonServerCA.txt
and got this confusing output that only seems to show the leaf certificate:
InCommonServerCA.txt: C = US, O = Internet2, OU = InCommon, CN = InCommon Server CA
error 26 at 0 depth lookup:unsupported certificate purpose
OK
Any ideas?
For local certificates you can see the subject and direct issuer using:
openssl x509 -noout -subject -issuer -in test.crt
subject= /C=US/ST=Utah/L=SLC/O=My Organization/CN=my.server.com
issuer= /C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2
But that doesn't indicate if the certificate includes any intermediate certificates or the full chain of trust. The verify command you listed will fail if your system cannot validate the chain (example: you are missing an intermediate certificate or the root is not trusted), showing an error message like:
error 20 at 0 depth lookup:unable to get local issuer certificate
If you want to verify each entry in the file, you can use this script to show the chain of trust for a local certificate:
~ % ssl_chain.sh google.crt
0: subject= /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
issuer= /C=US/O=Google Inc/CN=Google Internet Authority G2
1: subject= /C=US/O=Google Inc/CN=Google Internet Authority G2
issuer= /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2: subject= /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
issuer= /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
google.crt: OK
If you want to verify the chain and purpose, your openssl command is correct. The "OK" indicates the chain verifies. The error indicates there is an issue with that certificate being used for an sslserver purpose. It looks like your certificate is a CA cert, not a leaf cert.
What kind of chain info are you trying to display? You could look at the subject and issuer fields to show chaining. The verify command you used above proves that the one cert signed the other cert.