Defect #35979

SSL Bad certificate

Added by sacha b 10 days ago. Updated 10 days ago.

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


Category:Website (
Target version:-
Resolution: 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 10 days 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.

Also available in: Atom PDF