Weird...
I removed from the www.munerotto.it vitual host conf the rewrtie rule to force the use od https for the incmin request on port 80. But the opposite...
An idea might be that the https' are missing. I'll try to add the virtual host for 443 again.
Using https://www.munerottoit finally, accepting the "nasty" certificate (expired), I receive the page:
The same happen for the nextmune (accepting shows my hello page)
but certbot still fails:
$ sudo certbot renew -v --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/nextmune.munerotto.it.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Certificate is due for renewal, auto-renewing...
Plugins selected: Authenticator apache, Installer apache
Failed to renew certificate nextmune.munerotto.it with error: HTTPSConnectionPool(host='acme-staging-v02.api.letsencrypt.org', port=443): Max retries exceeded with url: /directory (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f1061759550>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution'))
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All simulated renewals failed. The following certificates could not be renewed:
/etc/letsencrypt/live/nextmune.munerotto.it/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)
The DNS resolving capabilities of the host running Certbot is broken.
It doesn't seem a resolv.conf problem:
PING www.munerotto.it (93.49.253.65) 56(84) bytes of data.
64 bytes from fedehome (93.49.253.65): icmp_seq=1 ttl=64 time=0.690 ms
64 bytes from fedehome (93.49.253.65): icmp_seq=2 ttl=64 time=0.638 ms
64 bytes from fedehome (93.49.253.65): icmp_seq=3 ttl=64 time=0.542 ms
64 bytes from fedehome (93.49.253.65): icmp_seq=4 ttl=64 time=0.608 ms
64 bytes from fedehome (93.49.253.65): icmp_seq=5 ttl=64 time=0.614 ms
64 bytes from fedehome (93.49.253.65): icmp_seq=6 ttl=64 time=0.617 ms
64 bytes from fedehome (93.49.253.65): icmp_seq=7 ttl=64 time=0.668 ms
^C
--- www.munerotto.it ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6103ms
rtt min/avg/max/mdev = 0.542/0.625/0.690/0.044 ms
mune@fedehome:/var/www/html$ ping nextmune.munerotto.it
PING nextmune.munerotto.it (93.49.253.65) 56(84) bytes of data.
64 bytes from fedehome (93.49.253.65): icmp_seq=1 ttl=64 time=0.738 ms
64 bytes from fedehome (93.49.253.65): icmp_seq=2 ttl=64 time=0.660 ms
64 bytes from fedehome (93.49.253.65): icmp_seq=3 ttl=64 time=0.613 ms
64 bytes from fedehome (93.49.253.65): icmp_seq=4 ttl=64 time=0.639 ms
^C
--- nextmune.munerotto.it ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3062ms
rtt min/avg/max/mdev = 0.613/0.662/0.738/0.046 ms
Try pinging acme-staging-v02.api.letsencrypt.org.
Or maybe it was just temporary. No Docker involved, right?
You were right!
In this PC says
ping acme-staging-v02.api.letsencrypt.org
PING 56a5f4b0bc8146689ec3e272c43525f9.pacloudflare.com (172.65.46.172) 56(84) bytes of data.
64 bytes from 172.65.46.172 (172.65.46.172): icmp_seq=1 ttl=57 time=18.0 ms
64 bytes from 172.65.46.172 (172.65.46.172): icmp_seq=2 ttl=57 time=26.7 ms
64 bytes from 172.65.46.172 (172.65.46.172): icmp_seq=3 ttl=57 time=14.7 ms
but in the PC with the web server says:
ping acme-staging-v02.api.letsencrypt.org
ping: acme-staging-v02.api.letsencrypt.org: Name or service not known
meaning that there something wrong in the name resolutioin.
resolc.conf says
$ cat /etc/resolv.conf
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 127.0.0.53
options edns0 trust-ad
search .
eehh? What's that??
That's systemd-resolved for ya.
I have absolutely zero experience with systemd systems, as my Gentoo GNU/Linux uses OpenRC.
Actually that file (resolv.conf) is equal on both the machines.
It has to be something else.
Resolve.conf would have to have the entire Internet for it to replace DNS.
It is NOT for that purpose.
You need to fix DNS.
Checking resolv.conf for DNS issues is a good way to start Rudy..
Unfortunately it doesn't really help in the case of systemd-resolved and further steps (which I do not know) are required.
I think we both understand how/why DNS works.
@mune may need to review the basic steps/setup.
Two clues in that file:
You might want to elaborate a little bit, because I'm not following.
I'm more interested in the
# Run "resolvectl status" to see details about the uplink DNS servers
part.
This is clearly a DNS issue.
resolve.conf does NOT replace DNS [only the entries found in there].
[this is not a DNS forum]
I think I found.
The working machine ha this conf:
...
Ach this damn modem!! 
It is so basic that the DNS can be changed there, it is hardcoded.
I tried to modify the resolv.conf via CLI but I failed. so II forced it, changing the last lines of the file redolv.conf
$ tail /etc/resolv.conf
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 8.8.8.8
options edns0 trust-ad
search .
and finally the ping works:
$ ping acme-staging-v02.api.letsencrypt.org
PING 56a5f4b0bc8146689ec3e272c43525f9.pacloudflare.com (172.65.46.172) 56(84) bytes of data.
64 bytes from 172.65.46.172 (172.65.46.172): icmp_seq=1 ttl=58 time=13.8 ms
64 bytes from 172.65.46.172 (172.65.46.172): icmp_seq=2 ttl=58 time=13.0 ms
64 bytes from 172.65.46.172 (172.65.46.172): icmp_seq=3 ttl=58 time=13.6 ms
^C
--- 56a5f4b0bc8146689ec3e272c43525f9.pacloudflare.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 13.030/13.452/13.764/0.309 ms
BUT again certbot doesn't
$ sudo certbot renew -v --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/nextmune.munerotto.it.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Certificate is due for renewal, auto-renewing...
Plugins selected: Authenticator apache, Installer apache
Simulating renewal of an existing certificate for nextmune.munerotto.it and www.munerotto.it
Performing the following challenges:
http-01 challenge for nextmune.munerotto.it
http-01 challenge for www.munerotto.it
Waiting for verification...
Challenge failed for domain nextmune.munerotto.it
Challenge failed for domain www.munerotto.it
http-01 challenge for nextmune.munerotto.it
http-01 challenge for www.munerotto.it
Certbot failed to authenticate some domains (authenticator: apache). The Certificate Authority reported these problems:
Domain: nextmune.munerotto.it
Type: connection
Detail: 93.49.253.65: Fetching http://nextmune.munerotto.it/.well-known/acme-challenge/h0eNXBVKy1reiCR7qtVCL1Q_CCeYAPl8v-2NFYKNGUc: Timeout during connect (likely firewall problem)
Domain: www.munerotto.it
Type: connection
Detail: 93.49.253.65: Fetching http://www.munerotto.it/.well-known/acme-challenge/grfGMf9gp7wMA24CAJC69Podbnqgje5wqBi5I8tTAzk: Timeout during connect (likely firewall problem)
Hint: The Certificate Authority failed to verify the temporary Apache configuration changes made by Certbot. Ensure that the listed domains point to this Apache server and that it is accessible from the internet.
Cleaning up challenges
Failed to renew certificate nextmune.munerotto.it with error: Some challenges have failed.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All simulated renewals failed. The following certificates could not be renewed:
/etc/letsencrypt/live/nextmune.munerotto.it/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details
te that in the apache virtual host conf files I wrote
$ cat /etc/apache2/sites-enabled/www.munerotto.it-le-ssl.conf
<IfModule mod_ssl.c>
<VirtualHost *:443>
# This is the name of the vhost.
ServerName www.munerotto.it
# These are alternative names for this same vhost.
# We put the other domains here. They will all go to the same place.
ServerAlias www.munerotto.it
# Directory where the website code lives.
DocumentRoot /var/www/html/www.munerotto.it
<Directory />
Options FollowSymLinks
AllowOverride All
</Directory>
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/nextmune.munerotto.it/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/nextmune.munerotto.it/privkey.pem
# FM These lines are fot the let's enctypt https verification process
AliasMatch /.well-known/acme-challenge/(.*)$ /var/www/html/.well-known/acme-challenge/$1
<directory /var/lib/letsencrypt/http_challenge>
AllowOverride None
Require all granted
</directory>
</VirtualHost>
</IfModule>
and
<IfModule mod_ssl.c>
<VirtualHost *:443>
# This is the name of the vhost.
ServerName nextmune.munerotto.it
# These are alternative names for this same vhost.
# We put the other domains here. They will all go to the same place.
ServerAlias nextmune.munerotto.it
# Directory where the website code lives.
DocumentRoot /var/www/html/nextmune.munerotto.it
<Directory /var/www/html/nextmune.munerotto.it>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Require all granted
</Directory>
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
</IfModule>
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
AddDefaultCharset utf-8
Options -Indexes
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/nextmune.munerotto.it/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/nextmune.munerotto.it/privkey.pem
# FM These lines are fot the let's enctypt https verification process
AliasMatch /.well-known/acme-challenge/(.*)$ /var/www/html/.well-known/acme-challenge/$1
<directory /var/www/html/.well-known/acme-challenge>
AllowOverride None
Require all granted
</directory>
</VirtualHost>
</IfModule>
You are now facing the firewall problem:
And I'm not sure if the manual edit of that resolv.conf file will survive a reboot.
[something you will have to check]
But where is it? ufw is disabled and the ports are opened
Again I agree, but the porpoise was a test for a while, tomorrow I will insert manually again it is not not a permanent fix, I know it: they say "Don't edit this file": I trust that 