Video summary

(Updated Video In Description) Creating pfsense Let's Encrypt Wildcard Certificates using HAProxy

Main summary

Key takeaways

Technology

Summary of the Video (Tech + How-To)

The video explains how to use pfSense + HAProxy + Let’s Encrypt wildcard certificates to securely serve private/internal servers (not publicly exposed) without browser self-signed certificate warnings.

It uses DNS-based Let’s Encrypt validation (DNS-01) to obtain wildcard certificates, then uses HAProxy to SSL offload and route requests based on SNI/hostnames. Meanwhile, pfSense handles internal DNS overrides so clients on the LAN (and optionally remote clients via public DNS) can resolve the private FQDNs correctly.

Key Concepts / Product Features Used

  • Wildcard TLS certificates via Let’s Encrypt

    • Uses a pattern like *.example.com so one certificate covers multiple subdomains.

  • DNS-01 ACME challenge (prerequisite)

    • Requires a DNS provider that supports API-driven TXT record updates; otherwise wildcard issuance becomes difficult or manual.

  • pfSense web GUI port changes to reduce troubleshooting/conflicts

    • Move the pfSense web interface away from the default port 443.
    • Use HTTP port 80 redirect to the configured TLS port to simplify ACME/HTTP behavior during setup.

  • HAProxy SSL offloading

    • HAProxy terminates TLS using the wildcard certificate, then forwards traffic to private backends on the LAN.

  • Internal-only hostname resolution

    • pfSense DNS resolver creates internal DNS records so private hostnames map to internal IPs.

  • Renewal handling

    • Certificates renew about every 90 days.
    • HAProxy must be restarted/reloaded after renewal.

Tutorial / Guide Steps (As Described)

  1. Choose prerequisites

    • Must be able to request a Let’s Encrypt wildcard certificate using DNS-based ACME (DNS-01).
    • The video uses DigitalOcean DNS with an API key to automate TXT record challenges.
    • Notes:
      • Wildcard issuance works at the base domain level.
      • For sub-zones, you typically need wildcard certificates for each sub-zone separately.

  2. Adjust pfSense defaults

    • Avoid setup conflicts by moving/disabling default TLS web GUI behavior (especially default binding to port 443).
    • Configure redirects so you can reach the target via HTTP and land on the correct TLS port.

  3. Set up ACME on pfSense

    • Load the ACME plugin.
    • Create an ACME account key.
    • Request the wildcard certificate using the DNS provider API credentials.

  4. Configure HAProxy backends

    • Create a backend per private service (example backends: FreeNAS, Nova Prospect).
    • HAProxy forwards to internal LAN IP/port (TLS is handled on the front-end/offload side).

  5. Configure HAProxy frontends for private routing

    • Create a frontend bound to LAN and port 443, with SSL offloading enabled.
    • Add an ACL rule that matches the requested hostname (e.g., FreeNAS.*, NovaProspekt.* style).
    • Select the wildcard certificate for TLS termination (SNI matching becomes simpler due to wildcard coverage).

  6. Create pfSense internal DNS records

    • Use DNS resolver/host overrides so hostname.yourdomain.com resolves inside your network to the pfSense/HAProxy address.
    • This prevents cert warnings because clients connect using a name that matches the wildcard cert and points to the internal TLS terminator.

  7. Test behavior inside LAN vs remote users

    • Inside LAN: hostname resolves to pfSense’s internal DNS → wildcard cert validates correctly.
    • Outside LAN: if DNS doesn’t resolve to the internal IP, it won’t work unless remote clients use correct DNS or public DNS redirects are set up.

  8. Optional: support remote users via public DNS pointing to LAN

    • Create public DNS records (example shown with DigitalOcean) mapping internal resources to the pfSense internal resolver IP (often demonstrated with VPN).
    • Remote users connect (typically via VPN) so traffic reaches pfSense and the TLS hostname matches the wildcard cert.

Analysis / Important Notes Included

  • Certificate renewal requirements

    • After Let’s Encrypt renews certificates, HAProxy must be restarted/reloaded.
    • The video mentions a script concept for automating this.

  • Logging / troubleshooting implication

    • Backend services will see connections coming from pfSense/HAProxy, not the original client IP (because pfSense performs connection offload).

  • Scale considerations

    • Demonstrated on a small device (SG-1100 class) and said to work well for home/light use.
    • For business scale or many users, you may need a more powerful pfSense/HAProxy platform.

  • Real-world benefit

    • Eliminates repetitive “self-signed certificate” click-through issues in browsers and apps.
    • Also mentions using this pattern for self-hosted services (e.g., Bitwarden) without cert warnings.

Key takeaway: The wildcard cert + internal DNS mapping is what makes private/internal hostnames validate cleanly.

Main Speakers / Sources

  • Speakers: Warren Systems / Lauren Systems (the narrator references “Warren systems” and promotes Lauren Systems)
  • Primary technical sources in content:
    • pfSense ACME plugin
    • HAProxy
    • Let’s Encrypt (ACME wildcard DNS-01)
    • DigitalOcean DNS API (example DNS provider with an API key)

Original video