On Fri, Feb 22, 2013 at 4:14 PM, Lukas Tribus wrote:
> If you upgrade to a recent snapshot you can use the strict-sni feature
> [1]. This way, when the client doesn't provide SNI, the handshake is
> aborted.
>
I'd rather not clutter the conf with redundant statements. If the client
doesn't suppo
Are you *only* selecting based on SNI? I ask because our setup uses
cookies as well, specifically to get around SNI issues (we store the
cookie on normal HTTP as well as HTTPS, and use it as a fallback if
SNI fails). If you have other things going on besides SNI, that
could explain that behaviour
If you upgrade to a recent snapshot you can use the strict-sni feature [1].
This way, when the client doesn't provide SNI, the handshake is aborted.
I think this is important even when your clients are supposed to support SNI;
the client may be buggy or the SNI detection in haproxy - strict-sni
Hello,
I upgraded to dev17 from dev15. I am running Tornado servers behind HAProxy
with SockJS support. Comparing to before the upgrade, I've noticed two
problematic behaviors:
1. When a client is using IE with xhr-streaming protocol to connect to
servers, such connections are closed (seeing 'Con
Hi,
As I mentioned in my original email - The problem is intermittent, i.e. it
works sometimes and other times not. And I do not mean with different
clients - A page refresh is sufficient for HAProxy to return the correct
certificate.
All clients that connect use TLS1.1 and have support for SNI.
On 22 February 2013 08:29, Kenneth Mutka wrote:
> Hi,
>
> I'm having a bit of a problem with my certificates. I have about 15 separate
> certificates, including the default one. Apart from listening to 443, I also
> have a bunch of regular HTTP sites.
>
> Now, obviously I am using the SNI features
unsubscribe
7 matches
Mail list logo
