I have a git server running with a valid let's encrypt certificate.
Now I created an Ubuntu server:
Ubuntu 22.04.3 LTS
When trying to connect to my server having the Let's Encrypt certificate using
wget -p https://git.dev.dynamic-biosensors.com
I receive the following message
--2023-08-22 19:40:40-- https://git.dev.dynamic-biosensors.com/
Resolving git.dev.mydomain.com (git.dev.dynamic-biosensors.com)... 192.168.70.14
Connecting to git.dev.mydomain.com (git.dev.dynamic-biosensors.com)|192.168.70.14|:443... connected.
ERROR: cannot verify git.dev.dynamic-biosensors.com's certificate, issued by ‘CN=R3,O=Let's Encrypt,C=US’:
Unable to locally verify the issuer's authority.
To connect to git.dev.dynamic-biosensors.com insecurely, use `--no-check-certificate'.
I already ran
sudo apt-get install --reinstall ca-certificates
and all came back without error, but the issue persists.
The certificate was issued Monday, 14. August 2023 at 21:25:48 Central European Summer Time and the new Ubuntu server's timedatectl is
Local time: Tue 2023-08-22 19:47:49 UTC
Universal time: Tue 2023-08-22 19:47:49 UTC
RTC time: Tue 2023-08-22 19:47:49
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
Any ideas what is going on? The connection should just work, should it not?
Almost certainly the problem is that you're not serving a certificate chain. A webserver needs the certificate, as well as an intermediate or two which "chain" back to the long-lived roots in the ca-certificates package.
What is the webserver (eg, nginx), and how is the certificate configured in it? Unfortunately there is some inconsistency in how this is set up.
A typical source of this error is giving software the cert.pem file, when it needs fullchain.pem -- to use the filenames certbot produces by default. Some other software takes the cert.pem and chain.pem seperately. (fullchain.pem is both of them combined)
If you only see a single certificate, ie, you don't see a line like i:C = US, O = Internet Security Research Group, CN = ISRG Root X1, then you've got the problem I just described and aren't serving a complete chain.
This is probably the most common TLS misconfiguration, and unfortunately it's largely due to inconsistencies between how different webservers are configured. Web browsers like Chrome and Firefox have workarounds for this issue because it's so common, so your website may work in them still.
Whatever server is running https://git.dev.mydomain.com is probably pointing to the certificate file instead of the full chain file, so the intermediate R3 certificate is not being served as part of the chain.
So, it's likely not wget that's the problem, it's the web server you're connecting to.