How Apache and Nginx Should Properly Trust an Internal PKI

Making HTTPS About Identity Verification — Not Just Encryption

After an enterprise deploys an Internal PKI (Internal CA), a common but dangerous situation often appears:

“We have certificates, HTTPS is enabled everywhere — so we’re secure.”

In reality, many environments look like this:

• Proxy ↔ Backend uses HTTPS
• Certificates are issued by an Internal PKI
• But the proxy does not actually verify certificates
• Or SSL verification is disabled to “make things work”

The result:

HTTPS exists, but identity is never verified.

This article explains — from an enterprise, production-ready perspective —
how Apache and Nginx should correctly, safely, and controllably trust an Internal PKI.

---

1. The Most Important Concept to Understand First

In a reverse proxy architecture:

Client ── HTTPS ──> Reverse Proxy ── HTTPS ──> Backend

The proxy plays two roles at the same time:

• To the client: TLS Server
• To the backend: TLS Client

👉 Internal PKI matters primarily on the “Proxy → Backend” connection

If the proxy does not verify the backend certificate:

HTTPS provides encryption only — identity verification is gone

---

2. Typical Enterprise Internal PKI Architecture

User
│ HTTPS (Public Certificate)
▼
Apache / Nginx Reverse Proxy
│ HTTPS (Internal PKI)
▼
Backend Services

Security depends not on whether HTTPS exists, but on:

Whether the proxy trusts the correct CA and verifies the correct identity

---

3. Correct Internal PKI Preconditions

Before configuring Apache or Nginx, verify these rules:

✅ What the Proxy Should Have

• Internal Root CA certificate (public), or
• Intermediate CA certificate (public)

❌ What the Proxy Must Never Have

• Root or Intermediate private keys
• Full system CA bundles without clear justification

👉 A proxy needs to trust a CA — not issue certificates

---

4. Apache: Properly Trusting an Internal PKI

4.1 Apache’s Design Philosophy

When Apache proxies HTTPS traffic, it behaves as a real TLS client:

If TLS is used, verification must be explicit and enforced

This makes Apache naturally well-suited for enterprise PKI and audit requirements.

---

4.2 Recommended Apache Configuration (Production-Ready)

SSLProxyEngine On

# Enforce backend certificate verification
SSLProxyVerify require
SSLProxyCheckPeerName on
SSLProxyCheckPeerExpire on

# Trust only the Internal PKI
SSLProxyCACertificateFile /etc/apache2/ssl/internal-pki.pem

ProxyPreserveHost On
ProxyPass        /api https://backend-api.internal/
ProxyPassReverse /api https://backend-api.internal/

What Apache Verifies in Practice

• Certificate is issued by the Internal PKI
• SAN includes backend-api.internal
• Certificate is not expired

👉 This is real PKI validation — not “cosmetic HTTPS”

---

4.3 Common Apache Mistakes

❌ Using IP addresses instead of hostnames (breaks SNI)
❌ SAN mismatch between certificate and ProxyPass target
❌ Trusting too many CAs and expanding the attack surface

---

5. Nginx: Properly Trusting an Internal PKI (Be Very Careful)

5.1 A Critical Fact: Nginx Does Not Verify by Default

When proxying to an HTTPS backend:

Nginx encrypts traffic but does NOT verify backend certificates by default

In an Internal PKI environment, this is a high-risk default state.

---

5.2 Mandatory Nginx Configuration (All Lines Required)

proxy_ssl_verify on;
proxy_ssl_trusted_certificate /etc/nginx/internal-pki.pem;
proxy_ssl_server_name on;

Why Each Directive Matters

• proxy_ssl_verify on;
  → Enables backend certificate verification
• proxy_ssl_trusted_certificate
  → Explicitly defines which Internal PKI is trusted
• proxy_ssl_server_name on;
  → Enables SNI to ensure the correct certificate is presented

Missing any one of these weakens security.

---

5.3 Common Nginx Pitfalls in Enterprises

❌ CA file configured but verification not enabled
❌ Backend accessed by IP instead of hostname
❌ Overly large CA trust bundles with unclear scope

👉 Nginx is powerful — but silently permissive

---

6. Apache vs Nginx: Internal PKI Behavior Comparison

Aspect	Apache	Nginx
Backend certificate verification default	Strict by design	Disabled by default
Internal PKI configuration clarity	High	Medium (manual)
SAN / SNI enforcement	Explicit	Easy to miss
Misconfiguration risk	Low	High
Enterprise audit friendliness	High	Depends on team discipline

---

7. Enterprise Best Practices (Non-Negotiable)

✅ Always Do

• Enforce certificate verification on proxy → backend
• Use hostnames, never IPs
• Minimize CA trust scope
• Keep SAN entries precise

❌ Never Do

• Disable SSL verification
• Trust all CAs blindly
• Use wildcard internal certificates
• “Temporarily” bypass PKI problems

---

8. Zero Trust Perspective (One-Sentence Conclusion)

Zero Trust requires:

Every connection must verify identity

If Apache or Nginx:

• Does not validate Internal PKI certificates
• Simply forwards encrypted traffic

Then that connection:

Does not meet Zero Trust or modern enterprise security requirements

---

Conclusion: Trust Is an Architectural Decision, Not a Toggle

Configuring Apache and Nginx to properly trust an Internal PKI is not about adding a few TLS directives.

It is about answering a fundamental question:

Who is trusted, to what extent, and how is that trust verified?

When this foundation is correct, your work with:

• Reverse proxies
• Docker and Kubernetes
• mTLS
• Zero Trust architectures

becomes simpler, safer, and sustainable long-term.