Client TLS Authentication for Request Resolution

Overview

The article describes how to enable a secure request resolution of requests coming through a load balancer or multiple load balancers to the DirX Access Server. The secure request resolution is important in case X.509 authentication takes place though multiple components.

In test environments, if only the DirX Access Server is in the game, the X.509 certificate used for authentication on the DirX Access Server side is taken from the SSL context. The problem is that this never happens in real life deployments. In real life deployments, there are many components in front of the DirX Access Server and an SSL context can only exist between two components. The SSL context cannot be forwarded or redirected. The X.509 certificate can only be obtained after successful Client TLS authentication.

The solution for the real life deployments is that the DirX Access Server can also accept an X.509 certificate from the X-SSL-CERT header, where the first load balancer can place the certificate after successful SSL/TLS handshake with the client.

It is really important to secure the request resolution because any client could send us a certificate in the header and perform the authentication (if configured) on behalf of any user. The client should really authenticate itself that we know we can accept the resolution of the request.

The following configuration will differ from the real life deployment, but can be used as an example.

Load Balancer

As the first component in line, the load balancer should extract the X.509 certificate from the SSL context. It should also explicitly authenticate itself to meet the secure request resolution when passing the load to another component.

Configuration

The configuration is related to the Nginx - Load Balancing where the load is balanced between the two DirX Access Bridges.

#
# NGINX (Load Balancer) configuration
#
...
http {
    ...
    upstream mycompany10115 {
        server my-server1.my-company.example:11915;
        server my-server2.my-company.example:12915;
    }
    ...
    server {
        listen       10115 ssl;
        server_name  my-server.my-company.example;

        # Nginx SSL connector
        ssl_certificate      my-company.crt;
        ssl_certificate_key  my-company.key;
        # Nginx client verification
        ssl_verify_client    optional_no_ca;

        location / {
            # Reference to upstream
            proxy_pass https://mycompany10115;
            # Mutual authentication between Nginx and DirX Access Bridge
            proxy_ssl_certificate         my-company.crt;
            proxy_ssl_certificate_key     my-company.key;
            # The end user certificate after the SSL handshake is placed in the request header
            proxy_set_header X-SSL-CERT $ssl_client_escaped_cert;
            # External Host header in the request
            proxy_set_header Host my-server.my-company.example:10115;
        }
    }
}

Please mind the directives of the HTTP Proxy module:

Please mind also the variable $ssl_client_escaped_cert of the HTTP SSL Module.

DirX Access Bridge

As the second component in line, the Bridge forwards the load to the DirX Access Server without any change.

The extracted certificate still remains in the request header and therefore the request resolution must be set to secure again.

Inbound Connection

Prerequisite

Installation of the Bridge.

Configuration

On the side of an inbound SSH connector, authentication by (incoming) client certificate must be set as needed.

## Whether client certificate authentication is required.
jetty.sslContext.needClientAuth=true

Outbound Connection

Configuration

On the side of an outbound web application that forwards the load, we need to set up the second client TLS authentication between the DirX Access Bridge and the DirX Access Server to secure the X.509 certificate in the header.

Please mind the optional init-param(s) of all webapps/{connTo}.war/WEB-INF/web.xml files of the Bridge:

Parameter Description

keyStore

The KeyStore file path (relative to Bridge/jetty-base folder) of the SSL Context Client Factory of the HTTP client of the {connTo} web application. Use it to set the client TLS authentication between the web application and the specific port of the DirX Access Server.

trustStore

The TrustStore file path (relative to Bridge/jetty-base folder) of the SSL Context Client Factory of the HTTP client of the {connTo} web application. Use it to set the client TLS authentication between the web application and the specific port of the DirX Access Server.

keyStorePassword

The KeyStore password.

trustStorePassword

The TrustStore password.

keyStoreType

The KeyStore type [JKS | PKCS12].

trustStoreType

The TrustStore type [JKS | PKCS12].

Each web application uses its own HTTP client with its own SSL configuration. By default, and if the init-param(s) are not used, the client verifies the certificate sent by the server by verifying the certificate chain at the TLS level (in the JDK via cacerts truststore). This is not enough to secure the request resolution and the certificate in the header.

It is necessary to configure the optional parameters of the SSL Context Client Factory to secure the request resolution of the outbound connection where the X.509 certificate is sent in the header.

DirX Access Server

In cases where any component sends us credentials in a header such as X509 authentication, it is necessary to force secure resolution of requests on the DirX Access Server.

Prerequisite

The configuration of secure request resolution is related to port assignment configuration. Please pay attention to the port assignment configuration.

Configuration

The option to accept an X509 certificate from the X-SSL-CERT header can be turned on via the option "Do client certificate from proxy request header resolution".

In the PortAssignment configuration, it is absolutely necessary to turn on the option "Do verify proxy request resolution" and select a "Proxy truststore identifier" to verify the client certificate, where the client in this case is a component sending or forwarding the request with the X-SSL-CERT header.