Score:0

wget doesn't accept HTTPS certificate (from letsencrypt) on some computers but does on others

sj flag

I have the following situation:

On my www server (Apache2, Debian armhf) I have HTTPS certificate from letsencrypt.org by certbot.
When accessing the server from a browser (Firefox, Chromium) everything was fine, but when I tried git or wget then the HTTPS certificate was not acccepted.

But this I could observe only on some of the computers I tried this but not on others.
Output from 5 computers:
computer 0 and 4 (not working):

0.b:~> wget https://rnk.bicyclesonthemoon.info
--2023-05-12 00:12:47--  https://rnk.bicyclesonthemoon.info/
Resolving rnk.bicyclesonthemoon.info (rnk.bicyclesonthemoon.info)... 192.168.1.4
Connecting to rnk.bicyclesonthemoon.info (rnk.bicyclesonthemoon.info)|192.168.1.4|:443... connected.
ERROR: The certificate of ‘rnk.bicyclesonthemoon.info’ is not trusted.
ERROR: The certificate of ‘rnk.bicyclesonthemoon.info’ has expired.
4.b:~> wget https://rnk.bicyclesonthemoon.info
--2023-05-12 02:14:32--  https://rnk.bicyclesonthemoon.info/
Resolving rnk.bicyclesonthemoon.info (rnk.bicyclesonthemoon.info)... 192.168.1.4
Connecting to rnk.bicyclesonthemoon.info (rnk.bicyclesonthemoon.info)|192.168.1.4|:443... connected.
ERROR: The certificate of ‘rnk.bicyclesonthemoon.info’ is not trusted.
ERROR: The certificate of ‘rnk.bicyclesonthemoon.info’ has expired.

Computers 1, 2, and 6 (working)

1a.b:/botm/tmp> wget https://rnk.bicyclesonthemoon.info
--2023-05-12 00:06:07--  https://rnk.bicyclesonthemoon.info/
Resolving rnk.bicyclesonthemoon.info (rnk.bicyclesonthemoon.info)... 127.0.0.1
Connecting to rnk.bicyclesonthemoon.info (rnk.bicyclesonthemoon.info)|127.0.0.1|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 226 [text/html]
Saving to: ‘index.html’

index.html          100%[===================>]     226  --.-KB/s    in 0s      

2023-05-12 00:06:07 (732 KB/s) - ‘index.html’ saved [226/226]
2.b:~> wget https://rnk.bicyclesonthemoon.info
--2023-05-12 02:17:10--  https://rnk.bicyclesonthemoon.info/
Resolving rnk.bicyclesonthemoon.info (rnk.bicyclesonthemoon.info)... 192.168.1.4
Connecting to rnk.bicyclesonthemoon.info (rnk.bicyclesonthemoon.info)|192.168.1.4|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 226 [text/html]
Saving to: ‘index.html’

index.html          100%[===================>]     226  --.-KB/s    in 0.005s  

2023-05-12 02:17:10 (46.6 KB/s) - ‘index.html’ saved [226/226]
6.b:~> wget https://rnk.bicyclesonthemoon.info
--2023-05-12 02:18:01--  https://rnk.bicyclesonthemoon.info/
Resolving rnk.bicyclesonthemoon.info (rnk.bicyclesonthemoon.info)... 192.168.1.4
Connecting to rnk.bicyclesonthemoon.info (rnk.bicyclesonthemoon.info)|192.168.1.4|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 226 [text/html]
Saving to: ‘index.html’

index.html          100%[===================>]     226  --.-KB/s    in 0s      

2023-05-12 02:18:01 (15.7 MB/s) - ‘index.html’ saved [226/226]

What's interesting is that computers 2 and 4 have the same OS (Debian 10, but 2 is 32 bit, 4 is 64 bit), the same version of wget (1.21.2) and are in the same local network, and still on one of them (2) the certificate is accepted and on the other one (4) not

Below is the relevant apache configuration:

In /etc/apache2/sites-available/botm.conf:

# Manage BOTM sites externally:
IncludeOptional /botm/etc/www/sites/*.conf

In /botm/etc/www/sites/rnk.bicyclesonthemoon.info-ssl.conf:

<VirtualHost *:443>
    ServerName rnk.bicyclesonthemoon.info
    Include /botm/etc/www/conf/ssl-certbot-botm.conf
    Include /botm/etc/www/conf/rnk.conf
</VirtualHost>

In /botm/etc/www/conf/ssl-certbot-botm.conf:

SSLEngine On
SSLCertificateKeyFile /botm/etc/certbot/live/botm/privkey.pem
SSLCertificateFile /botm/etc/certbot/live/botm/cert.pem
SSLCertificateChainFile /botm/etc/certbot/live/botm/chain.pem

Originally, I didn't have SSLCertificateChainFile included and was told that this is the reason. But adding this did not help.
Also I have seen somewhere that I should use fullchain.pem instead but this doesn't help anything either.

At this point I am confused and I don't know how to continue, how to debug, solve.

dave_thompson_085 avatar
jp flag
Check the versions of OpenSSL and ca-certificates, and whether there are any local/manual changes to ca-certificates (i.e. certs added or removed), especially on 2 and 4 (the most mysterious) and maybe all. LetsEncrypt to support old phones continues to use a cert chain that links to DST Root CA X3 which has expired, but _most_ systems (and all browsers) 'shortcut' this chain to the ISRG Root which is valid; your systems might not if they either don't have ISRG Root or do have OpenSSL 1.0.2 which mishandles this, but Debian 10 _shouldn't_. Compare https://serverfault.com/questions/1079199/ .
cn flag
`At this point I am confused`. The problem is 100% on the clients, and the problem is the certificate is not trusted.
cn flag
You need to follow the certificate validation process and determine which of the many steps are failing. This differs per platform. A packet capture would also help for reviewing the CDP/AIA/OCSP traffic. https://www.baeldung.com/linux/validating-certificates-curl
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.