On 08/21/2015 08:08 PM, Emeric Brun wrote: > Hey Dave, > >>> the SNI tree a certificate regardless the CN/SAN. It's dirty i know, but >>> some people use it. >>> >>> You will also notice, reading 'ssl_sock_process_crt_file' that if we use >>> sni_filter (so filter in crt-list), a new ssl_ctx is always allocated and >>> stored. But if no filter is set on the "crt-list" line, >>> you will use SAN/CN to potentially complete an existing one. We reach an >>> unpredictable behavior depending of the line order in crt-list. >> >> Correct me if I¹m wrong, but sni_filter is only applied to the crtfile >> specified before the filter? So in the case, crt-list files without a user >> supplied SNI will be treated as ordinary crt files. >> >> In the current model, these are added as SNI entries in the tree. But >> these entries won¹t ever be used if there is another SNI entry that was >> loaded before. So even though they are added to the tree, they wouldn¹t >> ever be used? The behavior should remain consistent with what¹s there >> today. Or am I mis-interpeting the code? >> >> -Dave >> > > The issue is due to filters, I think the best is to write examples: > > crt.list: > (*.foobar.com RSA).pem *.foobar.com !foobar.foobar.com > (foobar.foobar.com RSA).pem > (foobar.foobar.com DSA).pem > > > You will complete (*.foobar.com RSA) SSL_CTX's using the (foobar.foobar.com > DSA). Because first line register the certificate in tree (with the flag > "neg"). > > An user connecting with SNI dummy.foobar.com will potentially retrieve > (foobar.foobar.com DSA).pem as a certificate. > > I think you can fix it looping on entries of same name and ignore those > flagged 'neg' in the tree. > > > There is other cases: > > (*.foobar.com RSA).pem > (*.foobar.com DSA).pem *.foobar.com > > Will always serve only the RSA.pem, because the second has a filter and in > your code it will not complete the first > > Whereas > (*.foobar.com RSA).pem *.foobar.com > (*.foobar.com DSA).pem > > Will serve both RSA and DSA, because the second will complete the first > regardless if the first was created with or without filter. > > But if you fix it, adding a lookup based on the filter to complete existing > cert we will reach new inconsistencies > > (*.foobar.com RSA).pem > (*.foobar.com DSA).pem *.foobar.com !foobar.foobar.com > > With that i expect to have both RSA/DSA available if dummy.foobar.com, but > always RSA for foobar.foobar.com. > > It doesn't appear trivial to handle and i express a real doubt: Is the SNI > tree and CN/SAN the right way to complete SSL_CTX with different > certificates/keys? > > If we're able to load the differents key/cert from the same pem file, we will > no have those inconsistencies. > > Or we could use additionnal extensions as we do for .ocsp and .issuers. > > R, > Emeric > > > > > > Hi All,
This stupid anti-spam flagged my last mail as a spam because f o o b a r. R, Emeric
