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
$HTTP[host]
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
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 luky...@hotmail.com wrote:
I have
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
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 Name
Ah OK. We
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 that. You
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, what if
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,
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
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.
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
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:
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
13 matches
Mail list logo