Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6229
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: The certificate of `` has expired

Sat May 30, 2020 7:02 pm

dickon wrote:
Sat May 30, 2020 6:43 pm
*Are* there any clouds over Cambridge today?

It's been gloriously sunny here all day...
Just checked and no, it does actually look quite lovely out there.

Posts: 9
Joined: Sun Feb 08, 2015 12:14 pm
Location: Tilburg, NL

Re: The certificate of `` has expired

Sat May 30, 2020 7:09 pm

Fixed for me. Thanks!
Mausy5043 - NL

User avatar
Posts: 1
Joined: Sat May 30, 2020 8:25 pm
Location: Anchorage, AK
Contact: Website Twitter

Re: [SOLVED] The certificate of `` has expired

Sat May 30, 2020 8:28 pm

Context and back story on this issue, as it may affect other upstream or downstream TLS upload/download workflows.

This is due to the expiration of the AddTrust root today. It means that some out-of-date TLS clients will treat the cert as untrusted (such as OpenSSL prior to 1.1.x)

This only affects non-modern TLS clients that can't follow multiple root-cert trust paths.

The remediations are basically to do one of these (or get the vendor to do it):

A) Remove the untrusted trust path from the cert on the server side, or

B) Upgrade the client to a modern one that can follows multiple trust paths, or

C) Disable cert trust checking on the client (not recommended, but might be temporarily necessary)

Good explainer here from Andrew Ayer, the SSLMate guy: ... expiration

Deliberately broken hostname for testing clients:

Check your server-side cert chain (and generate a new one if needed):
Just doing my undue diligence -

Forum Moderator
Forum Moderator
Posts: 3623
Joined: Wed Dec 28, 2011 11:45 pm

Re: [SOLVED] The certificate of `` has expired

Mon Jun 01, 2020 12:40 am

My understanding is it's a little more subtle than that.

GNUtls (used by apt and by wget on Debian/Raspbian, but NOT by wget on Ubuntu and NOT most web browsers) seems to be the main cause of issues here. There is a bug report at It's apparently been fixed but I suspect that will take some time to filter down to distros.

In the meantime apparently this issue can be worked around by the following

client side on Debian (and presumablly Raspbian) systems by editing /etc/ca-certificates.conf and adding "!" to the start of the line containing mozilla/AddTrust_External_Root.crt (apparently this doesn't work on Redhat systems though)

server side by removing the offending cert from the certificate chain

Return to “Advanced users”