Apache Reverse Proxy 的 TLS 驗證細節

從「能連線」到「真正驗證身分」的關鍵設定

在企業環境中使用 Apache 作為 Reverse Proxy 時，很多人會覺得：

「HTTPS 已經開了、後端也用憑證了，應該就安全了吧？」

但實務上，Apache Reverse Proxy 的 TLS 驗證行為，正是多數企業
「以為安全、實際卻沒有」的關鍵斷點。

這篇文章會聚焦在一件事：

Apache 在 Reverse Proxy → HTTPS Backend 時，到底驗證了什麼？
又有哪些設定，才算是真正的 TLS 驗證？

一、先釐清 Apache 在 Reverse Proxy 中的角色

在典型架構中：

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

Apache 同時扮演兩個 TLS 角色：

對 Client：TLS Server
對 Backend：TLS Client

👉 本文討論的 TLS 驗證，100% 指的是「Apache → Backend」這一段

二、Reverse Proxy + TLS 驗證架構示意

User
│ HTTPS (Public Certificate)
▼
Apache Reverse Proxy
│ HTTPS + TLS Verification
▼
Backend Service

重點不在於「有沒有 HTTPS」，而在於：

Apache 是否真的驗證 Backend 的身分

三、Apache TLS 驗證的核心模組

Apache Reverse Proxy 的 TLS 驗證，主要由以下模組負責：

mod_ssl
mod_proxy
mod_proxy_http

其中 所有安全行為，幾乎都由 mod_ssl 控制。

四、TLS 驗證的第一步：SSLProxyEngine

SSLProxyEngine On

這一行在做什麼？

啟用 Apache 作為 TLS Client
沒有這行，後端 HTTPS 根本不會進行 TLS 處理

👉 但請注意：

SSLProxyEngine On ≠ 有驗證

它只是「可以用 TLS」，不是「有做驗證」。

五、真正的核心：SSLProxyVerify

SSLProxyVerify require

可用值說明

設定值	行為
`none`	❌ 完全不驗證（最危險）
`optional`	⚠️ 有憑證才驗
`require`	✅ 強制驗證

為什麼企業一定要用 `require`？

因為：

沒有驗證 = 無法確認對方是誰

在 Internal PKI / Zero Trust 架構下，
SSLProxyVerify require 是不可妥協的設定。

六、驗證憑證「是不是對的人」：SSLProxyCheckPeerName

SSLProxyCheckPeerName on

這一項在驗證什麼？

Backend 憑證的 CN / SAN
是否與你連線的 hostname 一致

實務重點

ProxyPass /api https://backend-api.internal/

Backend 憑證 SAN 必須包含：

DNS: backend-api.internal

❌ 如果用 IP：

ProxyPass /api https://10.0.0.5/

SNI 失效
Name check 失效
很多人就「乾脆關掉驗證」

👉 這是企業最常見的錯誤來源

七、驗證憑證是否有效：SSLProxyCheckPeerExpire

SSLProxyCheckPeerExpire on

功能說明

檢查憑證是否過期
避免使用「早就該被淘汰的憑證」

這一項常被忽略，但在稽核與事故追蹤時非常重要。

八、Apache 要「信任誰」：SSLProxyCACertificateFile

SSLProxyCACertificateFile /etc/apache2/ssl/internal-ca.pem

正確觀念

放的是 CA 憑證（公鑰）
通常是：
- Intermediate CA
- 或 Root CA（不建議過度）

錯誤做法

❌ 放 Backend Server 憑證
❌ 放整包系統 CA bundle
❌ CA chain 不完整

👉 Apache 只該信任「必要的 CA」

九、SNI：TLS 驗證最常被忽略的一環

Apache 在 Proxy 時，會根據 目標 hostname 傳送 SNI。

正確作法

ProxyPass / https://backend-api.internal/

錯誤作法

ProxyPass / https://10.0.0.5/

後果：

Backend 回傳錯誤憑證
Apache 驗證失敗
管理者選擇關驗證（最糟）

十、完整且正確的 Apache TLS 驗證範例

SSLProxyEngine On

SSLProxyVerify require
SSLProxyCheckPeerName on
SSLProxyCheckPeerExpire on

SSLProxyCACertificateFile /etc/apache2/ssl/internal-ca.pem

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

👉 這一組設定，才是真正「有 TLS 驗證」的 Reverse Proxy。

十一、常見錯誤與實際後果

錯誤	後果
關閉 SSLProxyVerify	MITM 無感
使用 IP	SNI / Name check 失效
信任所有 CA	攻擊面暴增
SAN 不一致	驗證失敗
忽略過期檢查	稽核風險

十二、Zero Trust 視角的一句話總結

Zero Trust 的核心是：

每一次連線，都必須驗證身分

如果 Apache：

沒有驗證 Backend 憑證
只是轉發加密流量

那這條連線：

不符合 Zero Trust，也不符合企業資安要求

結語：TLS 驗證不是選項，而是責任

Apache Reverse Proxy 的 TLS 驗證，不是「進階技巧」，
而是 企業資安的基本責任。

真正安全的 HTTPS，必須同時具備：

✔ 加密
✔ 憑證驗證
✔ 身分確認
✔ 最小信任

如果你的系統因為 TLS 驗證而「連不上」，
問題一定在憑證或設計，而不是驗證本身。