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.
I just read your post on preventing Caddy’s automatic HTTP-to-HTTPS redirect—fantastic solution for local development! The detailed explanation of using both HTTP and HTTPS addresses in the site block for development environments is a real time-saver, especially when dealing with self-signed certificates.
While researching, I found this resource on securing websites with Caddy and automatic HTTPS: mobisoftinfotech.com/resources/blo... . It goes deep into Caddy’s security features, its SSL setup, and how automatic SSL works seamlessly for secure connections.
As you’re clearly an expert in Caddy’s HTTPS setup, I’d love to hear your thoughts on how Caddy compares to Nginx and Apache in terms of security, and if you think it’s a viable long-term solution for enterprise-level websites!