← All posts
6 min readDashCaddy Team

HTTPS for Your Homelab Should Be Invisible

httpstlshomelabcertificatesself-hostedssllets-encrypt

HTTPS is no longer optional. Browsers flag plain HTTP as "not secure." Some web APIs refuse to work without it. If you are serving anything on your home network — a media library, a password manager, a document editor — running over HTTP means your credentials cross the wire in the clear.

But getting HTTPS working on a homelab has always been a pain. Let's Encrypt made it free, but it did not eliminate the setup burden.

The certbot ritual

If you have set up TLS on a self-hosted service, you know the drill. You spin up Jellyfin on some high port. You want HTTPS, so you:

  1. Buy a domain or configure dynamic DNS.
  2. Open port 80 on your router for the ACME HTTP-01 challenge — or configure DNS-01 with your provider's API, which means finding the right certbot plugin, storing API credentials, and hoping the token doesn't expire.
  3. Install certbot. Your distribution's package may be outdated; the official recommendation is often to install via snap, which brings its own constraints.
  4. Run certbot certonly and stop whatever is on port 80 first.
  5. Copy the certificate paths into your reverse proxy config.
  6. Set up a cron job to renew. Hope the renewal doesn't fail silently two months later.
  7. Repeat for every new service.

DNS-01 validation avoids opening a port, but still requires API tokens, plugin configuration, and provider-specific hooks. Either path demands ongoing maintenance.

And if you want certificates for internal-only services with no public DNS zone, Let's Encrypt cannot help. The ACME provider must be able to resolve your domain, and certificates must match a publicly registered name.

The friction is not in the concept — it is in the ceremony. Seven steps per service, each with its own failure mode.

Automatic TLS with an internal CA

DashCaddy takes a different approach. Instead of managing external certificates per app, it runs its own internal certificate authority integrated with Caddy's PKI. Every deployed service receives a certificate from that CA, and Caddy handles the TLS termination. You never touch a PEM file or write a reverse proxy rule.

In practice, the internal CA issues certificates for every app you deploy — Plex, Jellyfin, Sonarr, Radarr, Vaultwarden, Nextcloud, and more. The reverse proxy rules are written automatically through Caddy's admin API:

Internal-only services get certificates too. The internal CA does not need public DNS validation. Services restricted to your Tailscale tailnet (via the deploy option for Tailscale-only routing) still receive valid certificates, even without a public DNS record.

Renewal is automatic. Certificates are managed through Caddy's PKI, not external cron jobs. When a certificate approaches expiry, Caddy renews it from the internal CA — no email warnings, no midnight outages, no "your site is not secure" surprises.

You set your own TLD. The dashboard runs on a configurable domain. Your services live at proper hostnames like plex.<your-tld> instead of localhost:32400. The TLD is yours to choose — whatever works on your network.

Trusting the CA on your devices

There is one step you do need to take. Because the CA is internal — not a public authority like Let's Encrypt or DigiCert — browsers and operating systems do not trust it out of the box. You install the root CA certificate on each device you use.

DashCaddy's dashboard includes a certificate authority distribution page that serves the root certificate and provides install scripts for each platform:

  • A shell script for Linux and macOS
  • A PowerShell script for Windows
  • A .mobileconfig profile for iOS

Running the script once per device tells your OS to trust the CA. After that, every service under your configured TLD shows a trusted padlock, no per-app work required.

It is a one-time setup step. Certificate renewal — the recurring part — is handled automatically by Caddy's PKI.

Why this changes self-hosting

Self-hosting has historically demanded three skills: know the app, know the server, and know the network. HTTPS falls into that third bucket, and it is the one that trips people up. Setting up TLS requires understanding DNS, certificate chains, and reverse proxy configuration — all before you have streamed a single movie.

When TLS is automatic, self-hosting becomes accessible to people who do not know what an A record is. They deploy Immich from the catalog and it gets HTTPS by default. They do not need to understand ACME, DNS-01, or certificate chains to get a secure connection.

For experienced self-hosters, automatic TLS means the mental overhead of certificate management disappears. You stop tracking expiry dates and start thinking about what you actually want to run.

Getting started

curl -fsSL https://get.dashcaddy.net | bash

The installer brings up the dashboard with the CA already provisioned. Every app deployed from there gets HTTPS automatically, and the CA distribution page is available from the dashboard to install the root certificate on your devices.