I. Introduction to the Environment
To be notified that the Web site from HTTP to use HTTPS, currently my site front-end architecture as shown:
650) this.width=650; "src=" Http://s2.51cto.com/wyfs02/M00/7F/72/wKioL1cfFiviTO_AAAEJI0txodI055.jpg "title=" Qq20160426150836.jpg "alt=" Wkiol1cffivito_aaaeji0txodi055.jpg "/>
Suppose we have two physical machines, each of which has a lot of tomcat containers on it, the front end uses the HTTP layer load balancer of haproxy, and the LVS load balancer is used in the front end, the entire LVS is using the DR model.
At first I intend to change Tomcat to HTTPS, set to set Haproxy later, found that haproxy can no longer use load balancer, because SSL is on the fourth level, so this scheme is over, I will try to set up the Haproxy layer SSL, A normal connection to the backend is also used.
Second, the setup step
1. Overview
If your app uses SSL certificates, you'll need to decide how to use them on your load balancer.
A simple configuration of a single server is usually a way to consider how the client SSL connection is decoded by the server receiving the request. Because the load balancer is between the client and more servers, the SSL connection decoding becomes the focus of attention.
2. There are two main strategies
650) this.width=650; "src=" Http://s2.51cto.com/wyfs02/M00/7F/72/wKioL1cfGrSDKHXBAACdnMdjznE007.jpg "title=" Qq20160426153341.jpg "alt=" Wkiol1cfgrsdkhxbaacdnmdjzne007.jpg "/>
The first is the mode we choose, where SSL is set up in haproxy so that we can continue to use seven-tier load balancing. The SSL connection terminates in the load Balancer haproxy-----> decodes the SSL connection and sends a non-encrypted connection to the backend app Tomcat, which means that the load balancer is responsible for decoding the SSL connection, which, in contrast to SSL penetration, sends an SSL connection directly to the proxy server.
The second uses SSL penetration, and SSL connections are terminated on each Tomcat server, and the CPU load is distributed to the Tomcat server. However, doing so will allow you to lose the ability to add or modify HTTP headers because the connection is simply routed from the load balancer to the Tomcat server, which means that the application server loses the ability to acquire the x-forwarded-* header, which contains the client IP address, port, and protocol used.
There are two combinations of strategies, that is, the third, the SSL connection terminates at the load balancer, adjusts on demand, and then proxies to the backend server as a new SSL connection. This may provide maximum security and the ability to send client information. The cost of doing this is more CPU power and a slightly more complex configuration.
Which strategy you choose depends on the needs of you and your application. SSL terminals are the most typical strategy I have ever seen, but SSL penetration can be more secure.
3. Use Haproxy as SSL terminal
First, we will introduce the most typical solution-SSL terminal. As mentioned earlier, we need to have the load Balancer handle SSL connections. This means that you want to place the SSL certificate on the Load Balancer server.
Remember that using an SSL certificate in a production environment (rather than self-signed) does not require you to generate or sign your own-you just need to create a certificate signing request (CSR) and hand it over to the institution that you purchased the certificate from.
First, we create a self-signed certificate as a demonstration and use the same certificate locally.
Openssl genrsa -out /etc/haproxy/wzlinux.key 2048openssl req -new -key /etc/haproxy/wzlinux.key -out /etc/haproxy/wzlinux.csr> Country Name (2 letter code) [AU]:CN> State or Province Name (full name) [Some-State]:Shanghai> Locality Name (eg, city) []:Shanghai> organization name (Eg, company) [Internet Widgits Pty Ltd]:wzlinux> Organizational Unit Name (eg, section) []:> Common Name (e.g. server fqdn or your name) []:www.wzlinux.com> email address [ ]:> please enter the following ' Extra ' attributes to be sent with your certificate request> A challenge password []:> an optional company name  []:cd /etc/haproxyopenssl x509 -req -days 3655 -in wzlinux.csr - Signkey wzlinux.key -out wzlinux.crt
This generates the Wzlinux.csr,wzlinux.key and WZLINUX.CRT files.
Next, after creating the certificate, we need to create a PEM file. PEM files are essentially simply stitching together certificates, keys, and certificate Authentication Center certificates (optional) into a single file. In our example, we simply stitch the certificate and key file together in this order to create the Wzlinux.pem file. This is the preferred way for Haproxy to read SSL certificates.
Cat Wzlinux.crt Wzlinux.key | Tee WZLINUX.PEM
When you buy a real certificate, you don't necessarily get the stitched file. You may want to splice them yourself. However, many organizations will provide you with a well-stitched document. If you don't get the stitched file, it might not be a PEM file, but a bundle, cert, cert, key file, or some similar file with the same concept but a name.
In any case, as long as we get the Pem file used by Haproxy, we simply have to configure it to handle the SSL connection.
Below we will configure Haproxy to install the SSL certificate, the configuration file is as follows
#---------------------------------------------------------------------# example configuration For a possible web application. see the# full configuration options online.## http://haproxy.1wt.eu/download/1.4/doc/configuration.txt##------ ---------------------------------------------------------------#----------------------------------------------- ----------------------# global settings#------------------------------------------------------------ ---------Global # to have these messages end up in /var/log/haproxy.log you will # need to:  #    # 1) configure syslog to accept network log events. this is done # by adding the '-R ' option to the syslogd_options in # /etc/ SYSCONFIG/SYSLOG    #    # 2) configure local2 events to go to the /var/log/haproxy.log # file. a line like the following can be added to # /etc/sysconfig/syslog # # local2.* /var/log/haproxy.log # log 127.0.0.1 local2 warning chroot /var/lib/haproxy pidfile /var/run/haproxy.pid maxconn 400000 user haproxy group haproxy daemon tune.ssl.default-dh-param 2048# nbproc 3 # turn on stats unix socket stats socket /var/lib/haproxy/stats #---------------------------------------------------------------------# common defaults that all the ' Listen ' and ' backend ' sections will# use if not designated in their block#--------------------------------------------------------------- ------defaults mode http log global option httplog option dontlognull option http-server-close option forwardfor except 127.0.0.0/8 option redispatch option httpclose retries 3 timeout http-request 10s timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout http-keep-alive 10s timeout check 10s stats enable stats hide-version stats uri /haproxy?status stats realm haproxy\ statistics stats auth admin:asd870719# stats admin if true#---------------------------------------------------------------------# main frontend which proxys to the backends#----------------------------------------------- ----------------------#frontend main *:5000# acl url_static path_beg -i /static /images /javascript /stylesheets# acl url_static path_end -i .jpg .gif .png .css .js# use_backend static if Url_static# &nbsP;default_backend appfrontend wzlinux_ssl bind *:80 bind *:443 ssl crt /etc/haproxy/wzlinux.pem mode http default_backend wzlinux#----------------------------------- ----------------------------------# static backend for serving up images, stylesheets and such#---------------------------------------------------------------------#backend static# balance roundrobin# server static 127.0.0.1:4331 checkbackend wzlinux mode http balance roundrobin option forwardfor option httpchk head / http/1.1\r\nhost:localhost server wzlinux01 10.0.0.9:8080 check inter 15000 rise 2 fall 4 server wzlinux02 10.0.0.9:8081 check inter 15000 rise 2 fall 4 server wzlinux03 10.0.0.9:8082 check inter 15000 rise 2 fall 4 server wzlinux04 10.0.0.9:8083 check inter 15000 rise 2 fall 4 server wzlinux05 10.0.0.9:8084 check inter 15000 rise 2 fall 4 server wzlinux06 10.0.0.9:8085 check inter 15000 rise 2 fall 4 server wzlinux07 10.0.0.9:8086 check inter 15000 rise 2 fall 4 http-request set-header X-forwarded-port %[dst_port] http-request add-header x-forwarded-proto https if { ssl_fc }
Because the SSL connection terminates on the load balancer, we still send a normal HTTP request to the backend server.
Accept SSL Connections only
If you want the Web site to accept only SSL connections, you can add a redirect-to-front configuration plus a guide:
Frontend Wzlinux_ssl bind *:80 bind *:443 SSL CRT/ETC/HAPROXY/WZLINUX.PEM REDIRECT scheme HTTPS if! {SSL_FC} mode http Default_backend wzlinux
Above, we added the redirect guidance, which redirects HTTP to https if the connection is not connected over SSL.
4. Using Haproxy to achieve SSL penetration
With SSL penetration, we'll have the backend server handle the SSL connection, not the load balancer.
The load balancer's job is simply to forward the request to the configured backend server. Because the connection remains encrypted, Haproxy can only forward it to other servers, and nothing else is possible.
In this configuration, we need to use TCP mode instead of HTTP mode in both front-end and background configuration. Haproxy only uses connections as a stream of information to be forwarded to other servers without using features that can be used on HTTP requests.
First, let's adjust the front-end configuration:
Frontend Wzlinux_ssl bind *:80 bind *:443 option tcplog mode TCP Default_backend Wzlinux
The 80 and 443 ports are still bound together to ensure that both the normal HTTP connection and the SSL connection will work.
As mentioned above, forwarding a secure connection and the server without any decoding, we need to use TCP mode (mode TCP). This also means that we need to set the TCP log instead of the default HTTP log (option Tcplog).
Next, we'll adjust the background end configuration. Note that we will also change this to TCP mode and remove some directives to avoid conflicts caused by modifying/adding the HTTP header feature:
backend wzlinux mode tcp balance roundrobin option ssl-hello-chk server wzlinux01 10.0.0.9:8080 check inter 15000 rise 2 fall 4 server wzlinux02 10.0.0.9:8081 check inter 15000 rise 2 fall 4 server wzlinux03 10.0.0.9:8082 check inter 15000 rise 2 fall 4 server wzlinux04 10.0.0.9:8083 check inter 15000 rise 2 fall 4 server wzlinux05 10.0.0.9:8084 check inter 15000 rise 2 fall 4 server wzlinux06 10.0.0.9:8085 check inter 15000 rise 2 fall 4 server wzlinux07 10.0.0.9:8086 check inter 15000 rise 2 fall 4
As you can see, this is set to mode TCP-front-end and background configuration needs to be set to this pattern.
We also removed the option forwardfor and http-request options-these cannot be used in TCP mode, and we cannot add headers to an encrypted request, and some of the previous default configurations also delete the configuration for HTTP, which is no longer demonstrated here.
To check for correctness, we can use SSL-HELLO-CHK to check the connection and its ability to handle SSL (especially SSLv3) connections.
In this example, I have invented two background servers that accept SSL certificates. If you have read edition SSL certificates, you will see how to integrate them into Apache or Nginx to create a Web server backstage to handle SSL communication. With SSL traversal, you do not need to create or use an SSL certificate for Haproxy. The background server can handle SSL connections as if there were only one server and not using a load balancer.
In about how to set up LVS distribution here no more setting up a demo, you can view my article about LVs.
This article is from the "Little Water Drop" blog, please make sure to keep this source http://wangzan18.blog.51cto.com/8021085/1767920
Connect using an SSL certificate in Haproxy