Occasionally while developing a web app locally, you need to build an isolated feature that requires https
(such as a service worker). Using a self-signed certificate locally introduces the annoyance of Chrome returning an error every few hours that says Your connection is not private
.
It would be nice to only deal with those self-signed https
warnings when you absolutely needed to use https
, then access the site warning-free via http
the rest of the time. However, Caddy automatically adds an http
-to-https
redirect for all domain site addresses.
You can prevent the automatic redirection from http
-to-https
by listing both http
and https
addresses at the beginning of the site block:
http://mysite.test, https://mysite.test {
# bind allows access to containers from host when
# running Caddy in Docker.
bind 0.0.0.0
# Issue a self-signed certificate for development.
tls internal
respond "Hello, world! I am being accessed from {scheme}."
}
Do not use this configuration in production. There are very few responsible reasons to serve an http
version of your production site. Only use this configuration for development.
Alternatively, you can disable http-to-https redirects for all sites in your Caddyfile by adding the following block to the top of your Caddyfile (as seen in this GitHub issue):
{
auto_https disable_redirects
}
Don't run this configuration in production either.
Gotchas
When developing locally, you may need to add the domains to your system's hosts
file if they aren't already there.
Top comments (3)
I’ve been exploring your blog on Prevent Caddy's automatic http-to-https redirect—such a well-explained guide! The step-by-step approach to disabling automatic HTTPS redirects was really helpful.
While researching, I found this resource on Caddy’s automatic HTTPS and security features, which dives into how Caddy simplifies SSL setup while ensuring website security: mobisoftinfotech.com/resources/blo....
It’s a solid guide for anyone looking to manage HTTPS configurations in Caddy effectively. I’d love to hear your thoughts on best practices for handling self-signed certificates in development! 🚀
Some comments may only be visible to logged-in visitors. Sign in to view all comments.