Hey Emeric, >> >> >> In 1.0.2, we can make use of API to load multiple certificate chains >>into >> a CTX. Prior to 1.0.2, you could not load the chains. So the checks >>ensure >> that we make use of the new APIs, and can then serve the correct >> certificate to users based on the user¹s cipher suite. >I see, but if the feature is only half-supported for openssl version < >1.0.2 we should simply avoid to use it on these versions.
I don’t use it in earlier versions of OpenSSL, and I default back to existing behavior. This should not be an issue >Anyway, I admit i'm a little scared with your latest patches, you re-code >a large part of certificates loading and i'm currently unable to >guarantee that there is no regressions on linked features (SNI, ocsp, >crt_list, passphrase management). > >The first proposal was very less intrusive (the ones which don't used >1.0.2 API but secret callback). But i understand the point of view of the >experts of the mailing list . > >Did you expore an intermediate solution: > >Continue to load keys/certificates etc in one new allocated SSL_CTX and >when you fill the SNI tree, if the certificate comes into collision with >an other, extract key/cert/chain from the early allocated SSL_CTX to >fill/complete the already existing one? I don't know >if Openssl API provide enougth primives to do that. But it will certainly >have less impact on the existing behavior. I have considered doing this in the beginning. However, OpenSSL doesn’t really provide any good ways to pull key information out of an SSL CTX. But what you’ve described is basically what I’m doing, just with refactoring around the code that loads the certs. -Dave
