Private SSL 204 - Securing Internal APIs and Microservices with Private SSL/TLS (mTLS)

As organizations migrate from monolithic deployments to microservices and distributed internal APIs, network communication shifts dramatically. Historically, perimeter security (firewalls and VPNs) protected applications from external threats, while traffic inside the internal network remained unencrypted and unauthenticated.

This unencrypted communication between internal services—known as "east-west" traffic—represents a major architectural blind spot. If an attacker or malicious insider gains access to a single internal host, lateral movement across unencrypted internal APIs is trivial.

To establish a true Zero-Trust architecture, enterprises must verify and encrypt every transaction between internal services. Implementing Mutual TLS (mTLS) backed by internal certificates from SecureNT guarantees that every microservice authenticates bi-directionally before exchanging sensitive business data.

What is East-West Traffic and Why is Mutual TLS (mTLS) Essential?

Standard TLS only authenticates the server: the client verifies the identity of the API endpoint before sending data. Mutual TLS (mTLS) enforces two-way cryptographic verification:

The client verifies the server's identity against the enterprise root trust chain.
The server verifies the client's identity using a valid, cryptographically signed client certificate before accepting any request.

By replacing static API tokens, bearer headers, or cleartext communication with mTLS, organizations eliminate:

Lateral Movement: Compromising one service does not give an attacker automatic access to call adjacent microservices.
Credential Interception: There are no plaintext API keys or shared secrets transmitted across the wire that can be captured via packet inspection.
Service Spoofing: Rogue containers or unapproved workloads cannot impersonate authentic internal services.

Architecture: SecureNT mTLS Trust Model

[ Service A: Billing Client ]                         [ Service B: Payment API ]
   (Possesses Client Cert)                               (Possesses Server Cert)
              │                                                     │
              │──────── 1. Client initiates TLS connection ────────>│
              │<─────── 2. Server presents server certificate ──────│
              │         (Service A validates against SecureNT CA)   │
              │                                                     │
              │<─────── 3. Server requests client certificate ──────│
              │──────── 4. Client presents client certificate ─────>│
              │         (Service B validates against SecureNT CA)   │
              │                                                     │
              │<═══════ 5. Encrypted & Authenticated Tunnel ═══════>│

SecureNT acts as the single, authoritative Private Certificate Authority (CA) that issues both the server certificates for API gateways and the client certificates assigned to calling services.

Prerequisites

An internal microservice environment (such as Docker, Kubernetes, or standalone Linux hosts).
Access to your API Gateway or Ingress Reverse Proxy (e.g., Nginx, Envoy, or Traefik).
The SecureNT Root and Intermediate CA bundle installed on both client and server hosts.

Step-by-Step Implementation Guide

Step 1: Generate Server and Client Keypairs with CSRs

On your infrastructure host, generate two separate sets of keys and Certificate Signing Requests: one for the API server and one for the calling client service.

1. Server Key & CSR:

Bash

openssl req -new -newkey rsa:2048 -nodes \
     -keyout api_server.key \
     -out api_server.csr \
     -subj "/C=US/ST=State/L=City/O=Enterprise/OU=Backend/CN=payment-api.internal"

2. Client Key & CSR:

Bash
openssl req -new -newkey rsa:2048 -nodes \
     -keyout billing_client.key \
     -out billing_client.csr \
     -subj "/C=US/ST=State/L=City/O=Enterprise/OU=Microservices/CN=billing-service.internal"

Step 2: Issue Certificates via SecureNT

Visit the SecureNT Intranet SSL website.
For the server certificate: Upload api_server.csr, select the Web Server profile, and download the issued certificate (api_server.cer).
For the client certificate: Upload billing_client.csr, select the Client Authentication profile, and download the issued certificate (billing_client.cer).
Download the SecureNT CA trust bundle (SecureNT CA-Bundle.cer).

Step 3: Bundle Certificates on the Hosts

On the server host (Payment API):

Bash

cat api_server.cer "SecureNT CA-Bundle.cer" > /etc/ssl/certs/api_server_bundle.crt
mv api_server.key /etc/ssl/private/api_server.key
chmod 600 /etc/ssl/private/api_server.key
cp "SecureNT CA-Bundle.cer" /etc/ssl/certs/securent_ca.crt

On the client host (Billing Service):

Bash

mv billing_client.cer /etc/ssl/certs/billing_client.crt
mv billing_client.key /etc/ssl/private/billing_client.key
chmod 600 /etc/ssl/private/billing_client.key

cp "SecureNT CA-Bundle.cer" /etc/ssl/certs/securent_ca.crt

Step 4: Configure the API Gateway / Nginx Server for mTLS

Configure Nginx to mandate client verification by specifying ssl_client_certificate and setting ssl_verify_client on:

Nginx
server {
    listen 443 ssl http2;
    server_name payment-api.internal;

    # Server TLS Identity
    ssl_certificate /etc/ssl/certs/api_server_bundle.crt;
    ssl_certificate_key /etc/ssl/private/api_server.key;

    # Client Authentication (mTLS Enforced)
    ssl_client_certificate /etc/ssl/certs/securent_ca.crt;
    ssl_verify_client on;
    ssl_verify_depth 2;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location /v1/process-payment {
        # Optional: Forward client identity to upstream application
        proxy_set_header X-Client-DN $ssl_client_s_dn;
        proxy_set_header X-Client-Verified $ssl_client_verify;

        proxy_pass http://127.0.0.1:5000;
    }
}

Reload Nginx:

Bash

nginx -t && systemctl reload nginx

Verification and Testing

Test 1: Connection Without Client Certificate (Should Fail)

From the client terminal, attempt a standard HTTPS call to the API without presenting a client certificate:

Bash

curl -Iv --cacert /etc/ssl/certs/securent_ca.crt <https://payment-api.internal/v1/process-payment>

Result: The server terminates the handshake or returns 400 Bad Request (No required SSL certificate was sent).

Test 2: Authenticated mTLS Handshake (Should Succeed) Execute the request supplying the SecureNT-issued client certificate and private key:

Bash
curl -Iv \
  --cacert /etc/ssl/certs/securent_ca.crt \
  --cert /etc/ssl/certs/billing_client.crt \
  --key /etc/ssl/private/billing_client.key \
  https://payment-api.internal/v1/process-payment

Result: The TLS handshake completes successfully with status 200 OK, authenticating both sides of the channel.

Adopting Mutual TLS across internal APIs and microservices transforms your perimeter into an auditable Zero-Trust environment. Backed by SecureNT's centralized trust, internal services communicate with hardened, cryptographic identity verification across all east-west transactions.