Encrypt IHS proxypass traffic to Component Pack

I’m still working on encrypting all network traffic between Connections and Component Pack servers. This time I checked the Ingress-Nginx Controller - TLS/HTTPS documentation.

The default configuration for connecting IHS with Component Pack uses the plain HTTP port 32080. All traffic like /social or the Tailored Experience wizard is routed from IHS to Kubernetes on port 32080.

Our target is to encrypt the traffic on port 32443.

Traffic Flow Process

#

1. Client Connection: Client connects to HAProxy Load Balancer (port 443)
2. HAProxy Routing: HAProxy has two forwarding rules:
   • Rule 1: Forward HTTP/HTTPS traffic (443) to IBM HTTP Server
   • Rule 2: Forward specific traffic to Kubernetes cluster (32443)
3. IBM HTTP Server Processing: IBM HTTP Server processes requests and uses ProxyPass to forward back to HAProxy (port 32443)
4. Kubernetes Routing: HAProxy forwards the ProxyPass traffic to Kubernetes NGINX Ingress (port 32443)
5. Service Distribution: NGINX Ingress Controller routes requests to appropriate services and pods within the cluster

Port Configuration

#

• Client → HAProxy: 443 (HTTPS)
• HAProxy → IBM HTTP Server: 443
• IBM HTTP Server → HAProxy: 32443 (ProxyPass)
• HAProxy → Kubernetes: 32443
• NGINX Ingress: Receives on 32443, routes internally to services

Example Infrastructure Components

#

Create Certificate

#

First, we need to create a certificate for the ingress service. I used a self-signed certificate here, as it is not visible to our users, but you can also obtain an official one or request it from your company CA.

I created a certificate for the hostname cnx8-db2.stoeps.home and added the Kubernetes server as an alias. Additionally, I added the IP addresses of both servers.

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ingress.key -out ingress.cert -subj "/CN=cnx8-db2.stoeps.home/O=stoeps.home" -config <(cat <<EOF
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no

[req_distinguished_name]
CN = cnx8-db2.stoeps.home
O = stoeps.home

[v3_req]
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = cnx8-db2.stoeps.home
DNS.2 = cnx8-db2-cp.stoeps.home
IP.1 = 10.0.22.92
IP.2 = 10.0.22.95
email.1 = admin@stoeps.home
EOF
)

I added the Kubernetes hostname and IP address, as I want to test connections directly during troubleshooting. For basic functionality, the IP address and hostname of the load balancer are sufficient.

Add Certificate to Kubernetes Secret

#

Now upload the newly created certificate to a secret:

kubectl create secret tls ingress-secret --key ingress.key --cert ingress.cert -n connections

Edit Deployment for Ingress

#

The deployment cnx-ingress-ingress-nginx-controller needs an additional line to use the certificate (see line 14 in the next code block):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

 spec:
   containers:
   - args:
     - /nginx-ingress-controller
     - --default-backend-service=$(POD_NAMESPACE)/cnx-ingress-ingress-nginx-defaultbackend
     - --publish-service=$(POD_NAMESPACE)/cnx-ingress-ingress-nginx-controller
     - --election-id=cnx-ingress-ingress-nginx-leader
     - --controller-class=k8s.io/ingress-nginx
     - --ingress-class=nginx
     - --configmap=$(POD_NAMESPACE)/cnx-ingress-ingress-nginx-controller
     - --validating-webhook=:8443
     - --validating-webhook-certificate=/usr/local/certificates/cert
     - --validating-webhook-key=/usr/local/certificates/key
     - --default-ssl-certificate=connections/ingress-secret

To automate this step, use kubectl patch to add the line:

kubectl patch deployment cnx-ingress-ingress-nginx-controller \
  -n connections \
  --type='json' \
  -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--default-ssl-certificate=connections/ingress-secret"}]'

Restart All Deployments and StatefulSets

#

With up-to-date Kubernetes, we can restart with these two commands:

kubectl rollout restart sts -n connections
kubectl rollout restart deploy -n connections

Configure IBM HTTP Server (IHS)

#

Get the root certificate with openssl:

cd /opt/IBM/HTTPServer
openssl s_client -connect 10.0.22.95:32443 -servername 10.0.22.95 -showcerts < /dev/null 2>/dev/null | openssl x509 -outform PEM > server-cert.pem

Add ingress.cert as a trusted signer to the IHS keystore:

bin/gskcapicmd -cert -add -db cnx8-db2-was-key.kdb -pw password -label "ingress-root-cert" -file server-cert.pem

Edit /opt/IBM/HTTPServer/conf/httpd.conf:

cp conf/httpd.conf conf/httpd_conf.$(date +%F_%H%M%S)
# Change port to 32443
sed -i 's/32080/32443/g' conf/httpd.conf
# Change http to https in lines containing 32443
sed -i '/32443/s/http:/https:/g' conf/httpd.conf

Add SSLProxyEngine On to httpd.conf (right after the entries ProxyPreserveHost On), then IHS will support TLS ProxyPass entries.

Restart HTTPServer: bin/apachectl -k graceful

On the Load Balancer (Optional)

#

Edit /etc/haproxy/haproxy.cfg

Copy the frontend cnx_ingress_http and backend masters_cnx_ingress_http, then replace 32080 with 32443 again.

The new sections will look like this:

frontend cnx_ingress_https
    bind *:32443
    mode tcp
    option tcplog
    timeout client  10800s
    default_backend masters_cnx_ingress_https

backend masters_cnx_ingress_https
    mode tcp
    option tcplog
    option tcp-check
    balance roundrobin
    default-server inter 10s downinter 5s rise 2 fall 2 slowstart 60s maxconn 1000 maxqueue 1024 weight 100
        server cnx8-db2-cp.stoeps.home cnx8-db2-cp.stoeps.home:32443 check

Restart haproxy:

systemctl restart haproxy

Conclusion

#

With these configuration changes, we have successfully encrypted the network traffic between IBM HTTP Server and the Kubernetes NGINX Ingress Controller, moving from the unencrypted port 32080 to the secure port 32443. Combined with our previous work on Redis traffic encryption, we’ve significantly improved the security posture of our HCL Connections deployment.

The implementation covers the critical communication path where user data flows from the web server through the load balancer to the Kubernetes cluster. All ProxyPass traffic is now protected with TLS encryption, ensuring data confidentiality in transit.

The remaining component that still needs attention is Customizer, which presents its own unique challenges for traffic encryption. This will be the focus of future security enhancements as we work toward fully encrypted inter-service communication across the entire Connections infrastructure.