[openssl-users] Confirmation of what I believe to be true from docs and observation

[Benjamin Kaduk]

On 01/10/2018 08:41 AM, Karl Denninger wrote:
>
> We start with a context that I load a dhparam file to (so I can take a
> DH connection) along with an edh curve, then set an acceptable cipher
> list for it to use.
>

Why not just use AUTO_DH (the only option for 1.1.0, IIRC)?

> Assume I next manually load both the CA store (using
> X509_STORE_add_cert as many times as necessary to load the
> intermediate components and the root of trust) and then load the
> cert/key pair (using SSL_CTX_use_certificate/SSL_CTX_use_PrivateKey)
>
> I then create some number of SSLs from that context to perform
> communication with and all is well.
>
> Now I want to rekey that context for some reason.  It appears that
> while I can add things to
>

Why do you need to rekey the context as opposed to making a new one?

In general, making configuration changes to an SSL_CTX after it has been
used to generate SSL objects is a risky proposition -- the locking model
does not really account for doing synchronization properly, and there
might be some latent race conditions.  In practice, some operations are
currently safe, but there is no authoritative list of which ones, and at
least my personal recommendation is to not try to rely on it.

> the CA chain trying to load the same component that is already in
> there returns a failure (somewhat-expected; that is, it does not
> overwrite but rather adds, and if you try to add what's already there
> you get an error back) and there's no call to CLEAR the certificate
> validation chain -- if I want to *replace* the validation chain I have
> to destroy the context and initialize a new one from scratch.
>

N.B. that the X509_STORE_add_cert behavior when presented with a
duplicate certificate changed in commit
c0452248ea1a59a41023a4765ef7d9825e80a62b (from returning an error to
doing nothing and returning success); this will be in 1.1.1.

As to the desired behavior, there does not seem to be an API to remove
an entry from an X509_STORE.  With the above caveat about thread-safety
in mind, couldn't you just make a call to SSL_CTX_set{1}_cert_store() to
replace the X509_STORE without tearing down the whole SSL_CTX?

> It appears, however, that I *can* load over the top of a certificate
> and private key of the same type and that's acceptable.  In other
> words, if I have an RSA key/cert pair in the context and I load
> another one, the first one is replaced.  This *looks* to be working ok
> as far as I can tell and it doesn't appear to leak memory doing that
> but it's not explicitly stated that this is considered acceptable
> (rather than destroying and re-creating the context.)
>

The leaf certificate and private key are stored as arrays (for different
types of certificates) of pointers in the associated CERT structure, and
the "set" routines do not currently check for and error out if there is
already one set.

> Is my understanding correct?
>
>

Mostly ... but I am not sure that your desired workflow is wise.

-Ben