Let’s Encrypt

Caddy – The Ultimate Server with Automatic HTTPS

Great things are easy to get used to. When something works the way you want it, and does so for a long a time, it is inevitable that one day you’ll stop thinking about it altogether and accept it as a given.

Apache was a great web server, until Nginx came along. All of a sudden, it became obvious how much faster things could be, and how much simpler the configuration file is possible.

For the last few years, Nginx was working great for me. And now that I came across Caddy, I realized that life can be a lot simpler.

Here’s a bit to get you started:

Caddy simplifies your infrastructure. It takes care of TLS certificate renewals, OCSP stapling, static file serving, reverse proxying, Kubernetes ingress, and more.

Its modular architecture means you can do more with a single, static binary that compiles for any platform.

Caddy runs great in containers because it has no dependencies—not even libc. Run Caddy practically anywhere.

Seriously? We now have a web server which handles HTTPS with automatically renewed certificates (yes, Let’s Encrypt) out of the box… Mind-blowing. I guess, 21st century is indeed here now.

What else is there? Well, let’s see:

Configurable via RESTful JSON API. OMG! No more trickery with include files, syntax checking and restarts. In fact, configuration files are completely optional, and even if you choose to use them, they just use the same API under the hood. Bonus point: you can export full configuration of a running server into a file via a simple API call.
Extensible. Yes, that’s right! “Caddy can embed any Go application as a plugin, and has first-class support for plugins of plugins.” Check out their forum for plugin-related discussions, or simply search GitHub for Caddy.
Supports HTTP/1.1, HTTP/2, and even HTTP/3 (ETF-standard-draft version of QUIC), WebSocket, and FastCGI.
… and a lot more.

Wow! It’s definitely worth checking out. While Nginx is not going to disappear (much like Apache being still around), Caddy might be a better option for your next project.

Welcome to HTTPS

Finally, after years and years of recommending Let’s Encrypt to everyone, this blog has now followed its own advice and moved to HTTPS. All the old links should be automatically redirected as well, so most people probably won’t notice any difference. But if you do, please do let me know.

Well-Known URIs

Back when Let’s Encrypt started giving out free SSL certificates, one bit that visible all over the web was the “well-known” directory. I never thought much about it – it’s just a name after all.

Turns out, there is actually an RFC 5785 that defines a standard for the well-known uniform resource identifiers (URIs). And that’s a lot more generic than just the bit that Let’s Encrypt needs.

Accidentally stumbled upon this while reading “A Well-Known URL for Changing Passwords” draft.

Let’s Encrypt now supports wildcard certificates

Here are some very exciting news from Let’s Encrypt:

We’re pleased to announce that ACMEv2 and wildcard certificate support is live! With today’s new features we’re continuing to break down barriers for HTTPS adoption across the Web by making it even easier for every website to get and manage certificates.

ACMEv24.0k is an updated version of our ACME protocol which has gone through the IETF standards process, taking into account feedback from industry experts and other organizations that might want to use the ACME protocol for certificate issuance and management some day.

Wildcard certificates5.1k allow you to secure all subdomains of a domain with a single certificate. Wildcard certificates can make certificate management easier in some cases, and we want to address those cases in order to help get the Web to 100% HTTPS. We still recommend non-wildcard certificates for most use cases.

Wildcard certificates are only available via ACMEv2. In order to use ACMEv2 for wildcard or non-wildcard certificates you’ll need a client that has been updated to support ACMEv28.5k. It is our intent to transition all clients and subscribers to ACMEv2, though we have not set an end-of-life date for our ACMEv1 API yet.

Additionally, wildcard domains must be validated using the DNS-01 challenge type. This means that you’ll need to modify DNS TXT records in order to demonstrate control over a domain for the purpose of obtaining a wildcard certificate.

Let’s Encrypt is leading Top SSL Issuers

Netrack reports some statistics for the Top SSL Issuers, and it’s nice to see Let’s Encrypt leading the race with a significant advantage over the rest. Well done, ladies and gentlemen!