Re: Cert hot-reloading

On Tue, Sep 01, 2020 at 11:09:18PM -0400, Michael Richardson wrote: > My reading of the CABForum push towards 13 month validity, and the > LetsEncrypt 90-day process it that private key replacements are not > necessarily replaced that often. Perhaps so, but the mechanism needs to be general enoug

Re: Cert hot-reloading

Having read through the thread, I think that Viktor is assuming that the private key will always be replaced. My reading of the CABForum push towards 13 month validity, and the LetsEncrypt 90-day process it that private key replacements are not necessarily replaced that often. The shortest *certi

Re: Cert hot-reloading

On 2020-09-01 06:57, Viktor Dukhovni wrote: On Mon, Aug 31, 2020 at 11:00:31PM -0500, David Arnold wrote: 1. Construe symlinks to current certs in a folder (old or new / file by file) 2. Symlink that folder 3. Rename the current symlink to that new symlink atomically. This is fine, but does no

Re: Cert hot-reloading

On 2020-09-01 04:26, Viktor Dukhovni wrote: On Aug 31, 2020, at 10:57 PM, Jakob Bohm via openssl-users wrote: Given the practical imposibility of managing atomic changes to a single POSIX file of variable-length data, it will often be more practical to create a complete replacement file, then

Re: Cert hot-reloading

On Tue, Sep 01, 2020 at 12:22:30AM -0500, David Arnold wrote: > A SSL_CTX api seem like a good idea to provide additional guarantees to > applications. > > Maybe Openssl - used as a library - can return to the other legacy > applications that the certificate is "deemed not valid any more" wheneve

Re: Cert hot-reloading

A SSL_CTX api seem like a good idea to provide additional guarantees to applications. Maybe Openssl - used as a library - can return to the other legacy applications that the certificate is "deemed not valid any more" whenever they try to use an outdated pointer? This ought to be a transparent sc

Re: Cert hot-reloading

On Mon, Aug 31, 2020 at 11:00:31PM -0500, David Arnold wrote: > 1. Construe symlinks to current certs in a folder (old or new / file by file) > 2. Symlink that folder > 3. Rename the current symlink to that new symlink atomically. This is fine, but does not provide atomicity of access across file

Re: Cert hot-reloading

1. Construe symlinks to current certs in a folder (old or new / file by file) 2. Symlink that folder 3. Rename the current symlink to that new symlink atomically. On OpenSSL side statd would have to follow through on symlinks - if it shouldnt do so. This is +- how kubernetes atomically provisions

Re: Cert hot-reloading

> On Aug 31, 2020, at 10:57 PM, Jakob Bohm via openssl-users > wrote: > > Given the practical imposibility of managing atomic changes to a single > POSIX file of variable-length data, it will often be more practical to > create a complete replacement file, then replace the filename with the > "m

Re: Cert hot-reloading

On 2020-09-01 01:52, Viktor Dukhovni wrote: On Sun, Aug 30, 2020 at 07:54:34PM -0500, Kyle Hamilton wrote: I'm not sure I can follow the "in all cases it's important to keep the key and cert in the same file" argument, particularly in line with openat() usage on the cert file after privilege t

Re: Cert hot-reloading

On Sun, Aug 30, 2020 at 07:54:34PM -0500, Kyle Hamilton wrote: > I'm not sure I can follow the "in all cases it's important to keep the key > and cert in the same file" argument, particularly in line with openat() > usage on the cert file after privilege to open the key file has been > dropped. I

Re: Cert hot-reloading

On 8/31/2020 6:29 AM, Karl Denninger wrote: > > I'm trying to figure out why you want to replace the context in an > *existing* connection that is currently passing data rather than for > new ones. > No, not for existing connections, just for new ones using the same context. Note that I'm interes

Re: Cert hot-reloading

On 8/30/2020 10:26 PM, Kyle Hamilton wrote: > Could this be dealt with by the simple removal of any caching layer > between an SSL_CTX and a directory processed by openssl c_rehash? > Would reading the filesystem on every certificate verification be too > heavy for your use case? That might well b

Re: Cert hot-reloading

On 8/30/2020 7:24 PM, David Arnold wrote: > Hot-plugging the pointer seems to force atomicity considerations > down-stream, which might be > educationally a good thing for openssl to press for. It also addresses > Jordan's use case, for however > application specific it might be. For compat reasons

Re: Cert hot-reloading

On 8/30/2020 20:19, Jordan Brown wrote: Well, I can restate the problem that I encountered. We deliver an integrated storage system.  Under the covers it is a modified Solaris running a usual collection of proprietary and open-source components.  We supply an administrative user interface tha

Re: Cert hot-reloading

Could this be dealt with by the simple removal of any caching layer between an SSL_CTX and a directory processed by openssl c_rehash? Would reading the filesystem on every certificate verification be too heavy for your use case? On Sun, Aug 30, 2020 at 7:20 PM Jordan Brown wrote: > > Well, I can

Re: Cert hot-reloading

Should aspects of an implementation be configurable behavior with a sane default? I'd guess so... Hot-plugging the pointer seems to force atomicity considerations down-stream, which might be educationally a good thing for openssl to press for. It also addresses Jordan's use case, for however a

Re: Cert hot-reloading

I'm not sure I can follow the "in all cases it's important to keep the key and cert in the same file" argument, particularly in line with openat() usage on the cert file after privilege to open the key file has been dropped. I agree that key/cert staleness is important to address in some manner, b

Re: Cert hot-reloading

Well, I can restate the problem that I encountered. We deliver an integrated storage system.  Under the covers it is a modified Solaris running a usual collection of proprietary and open-source components.  We supply an administrative user interface that, among many other things, lets you manage a

Re: Cert hot-reloading

On 8/30/2020 19:28, Viktor Dukhovni wrote: On Sun, Aug 30, 2020 at 05:45:41PM -0500, David Arnold wrote: If you prefer this mailing list over github issues, I still want to ask for comments on: Certificate hot-reloading #12753 Specifically, m

Re: Cert hot-reloading

On Sun, Aug 30, 2020 at 05:45:41PM -0500, David Arnold wrote: > If you prefer this mailing list over github issues, I still want to ask > for comments on: > > Certificate hot-reloading #12753 > > > Specifically, my impression is that this topic