Trending: Jul 20- Jul 27 : Shahid Kapoor spills the beans about charging Rs. 35 crores as fee post the success of Kabir Singh
Haproxy w/ Keepalived using SSL Passthrough example.
Hello, I'm trying to configure Haproxy w/ Keepalived to pass TLS encrypted traffic from the VIP to the underlying hosts which are also themselves running with TLS Certificates. Highlevel overview of the setup: server1:7182 ( TLS Encrypted ) 10.0.0.1 server2:7182 ( TLS Encrypted ) 10.0.0.2 srv-cluster01:7182 10.0.0.3 ( TLS Encrypted ) Right now I have the client trying to connect to the server via an Haproxy/Keepalived two node cluster, however I'm getting: SSLError: certificate verify failed Both the server is Java based and so is the Client Agent app. I've added the private key to the /etc/pki/ca-trust/extracted/java/jssecacerts Appears as if though the traffic is passing through however the certs aren't matching up. So I'm wondering if anyone could share their config that I could use as an example of how things should be configured in this scenario. -- Thx, TK.
stable-bot: WARNING: 29 bug fixes in queue for next release - 1.8
Hi, This is a friendly bot that watches fixes pending for the next haproxy-stable release! One such e-mail is sent periodically once patches are waiting in the last maintenance branch, and an ideal release date is computed based on the severity of these fixes and their merge date. Responses to this mail must be sent to the mailing list. Last release 1.8.20 was issued on 2019/04/25. There are currently 29 patches in the queue cut down this way: - 3 MAJOR, first one merged on 2019/04/30 - 20 MEDIUM, first one merged on 2019/04/29 - 6 MINOR, first one merged on 2019/04/29 Thus the computed ideal release date for 1.8.21 would be 2019/05/14, which was ten weeks ago. The current list of patches in the queue is: - MAJOR : map/acl: real fix segfault during show map/acl on CLI - MAJOR : listener: fix thread safety in resume_listener() - MAJOR : lb/threads: make sure the avoided server is not full on second pass - MEDIUM : tcp-check: unbreak multiple connect rules again - MEDIUM : tcp-checks: do not dereference inexisting conn_stream - MEDIUM : lb_fwlc: Don't test the server's lb_tree from outside the lock - MEDIUM : contrib/modsecurity: If host header is NULL, don't try to strdup it - MEDIUM : protocols: add a global lock for the init/deinit stuff - MEDIUM : da: cast the chunk to string. - MEDIUM : connection: fix multiple handshake polling issues - MEDIUM : spoe: arg len encoded in previous frag frame but len changed - MEDIUM : mux-h2: make sure the connection timeout is always set - MEDIUM : dns: make the port numbers unsigned - MEDIUM : compression: Set Vary: Accept-Encoding for compressed responses - MEDIUM : lb_fas: Don't test the server's lb_tree from outside the lock - MEDIUM : lb-chash: Fix the realloc() when the number of nodes is increased - MEDIUM : http/htx: unbreak option http_proxy - MEDIUM : vars: make the tcp/http unset-var() action support conditions - MEDIUM : vars: make sure the scope is always valid when accessing vars - MEDIUM : http: fix "http-request reject" when not final - MEDIUM : spoe: Don't use the SPOE applet after releasing it - MEDIUM : listener: Fix how unlimited number of consecutive accepts is handled - MEDIUM : port_range: Make the ring buffer lock-free. - MINOR : http: Call stream_inc_be_http_req_ctr() only one time per request - MINOR : http-rules: mention "deny_status" for "deny" in the error message - MINOR : deinit/threads: make hard-stop-after perform a clean exit - MINOR : ssl_sock: Fix memory leak when disabling compression - MINOR : proxy: always lock stop_proxy() - MINOR : http_fetch: Rely on the smp direction for "cookie()" and "hdr()" --- The haproxy stable-bot is freely provided by HAProxy Technologies to help improve the quality of each HAProxy release. If you have any issue with these emails or if you want to suggest some improvements, please post them on the list so that the solutions suiting the most users can be found.
stable-bot: INFO: 3 bug fixes in queue for next release - 1.9
Hi, This is a friendly bot that watches fixes pending for the next haproxy-stable release! One such e-mail is sent periodically once patches are waiting in the last maintenance branch, and an ideal release date is computed based on the severity of these fixes and their merge date. Responses to this mail must be sent to the mailing list. Last release 1.9.9 was issued on 2019/07/23. There are currently 3 patches in the queue cut down this way: - 2 MEDIUM, first one merged on 2019/07/26 - 1 MINOR, first one merged on 2019/07/26 Thus the computed ideal release date for 1.9.10 would be 2019/08/23, which is in four weeks or less. The current list of patches in the queue is: - MEDIUM : protocols: add a global lock for the init/deinit stuff - MEDIUM : lb-chash: Fix the realloc() when the number of nodes is increased - MINOR : proxy: always lock stop_proxy() --- The haproxy stable-bot is freely provided by HAProxy Technologies to help improve the quality of each HAProxy release. If you have any issue with these emails or if you want to suggest some improvements, please post them on the list so that the solutions suiting the most users can be found.
stable-bot: INFO: 3 bug fixes in queue for next release - 2.0
Hi, This is a friendly bot that watches fixes pending for the next haproxy-stable release! One such e-mail is sent periodically once patches are waiting in the last maintenance branch, and an ideal release date is computed based on the severity of these fixes and their merge date. Responses to this mail must be sent to the mailing list. Last release 2.0.3 was issued on 2019/07/23. There are currently 3 patches in the queue cut down this way: - 2 MEDIUM, first one merged on 2019/07/26 - 1 MINOR, first one merged on 2019/07/26 Thus the computed ideal release date for 2.0.4 would be 2019/08/23, which is in four weeks or less. The current list of patches in the queue is: - MEDIUM : lb-chash: Fix the realloc() when the number of nodes is increased - MEDIUM : protocols: add a global lock for the init/deinit stuff - MINOR : proxy: always lock stop_proxy() --- The haproxy stable-bot is freely provided by HAProxy Technologies to help improve the quality of each HAProxy release. If you have any issue with these emails or if you want to suggest some improvements, please post them on the list so that the solutions suiting the most users can be found.
Re: 'sni' parameter - reasonable default/implicit setting ?
That looks right on - thanks for the pointer ! I couldn't tell from the brief gander I took - works the same for 'server-template' as for 'server' ? On Sat, Jul 27, 2019 at 2:53 AM Aleksandar Lazic wrote: > Hi. > > Am 27.07.2019 um 00:24 schrieb Jim Freeman: > > For outgoing TLS connections, might haproxy be taught to use a reasonable > > default/implicit value 'sni' [1] expression/behavior that would 'first > do no > > harm'[2], and usually be correct, in the absence of an explicit > expression ? > > (Understood that haproxy depends on an SSL lib) > > > > E.g.; req.hdr(host) if it is set, else server(-template) (if > it is > > cfg'd as name, not IP), else ssl_fc_sni for bridged HTTPS, else ... ? > > > > If SNI [3] is used vs. an endpoint that doesn't require/utilize it, is > it always > > innocuous ? > > > > Are increasing demands by service providers that clients (e.g.; haproxy > vs. an > > SSL endoint) send SNI inevitable? Or is some alternative pending? > > I think this is similar Ideas as the vhost patch intend to solve. > > https://www.mail-archive.com/haproxy@formilux.org/msg34532.html > > I think the patch should be adopted for `mode tcp` also, jm2c. > > > Just wondering, > > ...jfree > > Best Regards > Aleks > > > [1] http://cbonte.github.io/haproxy-dconv/1.9/configuration.html#sni > > [2] https://en.wikipedia.org/wiki/Primum_non_nocere > > https://en.wikipedia.org/wiki/Robustness_principle > > [3] https://en.wikipedia.org/wiki/Server_Name_Indication > > > > > >
Re: 'sni' parameter - reasonable default/implicit setting ?
Hi. Am 27.07.2019 um 00:24 schrieb Jim Freeman: > For outgoing TLS connections, might haproxy be taught to use a reasonable > default/implicit value 'sni' [1] expression/behavior that would 'first do no > harm'[2], and usually be correct, in the absence of an explicit expression ? > (Understood that haproxy depends on an SSL lib) > > E.g.; req.hdr(host) if it is set, else server(-template) (if it is > cfg'd as name, not IP), else ssl_fc_sni for bridged HTTPS, else ... ? > > If SNI [3] is used vs. an endpoint that doesn't require/utilize it, is it > always > innocuous ? > > Are increasing demands by service providers that clients (e.g.; haproxy vs. an > SSL endoint) send SNI inevitable? Or is some alternative pending? I think this is similar Ideas as the vhost patch intend to solve. https://www.mail-archive.com/haproxy@formilux.org/msg34532.html I think the patch should be adopted for `mode tcp` also, jm2c. > Just wondering, > ...jfree Best Regards Aleks > [1] http://cbonte.github.io/haproxy-dconv/1.9/configuration.html#sni > [2] https://en.wikipedia.org/wiki/Primum_non_nocere > https://en.wikipedia.org/wiki/Robustness_principle > [3] https://en.wikipedia.org/wiki/Server_Name_Indication > >
