Detections
Analytics

4.1.9 Ensure upstream server traffic is authenticated with a client certificate

Information

In a reverse proxy configuration, NGINX acts as a client when communicating with an upstream server. To secure this server-to-server connection based on a Zero Trust principle, m utual TLS (mTLS) must be used. This is achieved by configuring NGINX to present its own client certificate to the upstream server. The upstream server then authenticates NGINX based on this certificate, ensuring that only trusted proxies can access backend services.

Authenticating the proxy's connection to the upstream server via a client certificate provides strong, cryptographic proof of identity. This is vastly superior to weaker authentication methods like IP whitelisting, which can be spoofed. In a modern microservices or cloud environment, mTLS is a cornerstone of network security, as it prevents unauthorized services from making requests to sensitive backends, thereby mitigating lateral movement attacks.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance.

Solution

Implementing mTLS requires configuration on both the NGINX proxy (the client) and the upstream server (the server). This example assumes you have a simple internal CA.

Prerequisite: Create a CA

# Create CA Key
openssl genrsa -out my-ca.key 4096
# Create CA Certificate
openssl req -x509 -new -nodes -key my-ca.key -sha256 -days 3650 -out my-ca.crt

Step 1: Configure the Upstream Server to Require Client Certificates

The upstream server must be configured to request and verify client certificates against your CA. (If your upstream is also NGINX, the config would look like this):

# On the Upstream Server's configuration
server {
 listen 443 ssl;
 # ... other ssl directives ...

 ssl_client_certificate /path/to/my-ca.crt; # The CA to verify against
 ssl_verify_client on; # Require a valid client cert
}

Step 2: Create and Sign a Client Certificate for NGINX

On your NGINX proxy, create a key and a certificate signing request (CSR).

# Create a key for the NGINX proxy
openssl genrsa -out nginx-client.key 4096
# Create CSR
openssl req -new -key nginx-client.key -out nginx-client.csr

Sign this CSR with your CA to create the client certificate:

openssl x509 -req -in nginx-client.csr -CA my-ca.crt -CAkey my-ca.key -CAcreateserial -out nginx-client.crt -days 365

Step 3: Configure NGINX to Present its Client Certificate

In your NGINX reverse proxy configuration, use the generated client certificate and key.

# In your reverse proxy's location block
location /api/ {
 proxy_pass https://your-upstream-server;

 # Present this client cert to the upstream
 proxy_ssl_certificate /etc/nginx/ssl/nginx-client.crt;
 proxy_ssl_certificate_key /etc/nginx/ssl/nginx-client.key;
}

Impact:

Implementing mTLS introduces operational overhead for certificate management. You must have a process (often an internal P ublic K ey I nfrastructure, or PKI) for issuing, renewing, and revoking these client certificates. If the client certificate used by NGINX expires, or if the CA certificate on the upstream server expires, the connection between NGINX and the upstream will fail, leading to a service outage.

See Also

https://workbench.cisecurity.org/benchmarks/18528

Item Details

Category: ACCESS CONTROL, IDENTIFICATION AND AUTHENTICATION, SYSTEM AND COMMUNICATIONS PROTECTION

References: 800-53|AC-17(2), 800-53|IA-5, 800-53|IA-5(1), 800-53|SC-8, 800-53|SC-8(1), CSCv7|14.4

Plugin: Unix

Control ID: c4809ef0c5735a2fae43245f502931e4a16cbe8a0168d0f4b139705f3ce0ba24