0 - https://github.com/mholt/caddy/pull/913
The approach to locking we're using is somewhat simplistic (and the specifics depend on the storage adapter you're using), so there might be some rare edge-cases in which 2 requests to Let's Encrypt slip through. However, that shouldn't actually affect the functionality (the last response simply wins). Here's a bit more detail in the code: https://github.com/GUI/lua-resty-auto-ssl/blob/v0.8.2/lib/re...
That almost changed, but the current consensus seems to be that you should be using dns-01 for validation behind a load balancer instead.
The certificate cartel is slowly dying :)
We'll look into including this in pfsense 2.4.
But I do like the idea of allowing this to be handled at startup too. Thanks for the idea!
I had been playing around with https://github.com/jwilder/nginx-proxy and docker-gen to handle automatic Let's Encrypt generation for my docker containers.
It's amazing how quick to get some of these thing setup with very work:
I set up Courier today to use it for TLS imap
My $work has a very terribe DNS infrastructure that needs lots of work to implement dns-01.
Does assume you will have a shared volume so you can save/check certs, but it works great for my use case.
See https://github.com/GUI/lua-resty-auto-ssl#precautions and the "allowed_domain" configuration for a bit more detail.
This is a reason that being at least somewhat aware of the overall list of names to be covered ahead of time could be helpful.
OpenResty is a cool project, but it brings a lot of additional infrastructure along with it that you may not want.
It would be nice of this was clearly indicated in the title of this post.
Updated: see comment below, the README has been clarified, you can run this with the nginx_lua extension. You don't necessarily need all of OpenResty.
OpenResty 220.127.116.11 or higher
It becomes 98% of the time spent enabling this awesome feature (at least on CentOS and Fedora, from what I can tell there aren't RPM packages for ngx_lua).
If you want to give this a try within Docker I setup a repo here to try it out: https://github.com/msumpter/docker-lua-resty-auto-ssl
As others replied, x509 would be even more correct, but SSL is completely incorrect, because that protocol is insecure and shouldn't be used. Using SSL suggest that the software supports that protocol, although it doesn't (as it should)
What's in a name? That which we call TLS
By any other name would still offer encryption.
I'm going to call it certificateless SSL.