Defect #35979


SSL Bad certificate

Added by sacha b about 2 years ago. Updated over 1 year ago.

Website (
Target version:
Start date:
Due date:
% Done:


Estimated time:
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

Actions #1

Updated by Holger Just about 2 years 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.

Actions #2

Updated by Jan Niggemann ( team member) over 1 year ago

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

See Holgers comment, closing this one.

Actions #3

Updated by Vincent Caron over 1 year 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