On 6/24/15, 2:58 PM, "Willy Tarreau" <w...@1wt.eu> wrote: >What I'm understanding here is that instead of using SNI only as the key >to pick a cert, we want the (SNI, algo) combination. Coudln't we have two >certs per SNI entry ? One in RSA form, the other one in ECDSA, and only >provide what is supported ? We could even consider that whenever a client >advertises support for ECDSA we should provide it first as it saves CPU >cycles. I guess that RSA won't go away for a long time and might still >be there in 10 years anyway, so selecting first on SNI and second on the >algo with a fallback to the only cert present in the SNI for most cases >where there's a single one sounds the right approach.
I agree that this is the best approach to take. I¹ll begin to shift my implementation to do this. It currently does not take SNI into account. >I could be wrong but I think that we have as many SSL_CTX as we load >certs, >and we pick the correct one based on the SNI, so it should probably not be >an issue in our case with either version. Yup, this is true. I¹ll have to do some more research on how the EB trees work in HAProxy. I think the current code just looks for the first match, whereas the new code should look for all matches and pick based on algo. >BTW, please take care of surrounding your code with the appropriate ifdefs >if you think you're using features from recent libs. Yup, I¹m trying to be as mindful as I can about this. Thanks for the feedback! -Dave
