Defect #35979

SSL Bad certificate

Added by sacha b about 1 year ago. Updated 4 months ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:Jean-Philippe Lang% Done:


Category:Website (
Target version:-
Resolution:Invalid Affected version:



when you use:
wget -d <= KO
curl --output redmine-4.2.3.tar.gz <= OK

enyo|14:28:52|:/home/sacha# wget -4d DEBUG output created by Wget 1.21 on linux-gnu. Reading HSTS entries from /root/.wget-hsts URI encoding = « UTF-8 » Converted file name 'redmine-4.2.3.tar.gz' (UTF-8) -> 'redmine-4.2.3.tar.gz' (UTF-8) --2021-10-11 14:30:02-- Certificates loaded: 121 Résolution de (… Caching => Connexion à (||:443… connecté. Created socket 3. Releasing 0x0000564a662eebe0 (new refcount 1). Erreur : le certificat de « » n’est pas de confiance. Erreur : le certificat de « » n’est pas d’un émetteur connu. Erreur : le certificat de « » a expiré.

You an Usertrust chain expired since 2020 and the Gandi intermediate since last spring.

Kind regards


#1 Updated by Holger Just about 1 year ago

The provided intermediate certificate is the "Gandi Standard SSL CA 2" certificate. Its valid until 2024-09-11, i.e. about three years from now.

The provided chain does indeed send additional (expired) certificates. However, those should generally be ignored by your TLS client library as it can use its own trust store to validate the chain against its own (local) version of the "USERTrust RSA Certification Authority" certificate. The one shipped with Chrome and Firefox is valid until 2038-01-18. Here, the clients are able to verify a complete trusted certificate chain.

With that being said, some older TLS client libraries (most prominently OpenSSL < 1.1.1) do not attempt to try to validate alternate chains and abort the TLS connection. To fix this, you could (and should) try to update the TLS client library used by your wget.

#2 Updated by Jan Niggemann ( team member) 8 months ago

  • Status changed from New to Closed
  • Resolution set to Invalid

See Holgers comment, closing this one.

#3 Updated by Vincent Caron 4 months ago

It's true that the HTTPS client should pick the valid issuer and ignore the invalid/exired one (`wget` being known for this long-standing bug, even in 1.21 from 2021/01), but still I think's HTTPs server should not send intermediate CA certs which have expired a long time ago : says those 4 CAs are sent along '' cert :

  • Gandi Standard SSL CA 2 : OK (expires 2024/09/11)
  • USERTrust RSA Certification Authority : NOK (expired 2020/05/30, +2 years ago)
  • AddTrust External CA Root : NOK (expired 2020/05/30, +2 years ago)
  • UTN - DATACorp SGC : NOK (expired 2019/06/24, +3 years ago)

That's not a good admin pratice to bundle those 3 invalid CAs and I think a server-side fix would also help. The HTTPS server should only bundle the "Gandi Standard SSL CA" cert.

Also available in: Atom PDF