Hello Oliver, On 12/1/2015 12:32 AM, Olivier Doucet wrote: > Hello, > > I'm digging out this thread, because having multiple certificate for one > single domain (SNI) but with different key types (RSA/ECDSA) can really > be a great functionality. Is there some progress ? How can we help ? >
In the mean time, you can use this: http://blog.haproxy.com/2015/07/15/serving-ecc-and-rsa-certificates-on-same-ip-with-haproxy/ > A subsidiary question is : how much ECDSA certificates are supported ? > So if I use a single ECDSA certificate, how many people wont be able to > see my content ? On a fairly busy site (couple tens of millions requests per day), roughly 85% of the clients have been found ECDSA capable. Regards, Nenad > > > Olivier > > > 2015-08-25 18:16 GMT+02:00 Willy Tarreau <[email protected] <mailto:[email protected]>>: > > Hi Dave, > > On Tue, Aug 25, 2015 at 03:50:23PM +0000, Dave Zhu (yanbzhu) wrote: > > Hey Willy, > > > > On 8/25/15, 10:36 AM, "Willy Tarreau" <[email protected] > <mailto:[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? > > In my opinion that only adds extra burden because this delay adds > loss of > knowledge or association between the certs that were initially loaded at > the same time. > > > 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. > > I'm not much concerned by this for now because when you have many FQDN, > you already have as many SSL_CTX today. I tend to consider that large > configs (the ones where memory footprint starts to matter) don't have > many names for each of their certs. For example the config that led to > crt-list being designed was working with 50000 certificates. I really > doubt that there were more than 1-2 names per cert on average, I'd even > bet something around 1.01 or so in average. > > > 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. > > That's the part I tend to dislike. If we later add extra parameters in > crt-list, we'll be happy to keep each line separate and *not* to merge > them. The example of validity dates was one such case but there could > be other ones. > > While this may seem a stupid or completely made up example, imagine that > we could specify on each line of the crt-list a filter on the source > network > to decide if the cert has to be presented or not. This way users could > decide that certs signed with official CAs are delivered to the public > while certs signed with internal CAs are delivered inside. Or even just > to use different algos depending on the network, for example test ECDSA > just on internal users first. As long as we keep all the elements of one > crt-list entry tied together, all such fantasy remains possible. When we > tear them apart and only focus on names to pack everything together, > this > is not possible anymore. You said yourself that the memory usage doesn't > matter much here, let's not risk to sacrify extensivity for the sake of > trying to compress just a few more bytes. > > > 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 <http://www.blahDomain.com> > > SANs: 1.blahDomain.com <http://1.blahDomain.com> > > 2.blahDomain.com <http://2.blahDomain.com> > > 3.blahDomain.com <http://3.blahDomain.com> > > > > Cert B(ECDSA) > > > > CN: www.blahDomain.com <http://www.blahDomain.com> > > > > SANs: 2.blahDomain.com <http://2.blahDomain.com> > > 3.blahDomain.com <http://3.blahDomain.com> > > 4.blahDomain.com <http://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 <http://www.blahDomain.com>; SSL_CTX#1={Cert > A, > Cert B} > > 2: Name=1.blahDomain.com <http://1.blahDomain.com>; SSL_CTX#2={Cert A} > > > > 3: Name=2.blahDomain.com <http://2.blahDomain.com>; SSL_CTX#1={Cert > A, Cert B} > > > > 4: Name=3.blahDomain.com <http://3.blahDomain.com>; SSL_CTX#1={Cert > A, Cert B} > > > > 5: Name=4.blahDomain.com <http://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. > > In the case I proposed, it would be exactly the same, without > requiring to > merge all of them by name between different lines. > > > 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. > > That's why I prefer not to change the existing selection logic which is > documented and deployed. Also, please keep in mind that changing > anything > here is really vicious because issues may happear days or weeks > after the > code change, just because some tricky setups were deployed and > happened to > work before the update. We definitely need to make users not lose > trust in > the product if it has been working well for a year or so for them. > > But overall, I think we're all aiming towards more or less the same > directions > and coming to comparable conclusions after identifying the same > problem, which > is encouraging! > > Thanks, > Willy > > >
