Caddy has this feature and it's amazing. https://caddyserver.com/docs/automatic-https

this is how it should work. Very nice. I can't wait for other web servers to gain this ability too. Or at least allow us to load certificates from dynamic locations based on some request data.

All other web servers I looked at (nginx, apache, lighttpd) still require at least a reload for an updated certificate and a configuration file change for a new certificate to be used.

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?

> 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.

Know of an automated caddy docker reverse proxy container?

Here's an nginx one. Took about < 5 mins to add to my docker-compose file and start proxying my existing site

https://hub.docker.com/r/dmp1ce/nginx-proxy-letsencrypt/

Would love to see a caddy version of same

---

hmm, I guess the current caddy docker images can do this though though they need a little more configuration

There's ongoing discussion about this here: https://github.com/mholt/caddy/issues/199

One of my tasks this week is to get this in motion.

Wow. I might check try it out then.

It really does do what it says it does.

https://github.com/Xe/dotfiles/tree/master/ansible/roles/cad...

https://xena.greedo.xeserv.us

I would definitely recommend it, I've replaced a few instances of nginx with it with no problems. It is based on the really solid net/http code from golang std lib and adds a few nice things like automatic tls/certs.

If you're open to using OpenResty (basically nginx with some additional plugins and Lua integration), I've coincidentally been working on a plugin to make all of this completely automatic with Let's Encrypt (taking advantage of the relatively new ssl_certificate_by_lua functionality OpenResty provides): https://github.com/GUI/lua-resty-auto-ssl We just rolled it out to our first production site last week, but any feedback would be welcome.

Or better yet, make "ssl_letsencrypt on;" the default. Make it so that newbies can just apt-get install nginx/apache/lighttpd/etc. and have https up and running, no questions asked. The real reason https adoption isn't up to par has less to do with people not willing to spend money, and more because it's not up by default. Now that https is free, please make it enabled by default.

Check out Caddy, which enables HTTPS by default: https://caddyserver.com/docs/automatic-https

That was something that I complained about even before letsencrypt. It's insanely difficult for anyone except crypto experts to figure out a sane selection of cipher suite, so why can't they not just include one or two sane presets with the application, that get updated along with it when algorithms are broken and new ones emerge?

I just went threw a full configuration and the cipther suit was the easiest. I had some guides and the basically said, copy this or this depending on how prohibitive you want it.

The hardest thing to figure out is HPKP (and I still have not).

are the guides up to date?

I used https://cipherli.st/

hopefully it's good, if not it isn't protecting anything important really

Me too. I'm disappointed, this would be THE killer feature. Hope they are working on it (they should imho.)

I think its not gona be easy as that - there has to be some croned process and some kind of error handling. (I created https://hub.docker.com/r/analogic/lemanager/ which does both but i am still waiting for some better "native" solution)

It could hypothetically be that easy, AFAICT. Nginx service runs constantly, so a module could presumably execute scheduled tasks. Those tasks could have error checking, sending errors to the root inbox.