Wget not working for https

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:
I ran this command:
wget https://dl.eff.org/certbot-auto
It produced this output:
wget: not an http or ftp url: https://dl.eff.org/certbot-auto
My web server is (include version):

The operating system my web server runs on is (include version):
Trying to install on my NAS which is some version of linux.
My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don’t know):

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):

1 Like

What kind of device are you running? And what does wget --version output?

I’m guessing a Zyxel NAS looking at the TLD of your domain. Which would probably make your wget not a wget at all, but a BusyBox function which not always has TLS(/SSL) support build in. It seems your BusyBox was compiled without TLS support.

My own Zyxel NAS does have curl. However, its /etc/ssl/certs/ directory is empty… Therefore, it will give an error complaining about not able to get a local certificate to verify the connection.

With the following command you can download certbot-auto:

curl -o certbot-auto https://dl.eff.org/certbot-auto

If it also complains about not being able to verify the SSL certificate, you can add the -k option. However, your download is then insecure. If you do this, you should check the validity of certbot-auto:

~ # sha256sum certbot-auto 
3b03c28a3d231e380c5b8616cfb6bcae15c24d507ae86bccaebe4420dc0613d4  certbot-auto
~ # 

The long value should be exactly the same.


In one indication of the limitations of this verification strategy, the correct value has changed since yesterday (!) due to the release of Certbot 1.2.0.

The correct value is now 0b2548809531fa447352718d54b6271deffdb7d3be24762b01c801ee8f22ffbc and will continue to change regularly in the future as a result of ongoing Certbot releases.

1 Like

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