How to get the Root CA Certificate Fingerprint using openssl

Question

By using the following command, I can verify the sha1 fingerprint of the presented certificate:

$ openssl s_client -connect hooks.slack.com:443 -showcerts < /dev/null 2>/dev/null   | openssl x509 -in /dev/stdin -sha1 -noout -fingerprint
SHA1 Fingerprint=AB:F0:5B:A9:1A:E0:AE:5F:CE:32:2E:7C:66:67:49:EC:DD:6D:6A:38

But what if I want to get the fingerprint of the Top Level Signing Authority?

$ openssl s_client -connect hooks.slack.com:443 < /dev/null 2>/dev/null
CONNECTED(00000003)
---
Certificate chain
 0 s:/C=US/ST=California/L=San Francisco/O=Slack Technologies, Inc/CN=*.slack.com
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3
 1 s:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA <- **I WANT THIS SHA1**

In the case that I want to verify this against a Java keystore, to check definitively if it contains the same CA.

geotrustglobalca, 18-Jul-2003, trustedCertEntry,
Certificate fingerprint (SHA1): DE:28:F4:A4:FF:E5:B9:2F:A3:C5:03:D1:A3:49:A7:F9:96:2A:82:12

Since "geotrustglobalca" and "/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA" aren't really comparable.

Answer 1

In a similar situation with a let's encrypt certificate on a shared hosting solution I had success with specifying the servername parameter:

openssl s_client -connect hooks.slack.com:443 -servername hooks.slack.com -showcerts < /dev/null 2>/dev/null   | openssl x509 -in /dev/stdin -sha1 -noout -fingerprint

Answer 2

I'm not sure this directly answers your question, but if the server presents the root certificate as part of the chain (this is optional, so it may not), you can use the -showcerts option to show all of them.

I put this together previously (which hopefully someone can improve upon) in order to get the thumbprint for each of the certificates. You can play with the arguments to openssl x509 at the end to get different information if you need.

echo "" | openssl s_client -showcerts -connect eistest.mtsu.edu:443 2>&1 |\ 
sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p;/-END CERTIFICATE-/a\\x0' |\ 
sed -e '$ d' |\ 
xargs -0rl -I% sh -c "echo '%' | openssl x509 -subject -issuer -fingerprint -noout"

Echoing a null string to openssl s_client keeps it from waiting for the connection to time out. The first sed will output only the PEM formatted certificates, separated by a NUL character.

Answer 3

Since "geotrustglobalca" and "/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA" aren't really comparable.

I'll wander into the pool with an answer for "X.509 certificate equivalency" since its not readily apparent or easy to come by.

First, you should be careful comparing certificates for equality. If <certificate bits 1> == <certificate bits 2>, then you can say they are the exact same certificate and equal. However, the converse does not hold.

To understand the converse, you need to know two things. First, CAs sometimes re-issue a certificate with nearly the same parameters. Based on the Subject Name, they are equivalent; but based on the bits they are not equal. Some CAs have done this in the past to bump from SHA-1 to SHA-256.

The second thing to understand is, what are the important bits so you can determine if certificates are equivalent. The IETF does not have an X.509 validation document. The closest is RFC 4158: Internet X.509 Public Key Infrastructure: Certification Path Building, mixed with some other docs, like Issuing rules (which are not the same as Validation rules).

According to RFC 4158, you can uniquely identify a certificate with either:

• {Issuer DN, Serial Number} pair
• {Authority Key identifier (AKID), Subject Key identifier (SKID)} pair

The corner case of a CA re-issuing a Root CA results in:

1. the hash changes
2. the serial number changes
3. the public key remains
4. the Distinguished Name remains

Item (3), the public key remains, is significant because it means neither the Authority Key identifier (AKID) nor the Subject Key identifier (SKID) changes. Item (4), the Distinguished Name remains, is significant because its what many people use for the comparison (and its been the cause of many security bugs over the years).

In this case, the Key Identifiers will be the same, so you should consider accepting even though the serial number changed. (The serial number must change according to IETF and CA/B rules).

A very odd corner case that came up in public key pinning recently is, a server presents a Elliptic Curve certificate using domain parameters (the full expansion of p, g, Q, etc), but the client expects a named curve (like secp256r1). Should this key be accepted as equivalent? (The IETF says the certificate must use the named curve).

---

Given the above information, this information is useless in your comparison:

• "geotrustglobalca"

And this information is incomplete for your comparison:

• "/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA"

In this case, you should err on the side of caution and reject the comparison for equality or equivalence.