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
