>> SAN = Subject Alternative Name
>
> Ah OK. We could double-check but I *believe* Emeric told me about
> something like this when he implemented the SNI. But I could be
> wrong and could confuse with something else. You could easily
> check in the code if you feel at ease with openssl's API (I
> p
On Thu, Jan 22, 2015 at 08:24:57PM +0100, Willy Tarreau wrote:
> Hi Simon,
>
> On Tue, Jan 20, 2015 at 01:22:38PM +0900, Simon Horman wrote:
> (...)
> > This seems to have slipped through the cracks.
> > I'm wondering if we could revisit it and the other patch in this series.
>
> Hmmm sorry for t
On Thu, Jan 22, 2015 at 02:28:11PM -0600, Nathan Neulinger wrote:
> >>Similar question for
> >>certs with SANs - does it consider the alternative names in the selection
> >>process?
> >
> >I don't know what SANs is.
>
> Lukas already answered my base question, but:
>
> SAN = Subject Alternative N
Hi Raphaël,
Le 12/01/2015 17:10, Raphaël Enrici a écrit :
Dear all,
nice to meet you (first post since a very lng time here).
As far as I understand it, when using the crt option of bind directive with a
directory as parameter, cert files from the specified directory are loaded...
Well, go
Wonderful! Thank you.
Looks like both the default behavior will work, and it has full capability for
manual control if needed. Nicely built!
-- Nathan
On 01/22/2015 01:31 PM, Lukas Tribus wrote:
Similar question for certs with SANs - does it consider the
alternative names in the selection pro
Similar question for
certs with SANs - does it consider the alternative names in the selection
process?
I don't know what SANs is.
Lukas already answered my base question, but:
SAN = Subject Alternative Name
example:
[root@cups-p1 ssl]# openssl x509 -in httpd.crt -text
Certificate:
Data
> Similar question for certs with SANs - does it consider the
> alternative names in the selection process?
Yes, as per the doc:
> The certificates will be presented to clients who provide a
> valid TLS Server Name Indication field matching one of
> their CN or *alt subjects*.
> And lastly, wha
On Thu, Jan 22, 2015 at 01:04:15PM -0600, Nathan Neulinger wrote:
> How does haproxy handle overlaps and wildcards?
>
> For example, if I have a cert for '*.domain.com' and 'something.domain.com'
>
> Does it automatically pick the more specific match?
yes, wildcards are only considered last.
>
Hi Simon,
On Tue, Jan 20, 2015 at 01:22:38PM +0900, Simon Horman wrote:
(...)
> This seems to have slipped through the cracks.
> I'm wondering if we could revisit it and the other patch in this series.
Hmmm sorry for that. You previously said that both patches were
right, do you simply want me to
How does haproxy handle overlaps and wildcards?
For example, if I have a cert for '*.domain.com' and 'something.domain.com'
Does it automatically pick the more specific match? Similar question for certs with SANs - does it consider the
alternative names in the selection process?
And lastly, w
> Is there any way to use SNI + specify the server name
> to certificate mapping?
>
> To specifically tell it "for requests coming in with SNI
> of ttrss.neulinger.org, use this certificate instead".
>
> Is there any way to do this equivalent with haproxy?
There is no need to, HAproxy does this au
For example, with lighttpd, I can do:
$SERVER["socket"] == ":443" {
ssl.engine = "enable"
ssl.pemfile = "/local/lighttpd-root/ssl/ssl.pem"
ssl.ca-file = "/local/lighttpd-root/ssl/chain.pem"
ssl.cipher-list = "AES256+EECDH:AES256+EDH:!aNULL:!eNULL"
> Lukas,
>
> Thanks for the update. How to verify whether haproxy already linked to
> openssl.
Can you use SSL or does it fail saying that you need to enable OpenSSL?
If the former is the case, then SSL is enabled, otherwise, its not.
> Please note that I'm not build the haproxy from source
Lukas,
Thanks for the update. How to verify whether haproxy already linked to
openssl. Please note that I'm not build the haproxy from source code. Is
there anyway to verify which version openssl used by haproxy?
On Wed, Jan 21, 2015 at 1:46 PM, Lukas Tribus wrote:
> > I have installed haproxy
14 matches
Mail list logo