[GTALUG] SSL Server Certificate

Jamon Camisso jamon.camisso at utoronto.ca
Mon Jul 16 23:35:34 EDT 2018


On 16/07/18 21:16, Peter King via talk wrote:
> I'm puzzled about how to set up server certificate validation in getting
> my email, which isn't surprising given that I understand next to nothing
> about the way certificates work.
> 
> Here's the particular issue.  I want to check over ssl/tls to see that the
> server certificate is valid, and that it matches a fingerprint I have for
> it.  So, I know just enough to get the certificate from the server, in this
> case from Google:
> 
>   $ openssl s_client -connect pop.gmail.com:995 -showcerts > ~/gmail.openssl.txt
> 
> By inspection I can see that the certificate is provided by GlobalSign.  So
> I do a quick check:
> 
>   $ ls -l /etc/ssl/certs/GlobalSign*

s_client doesn't behave exactly as you expect. It needs explicit
instructions to send a -servername when you use -connect. What you're
actually getting if you look carefully is the imap.gmail.com certificate.

Without servername:

openssl s_client -connect pop.gmail.com:993 2>&1 |openssl x509 -noout
-subject -fingerprint
subject=C = US, ST = California, L = Mountain View, O = Google LLC, CN =
imap.gmail.com
SHA1 Fingerprint=BD:94:41:8C:64:D9:B1:43:49:3A:98:68:57:12:51:A3:3C:52:BF:86


With -servername:
openssl s_client -servername pop.gmail.com -connect pop.gmail.com:993
2>&1 |openssl x509 -noout -subject -fingerprint
subject=C = US, ST = California, L = Mountain View, O = Google LLC, CN =
pop.gmail.com
SHA1 Fingerprint=59:B1:5F:6A:BF:F2:28:D9:4A:FC:89:DB:75:FD:7D:65:EC:82:AD:E7


> Lo and behold, there is an obvious hit: GlobalSign_Root_CA.pem.  So I put
> that down as the certificate for the server.

This ends up being the incorrect CA certificate. If you take a look at
the full openssl s_client output, you'll see the chain listed right at
the beginning, including the identity of the authority's certificate:

openssl s_client -servername pop.gmail.com -connect pop.gmail.com:993
.....
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=pop.gmail.com
   i:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
 1 s:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
   i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign

0 is the certificate from the server itself, with the subject and CN
matching pop.gmail.com. The 's' field is the subject field of the
certificate. The 'i' field is the issuer field.

Likewise, 1 is the intermediate certificate that Google uses to sign
their public-facing certificates, which itself is the public component
of their private intermediate certificate.

That intermediate of Google's is signed by GlobalSign using the latter's
root R2 certificate. Their root R2 is self-signed, and there's the
entire chain.

So the root that you're looking for is described in that last field of
the intermediate certificate 'OU=GlobalSign Root CA - R2'. Take a look
in /etc/ssl/certs/ and you'll see a file: GlobalSign_Root_CA_-_R2.pem

To see how the chain all lines up, look at how the issuer of one is the
subject of the next.

I've saved Google's pop & the intermediate to separate files to make it
easier. Also note that openssl 'hash' operates on the subject, so it
isn't anything special, it is just easier to eyeball when checking
things as opposed to reading a subject and missing something like 'R2'
for example ;)


---- server certificate:
openssl x509 -in pop.gmail.com.pem -noout -subject -issuer -issuer_hash


subject=C = US, ST = California, L = Mountain View, O = Google LLC, CN =
pop.gmail.com
issuer=C = US, O = Google Trust Services, CN = Google Internet Authority G3
6a909d98


---- intermediate Google G3 certificate:
openssl x509 -in globalsign-intermediate.pem -noout -subject -issuer
-hash -issuer_hash

subject=C = US, O = Google Trust Services, CN = Google Internet Authority G3
issuer=OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
6a909d98
4a6481c9


---- globalsign root R2 certificate
openssl x509 -in /etc/ssl/certs/GlobalSign_Root_CA_-_R2.pem -noout
-subject -issuer -hash
subject=OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
issuer=OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
4a6481c9


See how subjects & hashes line up? Note the G3, R2 bits don't mean
anything special in terms of protocols, they're just labels that Google
& GlobalSign use internally to keep track of their different
certificates. Every intermediate & root CA do these however they like -
just look through /etc/ssl/certs and check subject names to see the variety.

Hope this helps with troubleshooting.

Cheers, Jamon


More information about the talk mailing list