Activate automatic HTTPS

Here’s the feature Caddy is famous for. Give it a domain name and it obtains a TLS certificate, renews it forever, and redirects HTTP to HTTPS. That whole feature set is called automatic HTTPS, and you enable it by writing a hostname.

blog.example.com {
  respond "hello over HTTPS"
}

That’s the entire configuration. When Caddy sees a qualifying hostname as the site address, it asks an ACME certificate authority — Let’s Encrypt or ZeroSSL — for a certificate, answers the validation challenge, installs the certificate, and schedules renewal. It also serves a redirect from port 80 to port 443 for that name.

The trigger is the site address, nothing else. Compare these two sites:

http://app.example.test {
  respond "HTTP only"
}

blog.example.com {
  respond "automatic HTTPS"
}

The explicit http:// scheme opts the first site out. The bare hostname opts the second one in. Addresses like :8080 don’t trigger public issuance either, and localhost gets a locally-trusted certificate instead — that’s the next lesson.

You can study the effect without owning a domain. Adapt the configuration and read the JSON:

caddy adapt --config Caddyfile --pretty

For issuance to work in production, two things must be true: DNS for the name points at your server, and ports 80 and 443 reach Caddy. That’s it. No renewal cron job, no certbot, nothing to remember in three months.

Now the mistake that bites beginners: testing against the real Let’s Encrypt endpoint over and over. Production CAs enforce rate limits, and if you restart a broken setup twenty times you can get locked out of issuance for days. While you’re testing, point Caddy at the staging CA:

blog.example.com {
  tls {
    ca https://acme-staging-v02.api.letsencrypt.org/directory
  }
  respond "testing issuance"
}

Staging certificates aren’t trusted by browsers, but issuance succeeds or fails for the same reasons as production. Once the staging flow works, remove the ca line and let Caddy get the real certificate once.