Oh. So that's what they meant by "variables support" in the ssl directives. I didn't realize the significance of that change when I read the changelog earlier today.

What is? Looks like the link goes to a changelog and nothing else.

The original title for this item was "Nginx 1.15.9 adds support for dynamic certificate loading" which explains why this is interesting, but then someone edited it to the current less useful version ¯\_(ツ)_/¯

Noticed via https://hackernewstitles.netlify.com/

> Noticed via https://hackernewstitles.netlify.com/

Of course that's a thing.

Bear in mind: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_c...

    Note that using variables implies that a certificate will be loaded for each SSL handshake, and this may have a negative impact on performance.

Still a great feature. About to significantly simplify a few complex deployments I'm running.

Mostly likely the certificates will stay in filesystem's cache because of the number of reads, and memcpy of some pages isn't a huge deal unless you're having 100K+ active and short-lived sessions per nginx instance.

Parsing is probably slower than memcpy

Fair enough, but the server parses only the private key which is already well structured in any encoding. I haven't checked myself, but I believe correctness checks are ran on the reloading of a configuration.

That's a strange disclaimer. There should've been a cache there.

Strange and potentially busted, if that interpretation is correct.

What if your ACME client is updating the certificate and private key when an nginx connection comes in?

You can't atomically update both files, right? So nginx will potentially see a mismatched key and certificate?

:\

I hope it's guarded by SIGHUP, like sibling comment suggests.

You don't need to atomically replace 2 files. Renewing the certificate does not entail changing the private key, so unless you toss away the private key yourself you won't get a mismatched key and certificate situation.

It only needs to update the certificate, a single operation, which can be done atomically. Certificates are also renewed ahead of time so a previous connection still having the old cert is not an issue.

Is it still best practice to create a new key on cert renewal? It was just a few years ago.

FWIW, Certbot does, by default, replace the private key on renewal.

ACME clients should write the private key and certificate to a temporary file, then move it to the final destination so that the change is atomic.

The change to /each/ file is atomic, but both updates /together/ aren't atomic.

Put them in a diectory and move the directory?

This won't work AFAIK.

open takes a file path and gives you back a fd that doesn't know anything about fs paths (it tracks the underlying inode).

Thus, nginx may open(key) before the directory is renamed, and open(cert) afterwards. The first fd is now pointing to the old key, while the second fd points to the new cert.

https://linux.die.net/man/2/openat solves that specific issue.

The actual problem is you can't atomically replace a directory with another one. You have to do tricks where you have a symlink to the real directory and atomically replace the symlink with a new symlink to the new directory.

Another comment pointed out though that most of the time you only need to update the cert, and not the key. So it's mostly a moot issue..

Was thinking same, now that certs are free I tend to just use single domain certs but maybe that is not ideal? Suppose you could modify this[1] to mv / symlink dir as final step for multi domain certs. https://github.com/h0l0gram/letsencrypt-utils/blob/master/le...

That would work for one file but there's no way to atomically rename two.

You should only need to update the certificate not the private key

I suppose you could do it if you placed them in a directory, and renamed that. But I don't think that's what Certbot does, I think it works by changing file symlinks individually.

The actual problem is the other way around: you can’t open two files atomically.

There's a format that stores key and cert in the same file. Name escapes me now and I'm not sure if nginx supports it.

Edit: it does. Just use that instead of messing with separate files

Great question.

You have a cache, if you SIGHUP the nginx process it'll reload the config and certificates on disk. With a simple script it is possible to SIGHUP when the certificate file is changed on disk.

Does nginx still halt the master process when you have more than 70k cert/key pairs and send it a hup?

I cannot find any any information on how this data is sanitized.

   /safe/path/$hostname.key
   $hostname = ../../etc/some/secret
   /safe/path/../../etc/some/secret.key

That wouldn't be a valid hostname or Host-header, see https://tools.ietf.org/html/rfc952

Host headers are transmitted after the ssl handshake.

SNI?

I read through the codebase and can't assert that couldn't happen... wasn't sure if the ngx_http_ssl_certificate callback could be executed after a point where any of the client-controlled variables from [1] are defined.

[1] - https://nginx.org/en/docs/http/ngx_http_ssl_module.html#vari...

Nifty. I've been using ssl_certificate_by_lua_block from the openresty nginx lua module to accomplish this.

So with poll() now available on Windows is nginx ready to drop the beta label for Windows?

http://nginx.org/en/docs/windows.html

Why are they still supporting Windows Vista?!

Most likely because of Windows Server 2008: they are almost the same.

If there is a feature ‘for Windows Vista or newer’ that implies they support even older versions.

Probably that's the version that introduced the poll API. They developed it on Win10, then noticed oh it should work on Vista. Tested it [maybe] and put it in the changelog. (And probably they have nginxplus customers that need Vista support?)