security/acme-client: Feature Request - IPv6 Option for CG-NAT-Firewalls

[robgnu]

Important notices Before you add a new report, we ask you kindly to acknowledge the following:

• [ X ] I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
• [ X ] I have searched the existing issues, open and closed, and I'm convinced that mine is new.
• [ X ] When the request is meant for an existing plugin, I've added its name to the title.

Is your feature request related to a problem? Please describe. Some OPNsense Firewalls that I've configured are IPv6 only by the ISP (CG-NAT). Trying to issue a certificate via HTTP-01 always fails. For my understanding acme.sh only listens on IPv4 Interfaces by default.

Describe the solution you'd like But there is a command line option in acme.sh to listen on IPv6: --listen-v6. Maybe there is an easy way to integrate this option into the Plugin-GUI? It would be really nice, because more and more ISPs are switching to CG-NAT configuration.

Thank you Robert.

[promd]

I am facing the sa,e issue with IPv6-only DynDNS domains. A fix would be fantastic.

The logs of the acme client indicate that the resonse is invalid, the log of the plugin only mentions the IPv4 address to be used (which does not get resolved by the DynDNS provider)

[discordier]

Having the same problem as @promd. OPNsense is only reachable via IPv6 but is listening on an internal IPv4.

Trying via CLI and passing --listen-v6 did not solve anything. I found the following issue in openbsd tracker, which might be related (given opnsense is based on BSD): https://github.com/acmesh-official/acme.sh/issues/5065

[stolendata]

@robgnu @promd @discordier

A makeshift solution is to hard-code your IPv6 address in the ncaddr parameter in _startserver() like so:

...
_startserver() {
  content="$1"
  ncaddr="$2"
...

... change to ...

...
_startserver() {
  content="$1"
  ncaddr="xxxx:yyyy:zzzz::etc"
...

If you're uncertain of what your IPv6 address is, or if it keeps changing, you may use ::.

[discordier]

@stolendata Thanks for your suggestion but it's not working for me. The request gets sent correctly, yet the listening does still not work.

OPNsense stays attached to port 80 on IPv6, therefore I see in the logs something along the lines of:

== Info: Connected to [REDACTED] () port 80
GET /.well-known/acme-challenge/[REDACTED]
HTTP/1.1 301 Moved Permanently
Location: https://[REDACTED]/.well-known/acme-challenge/[REDACTED]

OPNSense is always redirecting to HTTPs.

I wonder how this is supposed to work at all, given that the web interface apparently must get shut down temporarily? Can't we make certbot put the secrets in a (no pun intended) .well-known directoy that OPNSense will serve from its webserver?

[Ryushin]

This doesn't address this feature request, but I switched to DNS-01 for my challenge type when I went behind Starlink's CG-NAT last month. An advantage is I could make a wildcard or even multi wildcard cert as well. It's not as easy as a set up but it has other advantages as well. Such as I can block port 80 and 443 from most of the world using GEO-IP and still get my certificates. I can have use private IP addresses and have SSL certs for internal network devices. I've actually started switching all my ACME certs over DNS-01 challenge. Other than the ease of using the HTTP-01 challenge type, the DNS-01 is better for everything else.

[discordier]

@Ryushin This won't work for me as my DNS API is not reachable from OpnSense (Domain is registered and setup on Internet servers while OpnSense is on inhouse colo).

Using wildcard is not an requirement for me at all and rather discouraged for me as I want a cert per service and not allow a service to mimic another one in case the cert get's stolen.

[Ryushin]

@Ryushin This won't work for me as my DNS API is not reachable from OpnSense (Domain is registered and setup on Internet servers while OpnSense is on inhouse colo).

Using wildcard is not an requirement for me at all and rather discouraged for me as I want a cert per service and not allow a service to mimic another one in case the cert get's stolen.

The ACME client supports dozens and dozens of DNS providers and it does not have to talk to DNS servers in house. I just set up dual a Opnsense HA firewalls yesterday to use DNS-01 and GoDaddy API for firewalls that were behind triple NAT.

I use HA to replicate the certificates. I need a wildcard cert to match both firewalls, but I use a subdomain wildcard. Such as *.fw.domain.com. But you know what, thinking about it, when using DNS-01 I don't even need to do that. I can create the cert with fw1.domain.com and alt name for fw2.domain.com and since it's using DNS-01, it will give me a cert for both of them and when HA replicates over to FW2 it's name will be valid as well. No way I can do that with HTTP-01. Win Win!