SSL Certificates on EVERYTHING! (DDNS, Local Domains, Cloudflare) - Full Walkthrough Guide Pt.4

Summary of Technological Concepts, Setup, and Key Features

This walkthrough explains how to securely expose services in a home lab to the internet using Docker, Nginx Proxy Manager, and Cloudflare. It also supports internal-only “local top-level domains” via Let’s Encrypt, and finally enables secure remote access using Twingate (zero-trust networking).

---

1) Core Architecture / Goals

• Use a single Nginx Proxy Manager Docker stack to manage:
  • Public subdomains for services (e.g., Jellyfin, and Nextcloud is mentioned as a separate video)
  • Internal-only domains for services that should not be publicly reachable
  • SSL certificates for both public and internal hostnames
• Place Cloudflare DDNS in the stack to automatically update DNS A records when the public IP changes (dynamic IP use case).
• At the end, add a Twingate connector so you can reach internal DNS names externally without a traditional VPN.

---

2) SSL Certificates Everywhere (Public + Internal)

Public Domains

• Use the Cloudflare account as the DNS provider for DNS-based Let’s Encrypt challenges.
• Recommended Cloudflare SSL/TLS mode change:
  • Use Full (not Strict) because Strict may require Cloudflare API keys; Flexible may break services like Jellyfin.

Internal Domains

• Create a separate internal DNS zone (example: hopkey.net), pointing to the internal IP of the proxy manager.
• Generate Let’s Encrypt certificates for internal names using DNS-01 (Cloudflare).
• Validate using local testing (example: hello.hopkey.net).

---

3) Docker Stack: What’s Included

A Compose YAML stack includes containers for:

1. Nginx Proxy Manager

   • Provides a GUI for managing subdomains/domains and SSL.
   • Uses persistent volumes (including Let’s Encrypt storage).
   • Networking approaches discussed:
     • Host network mode (recommended for best results)
     • Bridge mode (example provided; may require port adjustments)
   • Critical note for host networking:
     • Ensure ports 80/81/443 aren’t used by other services.

2. Cloudflare DDNS

   • Automatically updates Cloudflare A records with the current public IP.
   • Uses a Cloudflare API token with permission to update Zone DNS.
   • Update interval:
     • Container scans public IP approximately every 5 minutes.
   • Disables IPv6 and uses bridge mode for ease (optional).

3. Hello World container

   • Used purely for testing proxy routing and SSL validation.
   • Runs on port 8888.

4. Twingate connector (added later)

   • Not started initially to avoid errors; deployed near the end.

---

4) DDNS + Cloudflare DNS Configuration Steps

• In Cloudflare, create A records for:
  • The root domain (or public domain) → updated automatically by DDNS
  • A Jellyfin streaming subdomain:
    • Proxy disabled to avoid Cloudflare media streaming terms issues
    • (The tutorial notes Cloudflare proxy services can conflict with media streaming.)
• Retrieve/create a Cloudflare API token:
  • Template: Zone DNS - Edit
  • Scope: include all zones
• Provide the token and domain/subdomains to the Cloudflare DDNS container via environment variables.
• Confirm:
  • Container logs show the stale A record being updated to the real current public IP.

---

5) Router Port Forwarding (Critical / Security-Sensitive)

The walkthrough emphasizes that port forwarding is the most dangerous step.

Needed for Cloudflare → proxy manager connectivity:

• Forward 80 → Nginx Proxy Manager
• Forward 443 → Nginx Proxy Manager

Notes on source vs destination ports:

• Cloudflare connects to source 443
• Forwarded to the destination port where proxy manager listens (examples mentioned):
  • 443 in host mode
  • 5443 in the bridge-mode example

---

6) Nginx Proxy Manager Configuration (Hosts + SSL)

• Create proxy hosts:
  • Add host pointing to the internal target service/container.
  • Map SSL settings to the previously generated certificates.
• Use the “hello world” host to verify:
  • HTTPS works externally
  • Cloudflare hides the origin IP (as intended)

---

7) Jellyfin-Specific Proxy Tuning

Jellyfin may initially appear “not secure” internally; the tutorial fixes it via correct proxy configuration.

Steps include:

• In Jellyfin settings:
  • Add Known Proxies (use the proxy manager IP so Jellyfin trusts the reverse proxy).
• In Nginx Proxy Manager host configuration:
  • Set scheme to HTTP
  • Enable WebSocket support
  • Add an “Advanced” custom configuration block (taken from Nginx Proxy Manager guidance)
  • Force SSL using the wildcard cert
• Uses Custom Locations in Jellyfin:
  • Example: map Jellyfin under a path like /jellyfin for the same subdomain (so multiple services can share a hostname).
  • Requires a Jellyfin restart after changing base/custom locations.

---

8) Local Top-Level Domain / Internal-Only Access

Cloudflare is used to host DNS records for internal names too, configured to resolve to private IPs:

• The public domain continues to exist for internet access.
• A separate internal domain (example: hopkey.net) is pointed to the internal IP of Nginx Proxy Manager.

For internal-only access:

• Generate certificates for *.hopkey.net.
• Local tests confirm names resolve to internal addresses (example: hello.hopkey.net).
• Example extension:
  • Proxy Proxmox via proxmox.hopkey.net using HTTPS and Let’s Encrypt to avoid browser warnings.

---

9) Twingate Integration (Zero-Trust Remote Access to Internal Services)

Twingate enables access to internal hostnames externally without a conventional VPN.

Setup flow:

• Create a remote network
• Create one or more connectors (connectors may be placed on different machines for redundancy)
• Deploy a Twingate connector using Docker:
  • Requires: tenant name, access token, refresh token
• In Twingate Resources:
  • Define service/port mapping (e.g., Nginx Proxy Manager port where it listens)
  • Optionally enforce port restrictions by user/group (described but not heavily used)

Result:

• External browser access to internal domains (example: proxmox.hopkey.net) works over encrypted connections.
• Access remains functional even when away from the home network.

---

10) Scaling Up to Many Services

After the initial setup, the author expands Nginx Proxy Manager to many proxy hosts (example counts: 19 proxy hosts and many containers/services).

Examples of scaling considerations mentioned:

• Home Assistant:
  • Required updates to configuration.yaml with trusted proxy headers:
    • http.use_x_forwarded_for: true
    • trusted_proxies set to the proxy IPs
• A limitation/issue:
  • Some services (e.g., Sonarr/Radarr grouping) didn’t work with the desired scheme (r.hopkey.net/...), leading to many separate proxy hosts instead.

---

Main Speakers / Sources

• Main speaker: The video’s primary narrator/author (a single person) describing their home lab setup.
• Products / sources referenced:
  • Nginx Proxy Manager (Docker container + GUI)
  • Cloudflare DDNS container (author referenced as Faviana in the subtitles)
  • Twingate (sponsor; zero-trust platform)
  • GitHub companion repository: “home lab” → “proxy” repository containing compose files and step-by-step configs
  • Documentation/config guidance indirectly referenced for:
    • Proxmox
    • Jellyfin
    • Home Assistant