Renew doesn't work anymore with CGNAT

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:
kriebel.mooo.com

I ran this command:

sudo certbot renew

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/kriebel.mooo.com.conf

Renewing an existing certificate for kriebel.mooo.com

Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems:
Domain: kriebel.mooo.com
Type: connection
Detail: 2a00:6020:a583:b000:6b4a:4b95:e3fc:5be9: Fetching http://kriebel.mooo.com/.well-known/acme-challenge/xxxx: Error getting validation data

Hint: The Certificate Authority failed to download the challenge files from the temporary standalone webserver started by Certbot on port 80. Ensure that the listed domains point to this machine and that it can accept inbound connections from the internet.

Failed to renew certificate kriebel.mooo.com with error: Some challenges have failed.

All renewals failed. The following certificates could not be renewed:
/etc/letsencrypt/live/kriebel.mooo.com/fullchain.pem (failure)

1 renew failure(s), 0 parse failure(s)

My web server is:

apache2 -v
Server version: Apache/2.4.59 (Raspbian)
Server built: 2024-04-05T12:08:04

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

lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye

My hosting provider, if applicable, is:
It is my own local server (raspberry pi) behind a router

I can login to a root shell on my machine:
yes

I'm using a ssh terminal to connect to the RPi

The version of my client is:

certbot --version
certbot 2.8.0

Additonal Info:
I guess this is an IPV6 issue with certbot in standalone mode.
I have a new provider which uses CGNAT for 6 weeks now. Since then I have this issue. Before, with the old provider and dynamic IPV4, certbot was running fine.
I have an working entry for kriebel.mooo.com at freedns, my apache2 webiste running on my RPI which can be successfully accessed from outside, i.e. if you call https://kriebel.mooo.com, you'll see "Hello world" from my server. To my view that proves that the RPI can be accessed via IPV6 and that DNS offers the correct IP.
In the letsencrypt.log I found these suspicious lines:

2024-07-24 16:19:38,998:INFO:certbot._internal.auth_handler:Performing the following challenges:
2024-07-24 16:19:38,999:INFO:certbot._internal.auth_handler:http-01 challenge for kriebel.mooo.com
2024-07-24 16:19:39,001:DEBUG:acme.standalone:Successfully bound to :80 using IPv6
2024-07-24 16:19:39,002:DEBUG:acme.standalone:Certbot wasn't able to bind to :80 using IPv4, this is often expected due to the dual stack nature of IPv6 socket implementations.

I don't know how to convince certbox to use IPV6.

My renewal params are

[renewalparams]
account = xxxxxxxxx
authenticator = standalone
server = https://acme-v02.api.letsencrypt.org/directory
key_type = ecdsa

2

I'm pretty sure that is not an IPv6 CGNAT IP.

That said, can you confirm the IPv6 address on your system?

It did use IPv6:
[there is no setting (that I'm aware of) for it to only use IPv6]

4 Likes
3

Is port 80 still working? The --standalone method is difficult to debug because you need to keep Certbot running to test connection from the public internet.

A way to test this easier is to use these command options

sudo certbot certonly --standalone --dry-run --debug-challenges -v -d (domain)

This command will show you the challenge URL to try from the public internet and the proper response. After showing you this it will say "Press Enter to Continue". DO NOT PRESS ENTER.

Leave it paused like that and use a different device to test connection. You can use a mobile phone with wifi disabled so use your carrier's network.

You do not have to use the full URL. Just try http://(yourdomain)

If the connection works this shorter URL should see a response like below.

ACME client standalone challenge solver
3 Likes
5

Hi Mike, thanks for the quick reply. I got the failure. I didn't forward port 80 on my router. Your hint led me to the solution. For whatever reason I had this forward disabled during my IPV6 experiments.

Sorry for this. Stupid mistake.

3 Likes
6

Usually with IPv6 there's no need to "forward" anything. I think that's mostly a NAT thing, something which is mainly an IPv4 thing and IMO is usually not to be used with IPv6.

Usually only the firewall needs to be "opened" for a specific port and a specific IPv6 IP address.

Please note that it if you want your server to be accessible using IPv6 without much trouble with DNS, you want to specify a relatively static IPv6 IP address. Not "Privacy Extensions for Stateless Address Autoconfiguration in IPv6". "Stateless address autoconfiguration" (SLAAC) can be fine if it results in a non-emphemeral address.

4 Likes
7

Right, I should have written ‘opened’.
I'm using a static, not temporary, address.

1 Like
8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.