> this is how it should work. Very nice.

Thanks for your comments; glad you like the way we integrated it!

> Does it automatically bundle domains and request a single certificate with SANs?

No, as it turns out, SAN makes the auto-management code highly complicated, since names could overlap in different certs, etc. It also complicates renewals and gives more room for error (e.g. 49 of the domains verify but 1 fails, so the cert can't be renewed). So I've opted not to support SAN certificates for the automatic HTTPS feature. But you can of course still issue your own SAN certificates and use those.

Right now, Caddy reloads itself when it renews certificates, but as of Caddy 0.8.2 (slated for release any day now), Caddy will do it all in-process, no reloading.

> this is how it should work. Very nice.

Yeah, Caddy is amazing. Matt is doing an awesome job with it.

> I wonder how caddy works with the very low 5 certificates per public suffix and week limit. Does it automatically bundle domains and request a single certificate with SANs?

I directed Matt to this discussion so I hope can answer these questions for you. I unfortunately cannot.

From what I can see, Caddy also does a reload. With Apache, you can do a Graceful restart and not lose any traffic, plus, using mod_lua you could create a relatively easy way to add this automagically.

nginx you can also reload gracefully using the same mechanism. Still. It would be cool if it wasn't needed. I mean - you don't normally restart web servers when a file in the document root changes - why would you still have to do this for changes to SSL certs.

(note: I know that these are two very different things and I know how complicated it is to get all that state correct and to properly re-initialize the SSL context - still, as certificates get more and more short-lived, this would be a cool thing to have)

FWIW, Caddy's next version will be able to update the certs without reloading at all.

Caddy does graceful reload with zero downtime on Linux.