Bad server certificate trying to get to the top-level https://shibboleth.net from AWS or a zscaler address

mat houser mhouser at uwm.edu
Fri Feb 25 17:26:08 UTC 2022


FWIW I started noticing that a bunch of certs issued by Let's Encrypt
are being reported as expired by curl and openssl s_client on some
systems. The affected systems all appear to have been running for
quite some time without getting updated.

RHEL6 (eol Dec 2020 iirc) shows expired as does a "managed" Mac that
hasn't been updated in a very long time. Anything that's been kept up to
date does not show those certificates as expired. My suspicion is that
anything that hasn't been updated since the Let's Encrypt root cert
expired back in September might be relying on an obsolete CA bundle or
something, and updating the client OS should probably fix it.

-- 
-------------
mat:houser
mhouser at uwm.edu
uwm:uits:iam-support
-------------

On Fri, 25 Feb 2022, Peter Schober wrote:

* Cantor, Scott <cantor.2 at osu.edu> [2022-02-25 14:35]:
> Even the cert on www.shibboleth.net, which is not run by us, is still valid.

That server has a misconfigured cert chain, though, by producing only
the leaf/server certificate but not the intermediate one.
(SSL certificate problem: unable to get local issuer certificate)

But while JISC should fix that ASAP[1] that wouldn't cause an expired
certificate error either, of course...

-peter

[1] The reason this hasn't caused sufficient problems in practice is
that browsers cache intermediates, it seems, and that most browsers
will know the (missing) intermediate from other, correctly configured,
servers. It's still wrong, of course.


More information about the users mailing list