Hacker News Reader

Comment by koolba | Hacker News Reader

Hey this is pretty cool. Would be even cooler if it held off on the SSL handshake with the initial client until after the certificate was issued by LetsEncrypt. If it's only a couple of seconds it might be possible.

View on HN

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

Nice work!

We'll look into including this in pfsense 2.4.

Ah I didn't realize that. I figured the first request kicks off the request process so it's available for subsequent requests. This is even cooler!

Or it would be even greater if it requested/generated all certificates upon configuration file parsing and delayed nginx from taking those values into account until valid certificates have been obtained.

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!

Reply on news.ycombinator.com