Product Documentation

    In typical production Encryption & Key Management (EKM) environments using the SAKA, there are at least two (2) SAKA servers configured in an active-active cluster for high availability. Each cluster-node is capable of handling cryptographic services independently while replicating to every other node asynchronously in the background. As such, sites may choose to redirect their client applications to requesting cryptographic webservices from all nodes in the EKM, as shown in the following diagram. This distributed communication can be achieved in many ways:

    • Through round-robin DNS which serves up a different IP address from the cluster for the common FQDN known to the client applications;
    • Through a configuration file on the client application that knows of all nodes and their FQDNs in the cluster and uses an application-specific algorithm to communicate with a different node for webservices;
    • Through a commercial load-balancer that hosts a single FQDN for client applications, but directs traffic to all nodes in the cluster; or
    • Through an free and open-source load-balancer that hosts a single FQDN for client applications, but directs traffic to all nodes in the cluster.

    This appendix explains how to set up a free and open source load balancer - HAProxy (available in the Base repository for most Linux distributions) - on a separate server (called the proxy-server in this document) running Rocky Linux.

    To install and configure HAProxy for use with the SAKA server cluster, follow the steps below:

    1. Install the standard Rocky Linux 9.x Linux distribution on a VM provisioned for this setup.
    2. Login to the server as root.
    3. Install HAProxy using the Yellowdog Updater, Modified (yum) tool: 
      shell> yum install haproxy
    4. Create a self-signed certificate to be used by HAProxy, replacing the value in the -subj parameter with the value relevant to the site. The most important element within this parameter is the CN component—the value must match the FQDN of the VM used for this load balancer; so if one chooses to name your VM sakaserver.mydomain.com then the -subj parameter may simply be /CN=sakaserver.mydomain.com 
      shell> openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/pki/tls/private/sakaserver.key -out /etc/pki/tls/certs/sakaserver.crt -subj "/CN=saka01.strongkey.com"
    5. Concatenate the generated key and certificate files into a single file, preserving the names of the files as shown below: 
      shell> cat /etc/pki/tls/certs/sakaserver.crt /etc/pki/tls/private/sakaserver.key > /etc/pki/tls/certs/sakaserver.pem
    6. Using a text editor, edit the HAProxy configuration file to make the following changes: 
      shell> vi /etc/haproxy/haproxy.cfg
    7. Replace the contents with the following and replace the <ip-sakaserver1> and <ip-sakaserver2> parameters with the IP addresses for the SAKA servers: 
      global
        log 127.0.0.1 local0
        log 127.0.0.1 local1 debug
        maxconn 45000 # Total Max Connections.
        daemon
        nbproc 1 # Number of processing cores.
      defaults
        timeout server 86400000
        timeout connect 86400000
        timeout client 86400000
        timeout queue 1000s
      listen https_web
        bind *:443 ssl crt /etc/pki/tls/certs/sakaserver.pem
        option tcplog
        mode http
        balance roundrobin
        option forwardfor
        server server1 <ip-sakaserver1>:8181 check ssl verify none
        server server2 <ip-sakaserver2>:8181 check ssl verify none
    8. Create a firewall rule to open port 443 to allow the web application to communicate with the load balancer: 
      shell> firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" port port=443 protocol=tcp accept'
    9. Restart HAProxy: 
      shell> service haproxy restart
    10. Verify HAProxy is functioning as expected by accessing the URL in the browser. If it is functioning correctly, it will redirect you to one of the configured SAKA servers. 
      https://<sakaserver.mydomain.com_>

     

    Selinux

    If the above URL cannot be accessed in the browser, ensure that the selinux config has been set to permissive instead of enforcing. The following command will show the current status of selinux:

    shell> sestatus

    If it is set to enforcing, change it to permissive by running the following command (this is a temporary fix that will reset on machine reboot, and which will be updated in a future release):

    shell> setenforce 0