[lug] Understanding a SSL/TLS Certificate Issue

[David Stearns]

Some in-line responses just to close to loop.

On Thu, Jun 18, 2020 at 4:37 PM Jed S. Baer <blug at jbaer.cotse.net> wrote:

> Thanks for that, but I'm having trouble following it. (Perhaps due in
> part to chronic insomnia)
>
> On Thu, 18 Jun 2020 14:43:44 -0600
> David Stearns wrote:
>
> > First easy thing to check, make sure you system time is correct.
>
> With ntp, that's a given.
>
> > My investigation is based on the TLS chain from 443 on www.cotse.net.
>
> I noticed, using sslchecker.com, that it gave me different results using
> port 465 (SMTP/TLS).
>
> I'm uncertain why I would do this exercise, since the 3 certs are
> apparently being sent during the SMTP/TLS connection, and I can view the
> dates in wireshark. (And, in fact, that's what I did.)
>

Wireshark is doing the same things openSSL does here. Either works for this.


>
> > For this chain, the root CA (identified by finding the issuer for the
> > first intermediate cert in the chain supplied by the server) is C = US,
> > ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN =
> > USERTrust RSA Certification Authority. On my system, running fairly
> > recently updated Arch linux, that CA has a validity
> > "Not After : Jan 18 23:59:59 2038 GMT".
> >
> > Looking at the rest of the intermediates and server cert, supplied as
> > part of the connection setup, they all have expires after today as well.
> >
> > Server (leaf) cert: Not After : Apr 17 23:59:59 2021 GMT
> > Intermediate 1: Not After : Dec 31 23:59:59 2030 GMT
> > Root (on my system): Not After : Jan 18 23:59:59 2038 GMT
>
> I would infer from that, that sslchecker.com is giving a bogus result.
> (And, what I'm seeing in the wireshark capture is irrelevant somehow.)
>

Guessing this is because I was checking against 443, and sslchecker was
testing against 465?


>
> > $ openssl s_client -connect www.cotse.net:443 | openssl x509 -out
> > chain.pem -CA ~/UserTrustRoot.pem
>  [snip]
> > unable to load certificate
> > 140107587052864:error:0909006C:PEM routines:get_name:no start
> > line:crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE
> > ^C
>
> Just ignore that part? ctrl-c and you don't use chain.pem in what
> follows. Is that a throwaway file? I recall seeing /dev/null in some
> stuff I was looking at earlier.
>

Overzealous copy/paste on my part. Was supposed to start at the next
openssl command. That was me misremembering openssl's options.


>
> > From this, we can see that the issuer for the first intermediate is
> > "CN = USERTrust RSA Certification Authority".
> >
> > I checked this against /etc/ssl/certs/ca-certificates.crt (your mileage
> > may vary depending on your distro and client application, for example
> > Java is notorious for maintaining their own CA store, and ignoring the
> > system CA's).
> >
> > I extracted the UserTrust RSA CA from  ca-certificates.crt (using vim,
> > just searched for "USERTrust RSA" and copied it into a new file), and
> > check the validity time using openssl:
>
> ca-certificates.crt, on my system, is all binary, except for begin/end
> tags, so there's no way to search for a string. I don't see how this ties
> in to the next step, since it uses UserTrustRoot.pem.
>

Dang, mine has comments before each cert, so I can search. You can use
something like "awk -v cmd='openssl x509 -noout -subject' '
    /BEGIN/{close(cmd)};{print | cmd}' <
/etc/ssl/certs/ca-certificates.crt"  to print out which ones are in the
bundle, a start at least. There's probably a better way of extracting a
single cert by subject, but I don't know it off hand.


> > [craisis at craisis-p1 ~]$ openssl x509 -in UserTrustRoot.pem -text -noout
>
> Okay, this is the UserTrustRoot.pem UserTrustRoot.pem from the first
> command then?
>

No, that was the CA I copied out of my ca-certificates.crt that matched the
"USERTrust RSA Certification Authority" subject, I copied the cert,
including BEGIN/END lines into a new file.


> Since you previously mentioned that the chain needs to connect to a
> trusted cert in the local trust store. I assume that's
> /etc/ssl/certs/ca-certificates.crt, which could well simply be too old on
> my machine.
>

Yep, that's what I've seen before with these symptoms, but my other email
addresses what actually happened here, as a best guess.


>
> > If, on your system, the room expired earlier, then your
> > ca_certificates.crt file is out of date (or your systems/applications
> > equivalent CA store).
>
> # ls -o /etc/ssl/certs/ca-certificates.crt
> -rw-r--r-- 1 root 233394 Jan  9  2019 /etc/ssl/certs/ca-certificates.crt
>
> Hmmm. / isn't mount noatime, and surely that file gets accessed a lot. I
> actually expected it to be older. I'll give update-ca-certificates a try,
> but I suspect it won't matter.
>

By default that'll be ctime, right?

If you want atime to be shown, you'd need "ls -o --time=atime
/etc/ssl/certs/ca-certificates.crt", at least on my system.

-DS


> > Hope this helped.
>
> I'm trying to get there.
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20200618/9e181df6/attachment.html>