當 HTTPS 不再只是「加密」，而是「信任驗證」
在企業內部導入 Internal CA / PKI 之後，很多團隊會遇到一個現實問題：
「我們明明全都走 HTTPS，為什麼安全性還是很模糊？」
深入一看才發現：
- 有些系統 沒有驗證憑證
- 有些 Proxy 只加密、不驗證
- 有些 CA 被亂信、被過度信任
而在 Reverse Proxy + Internal CA 的實戰中，
Apache 與 Nginx 在 PKI 行為上的差異，遠比效能差異重要。
這篇文章將從 企業實務角度，直接比較 Apache 與 Nginx 在 Internal CA / PKI 下的真實行為與風險。
一、Internal CA / PKI 在 Proxy 中到底在做什麼？
在 Reverse Proxy 架構下，Proxy 同時扮演兩個角色：
Client ──HTTPS──> Reverse Proxy ──HTTPS──> Backend
- 對 Client：Proxy 是 TLS Server
- 對 Backend：Proxy 是 TLS Client
👉 PKI 真正發揮價值的地方，在「Proxy → Backend」這一段
二、架構示意（實戰情境）
User
│ HTTPS (Public Cert)
▼
Reverse Proxy (Apache / Nginx)
│ HTTPS (Internal CA)
▼
Backend Services
問題不在「有沒有 HTTPS」，而在：
Proxy 是否真的驗證了 Backend 的身分？
三、Apache：Internal CA / PKI 的「嚴謹派」
1️⃣ Apache 的預設思維
Apache 在 HTTPS Reverse Proxy 中的設計哲學是：
你既然用了 TLS，我就會把你當成真正的 TLS Client。
這代表：
- 有明確的「驗證 / 不驗證」設定
- 驗證行為可讀、可控
- 對企業 Internal CA 非常友善
2️⃣ Apache + Internal CA 實戰設定
SSLProxyEngine On
SSLProxyVerify require
SSLProxyCheckPeerName on
SSLProxyCheckPeerExpire on
SSLProxyCACertificateFile /etc/apache2/ssl/internal-ca.pem
ProxyPass /api https://backend-api.internal/
ProxyPassReverse /api https://backend-api.internal/
Apache 實際做了什麼？
- 驗證 Backend 憑證是否由 Internal CA 簽發
- 驗證 SAN 是否符合 hostname
- 驗證憑證是否過期
👉 這才是真正的 PKI 使用
3️⃣ Apache 的優點（PKI 視角）
✅ 驗證邏輯清楚
✅ 設定語意明確
✅ Internal CA 行為可預期
✅ 錯誤訊息可讀
非常適合：
- 企業內網
- 自建 PKI
- Zero Trust 架構
四、Nginx：彈性高，但「很容易被用錯」
1️⃣ Nginx 的預設行為（很多人不知道）
在 Reverse Proxy → HTTPS Backend 時：
Nginx 預設「不驗證」後端憑證
也就是說：
- 有加密
- 但沒有身分驗證
- MITM 理論上可行
這在 Internal PKI 環境中是致命的誤用。
2️⃣ Nginx + Internal CA 正確設定（必須補）
proxy_ssl_verify on;
proxy_ssl_trusted_certificate /etc/nginx/internal-ca.pem;
proxy_ssl_server_name on;
如果少了任何一行，行為就會退化。
3️⃣ Nginx 常見實務風險
❌ 以為 HTTPS = 安全
❌ 沒發現 backend cert 根本沒被驗證
❌ CA 信任範圍過大
❌ Proxy reload 出錯影響全站
五、PKI 行為差異重點比較
| 項目 | Apache | Nginx |
|---|---|---|
| 預設驗證後端憑證 | 偏嚴謹 | 預設不驗證 |
| Internal CA 支援 | 原生清楚 | 需明確補齊 |
| SAN 驗證 | 明確開關 | 容易忽略 |
| 設定可讀性 | 高 | 中 |
| 誤用風險 | 低 | 高 |
| 企業 PKI 適配度 | 高 | 視團隊成熟度 |
六、企業實戰建議（很實際）
選 Apache，如果你：
- 有 Internal PKI
- 重視「驗證 > 效能」
- 團隊成員多、交接頻繁
- 想避免「默默不安全」
選 Nginx，如果你：
- 團隊對 TLS / PKI 非常熟
- 有嚴格設定審查流程
- 清楚知道哪些行為是「預設關掉的」
👉 Nginx 不是不安全，是太自由。
七、Zero Trust 視角的結論（非常重要）
Zero Trust 的核心是：
每一次連線，都要驗證身分
如果 Reverse Proxy：
- 沒驗證 Backend 憑證
- 只是「加密轉發」
那這條鏈路 不符合 Zero Trust
從這個角度看：
- Apache：預設思維更接近 Zero Trust
- Nginx：需要刻意設計才能符合 Zero Trust
八、實務總結一句話
Internal PKI 的價值，不在於你簽了多少憑證，而在於你「有沒有真的驗證」。
Apache 與 Nginx 的差異，不只是效能或語法，而是：
- 對「信任」的態度
- 對「預設行為」的風險控管
在企業環境中，避免「默默不安全」往往比追求極限效能更重要。