Hey Willy,
On 8/25/15, 10:36 AM, "Willy Tarreau" <[email protected]> wrote:
>This means that the RSA/DSA/ECDSA cert names must be derived from the
>original cert name.
I¹ve thought of a way to avoid this behavior, with the end result being
very similar to what you/Emeric proposed.
What if we delayed the creation of the SSL_CTX until we have all the certs
specified by the config? We would read in all the certificates first and
store them based on the CN/SAN inside the cert, or the SNIs specified by
the admin. We would also store the auxiliary information as well at this
point. Your tree would look like:
Names -----> Certificates + aux info
We then iterate on all of the Names and create an SSL_CTX for each Name
based on the certificates available + any wildcard/negation filters we
have. This will fill out our FQDN tree. After creating the SSL_CTX¹s we
could free the original tree, as it would no longer be needed.
In this scenario, each FQDN would have an SSL_CTX associated with it,
which is a departure from the current model. While this may seem like a
huge spike in memory footprint, consider that OpenSSL uses references for
keys and certificates. Therefore, the additional impact is limited to the
extra pointers in SSL_CTX, instead of duplicating X509 or PKEY buffers. We
could also add additional logic to search through the current FQDN tree
for ³duplicate² SSL_CTX that contain the same cert/keys, and just use the
pointer instead of creating a new SSL_CTX. Given enough metadata around
the SSL_CTX in the FQDN tree, this shouldn¹t be too hard.
I feel that this would solve the problem of admins having to keep track of
the certificate names, and keep the current behavior of ³Let HAProxy
figure out the certs, here¹s a bunch of them².
It would also solve the issue of conflicting names. For example:
Cert A(RSA):
CN: www.blahDomain.com
SANs: 1.blahDomain.com
2.blahDomain.com
3.blahDomain.com
Cert B(ECDSA)
CN: www.blahDomain.com
SANs: 2.blahDomain.com
3.blahDomain.com
4.blahDomain.com
If we optimize the insertion logic via metadata, we would have the
following in our FQDN tree:
1: Name=www.blahDomain.com; SSL_CTX#1={Cert A, Cert B}
2: Name=1.blahDomain.com; SSL_CTX#2={Cert A}
3: Name=2.blahDomain.com; SSL_CTX#1={Cert A, Cert B}
4: Name=3.blahDomain.com; SSL_CTX#1={Cert A, Cert B}
5: Name=4.blahDomain.com; SSL_CTX#3={Cert B}
Like your proposal, we would have 3 distinct SSL_CTX¹s in memory, and 5
entries in the FQDN table.
If the admin specified multiple certificates and wildcards that met the
same criteria, we would have to decide on which cert goes into the SSL_CTX
for that FQDN. My personal preference is to use the explicit before the
wildcard, but either way the logic would not be difficult.
Thoughts?
-Dave
