Hey Dave,
>> 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
>
I'm taking a look on how the feature interact with crt-list and its filters.
And there is a lot of inconsistencies:
First of all ssl_sock_get_ctx_from_eb_tree() is bugged
I think you don't notice that certificate in the wild card tree are not stored
using their fullnames (we exclude the '*' and start at the first '.').
A part from that,
multiple cert can be inserted in the tree for a same name. I think it was done
to manage the negation filter of the "crt-list" feature .
In 'static int ssl_sock_switchctx_cbk(SSL *ssl, int *al, struct bind_conf *s)',
we loop on multiple tree entries using the same name:
/* lookup in full qualified names */
node = ebst_lookup(&s->sni_ctx, trash.str);
/* lookup a not neg filter */
for (n = node; n; n = ebmb_next_dup(n)) {
if (!container_of(n, struct sni_ctx, name)->neg) {
node = n;
break;
}
}
In an other way, with none negative "crt-list" filter, we could store in 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.
These issues are not your fault, we always considered 1 certificate file == 1
SSL_CTX and we start to pay our tribute :)
I've no solution for the moment.
R,
Emeric
