Skip to content

RTFM · Networking

webDragon ports, HTTPS, and certificates

webDragon publishes HTTP on TCP 80 and HTTPS on TCP 443. Port 80 is often still useful because it can redirect visitors and lets ACME HTTP validation prove that the public hostname reaches this server.

Saphira Linux dragon mascot

What each web port does

webDragon public ports
PortNormal useWhy it matters
80/TCPHTTPHTTP-to-HTTPS redirects and ACME HTTP-01 validation.
443/TCPHTTPSEncrypted public web traffic.

webDragon's saphira-site creates ordinary Nginx virtual-host configuration. It can use Certbot to obtain certificates after it verifies that DNS points at the server and that public HTTP traffic can reach port 80. This is not a SaaS dependency: the resulting Nginx configuration and certificate files remain on your Saphira host.

Public HTTPS prerequisites
# Before requesting a certificate, prove the public name resolves correctly.
dig +short A www.example.test
dig +short AAAA www.example.test

# On the web host, identify listeners and validate Nginx.
ss -lntp '( sport = :80 or sport = :443 )'
nginx -t

# From an independent network.
curl -I http://www.example.test/
curl -Iv https://www.example.test/

Choose the certificate owner

With direct webDragon, Nginx/webDragon owns 80, 443, and its certificates. With terminating HAProxy, HAProxy owns the public certificate and webDragon normally receives private HTTP. With HAProxy TLS pass-through, webDragon owns the certificate even though HAProxy listens publicly. Write this choice down before setting up Certbot, otherwise renewals can update the wrong host.

Certificate ownership map
Direct webDragon
Internet → router/provider → webDragon :80/:443

Terminating HAProxy
Internet → HAProxy :80/:443 → webDragon private :80

TLS pass-through
Internet → HAProxy :443 → webDragon private :443

Do not forward public 80 and 443 to HAProxy while asking webDragon to perform HTTP-01 validation unless HAProxy deliberately forwards the ACME challenge to webDragon. The public validation request must arrive at the certificate owner.

Text-only router and firewall procedure

  1. 1. Reserve or configure the web host address

    For a home NAT deployment, keep the web edge on a stable LAN address such as 192.168.1.50.

  2. 2. Allow only TCP 80 and 443

    Create matching nftables rules and, where applicable, router forwarding rules. Do not use a broad DMZ setting merely to make certificate validation work.

  3. 3. Set public DNS

    Publish A and AAAA records for the exact hostname. An AAAA record must point to a reachable, firewall-permitted IPv6 path; otherwise some visitors will fail before IPv4 fallback.

  4. 4. Validate from outside

    Use curl from an independent network. Confirm HTTP behaves as intended, HTTPS presents the expected hostname, and an unlisted port stays closed.

Prove it works: HTTPS is genuinely public

curl -Iv from outside reports the expected certificate name and chain, the site returns the expected status, and the Saphira firewall counters show the connection on the intended interface and address family.