[lug] Understanding a SSL/TLS Certificate Issue

[Jed S. Baer]

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.)

> 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.)

> $ 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.

> 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.

> [craisis at craisis-p1 ~]$ openssl x509 -in UserTrustRoot.pem -text -noout

Okay, this is the UserTrustRoot.pem UserTrustRoot.pem from the first
command then?

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. 

> 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.

> Hope this helped.

I'm trying to get there.