On Fri, Jul 28, 2017 at 05:04:16PM +0200, Emmanuel Hocdet wrote:
> I talk with the case we don't want a default cert. With strict-sni the « fake
> » default_cert can be use if it as sni (i don't want that ideally).
> with strict-sni: no certificate match sni -> no ssl connection.
> I add strict-sni to haproxy because customers call when browser show warning
> with https on their vhost (without certificat), and they don't wont that.

That's a good point to keep in mind.

> The question is: force to have a default certificat is really necessary?
> generate an error or move to a warning? I understand the old use case but
> what about the strict-sni use case? is not incompatible with the default_ctx
> relax.

The default cert is useful every time the strict-sni is not in use. In fact
you are in the position of a hosting provider with no reason for presenting
your company's name instead of a hosted customer's cert when unknown, but
the other situation is very common : company "acme" has a certificate for
"www.acme.com" and occasionally needs a temporary vhost on "dev.acme.com"
or "cms.acme.com" or "support.acme.com" but they don't want to have to buy
and deploy an extra cert just for this, especially when they already have
a few domains in the alt names of the first cert. So it's very common to
see them just create the new name and fall back to the default cert. For
partners it's not a problem, they see a browser warning, they check it,
can confirm the cert is not for the correct hostname but valid for the same
domain (eg: www.acme.com when they asked for support.acme.com) and they can
pass through. It also happens with multi-tld names. You can have "acme.fr"
redirect to "acme.com" without having to buy a cert for "acme.fr". Just a
warning once in a while and that's all.

Then of course there's the case of the certificate generation on the fly
which needs one private key. Using that of the default cert is the current
choice and it makes quite some sense. It's obviously exclusive with strict-sni
by definition!

All these use cases are pretty valid and we just need to keep them all in
mind when seeking the proper fix.

Willy

Reply via email to