[Wget] Unable to locally verify the issuer's authority

1. Error

This issue happens when I run the command wget https://github.com/docker/compose/releases/download/v2.10.2/docker-compose-linux-x86_64 in my Ubuntu WSL.

The completed error looks like below:

The extracted error is

>> connected.
>> ERROR: cannot verify objects.githubusercontent.com's certificate, issued by ‘CN=ospanel’:
>>   Unable to locally verify the issuer's authority.
>> ERROR: certificate common name ‘localhost’ doesn't match requested host name ‘objects.githubusercontent.com’.
>> To connect to objects.githubusercontent.com insecurely, use `--no-check-certificate'.

You can see there are basically four highlight errors above and many answers for each error if you google them. I had tried the below workarounds in WSL:

1. add --no-check-certificate to the wget command. For instance, wget --no-check-certificate https://github.com/docker/compose/releases/download/v2.10.2/docker-compose-linux-x86_64
2. use curl to download the file. For example curl https://github.com/docker/compose/releases/download/v2.10.2/docker-compose-linux-x86_64
3. upgrade wget and ca-certificate. sudo apt-get update && sudo apt-get install wget ca-certificate
4. …
5. …

Unfortunately, none of above solutions can fix issues occurs to my host. After the further investigation, I found that the issue is caused by DNS setting, but wget problem.

2. Investigation

In the error block, the target website is objects.githubusercontent.com. So let’s open the site ping.eu and input the target site URL to look up its DNS records.

The result will show what the correct DNS records are. It might be different from your WSL if you run nslookup objects.githubusercontent.com. For my host, it shows:

nslookup objects.githubusercontent.com 
Server:		91.199.160.135
Address:	91.199.160.135#53

Non-authoritative answer:
Name:	objects.githubusercontent.com
Address: 87.236.146.71

Ops, they are DIFFERENT! If you have the same result, you can continue to read this post. Otherwise, the below solution might not work for you.

3. Solution

Let’s change the DNS setting in WSL.

1. cat /etc/resolv.conf will show the current DNS setting in WSL like below.

# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:

# [network]           
# generateResolvConf = false 

nameserver 91.199.160.135
nameserver 8.8.8.8

2. As the above instructed, create a new file /etc/wsl.conf with the content

[network]           
generateResolvConf = false 

3. remove the existing /etc/resolv.conf

4. create a new file /etc/resolv.conf with the content

nameserver 1.1.1.1

5. In your Windows host, shut down wsl wsl --shutdown and restart it. Try nslookup objects.githubusercontent.com again

Server:         1.1.1.1
Address:        1.1.1.1#53

Non-authoritative answer:
Name:   objects.githubusercontent.com 
Address: 185.199.111.133
Name:   objects.githubusercontent.com
Address: 185.199.108.133
Name:   objects.githubusercontent.com
Address: 185.199.109.133
Name:   objects.githubusercontent.com
Address: 185.199.110.133

Here we go. The DNS records are correct now. Let’s try to download the file with wget again.

It’s fixed!!!

4. Further Consideration

The reason why I found this issue relates to DNS setting is because I have another Linux host and it can download the file with wget at the beginning. So I compared multiple configurations between these two hosts, such as wget version, ca-certificate installation, and certificate information retrieved by openssl.

One useful command worth to mention is openssl s_client -connect objects.githubusercontent.com:443 -debug. It is the result of this command that shows the difference between the certificate common name. Afterwards I used the nslookup to nail the issue down.

Even though I solved this issue in WSL, I want to know why it happens. I actually experienced some wierd network issue in the recent two days since I installed WiFi Range Extender in the house. So I checked my router and surprisingly found the below configuration.

To be honest, I couldn’t remember how it was set before, but I highly suspected that my router is hacked and the DNS setting was changed. To find it out. I will need to backup my router configuration first and reset the router. Let’s see what I can find.