Help test a web server with Let's Encrypt built in

Caddy 0.8 beta is ready for developers to preview:

This is a web server that I’ve been writing in Go with native ACME support (using lego). It serves all your sites over HTTPS using Let’s Encrypt. It:

  • runs on all platforms,
  • has no dependencies,
  • and does not require sudo (on Linux).

It automatically renews your certificates for you. The idea is you start the program with a Caddyfile and it just works – no extra configuration needed. It has fully replaced Apache and nginx for my own needs.

Here’s a basic Caddyfile to get you started (replace with your own domain name):

root /www/mysite

This should serve your site over HTTPS and redirect HTTP to HTTPS.

Please read the release notes in my first link above to get an idea of what to expect.

I’m hoping that developers and others with technical abilities will try it out and offer your feedback. It may be a little rough around the edges, but I’m using it in production on unimportant sites and it’s working fine. Let me know both your good and bad experiences - and any questions you may have - thanks!


by the way does caddy just do http2 or can it use “normal” http/s as fallback?

also is there some way to override the new LE standard?

but it certainly sounds intresting.

if combined with PHP and MySQL (similar to xampp) it would seriously epic.

It falls back to HTTP/1.1 if the client does not support http2. You can also disable http2 with -http2=false from the command line.

Yep, if you define the host in your Caddyfile with a prefix http:// or have a line that says tls off.

well this is rather epic, now put this a PHP and a MySQL together and it gets even better.

also does caddy generate a cert for each domain or can I let it make a SAN with all in them instread, especially helpful for the little amount of people browsing without SNI support (or the people trying to access a Network Drive over Webdav, the WebClient STILL doesnt support SNI as of win8.1)

You can already use Caddy with PHP and MySQL just like you would nginx with them. Caddy can proxy fastcgi (more simply than nginx), and your PHP app can connect to MySQL like it normally does.

Since Caddy fully manages the certificates for you, it generates one certificate per domain. Turns out this is much simpler to manage in an automated environment. I don’t think this would be a problem since you (ideally) will never have to manage the certificates manually. And Caddy does have SNI support.

1 Like

well if caddy has SNI that might be nice but if the client doesn’t (older android, winXP IE didnt have that as well) you have a problem and the windows integrated WebDAV client doesnt do that.

also well I guess you can use the together but it probably means quite some work I always used XAMPP for that coz it’s easy to use and stuff.

1 Like

How does it behave if you have a test domain like pointing to or something like that? Does it have some setting to disable public certificates and use self-signed instead there for development?

It doesn’t know that the domain points to, but…

You can use tls off in the Caddyfile to disable the ACME features or you can use your own certs with tls cert.crt private.key .

The binaries on the release page have just been updated to the latest beta version, beta 2. This update contains a few bug fixes.

Here’s the link: - please continue to try it and give your feedback. It does help a lot!

by the way how do we work with chained certs (that are rather common because it keeps the root offline)

Caddy bundles automatically. (If I understand you correctly. Your question is a little open-ended.)

let’s say I have a cert from a CA where I have my cert and an intermediate. so the specs says that I use tls with ONE cert and a keyfile. and here’s the problem, where do I put the intermediate(s)

Oh, I see. You mean when manually specifying your own certificate and key. You concatenate the certs together in a text file then, and save it as a PEM.

(But you shouldn’t have to specify these yourself; Caddy will automatically issue and renew certs with Let’s Encrypt for you.)

yeah but when I already have a cert (I need to get in the beta for all the subdomains I have) I’d rather use that.

also is there a way to specify what the caddy does if it doesnt get SNI parameters from the client?

Nope. If SNI is required, clients must support it to connect.

well I have seen servers that do SNI but have some “fallback” cert which is presented by default (in apache that probably would be a cert presented outtside of the virtualhosts)
so in that case the worst you can get is an invalid cert (well obvious)

or let’s change the perspective what does the server do if it gets an SNI that isnt in the list? just kill the connection?

I just updated the binaries for beta 3, which has refinements to logging, error reporting, and a fixes for a few sneaky bugs.

At this point, all relevant known bugs have been fixed, so we’re mainly just waiting for Let’s Encrypt to reach general availability. I need your help, so please try it and report any bugs you encounter, but also let me know what you think in general.

@My1: To answer your questions, yeah, it probably won’t take. You can define a ‘wildcard’ host in your Caddyfile to handle requests for all other host names (but of course, you can’t get a certificate for

that it wont get a cert automatically for or similar is obvious, but there I can just put in the one that should be used, or what would be epic is like saying
or whatever so that it knows that if there’s nothing it just reacts as is it has gotten

Thanks for implementing this. I was able to get it working with the private beta during the second half of a football game—pretty good compared to my previous TLS experiences :slight_smile: .

It wasn’t clear from the notes, but it looks like specifying -agree for automatic operation is needed only the first time you run caddy, is that correct?

Glad you had a chance to try it! (FYI, a new beta release with even more improvements will come soon, so keep an eye out.) Thanks for letting me know.

In automated environments, you should always use that flag (assuming you do, in fact, agree) in case the terms change. Otherwise you may be prompted again.