Hey Emeric,
>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
>'.').
No I did not notice this, but I believe this is actually a good thing.
This way, crt-list entries with a filter will always get processed and
added to the tree since they will always be a ³new² SNI entry.
>
>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.
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
