讓 HTTPS 不只加密，而是真正做到「身分驗證」
在企業內部導入 Internal PKI（自建 CA） 之後，很多團隊都會遇到同一個問題：
憑證都有了，HTTPS 也跑起來了，但這樣真的安全嗎？
實務上，常見的現況是：
- Proxy 與 Backend 之間是 HTTPS
- 憑證由 Internal PKI 簽發
- 但 Proxy 其實沒有驗證憑證
- 或為了解決錯誤，直接關閉 SSL 驗證
結果是：
表面上是 HTTPS，實際上卻沒有任何身分保證。
這篇文章將從 企業實戰角度，說明
Apache 與 Nginx 要如何「正確、可控、安全地」信任 Internal PKI。
一、先建立正確的觀念（非常重要）
在 Reverse Proxy 架構中：
Client ── HTTPS ──> Reverse Proxy ── HTTPS ──> Backend
Proxy 同時扮演兩個角色：
- 對 Client：TLS Server
- 對 Backend：TLS Client
👉 Internal PKI 真正發揮價值的地方，是「Proxy → Backend」這一段
如果 Proxy 沒有驗證 Backend 憑證：
HTTPS 只剩加密，沒有身分驗證
二、典型企業 Internal PKI 架構
User
│ HTTPS (Public Certificate)
▼
Apache / Nginx Reverse Proxy
│ HTTPS (Internal PKI)
▼
Backend Services
安全與否，不在於有沒有 HTTPS，而在於：
Proxy 是否信任「正確的 CA」，並驗證「正確的身分」
三、Internal PKI 的正確使用前提
在設定 Apache / Nginx 之前，請先確認以下原則：
✅ Proxy 應該擁有的
- Internal Root CA（公鑰），或
- Intermediate CA（公鑰）
❌ Proxy 絕對不該擁有的
- Root / Intermediate 私鑰
- 不必要的整包系統 CA bundle
👉 Proxy 只需要「信任」，不需要「簽發」
四、Apache：如何正確信任 Internal PKI
1️⃣ Apache 的設計思維（為什麼適合企業）
Apache 在反向代理 HTTPS 時，會：
把自己當成真正的 TLS Client
也就是說，只要你設定清楚，它就會嚴格執行驗證流程，
這對企業 PKI 與資安稽核非常友善。
2️⃣ Apache 正確設定範例（實戰）
SSLProxyEngine On
# 強制驗證後端憑證
SSLProxyVerify require
SSLProxyCheckPeerName on
SSLProxyCheckPeerExpire on
# 僅信任 Internal PKI
SSLProxyCACertificateFile /etc/apache2/ssl/internal-pki.pem
ProxyPreserveHost On
ProxyPass /api https://backend-api.internal/
ProxyPassReverse /api https://backend-api.internal/
Apache 會實際驗證什麼？
- Backend 憑證是否由 Internal PKI 簽發
- 憑證 SAN 是否包含
backend-api.internal - 憑證是否過期
👉 這才是真正的 PKI 驗證，不是形式上的 HTTPS
3️⃣ Apache 常見錯誤
❌ ProxyPass 使用 IP（SNI 失效）
❌ 憑證 SAN 與 hostname 不一致
❌ 信任過多 CA，擴大攻擊面
五、Nginx：如何正確信任 Internal PKI（務必小心）
1️⃣ 關鍵事實：Nginx 預設「不驗證」後端憑證
也就是說：
如果你沒特別設定，Nginx 只會加密，不會驗證身分
在 Internal PKI 架構中，這是非常危險的狀態。
2️⃣ Nginx 必須補齊的設定（缺一不可）
proxy_ssl_verify on;
proxy_ssl_trusted_certificate /etc/nginx/internal-pki.pem;
proxy_ssl_server_name on;
每一行在做什麼？
proxy_ssl_verify on;
→ 啟用後端憑證驗證proxy_ssl_trusted_certificate
→ 明確指定「信任哪個 Internal PKI」proxy_ssl_server_name on;
→ 啟用 SNI，避免拿到錯誤憑證
3️⃣ Nginx 常見實務陷阱
❌ 有 CA 檔，但忘了開 proxy_ssl_verify
❌ 用 IP 連 Backend，導致驗證失敗
❌ CA 檔案放太多，不清楚信任邊界
👉 Nginx 不是不安全，而是「太自由」
六、Apache vs Nginx：Internal PKI 行為差異整理
| 項目 | Apache | Nginx |
|---|---|---|
| 預設驗證後端憑證 | 偏嚴謹 | 預設不驗證 |
| PKI 設定清楚度 | 高 | 中（需補齊） |
| SAN / SNI 控制 | 明確 | 易被忽略 |
| 誤用風險 | 低 | 高 |
| 企業稽核友善度 | 高 | 視團隊成熟度 |
七、企業級最佳實務（重點）
✅ 一定要做到
- Proxy → Backend 強制驗證憑證
- 使用 hostname，不用 IP
- CA 信任最小化
- 憑證 SAN 精準
❌ 絕對不要
- 關閉 SSL 驗證
- 信任所有 CA
- 使用萬用內網憑證
- 把憑證問題當成「先跳過」
八、Zero Trust 視角的一句話結論
Zero Trust 的核心是：
每一次連線，都必須驗證身分
如果 Apache / Nginx：
- 沒有驗證 Internal PKI
- 只是轉發加密流量
那這條連線：
不符合 Zero Trust，也不符合現代企業資安要求
結語：信任不是設定選項，而是架構設計
讓 Apache / Nginx 正確信任 Internal PKI，
不是多寫幾行設定，而是在做一件核心的事：
清楚定義：誰可以被信任、信任到哪裡、如何驗證
只要這個基礎打穩，後續你在推：
- Reverse Proxy
- Docker / Kubernetes
- mTLS
- Zero Trust
都會變得自然、穩定、可長期維運。