Wget cannot verify certificate

So I’ve just sitched one of our servers to a Let’s Encrypt cert. And It is mostly working, except for one of the installers, that uses wget on windows.

–2016-07-05 13:50:04-- https://yyy.com/updater.rb
Resolving yyy.com (yyy.com)… x.x.x.x
Connecting to yyy.com (yyy.com)|x.x.x.x|:443… connected.
ERROR: cannot verify yyy.com’s certificate, issued by ‘CN=Let’s Encrypt Authority X3,O=Let’s Encrypt,C=US’:
Unable to locally verify the issuer’s authority.
To connect to yyy.com insecurely, use `–no-check-certificate’.

I am not going to be the idiot that does the ‘–no-check-certificate’.

Interestingly, after opening up https://yyy.com/updater.rb in MSIE, wget works as expected. I figure MSIE is downloading the intermediate certificate, and wget can’t.

If this is the case, is there any way to get windows to do that - downloading and storing the intermediate certificate - in the background? Certutil seems the most likely candidate, but **** it’s documentation.

Have you installed the certificate on your server with cert.pem or cert.pem+chain.pem or with fullchain.pem? Your server whould provide the intermediate to the client with the aid of chain.pem or fullchain.pem.

my nginx confiuration is using a fullchain.pem - with two certificates in it - which does match up with cert.pem & chain.pem.

So my server, at least, seems to be providing the intermediate. Just windows doesn’t like it until MSIE sees it.

You might want to try running something like https://www.ssllabs.com/ssltest/ to check if nginx is sending the intermediate. You could also see what’s getting sent by using openssl (openssl s_client -connect yyy.com:443)

Been there, got an A+. I ASSUME this is the relevant section -

Certification Paths
Path #1: Trusted

1 Sent by server
yyy.com
Fingerprint SHA1: ec25cffe918891483c60b2781cc12804496e425c
Pin SHA256: 9HZT76p7snrhyOcSxhGazi9WYCDLll6V1xPxiplb3rk=
RSA 2048 bits (e 65537) / SHA256withRSA

2 Sent by server
Let’s Encrypt Authority X3
Fingerprint SHA1: e6a3b45b062d509b3382282d196efe97d5956ccb
Pin SHA256: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
RSA 2048 bits (e 65537) / SHA256withRSA

3 In trust store
DST Root CA X3
Self-signed
Fingerprint SHA1: dac9024f54d8f6df94935fb1732638ca6ad77c13
Pin SHA256: Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys=
RSA 2048 bits (e 65537) / SHA1withRSA
Weak or insecure signature, but no impact on root certificate

Previous experience says SSL Labs will complain if I actually include the root cert, so if there is somthing wrong here I am not seeing it.

No it looks indeed good. There is also another website for a faster check for missing intermediates BTW: https://whatsmychaincert.com/

Wget needs a list of trusted certificates

  --ca-certificate=FILE       file with the bundle of CAs
  --ca-directory=DIR          directory where hash list of CAs is stored

On Linux distributions, it finds these in a default directory provided by another installed package. For instance on Debian and Ubuntu systems the list of trusted certificates is provided by the ca-certificates package. I'm not familiar with using wget on Windows but I'm guessing it's not able to use the list of trusted certificates provided by Windows, which is not in the same format.

I would recommend grabbing /usr/share/ca-certificates from a Debian or Ubuntu box if you have one, or if that's not practical, you can grab just the DST Root X3 and ISRG Root X1 certificates from Chain of Trust - Let's Encrypt and make your own ca-certificates file. Then pass the --ca-certificates flag to wget.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.