Connect using an SSL certificate in Haproxy

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&nbsp []: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