SSL Server Certificate
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 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
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
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 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
On Tue, Jul 17, 2018 at 08:25:25PM -0400, Peter King via talk wrote:
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 <opengeometry@yahoo.ca>
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. -- William Park <opengeometry@yahoo.ca> On Mon, Jul 16, 2018 at 09:16:48PM -0400, 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*
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 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
--- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
On Mon, Jul 16, 2018 at 11:38:38PM -0400, William Park via talk wrote:
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 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
On 17/07/18 20:38, Peter King via talk wrote:
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
participants (3)
-
Jamon Camisso -
Peter King -
William Park