Re: Self-signed cert at haproxy, formal cert on backend web server
On 3/18/2022 9:28 AM, Moore, Dan [TREAS] wrote: This all works except the client browser is showing the connection as insecure. Would a formal certificate at haproxy fix this or is there another way to keep the browser happy using the self-signed cert? The config I'm using is below. Thanks! Yes, you need a real cert signed by a public CA on whatever users actually connect to with https, in this case it's haproxy. On your setup, the end user will never see the certificate on the backend server, they will only see the certificate that haproxy gives them. The place to use a self-signed certificate is on the backend servers. There is an option for haproxy to have it not validate the certificate chain, I can't remember what it is. I've worked hard on my setup to eliminate the need for SSL on the backend. It was only recently that I figured out how to accomplish this on all my sites. Wordpress and a WSGI application called dnote were the ones that I had the hardest time configuring to force https even though the connection to Apache is unencrypted. Once I figured out how to configure those applications, I was able to completely eliminate the SSL virtualhosts from my Apache configuration, and haproxy talks to Apache on localhost port 81. TL;DR: The way I got the wsgi application to force https was with this directive in the Apache virtualhost: WSGITrustedProxyHeaders X-Forwarded-For X-Forwarded-Proto Thanks, Shawn
Self-signed cert at haproxy, formal cert on backend web server
Hello all,
We have been using SSL passthrough for a long time but a new set of
applications require I
decrypt at the load-balancer to direct traffic and re-encrypt for sending to
the backend. For
testing, I'm using a self-signed cert at haproxy and the back end web server
has a formal certificate.
This all works except the client browser is showing the connection as insecure.
Would a formal
certificate at haproxy fix this or is there another way to keep the browser
happy using the
self-signed cert? The config I'm using is below. Thanks!
frontend http-in-nlbtest
bind xx.xx.xx.xx:80
bind xx.xx.xx.xx:443 ssl crt /x/ec-x.pem # Note:
self-signed cert
mode http
no option http-server-close
timeout client 1m
http-request add-header X-Forwarded-Proto https
http-request add-header X-Forwarded-Port 443
http-response add-header Strict-Transport-Security max-age=3600 # 60
minutes
acl Host_NLBTest hdr_beg(host) -i nlbtest
use_backend Cluster_NLBTEST_NoSSL if !{ ssl_fc } Host_NLBTest
use_backend Cluster_NLBTEST_SSL if{ ssl_fc } Host_NLBTest
backend Cluster_AD_APPENV2019_PRODUCTION_SSL
modehttp
balance roundrobin
server backendhost1 backendhost1:443 ssl verify none check-ssl
maxconn 128
server backendhost2 backendhost2:443 ssl verify none check-ssl
maxconn 128
Re: [PATCH] CI: switch to LibreSSL-3.5.1
On Wed, Mar 16, 2022 at 12:29:41PM +0500, Илья Шипицин wrote: > Hello, > > as LibreSSL-3.5.1 is released, let us switch to the most recent release. > > thanks, > Ilya Thanks, applied. -- William Lallemand
Re: CI caching improvement
On Wed, Mar 16, 2022 at 09:31:56AM +0100, Tim Düsterhus wrote: > Willy, > > On 3/8/22 20:43, Tim Düsterhus wrote: > >> Yes my point was about VTest. However you made me think about a very good > >> reason for caching haproxy builds as well :-) Very commonly, some VTest > >> randomly fails. Timing etc are involved. And at the moment, it's impossible > >> to restart the tests without rebuilding everything. And it happens to me to > >> click "restart all jobs" sometimes up to 2-3 times in a row in order to end > > > > I've looked up that roadmap entry I was thinking about: A "restart this > > job" button apparently is planned for Q1 2022. > > > > see https://github.com/github/roadmap/issues/271 "any individual job" > > > > Caching the HAProxy binary really is something I strongly advice against > > based on my experience with GitHub Actions and CI in general. > > > > I think the restart of the individual job sufficiently solves the issue > > of flaky builds (until they are fixed properly). > > > > In one of my repositories I noticed that this button is now there. One > can now re-run individual jobs and also all failed jobs. See screenshots > attached. > Hello Tim, It looks like it is available as well on our repositories, I just test it and it works correctly. Honestly I really don't like the dependency to another repository with a format specific to github. I agree that a cleaner integration with github with their specific tools is nice, but I don't want us to be locked with github, we are still using cirrus, travis, sometimes gitlab, and also running some of the scripts by hand. We also try to avoid the dependencies to other projects and its much simplier to have few shell scripts and a CI configuration in the repository. And typescript is not a language we would want to depend on if we need to debug it for example. Giving that github is offering the job restart feature, we could skip the VTest caching, since it's a little bit ugly. Only the quictls cache need to be fixed. Regards, -- William Lallemand
