Generating Let's Encrypt certificates unsuccessful with IPv6

NETWORKING SOLUTIONS
1

I have a RUTX50 connected via a 5G cellular network. The cellular network provider gives me a dynamic private IPv4 address behind CG NAT, and dynamic public IPv6 addresses. FQDN is sucessfully updated with IPv6 using DDNS of RUTX50.

When I’m trying to generate Let’s Encrypt Certificates from the RUTX50 web GUI, I get the following in the system log:

1117 Sun Jan 19 00:38:17 2025 kern.notice kernel: Uhttpd configuration has been changed
1118 Sun Jan 19 00:38:17 2025 kern.notice kernel: Firewall configuration has been changed
1119 Sun Jan 19 00:38:26 2025 daemon.err uhttpd[2315]: xxx.yyy.zz: invalid
1120 Sun Jan 19 00:38:26 2025 daemon.err uhttpd[2315]:   xxxx:801:549:xxxx:8965:1020:xxxx:xxxx: Fetching http://example.com/.well-known/acme-challenge/0b61WVnVoxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxaIk: Connection refused (urn:ietf:params:acme:error:connection)
1121 Sun Jan 19 00:38:26 2025 kern.notice kernel: Uhttpd configuration has been changed
1122 Sun Jan 19 00:38:26 2025 kern.notice kernel: Firewall configuration has been changed

https://letsdebug.net/ reports no issue.

Any solid, preferably non guess-work advice on why the connection is refused by the router? I can reach the device web interface from the internet via FQDN, so thats not the reason.

2

On which port ? 80 ? 443 ?
Let’s Encrypt expects an answer on port 80.

3

From internet on port 80. This is prior as well as after the process of trying to generate the certificates.
Obviously from reading the attached log, it can be seen that during the process of generating the certificates the RUTX50 makes changes to the firewall (probably to provide access to the acme-challenge), but it remains unknown to me exactly what those changes consist of.

4

Works for me.
Here are the logs containing the firewall rules added by the acme script:

2025-01-19T13:39:40-04:00 acme: port80 listens:
2025-01-19T13:39:40-04:00 run-acme[906]: acme: port80 listens:
2025-01-19T13:39:40-04:00 acme: v4 input_rule: Chain input_rule (1 references)  pkts bytes target     prot opt in     out     source               destination              0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80 /* ACME */
2025-01-19T13:39:40-04:00 run-acme[906]: acme: v4 input_rule: Chain input_rule (1 references)
2025-01-19T13:39:40-04:00 run-acme[906]:  pkts bytes target     prot opt in     out     source               destination
2025-01-19T13:39:40-04:00 run-acme[906]:     0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80 /* ACME */
2025-01-19T13:39:41-04:00 acme: v6 input_rule: Chain input_rule (1 references)  pkts bytes target     prot opt in     out     source               destination              0     0 ACCEPT     tcp      *      *       ::/0                 ::/0                 tcp dpt:80 /* ACME */
2025-01-19T13:39:41-04:00 run-acme[906]: acme: v6 input_rule: Chain input_rule (1 references)
2025-01-19T13:39:41-04:00 run-acme[906]:  pkts bytes target     prot opt in     out     source               destination
2025-01-19T13:39:41-04:00 run-acme[906]:     0     0 ACCEPT     tcp      *      *       ::/0                 ::/0                 tcp dpt:80 /* ACME */

Which validation method have you used ?

5

During your test, were the circumstances similar to what I described?…IPv4 behind CG NAT and public IPv6 address?

None, because there is no option to select validation method in the RUtX50 GUI. But judging from the log file in my first post it defaults to HTTP-01.

6

Yes, private IPv4 and public IPv6.
My /etc/config/acme:

config acme
        option state_dir '/etc/acme'
        option account_email 'xxx@yyy'
        option debug 1

config cert 'example'
        option enabled 1
        option validation_method 'webroot'
        option use_staging 1
        option keylength 2048
        option update_uhttpd 1
        option update_nginx 0
        list domains xxx.yyy.com
        option webroot ""
        # option user_setup "path-to-custom-setup.script"
        # option user_cleanup "path-to-custom-cleanup.script"

Of course, the xxx.yyy.com domain has been registered in a dyndns (freedns for me) before.

9

This topic was automatically closed after 60 days. New replies are no longer allowed.