Discussion:
[GTALUG] SSL Server Certificate
Peter King via talk
2018-07-17 01:16:48 UTC
Permalink
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*

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

Then, I can get the fingerprint for it from the same file, like so:

$ openssl x509 -fingerprint -sha256 -noout -in ~/gmail.openssl.txt > gmail.fingerprint.txt

(Getmail uses sha256 as its preferred algorithm.) I take the fingerprint
from the file and use that to certify the server.


Thing is, the technique doesn't work. First I get an unhelpful error
message saying that the certificate, GlobalSign_Root_CA.pem, gives an
authentication error. Well, okay. If I take that out of the equation
I then get told that the fingerprint is wrong, but this time at least
I'm told what the correct fingerprint is -- and if I put the correct one
in all seems well.

The example above is about gmail, but I have the same problem with rogers
and other servers. Oddly, the Office365 servers work exactly as they
should.

Two questions, which most of you undoubtedly know the answer to:

[1] If the email gets fetched with the fingerprint, is there any need for
validating the server certificate?

[2] How can I find out what the correct server certificate is?
--
Peter King ***@utoronto.ca
Department of Philosophy
170 St. George Street #521
The University of Toronto (416)-978-3311 dept
Toronto, ON M5R 2M8
CANADA

http://individual.utoronto.ca/pking/

=========================================================================
GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC 36F5 1FE6 D32A 7587 EC42)
gpg --keyserver pgp.mit.edu --recv-keys 7587EC42
Jamon Camisso via talk
2018-07-17 03:35:34 UTC
Permalink
Post by Peter King via talk
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
$ 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
$ 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
Post by Peter King via talk
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
---
Talk Mailing List
***@gtalug.org
Peter King via talk
2018-07-18 00:25:25 UTC
Permalink
Thanks very much for the informative and detailed reply, Jamon. Following
your example, I've now managed to get server certificate validation and
ssl fingerprinting to work on Rogers, Office365, and Gmail (both pop and
imap). I'll have to learn someday the ins and outs of how it all works,
but I'm pleased to say that I'm up and running on all counts, and have now
officially switched from fetchmail to getmail. (But I'm hanging on to my
.fetchmailrc just in case.)

Thanks everyone for all the help and suggestions!
--
Peter King ***@utoronto.ca
Department of Philosophy
170 St. George Street #521
The University of Toronto (416)-978-3311 dept
Toronto, ON M5R 2M8
CANADA

http://individual.utoronto.ca/pking/

=========================================================================
GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC 36F5 1FE6 D32A 7587 EC42)
gpg --keyserver pgp.mit.edu --recv-keys 7587EC42
William Park via talk
2018-07-18 01:14:07 UTC
Permalink
Post by Peter King via talk
Thanks very much for the informative and detailed reply, Jamon. Following
your example, I've now managed to get server certificate validation and
ssl fingerprinting to work on Rogers, Office365, and Gmail (both pop and
imap). I'll have to learn someday the ins and outs of how it all works,
but I'm pleased to say that I'm up and running on all counts, and have now
officially switched from fetchmail to getmail. (But I'm hanging on to my
.fetchmailrc just in case.)
Why did you have to set up certificate for your machine? I have Yahoo
and Gmail accounts, and I download emails via fetchmail simply with
user/password, without installing certificates (may be it's already
setup by Slackware distro).
--
William Park <***@yahoo.ca>
---
Talk Mailing List
tal
William Park via talk
2018-07-17 03:38:38 UTC
Permalink
Off-tangent... Can someone do a talk on "SSL/TLS Certificate" for users,
sysadmin, and application programmers level? Like,
- how to create certificate
- what fields to populate when create certificate. It seems to
be sensitive to expiry date, certain fields, etc.
- how to install them, at server side and at client side.

I understand SSH private/public keys. But, for the life of me, I don't
understand SSL/TLS or OpenSSL package.
--
Post by Peter King via talk
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
$ 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
$ ls -l /etc/ssl/certs/GlobalSign*
Lo and behold, there is an obvious hit: GlobalSign_Root_CA.pem. So I put
that down as the certificate for the server.
$ openssl x509 -fingerprint -sha256 -noout -in ~/gmail.openssl.txt > gmail.fingerprint.txt
(Getmail uses sha256 as its preferred algorithm.) I take the fingerprint
from the file and use that to certify the server.
Thing is, the technique doesn't work. First I get an unhelpful error
message saying that the certificate, GlobalSign_Root_CA.pem, gives an
authentication error. Well, okay. If I take that out of the equation
I then get told that the fingerprint is wrong, but this time at least
I'm told what the correct fingerprint is -- and if I put the correct one
in all seems well.
The example above is about gmail, but I have the same problem with rogers
and other servers. Oddly, the Office365 servers work exactly as they
should.
[1] If the email gets fetched with the fingerprint, is there any need for
validating the server certificate?
[2] How can I find out what the correct server certificate is?
--
Department of Philosophy
170 St. George Street #521
The University of Toronto (416)-978-3311 dept
Toronto, ON M5R 2M8
CANADA
http://individual.utoronto.ca/pking/
=========================================================================
GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC 36F5 1FE6 D32A 7587 EC42)
gpg --keyserver pgp.mit.edu --recv-keys 7587EC42
---
Talk Mailing List
https://gtalug.org/mailman/listinfo/talk
---
Talk Mailing List
***@gtalug.org
https://gtalug.org/mailman/l
Peter King via talk
2018-07-18 00:38:06 UTC
Permalink
Post by William Park via talk
Off-tangent... Can someone do a talk on "SSL/TLS Certificate" for users,
sysadmin, and application programmers level? Like,
- how to create certificate
- what fields to populate when create certificate. It seems to
be sensitive to expiry date, certain fields, etc.
- how to install them, at server side and at client side.
I understand SSH private/public keys. But, for the life of me, I don't
understand SSL/TLS or OpenSSL package.
Seconded! (For obvious reasons.)
--
Peter King ***@utoronto.ca
Department of Philosophy
170 St. George Street #521
The University of Toronto (416)-978-3311 dept
Toronto, ON M5R 2M8
CANADA

http://individual.utoronto.ca/pking/

=========================================================================
GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC 36F5 1FE6 D32A 7587 EC42)
gpg --keyserver pgp.mit.edu --recv-keys 7587EC42
Jamon Camisso via talk
2018-07-18 02:49:42 UTC
Permalink
Post by Peter King via talk
Post by William Park via talk
Off-tangent... Can someone do a talk on "SSL/TLS Certificate" for users,
sysadmin, and application programmers level? Like,
- how to create certificate
- what fields to populate when create certificate. It seems to
be sensitive to expiry date, certain fields, etc.
- how to install them, at server side and at client side.
I understand SSH private/public keys. But, for the life of me, I don't
understand SSL/TLS or OpenSSL package.
Seconded! (For obvious reasons.)
I suppose I could give a talk at an upcoming meeting. If an organizer
wants to contact me offlist I'm sure we can arrange something.

Cheers, Jamon
---
Talk Mailing List
talk

Loading...