Defguard 2.0 built-in Let’s Encrypt with External URL on port 8443

[minimalguru-dev]

Hello,

We are running Defguard 2.0.2 with Core and Gateway on one internal VM and Edge on a separate DMZ VM.

Public TCP 443 is used by another production service, so Defguard cannot use it directly. Currently, nginx listens on Edge TCP 8443 and certificates are issued with acme.sh using DNS-01, then securely copied from Core to Edge.

Could you please confirm:

1. Is this configuration officially supported?

   Public TCP 80 -> Edge TCP 80 for HTTP-01
   Public TCP 8443 -> Edge TCP 443 for Defguard HTTPS

2. Will enrollment, Desktop Client communication and automatic certificate renewal work correctly with the External URL on port 8443?

3. Does public TCP 80 need to remain permanently forwarded for renewals?

4. Does Defguard require public TCP 443 at any point, even when the configured External URL uses port 8443?

5. Does the built-in certificate functionality support ACME DNS-01 challenges instead of HTTP-01, either currently or on the roadmap?

Best regards

[jmrplens]

The built-in Let's Encrypt is HTTP-01 only, and the challenge listener is hard-coded to 0.0.0.0:80 on Edge. It is not --http-port and it cannot be moved. Upstream documents the requirement; the source shows it is not configurable:

Let's Encrypt validation in Defguard currently uses the ACME HTTP-01 challenge, which requires port 80 to be publicly accessible from the internet. […] If port 80 is blocked, filtered, or forwarded elsewhere, certificate issuance will fail.
Source: Certificate management

// DefGuard/proxy src/acme.rs @ v2.0.2 (byte-identical on the v2.1.0 tag)
let listener = TcpListener::bind("0.0.0.0:80").await
    .context("Failed to bind port 80 for ACME HTTP-01 challenge server")?;
let mut challenge = authz.challenge(ChallengeType::Http01)
    .ok_or_else(|| anyhow!("ACME server did not offer HTTP-01 challenge"))?;

1. Nothing in the code objects, and the firewall docs already bless the shape: "If you've configured your own reverse proxy for Edge, then expose the reverse proxy with your preference." Edge's HTTPS port is configurable in any case (--https-port / DEFGUARD_PROXY_HTTPS_PORT, default 443). Whether it is officially supported is a maintainer word.

2. The port survives Core's URL construction, and there is an upstream test for exactly your case: test_edge_callback_url asserts https://edge.example.com:8443/path → https://edge.example.com:8443/path/openid/callback. The cert subject comes from host_str() alone, so :8443 still yields a certificate for the bare hostname. Renewal works provided public 80 reaches Edge 80 when it fires: Core checks every 24 h (LETSENCRYPT_EXPIRY_CHECK_INTERVAL) and renews inside 14 days of expiry (LETSENCRYPT_EXPIRY_THRESHOLD), calling Edge over gRPC to re-run the same HTTP-01. I would still confirm one real enrollment and one desktop-client connect against :8443 rather than trust code reading for the client half.

3. Yes, permanently, if you use the built-in flow. Renewal is unattended and fires on whichever daily tick first lands inside the 14-day window, so there is no slot you can open on demand. Edge holds :80 only for the challenge itself (server_handle.abort() right after validation), but you cannot predict the day.

4. No, not for ACME. HTTP-01 is the only challenge implemented; TLS-ALPN-01, the one that would need 443, is not. Let's Encrypt's docs are explicit: HTTP-01 "can only be done on port 80", TLS-ALPN-01 is "performed via TLS on port 443". The "open TCP 443" in the firewall docs is about clients reaching Edge, which is the part you are moving to 8443.

5. Not currently; upstream's own wording is "currently uses the ACME HTTP-01 challenge". ChallengeType::Http01 is the only challenge referenced in either repo, and an org-wide code search for Dns01 returns nothing. The roadmap half is a maintainer question.

Since acme.sh with DNS-01 already works for you, I would skip the built-in flow and drop the scp instead. Core stores an uploaded PEM and pushes it to every connected Edge over the existing gRPC control channel, with no file copy:

POST /api/v1/proxy/cert/external_url_settings
{"ssl_type": "own_cert", "cert_pem": "...", "key_pem": "..."}

(set_external_url_settings → broadcast_proxy_https_certs → ProxyControlMessage::BroadcastHttpsCerts; Edge restarts its listener on the new cert.) One caveat before you wrap that in an acme.sh --reloadcmd: the Authorization: Bearer branch of the session extractor sits inside if is_business_license_active() (auth/mod.rs L44), so on an unlicensed install an API token never authenticates; it is session-cookie only (the Settings UI, or a scripted POST /api/v1/auth login). That tier covers "both Team & Business level in our current pricing structure", so any paid licence clears it.

If you would rather keep nginx terminating TLS, which is closest to what you run today, the setting is ssl_type: "none", the default variant, documented as "intended for deployments where TLS termination is handled externally, for example by a reverse proxy or load balancer in front of Defguard". Edge then serves plain HTTP on --http-port (default 8080) for nginx to proxy to, and 1 to 4 stop mattering.

One trap either way, on a DMZ VM that already runs nginx: the ACME listener binds :80 on all interfaces, and the graceful hand-off covers only Defguard's own HTTP server, and only when http_port == 80. If anything else holds :80, renewal fails at bind, and redirecting /.well-known/acme-challenge/ cannot rescue it, since Let's Encrypt follows redirects "only to ports 80 or 443". Binding below 1024 also needs root or CAP_NET_BIND_SERVICE.

The Defguard side above is read from the source at v2.0.2 (unchanged in v2.0.3), not from running it. The nginx-terminating-TLS-in-front half is what I run.