Skip to content

Nuface Blog

隨意隨手記 Casual Notes

Menu
  • Home
  • About
  • Services
  • Blog
  • Contact
  • Privacy Policy
  • Login
Menu

企業自建 CA 的最佳實務

Posted on 2026-01-122026-01-12 by Rico

在企業 IT 架構中,隨著以下需求越來越普遍:

  • 內部系統全面 HTTPS 化
  • Reverse Proxy / API Gateway 架構
  • Microservices、Docker、K8s
  • 零信任(Zero Trust)與內網加密

自建 CA(Internal Certificate Authority) 幾乎已成為中大型企業的標準配置。

但實務上,很多企業的自建 CA:

  • 能「簽憑證」
  • 卻 不安全、不好維運、風險極高

這篇文章將從 企業等級的角度,說明「自建 CA 該怎麼做,才不會變成資安地雷」。


一、什麼情況下「一定要」自建 CA?

企業選擇自建 CA,通常不是為了取代公開 CA(如 Let’s Encrypt),而是為了解決 內部信任問題。

常見適用場景

  • 內部系統(ERP、EIP、CRM、API)
  • Reverse Proxy → Backend HTTPS
  • VPN、Internal LDAP / SMTP / IMAP TLS
  • Kubernetes / Service Mesh mTLS
  • 裝置憑證(Wi-Fi、MDM、IoT)

👉 只要憑證不會被公開瀏覽器使用,自建 CA 就是合理選擇。


二、企業自建 CA 的基本架構(強烈建議)

public certificate authority

正確的 CA 架構:兩層式(至少)

Offline Root CA
   │(只用來簽 Intermediate)
   ▼
Intermediate CA
   │(簽發實際使用的憑證)
   ▼
Server / Client Certificates

為什麼不能只用一層?

  • Root CA 一旦外洩 = 全公司信任體系崩潰
  • Root CA 應該 永不上線、不直接簽憑證

三、Root CA 的最佳實務(最重要)

✅ Root CA 必須 Offline

  • 不安裝在任何 Server
  • 不存在於 VM、Docker、NAS
  • 建議:
    • 加密 USB
    • 離線電腦
    • 多人管控(2 人以上)

✅ Root CA 金鑰保護

  • RSA ≥ 4096 或 ECC P-384
  • 私鑰必須加密
  • 嚴禁自動化腳本使用 Root CA

✅ Root CA 有效期限

  • 10–20 年(正常)
  • 但 幾乎不使用

四、Intermediate CA 的最佳實務(實際運作核心)

Intermediate CA 是「工作馬」

  • 用來簽 Server / Client 憑證
  • 可以上線
  • 可以被自動化(但有限制)

建議設定

  • RSA 2048 / 3072 或 ECC P-256
  • 有效期限:3–5 年
  • 可以定期輪替

風險控管

  • Intermediate 外洩 → 可撤銷
  • Root CA 仍安全

五、憑證簽發策略(企業一定要訂規則)

1️⃣ 絕對不要簽「萬用內網憑證」

❌ *.corp.local
❌ *.internal

原因:

  • 一張憑證外洩 = 全內網淪陷

2️⃣ SAN 必須精準

每張憑證只包含:

  • 實際需要的 DNS name
  • 不要為了方便亂加

3️⃣ 最小權限原則

  • Server cert ≠ Client cert
  • TLS ≠ Code Signing
  • VPN ≠ Web

👉 用途一定要分開


六、有效期限與輪替策略(90% 企業會忽略)

建議有效期限

類型建議
Root CA10–20 年
Intermediate CA3–5 年
Server cert90 天 – 1 年

為什麼不該太長?

  • 憑證外洩風險
  • 漏洞影響時間
  • 強迫你建立「更新流程」

七、信任鏈部署最佳實務

不要亂丟 Root CA

  • Server 上不一定要裝 Root CA
  • Client / Proxy 才需要

正確作法

  • Apache / Nginx:只信任必要 CA
  • Docker Image:只放需要的 CA
  • 不要全公司電腦都亂加 Root CA

八、撤銷機制(CRL / OCSP)怎麼看?

實務建議

  • 內網系統,多數不即時查 CRL
  • 但你至少要有:
    • CRL 發布機制
    • 明確「撤銷流程」

👉 重點是 組織流程,不是技術炫技


九、常見錯誤(請直接對照檢查)

❌ Root CA 放在 Server
❌ 用同一張憑證給所有系統
❌ 憑證 10 年不換
❌ 私鑰沒加密
❌ 不知道哪張憑證在哪用
❌ 憑證壞了只能「重建全部」


十、企業級自建 CA Check List

✅ Root / Intermediate 分離
✅ Root Offline
✅ 明確憑證用途分類
✅ 有效期限策略
✅ 憑證盤點清單
✅ 人員異動可控
✅ 文件化、可交接


結語:自建 CA 是「信任工程」,不是工具問題

企業自建 CA 的核心,不在於:

  • 用 OpenSSL
  • 用 AD CS
  • 用哪個工具

而在於:

你是否能長期、穩定、可控地管理「信任」

只要 CA 架構設計正確,後續你在:

  • HTTPS Reverse Proxy
  • mTLS
  • Zero Trust
  • Hybrid Cloud

都會輕鬆非常多。

Recent Posts

  • Token/s and Concurrency:
  • Token/s 與並發:企業導入大型語言模型時,最容易被誤解的兩個指標
  • Running OpenCode AI using Docker
  • 使用 Docker 實際運行 OpenCode AI
  • Security Risks and Governance Models for AI Coding Tools

Recent Comments

  1. Building a Complete Enterprise-Grade Mail System (Overview) - Nuface Blog on High Availability Architecture, Failover, GeoDNS, Monitoring, and Email Abuse Automation (SOAR)
  2. Building a Complete Enterprise-Grade Mail System (Overview) - Nuface Blog on MariaDB + PostfixAdmin: The Core of Virtual Domain & Mailbox Management
  3. Building a Complete Enterprise-Grade Mail System (Overview) - Nuface Blog on Daily Operations, Monitoring, and Performance Tuning for an Enterprise Mail System
  4. Building a Complete Enterprise-Grade Mail System (Overview) - Nuface Blog on Final Chapter: Complete Troubleshooting Guide & Frequently Asked Questions (FAQ)
  5. Building a Complete Enterprise-Grade Mail System (Overview) - Nuface Blog on Network Architecture, DNS Configuration, TLS Design, and Postfix/Dovecot SNI Explained

Archives

  • January 2026
  • December 2025
  • November 2025
  • October 2025

Categories

  • AI
  • Apache
  • CUDA
  • Cybersecurity
  • Database
  • DNS
  • Docker
  • Fail2Ban
  • FileSystem
  • Firewall
  • Linux
  • LLM
  • Mail
  • N8N
  • OpenLdap
  • OPNsense
  • PHP
  • Python
  • QoS
  • Samba
  • Switch
  • Virtualization
  • VPN
  • WordPress
© 2026 Nuface Blog | Powered by Superbs Personal Blog theme