4 ms·
That's a strange disclaimer. There should've been a cache there.
by uasm 8y ago
That's a strange disclaimer. There should've been a cache there.
- zaarn 8y agoYou 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.
- scurvy 8y agoDoes nginx still halt the master process when you have more than 70k cert/key pairs and send it a hup?
- regecks 8y agoStrange 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.
- ngrilly 8y agoGreat question.
- emersion 8y agoACME 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.
- spatz 8y agoThat would work for one file but there's no way to atomically rename two.
- regecks 8y agoI 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.
- tinus_hn 8y agoThe actual problem is the other way around: you can’t open two files atomically.
- rubatuga 8y agoYou should only need to update the certificate not the private key
- scurvy 8y agoThere'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
- nightfly 8y agoThe change to /each/ file is atomic, but both updates /together/ aren't atomic.
- weinzierl 8y agoPut them in a diectory and move the directory?
- drewmol 8y agoWas 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/letslink.sh https://github.com/h0l0gram/letsencrypt-utils/blob/master/le...
- kilburn 8y agoThis 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.
- viraptor 8y agohttps://linux.die.net/man/2/openat https://linux.die.net/man/2/openat solves that specific issue.
- nightfly 8y agoThe 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..
- daenney 8y agoYou 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.