On Fri, Aug 21, 2015 at 05:07:30PM +0000, Dave Zhu (yanbzhu) wrote:
> 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?
>From what I remember, the purpose is to be able to do something like
this in the crt-list :
wildcard.mydomain.pem !secure.mydomain.com
secure.mydomain.pem secure.mydomain.com
The first cert is a wildcard and is not proposed for secure.mydomain.com
while the second one is.
Also I seem to remember about something related to being able to exclude
wildcard subdomains though I don't remember exactly how. I guess it's
like this :
wildcard.mydomain.pem .mydomain.com !.fr.mydomain.com
wildcard-fr.mydomain.pem .fr.mydomain.com
The second one will handle all domains ending in .fr.mydomain.com and
the first one will carefully avoid them.
At some point we had a discussion about being able to load multiple
certs for the same domains and ignoring those out of the validity date,
which would make it convenient to load the old and new certs and let
haproxy present the first valid one matching the name, but I don't
think it was implemented (or maybe only at load time, I don't remember).
But that comes back to the original discussion : should haproxy or openssl
decide on what cert to present. From what I'm seeing now, we have downsides
with the two options :
- openssl seems to offer limited options when there isn't a perfect
overlapping between certs (eg: one is a wildcard, the other not);
- openssl supports a single DH param for both certs;
- haproxy will have a hard time respecting the ciphers chain to
present the most suited cert;
If we add stricter rules to help in the first option, such as ensuring
that two apparently identical certs just differ by their algos and nothing
else, we risk to upset users trying to migrate from RSA to DSA who will
change a few things at the same time (such as taking this opportunity to
pick a larger dh-param or to extend the cert's life, or add extra alt names).
And if we're not that strict, they'll be upset if we can't ensure that the
correct cert is always delivered.
I'm starting to think that maybe we'd need to have 3 SSL_CTX when we support
two certs for the same domain :
- one with only the first cert;
- one with only the second;
- one with both.
And depending on the differences in the crt-list rules, we'd point to
a different SSL_CTX.
Maybe I'm thinking too far ?
Willy
