Table of Contents

Whether you’re testing HTTPS for a bunch of endpoints locally through a localhost port, or whether you just like to name things, to me it sounds like you need to use a reverse proxy. While working on a Dockerfile for this website (if I ever need to self-host it), I re-discovered Caddy after learning about it from MonSec’s usage of it as a CTFd reverse-proxy.

Local Certificate Authority #

Caddy can spin-up a local certificate authority for SSL certificates, which is not trusted by browsers. If you want to simulate valid HTTPS certificates, you can add Caddy’s certificate authority (CA) to the trusted authorities list of your operating system by running caddy trust.

According to Caddy’s documentation:

It is safe to trust Caddy’s root certificate on your own machine as long as your computer is not compromised and your unique root key is not leaked.

Therefore, it would be advisable to run caddy untrust as soon as you finish testing HTTPS locally.

Reverse Proxy #

Caddy can act as a reverse-proxy between a client and a server by adding an SSL certificate at the transport layer for transport layer tempering detection. It requires the proxied server to be accessible from the machine Caddy runs on, which in this use case is just a raker’s TCP port on localhost.

Caddyfile (to be mounted at /etc/caddy/Caddyfile in containers):
```
raker.local {
	reverse_proxy localhost:4100
}
```

CLI

caddy reverse-proxy --from raker.local --to localhost:4100

File Server #

Caddy can also act as a static file server, which is particularly useful for self-hosting websites such as this with an SSL certificate. In this use case, Caddy serves static files generated by Hugo.

Caddyfile (to be mounted at /etc/caddy/Caddyfile in containers):
```
hugo.local {
	root * public
	file_server
}
```

CLI

caddy file-server --root public --domain hugo.local