Local HTTPS without a public CA: Caddy internal vs step-ca

Which one to pick

For a single box serving a handful of LAN names, Caddy’s built-in CA is the short path: one site block, no second service. step-ca is worth its extra container when more than one machine or tool needs certificates from the same authority, because it speaks ACME to any client. This test measured both on the same names, in a throwaway VM, with no public CA involved.

Three cold runs per row, each starting from empty data volumes. The Caddy internal figure includes one slower first run (2.04 s against 0.75 s and 0.68 s for the others); the test does not explain it.

Certificate lifetimes and chains

The Caddy leaf was valid for 12.0 hours and the step-ca leaf for 24.0 hours, as served. Caddy’s automatic HTTPS page says its intermediate is short-lived and renewed automatically but gives no leaf figure, so the 12 h here is the measured value on Caddy 2.11.7, not a documented guarantee. Short leaves are a reason to keep the renewal path working: this test issued certificates but did not wait for a renewal.

Trust is the part that bites

A valid certificate from a private CA is only valid for clients that trust its root. The same curl call, three ways:

With no trust configured curl stops with exit 60. Passing the root with --cacert works, and so does adding the root to the Ubuntu system store. Removing it from the store brought the failure back, which shows the earlier success came from the store and not from a cached answer.

Getting the root out of each container, as tested:

# Caddy internal CA
docker compose cp caddy-internal:/data/caddy/pki/authorities/local/root.crt root.crt
# step-ca
docker compose cp step-ca:/home/step/certs/root_ca.crt root.crt

curl --resolve svc.lab.internal:443:127.0.0.1 --cacert root.crt https://svc.lab.internal/
sudo cp root.crt /usr/local/share/ca-certificates/lab.crt && sudo update-ca-certificates

Caddy also tries to install its root itself. Its log inside the container says “certificate installed properly in linux trusts”, which describes the container’s own store, not the VM or any other machine. The Caddy docs say the automatic install may not work in containers or unprivileged services and that administrators are responsible for trust in internal PKI setups. Every client device needs the root some other way.

The first ACME attempt did not use step-ca

The first Caddyfile put step-ca in Caddy’s global options (acme_ca and acme_ca_root). Caddy started, served svc.lab.internal, and the certificate it served was issued by its own local CA. step-ca’s log shows no ACME requests at all.

The Caddy docs say names ending in .internal do not qualify for publicly-trusted certificates and that Caddy signs non-public sites with its own CA; that is consistent with what was seen, but the docs do not say a global acme_ca is ignored for such names, so that part is inference. The test did not try a global acme_ca with a public-style name. The fix that worked was to name the issuer inside the site block. Both files are in the test folder; the second one is the one the timings and the step-ca certificate come from.

svc.lab.internal {
	tls {
		issuer acme {
			dir https://step-ca:9000/acme/acme/directory
			trusted_roots /stepca/certs/root_ca.crt
		}
	}
	respond "hello from step-ca via ACME\n"
}

The compose file for both profiles:

# Two ways to get valid HTTPS for a LAN-only name. Run one profile at a time (both publish 443).
services:
  caddy-internal:
    profiles: [internal]
    image: caddy:2.11.7
    ports: ["127.0.0.1:443:443"]
    volumes:
      - ./Caddyfile.internal:/etc/caddy/Caddyfile:ro
      - caddy_internal_data:/data

  step-ca:
    profiles: [acme]
    image: smallstep/step-ca:0.30.2
    environment:
      DOCKER_STEPCA_INIT_NAME: Lab CA
      DOCKER_STEPCA_INIT_DNS_NAMES: step-ca,localhost
      DOCKER_STEPCA_INIT_PROVISIONER_NAME: admin
      DOCKER_STEPCA_INIT_PASSWORD: lab-only-not-a-secret
      DOCKER_STEPCA_INIT_ACME: "true"
    volumes:
      - step:/home/step
    healthcheck:
      test: ["CMD", "step", "ca", "health"]
      interval: 2s
      timeout: 3s
      retries: 60

  caddy-acme:
    profiles: [acme]
    image: caddy:2.11.7
    depends_on:
      step-ca: { condition: service_healthy }
    ports: ["127.0.0.1:443:443"]
    volumes:
      - ./${ACME_CADDYFILE:-Caddyfile.acme}:/etc/caddy/Caddyfile:ro
      - step:/stepca:ro
      - caddy_acme_data:/data
    networks: { default: { aliases: [svc.lab.internal] } }

volumes:
  caddy_internal_data:
  caddy_acme_data:
  step:

step-ca’s own setup came from the DOCKER_STEPCA_INIT_* variables in that file, with DOCKER_STEPCA_INIT_ACME enabled. The ACME client container carries svc.lab.internal as a network alias so step-ca can resolve and reach it; the test did not try without the alias. In the Caddy log, the challenge that was answered was tls-alpn-01.

Where DNS-01 fits (not tested)

Both challenges above happen over the Docker network, with step-ca connecting back to the client. On a real LAN the same works as long as the CA can resolve and reach the client’s name on ports 80 or 443. When it cannot, the DNS challenge removes that need: per the Caddy docs it requires DNS provider credentials to write TXT records and opens no ports, and the same page says Let’s Encrypt requires it for wildcard certificates. The step-ca provisioner docs list dns-01 as a supported ACME challenge. This test used neither, so no timing, setup effort or failure mode for DNS-01 is reported here.

What this test did not cover

• Renewal: no certificate was renewed. Lifetimes are as issued.
• Real clients: only curl 8.5.0 on Ubuntu 24.04 was used. Browsers, phones, Java and Windows trust stores were not tested.
• DNS: names were forced with curl --resolve. No DNS server, split-horizon setup or mDNS was involved.
• DNS-01 and any public CA. No Let’s Encrypt, no real domain.
• step-ca hardening: the CA password is the lab placeholder, the provisioner is the default, and keys sit on a Docker volume. Root key protection, revocation and monitoring were not looked at.
• Load: one name, one request at a time.