Unable renewing certificate

gillesdeloustal · April 10, 2024, 2:50pm

Hi. I'm unable renewing certificate. Might help me ?
My domain is: https://decidim.ovh runs properly

I ran this command: sudo certbot renew

It produced this output:
Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: decidim.ovh
Type: connection
Detail: 90.9.0.72: Fetching https://decidim.ovh/.well-known/acme-challenge/rKyoe2gkqkYKcYBb_riD0aQEKFGV8Cxa-aPqtGLaWq8: Timeout during connect (likely firewall problem)

Domain: www.decidim.ovh
Type: connection
Detail: 90.9.0.72: Fetching https://decidim.ovh/.well-known/acme-challenge/2-PB620-S-WPnobGn7-VA60m4nvGCmIpt8GTCprsKMA: Timeout during connect (likely firewall problem)

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

My web server is (include version): Server version: Apache/2.4.52 (Ubuntu)
Server built: 2024-01-17T03:00:18

The operating system my web server runs on is (include version): ubuntu 22.04

My hosting provider, if applicable, is: localhost

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

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

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

I received this message : Your certificate (or certificates) for the names listed below will expire in 19 days (on 2024-04-27)

/etc/apache2/ports.conf
Listen 80

Listen 443

Listen 443

decidim.ovh.com
<VirtualHost *:80>
ServerName decidim.ovh
ServerAlias www.decidim.ovh
# Redirection 301 vers le site en HTTPS
Redirect permanent / https://decidim.ovh/

<VirtualHost *:443>
ServerName decidim.ovh
ServerAlias www.decidim.ovh
DocumentRoot "/var/www/nextcloud/"
<Directory "/var/www/nextcloud/">
Options -Indexes +FollowSymLinks +MultiViews
AllowOverride All
Require all granted

# directives obligatoires pour TLS
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/www.decidim.ovh/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.decidim.ovh/privkey.pem
Header always set Strict-Transport-Security "max-age=15768000"
ErrorLog /var/log/apache2/error.decidim.ovh.log
CustomLog /var/log/apache2/access.decidim.ovh.log combined

access.decidim.ovh.log
"GET /.well-known/acme-challenge/QecDsWZkeceqtLtqNwYLKx-4EDeZqk8a1Y3ICp0IAKo: HTTP/1.1" 404

MikeMcQ · April 10, 2024, 3:21pm

I believe your IPv6 address is not correct. Let's Encrypt favors that when you have an AAAA record in your DNS. Connections on that timeout. And, because you redirect HTTP to HTTPS the cert request fails due to LE failing the IPv4 retry. See below topic for details.

But, just make sure your IPv6 address is correct in your AAAA record

nslookup decidim.ovh
A    Address: 90.9.0.72
AAAA Address: 2a01:cb15:8455:d400:20f:b0ff:fece:da23

You could run this command to check your public IPv6 address

curl -6 https://ifconfig.io

gillesdeloustal · April 12, 2024, 4:47pm

Hi
The problem is that as soon as I change the AAAA parameter with the right IPV6, the IPV6 change immediately, so that when I run sudo certbot renew, IPV6 is wrong again.

Osiris · April 12, 2024, 4:57pm

Is your server getting their IPv6 address by SLAAC and is using privacy extensions by any chance?

For a server you probably want to configure your IPv6 in such a way you that you have a fixed IPv6 address. Whether that's using a static IPv6 address or using SLAAC but with the address based on the interface identifier, that doesn't matter that much. But a continuously changing address would be very cumbersome.

linkp · April 12, 2024, 5:16pm

If you have IPv6 privacy extensions enabled, you need to use the management address. If you have command line access you can identity the correct address using the following: ip -6 addr show and looking for the address with the mngtmpaddr flag.

Osiris · April 12, 2024, 5:21pm

The what now? My laptop using NetworkManager does not have that flag. My server however does. So it seems a YMMV thing.

linkp · April 12, 2024, 5:23pm

I copied that flag from a laptop that uses NetworkManager.

