National Renewable Energy Lab | Full-stack, back-end, or front-end | Golden, CO or Remote | Full-Time | https://www.nrel.gov
Hi! My team at the National Renewable Energy Laboratory (NREL) is looking to hire additional web developers who want to help make an impact on the future of transportation and climate. We're a US Department of Energy national lab focused on renewable energy research. Our team works on web sites, tools, and APIs to help disseminate transportation-related data (eg, where are all the locations you can charge an electric vehicle) or help consumers, fleets, and policy makers understand various options in this space.
Our team mostly works in Ruby on Rails, Vue.js, and PostgreSQL. Here are the full job listings with more details, or feel free to reach out to me if you want to chat (nick.muerdter [at] nrel [dot] gov):
Yes, by default the module requires that you explicitly whitelist the domains you want to allow certificate registration for. So while you could allow any domain to be registered, that's not recommended for this precise reason. But the whitelist is defined as a Lua function, so you have quite a bit of flexibility in integrating the whitelist logic with other sources of information.
I haven't actually looked into DVSNI in too much detail before, so that could definitely be the case. I'll have to investigate a bit more (or any pull requests are always welcome). Thank you for the tip!
Author here. I hadn't really considered it, but it should be possible. Since we're handling this with nginx and Lua, it made it pretty trivial to handle the simple HTTP challenge (since we can easily intercept the /.well-known/acme-challenge request), so that's why we went with that approach, but other approaches should be possible.
Yes, as long as you're using a shared storage adapter (like Redis), then for the most part, duplicate registration or renewal requests should be handled.
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...
Author here. Our current approach is perhaps a bit different, since we're not actually parsing the nginx config file, so we don't have knowledge of the domains at startup. Instead, we're relying on the "allow_domain" Lua function to be defined which provides a way to determine which domains should be allowed. By making this a Lua function, it allows for the logic behind this to be very flexible and dynamic (for example, nginx could handle wildcard requests to any domain, and then you could lookup what domains to allow SSL registration for from another dynamic source you might already have).
But I do like the idea of allowing this to be handled at startup too. Thanks for the idea!
Author here.. If I'm understanding you correctly, I believe that's how things are already working. The very first time a client hits a new domain, the SSL handshake initiates the certificate registration with Let's Encrypt (assuming the domain is part of the whitelist of allowed domains). The certificate is registered in the background, while this first request is paused. The SSL handshake is then completed with the first client once the certificate is successfully issued. This does lead to the very first client's request being delayed a few seconds, but this is a one-time delay (per allowed domain).
If you can use OpenResty (nginx+Lua), then that's exactly the approach I've taken for a plugin I've been developing recently (SNI, on-demand, and caching): https://github.com/GUI/lua-resty-auto-ssl There's still a couple loose ends to tie up, but we've been using it on production for a few weeks now, and it's been refreshingly nice to not worry about SSL for new domains.
Regarding the 5 requests per week, I believe that's only for repeated re-issuances of the same domain. As long as you cache the certs, then this shouldn't be an issue. Registering new certificates for new domains is limited to 500 per 3 hours: https://community.letsencrypt.org/t/rate-limits-for-lets-enc...
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.
Hi! My team at the National Renewable Energy Laboratory (NREL) is looking to hire additional web developers who want to help make an impact on the future of transportation and climate. We're a US Department of Energy national lab focused on renewable energy research. Our team works on web sites, tools, and APIs to help disseminate transportation-related data (eg, where are all the locations you can charge an electric vehicle) or help consumers, fleets, and policy makers understand various options in this space.
Our team mostly works in Ruby on Rails, Vue.js, and PostgreSQL. Here are the full job listings with more details, or feel free to reach out to me if you want to chat (nick.muerdter [at] nrel [dot] gov):
https://nrel.wd5.myworkdayjobs.com/en-US/NREL/job/Senior-Sof... https://nrel.wd5.myworkdayjobs.com/en-US/NREL/job/Developer-...