Osiris · April 12, 2024, 5:24pm

Oh, weird.. Then I don't know why I don't see it on this laptop

linkp · April 12, 2024, 5:28pm

We may need to start a new topic in the Lounge to investigate further.

gillesdeloustal · April 12, 2024, 9:26pm

Hi. Still does'nt work. Here are the results
<ip -6 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
5: wlxc8d3a3f440cf: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2a01:cb15:8455:d400:74f:14ac:2b06:e2b2/64 scope global temporary dynamic
valid_lft 86380sec preferred_lft 580sec
inet6 2a01:cb15:8455:d400:7ae8:e62e:1f98:be9f/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 86380sec preferred_lft 580sec
inet6 fe80::fc0a:23e0:84c1:5414/64 scope link noprefixroute
valid_lft forever preferred_lft forever/>

<nslookup decidim.ovh
Server: 127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
Name: decidim.ovh
Address: 90.9.0.72
Name: decidim.ovh
Address: 2a01:cb15:8455:d400:7ae8:e62e:1f98:be9f/>

sudo certbot renew
<Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: decidim.ovh
Type: connection
Detail: 90.9.0.72: Fetching https://decidim.ovh/.well-known/acme-challenge/eRYcaeKR79uvmeBz5r4hvKPYsnEHbXj0mOlgXGSuKZc: Timeout during connect (likely firewall problem)/>

<Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet./>

MikeMcQ · April 12, 2024, 9:32pm

Are you able to remove the AAAA from your DNS. Then Let's Encrypt will just use the IPv4 address.

Once that is proven you can work on sorting out the problems with IPv6.

If your DNS AAAA record does not match your IPv6 public IP that will affect anyone trying to use IPv6 to reach you. Not just Let's Encrypt

rg305 · April 12, 2024, 9:36pm

That [IPv4] path seems to have its' own problem:

MikeMcQ · April 12, 2024, 9:44pm

Not necessarily. That is the bug that shows the IPv4 address even when it was the IPv6 retry that failed. Note the HTTPS in the error message

I am not at a computer where I could poke that directly to see.

Osiris reported it formally After recurring here

github.com/letsencrypt/boulder

Incorrect IPv4 address in error message when IPv6 is not working

opened 10:48PM - 02 Mar 24 UTC

osirisinferi

**Summary:** On the Community, we've seen a few instances where users were sh…owing a time out error with an IPv4 IP address in the returned error, even though the IPv4 address was working properly. (E.g. https://community.letsencrypt.org/t/letsencrypt-reissue-certificate/214220.) In reality, it was the IPv6 address timing out. This problem only occurs if there's a HTTP to HTTPS redirect in place. For some reason Boulder only retries using IPv4 when there's an issue with IPv6 for the HTTP connection, but *not* for the HTTPS connection. (Not the scope of this issue.) But when the HTTPS over IPv6 attempt fails, Boulder uses the IPv4 address from the HTTP connection in the error message. Which is not correct. **Steps to reproduce:** * Have a site with HTTP to HTTPS redirect enabled; * Have a functional IPv4 address; * Have a non-functional IPv6 address; * Attempt to get a certificate. **Expected result:** * Time out error with the IPv6 address shown in the error message. **Actual result:** * Time out error with the IPv4 address shown in the error message. **Additional details:** It's really confusing to see a perfectly functional IPv4 address in a time out error message when actually the IPv6 address is the problem.

linkp · April 12, 2024, 9:52pm

That appears to be the correct address. It does not respond on port 80 or port 443.

It sounds like you may have a firewall issue or routing problem in your OVH infrastructure.

gillesdeloustal · April 13, 2024, 5:39am

Hi Firewall has always been inactive
sudo ufw status
État : inactif

all renewals succeeded

rg305 · April 13, 2024, 6:53am

What changed?

gillesdeloustal · April 13, 2024, 10:53am

Hi
getting rid of IPV6's adresses in DNS records fixed the problem
Thank's to all of you