AWS Certificate Manager 是什麼？SSL 憑證自動化管理與最佳實踐

更新日期： 2025 年 6 月 26 日

現在用 AWS 架設網站越來越普遍，但想讓網站安全上線、支援 HTTPS，卻常常讓人卡關。

你可能聽過 SSL 憑證、HTTPS 加密，也知道網站要能被大家安全瀏覽，這些東西都少不了。

不過，傳統安裝 SSL 憑證的流程又長又繁瑣，還要自己處理續期、驗證、設定檔，對新手來說真的很麻煩。

幸好 AWS 提供了 Certificate Manager（ACM），幫你把這些複雜的事情全自動化，讓你不用再為憑證煩惱。

這篇文章會帶你一步步了解：

• SSL 憑證是什麼？為什麼網站一定要有？
• 傳統安裝憑證有多麻煩？
• ACM 怎麼幫你省下大把時間？
• 以及 DNS、網域解析、根網域設定等常見問題的解法

不管你是剛開始用 AWS 架站，還是想讓網站更安全，這篇都能幫你一次搞懂 SSL 憑證與 ACM 的實戰重點！

憑證是什麼？為什麼網站需要它？

在開始介紹 ACM 之前，我們先從「憑證」本身講起。

你可能注意過，有些網站的網址開頭是 http://，而有些則是 https://，並且網址旁邊會顯示一個「🔒鎖頭」圖示。

這個小鎖頭，背後其實是一種叫做 SSL/TLS 憑證 的技術，負責讓你和網站之間的資料傳輸變得安全、加密且不可竄改。

沒有憑證會怎樣？

如果一個網站沒有憑證：

• 瀏覽器會跳出「⚠️ 此網站不安全」的警告
• 網址會顯示 http:// 而不是 https://
• 你在網站上輸入的帳號、密碼、信用卡等資料，可能在傳輸途中被攔截、竊聽

這就像你在一間咖啡廳的 Wi-Fi 上登入網銀，但資料完全沒加密，被駭客「聽光光」。

有憑證會怎樣？

有憑證的網站：

• 網址會自動轉為 https://
• 顯示綠色鎖頭，讓訪客安心
• 所有資料會在傳輸過程中被加密，就算被攔截也看不懂

簡單來說：

憑證的作用就是：幫你的網站戴上安全帽，保護用戶的隱私與資料安全。

誰簽發憑證？什麼是 CA（憑證頒發機構）？

網站不能自己說：「我有憑證，我很安全喔！」這就像某人自稱自己是醫生，但沒任何醫學院證書或公信力組織認可 —— 誰會信？

在數位世界中，你需要找一個大家都信得過的「中立第三方」來幫你背書，這個角色就叫做 CA（Certificate Authority，憑證頒發機構）。

CA 在做什麼？為什麼這麼重要？

CA 的工作就是幫網站核發 SSL/TLS 憑證，內容會包含：

• 這個網站的網域名稱（如 example.com）
• 憑證的有效期間（起訖日期）
• 發憑證的機構資訊
• 公開金鑰（用於加密通訊）

CA 會透過驗證機制，確保你真的擁有這個網域的管理權限，例如：

• 要你在 DNS 上加一筆 TXT 或 CNAME 記錄
• 要你在網站根目錄上傳一個驗證檔案
• 更嚴格的（EV 憑證）還要對企業資料進行人工審核

一旦驗證成功，CA 就會簽署憑證（Certificate），並發給你。這份憑證會被瀏覽器識別並信任，讓網站能正常顯示 HTTPS 🔒 鎖頭。

為什麼瀏覽器會信任 CA 發的憑證？

瀏覽器和作業系統內部都內建一份「信任 CA 名單」，這份名單就像一張白名單：

• 你不是在白名單上的機構 → 發的憑證預設就不被信任
• 你在白名單上 → 發的憑證會自動被所有用戶接受

所以，就算你技術上可以自己簽憑證（稱為 self-signed certificate），大多數瀏覽器一樣會跳出「⚠️ 不受信任的憑證」警告。因為它不知道該不該相信你。

這也是為什麼只有大型且可信的機構能當 CA，因為他們的根憑證（Root Certificate）已經內建在幾十億台裝置中。

常見的 CA 機構有哪些？

其中，Let’s Encrypt 和 Amazon Trust Services 都提供免費憑證，是開發者最常見的選擇。

🧠 小提醒：你無法自由選 CA（在某些平台）

如果你是使用托管平台（如 GitHub Pages、Firebase、Cloudflare、AWS ACM），它們通常已內建特定 CA，由平台自動幫你申請與管理憑證，你不用也不能選擇 CA。

但如果你是自己架站（用 Apache、Nginx、cPanel 等），就可以自由選擇要用哪個 CA 發憑證。

SSL 憑證是怎麼運作的？

SSL 憑證的真正用途，不只是讓網站顯示一個「🔒鎖頭」而已。

它背後運作的是一套叫做 公開金鑰加密（Public Key Encryption） 的安全機制，能讓你和伺服器之間的資料加密傳輸、避免被第三方竊聽或竄改。

讓我們用一個簡化但完整的流程來說明：

TLS/SSL 加密連線的流程步驟

假設你打開一個使用 SSL 的網站，例如 https://example.com，以下是瀏覽器背後發生的事：

✅ 第 1 步：瀏覽器發出請求（Hello!）

當你在瀏覽器輸入網址並按下 Enter，瀏覽器會先發出一個 Client Hello 請求，告訴伺服器它：

• 支援哪些加密演算法
• 使用的是哪個 TLS 版本
• 傳送一組隨機數（client random）

✅ 第 2 步：伺服器回應憑證（Hello + Certificate）

伺服器收到請求後，會回傳一個 Server Hello 響應，並附上：

• 一張 SSL 憑證（含公開金鑰）
• 它選擇的加密演算法
• 它的隨機數（server random）

這個憑證是之前由 CA 簽發的，用來讓瀏覽器確認：

• 🧾 這個網域是合法的（有通過驗證）
• 🔐 這把公開金鑰是網站的，且尚未過期或撤銷

✅ 第 3 步：瀏覽器驗證憑證的真偽

瀏覽器會使用它內建的「CA 名單」（白名單），來檢查這張憑證是否可信：

• 是否由受信任的 CA 簽發？
• 是否過期？
• 是否為指定網域使用？
• 是否有遭撤銷（透過 CRL 或 OCSP）？

如果這張憑證沒問題，就繼續下一步；
如果驗證失敗，瀏覽器會跳出警告：「⚠️ 憑證不安全，請勿繼續」

✅ 第 4 步：產生對稱金鑰（加密通訊的基礎）

此時，瀏覽器會使用伺服器提供的「公開金鑰」，加密一組「對稱金鑰」（也稱為 pre-master secret）並送回伺服器。

因為只有伺服器持有對應的「私密金鑰」，所以只有它能解開這段資料。

✅ 公開金鑰加密 → ✅ 私密金鑰解密
→ 這就是「公開金鑰加密」的核心概念

雙方接著用 client random + server random + pre-master secret 共同計算出後續溝通要用的對稱加密金鑰。

✅ 第 5 步：建立加密通道（TLS Handshake 完成）

握手成功後，瀏覽器與伺服器會開始使用 對稱加密 的方式傳輸資料。

這是因為對稱加密（雙方共用同一組金鑰）效率更高，速度快，適合傳輸大量資料。

此時，雙方的通訊已經是完全加密的，就算中間被攔截，也無法解密內容。

總結：SSL 憑證背後的功能有這些

👶 如果用日常比喻來說：

你可以把這整個流程想像成：

你（用戶）要寄出一封秘密信（資料）給網站，但不想被其他人偷看 →
網站先寄來一個「保險箱 + 鑰匙孔」（公開金鑰） →
你把信鎖進去（加密）後寄出去 →
網站用它唯一的鑰匙（私密金鑰）打開 →
雙方開始用一組共通暗號（對稱金鑰）來交談 →
沒有鑰匙的第三方全程都聽不懂

公有憑證 vs 私有憑證：有什麼差別？

在 SSL/TLS 憑證的世界中，依照簽發來源的信任層級不同，可以將憑證大致分為兩種：

1. ✅ 公有憑證（Public Certificate）
2. 🔒 私有憑證（Private Certificate）

它們的最大差異，就在於：誰簽的、誰會信任它。

公有憑證（Public Certificate）：對外公開、被瀏覽器預設信任

公有憑證是最常見、也是你每天使用的網站（如 Google、Facebook、Shopee）所使用的那種憑證。

🌍 特點如下：

• 由「公開信任的 CA（憑證機構）」簽發，如：
• Let’s Encrypt（免費）
• DigiCert、GlobalSign（商業）
• Amazon Trust Services（ACM 背後使用的 CA）
• 被幾乎所有作業系統與瀏覽器預先信任（例如 Chrome、Safari、Edge 會內建一份「可信任憑證頒發機構清單」）
• 使用者訪問網站時，不需要做任何設定，就會看到綠鎖頭 🔒 與 https://

🧭 常見用途：

私有憑證（Private Certificate）：內部使用、自訂信任範圍

私有憑證是由自己簽發（或企業內部的 CA 簽發），不被外部瀏覽器與裝置預設信任。

🔐 特點如下：

• 通常使用 自建 CA 或企業內部使用 AWS Private CA 等工具來簽發
• 不會被瀏覽器或作業系統信任，使用者必須手動匯入 CA 根憑證才會顯示安全
• 適合在內網、內部系統中使用，不需對外部公開

🛠️ 使用時會有這些現象：

• 瀏覽器會跳出「⚠️ 不受信任的憑證」紅色警告
• 需手動將私有 CA 加進裝置的信任憑證列表中（例如公司內部設備或 MDM 管理下的手機）
• 適合用於「你控制所有設備」的場景

🧭 常見用途：

🧰 ACM 裡的私有憑證功能（進階）

AWS 提供一個進階服務叫做 AWS Private CA，讓企業可以在雲端建立自己的憑證機構（CA），用來簽發私有憑證，並透過 ACM 管理。

• 適合大型企業需要控管大量內部系統或 IoT 裝置的身份時使用
• 支援與 AWS 其他服務整合（如 IoT Core、EC2）
• 可設定憑證存活時間、吊銷機制、發行規則等

不過這屬於進階企業應用，一般中小型開發者或公開網站幾乎不會用到。

公有 vs 私有憑證對比表：

傳統憑證安裝流程

安裝 SSL 憑證流程

如果你是自己架設網站（例如用 VPS、Nginx、Apache），想讓網站變成 HTTPS 🔒，大致上要做這幾件事：

✅ 步驟 1：先自己做一張申請表（CSR）

你需要在伺服器上用指令產生一組「金鑰」和一張「申請表」（CSR）。

這張申請表裡面會寫：你是誰、網站網域是什麼，準備拿去請別人簽名。

openssl req -new -newkey rsa:2048 -nodes -keyout example.key -out example.csr

✅ 步驟 2：把申請表送去憑證機構（CA）

把 CSR 傳給像 Let’s Encrypt 或 DigiCert 這類憑證機構。

他們會幫你「簽名」，回傳一張正式的憑證（.crt 檔）。

✅ 步驟 3：證明你真的擁有這個網域

憑證機構不會輕易相信你，會要求你驗證身分，例如：

• 在網站根目錄放一個特殊檔案（HTTP 驗證）
• 或是到 DNS 加上一筆 TXT / CNAME 記錄（DNS 驗證）

這樣他們才能確定：你真的可以管理這個網域。

✅ 步驟 4：手動裝上憑證

拿到憑證 .crt 檔後，你要自己開 Web Server 設定檔，把憑證路徑與金鑰路徑填進去：

ssl_certificate     /etc/ssl/example.crt;
ssl_certificate_key /etc/ssl/example.key;

然後重啟伺服器，HTTPS 才會生效。

✅ 步驟 5：定期續約，別忘了！

大部分免費憑證（像 Let’s Encrypt）只有效 90 天。

你要寫自動排程（如 cronjob）去幫它定期續期，否則網站會變「不安全」。

傳統方式的痛點：

ACM（AWS Certificate Manager）介紹

ACM（AWS Certificate Manager） 就是 AWS 為了解決上述痛點而推出的免費工具，它幫你把所有繁瑣的事都做完，流程變得非常簡單。

使用 ACM 的申請與安裝流程

只要你是在 AWS 架站（例如使用 Load Balancer、CloudFront、API Gateway），安裝憑證只需要這幾步：

1. 到 ACM 控制台，點選「Request a public certificate」
2. 輸入你要申請的網域（例如 www.example.com）
3. 選擇 DNS 驗證方式 → 系統提供 CNAME 記錄
4. 把 CNAME 設進 DNS 管理平台（GoDaddy、Cloudflare 都可以）
5. 幾分鐘後憑證核發 → 自動幫你套用到指定的 AWS 服務

憑證續期？你不用動手

ACM 會定期自動檢查憑證狀態並自動續期，只要：

• 當初的 DNS 驗證記錄沒刪除
• 憑證綁定的服務（如 ELB）還在使用中

你就永遠不用擔心憑證過期、網站掛掉的風險。

ACM 支援的服務有哪些？

⚠️ 注意：ACM 的憑證只能用在 AWS 生態系內，不能匯出到第三方主機使用。

ACM 只能用在 AWS 嗎？適用情境總整理

是的。ACM（AWS Certificate Manager）是 AWS 提供的專屬服務，只能在 AWS 的雲端平台內使用。

也就是說，你不能下載 ACM 的憑證檔，拿去裝在其他平台（例如 cPanel、Nginx）上使用。

ACM 會自動幫你安裝憑證到 AWS 提供的服務中，如 Load Balancer、CloudFront、API Gateway 等。

🔧 換句話說：

• 只要你的網站部署在 AWS 上，ACM 就非常好用
• 但如果你沒用 AWS，ACM 就完全派不上用場

常見架設方式與 ACM 適用性比較：

常見誤解釐清：

• ACM 是免費的，但不是「萬用型」的憑證解決方案。

它是 AWS 專屬工具，設計目的就是為了讓 AWS 內的 HTTPS 配置變簡單。

• 若你用其他平台，即便 ACM 免費，你也無法把它拿出來用。

因為它不能讓你下載 .crt 或 .pem 檔案，只能由 AWS 自動掛載到自家服務。

ACM 和 Let’s Encrypt 差在哪？

Let’s Encrypt 是一個開源、非營利的憑證機構（CA），可以讓所有人（不分平台）免費申請 SSL 憑證。

幾乎所有架站工具、VPS 主機、控制面板都支援它。

以下是 ACM 與 Let’s Encrypt 的對比：

選擇建議

📌 小提醒：

• ✅ ACM 的最大優勢：一鍵上線、自動續期、零設定負擔
• ⚠️ ACM 的最大限制：只能用在 AWS，自架站或搬家就不能用

所以在選擇憑證方案時，要看你的網站在哪裡運行、未來會不會搬遷、是否需要跨平台部署，才能選出最合適的工具。

ACM 憑證申請與驗證流程

當你在 AWS 架站，希望網站能使用 HTTPS 🔒 加密時，第一步通常就是使用 AWS Certificate Manager（ACM） 申請免費的憑證。

但申請之後，還需要你做兩件事：

1. 驗證你擁有這個網域（CNAME 驗證）
2. 把你申請的網域導向 AWS 上的網站（DNS 對應）

這兩步都要透過 在 DNS 控制台手動新增 CNAME 記錄 來完成。

設置 ACM 驗證用的 CNAME（核發與續期 HTTPS 憑證）

在 AWS 上使用 HTTPS 時，第一步就是申請 SSL 憑證，而 AWS 提供的 ACM（AWS Certificate Manager）讓你可以免費申請憑證。

不過為了確認「你確實擁有該網域」，AWS 不會直接核發，而是要求你在 DNS 控制台新增一筆 CNAME 記錄進行驗證。這就是這一段設定的目的。

🎯 為什麼要設這筆 CNAME？

• AWS 透過這筆 CNAME 驗證你對該網域有修改 DNS 記錄的權限
• 這筆 CNAME 必須一直保留，未來 ACM 會定期檢查，以便自動續期憑證
• 若設定錯誤或刪除，會導致：
• 憑證無法核發（Pending validation 卡住）
• 幾個月後憑證自動續期失敗，導致網站跳出「⚠️ 不安全連線」

步驟 1：申請憑證

1. 登入 AWS Certificate Manager 控制台
2. 點選「Request a certificate」
3. 選擇「Public certificate」（公開用）
4. 在「Add domain names」中輸入你要支援的網域：

• 建議輸入兩個：
  • example.com（根網域）
  • www.example.com（子網域）

5. 選擇「DNS validation」
6. 確認後送出，進入憑證清單畫面

步驟 2：取得 CNAME 驗證資訊

1. 點開剛剛送出的憑證
2. 會看到狀態為「Pending validation」
3. 畫面中會顯示一組或多組 CNAME 驗證資訊（針對你剛輸入的每個網域各有一筆）： 例如：

   Name：_1234567890abcdef.example.com.
   Value：_a1b2c3d4e5f6g7h8.acm-validations.aws.

步驟 3：前往 DNS 控制台新增 CNAME

開啟你註冊網域的平台（如 GoDaddy、Cloudflare、Route 53），到它的 DNS 控制台新增一筆 CNAME 記錄：

✅ 建議不要修改 CNAME 的尾端「.」，有些平台會自動加，有些不會，但保持完整格式比較安全。

步驟 4：驗證是否通過

1. 回到 ACM 頁面
2. 等待 5～30 分鐘，狀態應該會從「Pending validation」變成「Issued」
3. 若過一小時仍無變化，請檢查：

• DNS 是否有貼錯（特別是 Name 欄位不要截斷）
• TTL 設定是否太長（建議 300 秒）
• 有無覆蓋錯誤（有些平台會自動加網域字尾，導致 Name 重複）

⚠️ 常見錯誤提醒

設置網站對外導向用的 CNAME（讓網址連到 AWS 主機）

完成 ACM 憑證申請後，你的網站雖然可以提供加密連線（HTTPS），但這還不夠。

你還需要設定一筆 CNAME 記錄，讓使用者輸入網址（如 www.example.com）時，能正確連到你的 AWS 主機（Elastic Load Balancer, ELB）。

🔍 為什麼需要這筆 CNAME？

• ELB（Elastic Load Balancer）是 AWS 給你的一個「對外入口主機」，它會分流流量到背後的 EC2 或容器服務（如 ECS/Fargate）。
• AWS 不會主動幫你綁定網域名稱（如 www.example.com），你必須自己在 DNS 設定中把網域指向 ELB 的 DNS 名稱。
• 這筆設定的本質：是讓你自有的「域名」→ 導向 → AWS 提供的 ELB 主機。

步驟 1：進入 EC2 控制台，找到 Load Balancer

1. 登入 AWS EC2 控制台
2. 左側選單 → 點選「Load Balancers」
3. 找到你建立的 Load Balancer（通常是 application 類型）
4. 點進該 Load Balancer 詳細頁面
5. 在下方資訊區找到一個欄位叫做「DNS name」，例如：

   my-site-123456.ap-northeast-1.elb.amazonaws.com

6. 複製這組 DNS 名稱，稍後會貼入你的 DNS 控制台

步驟 2：到你的 DNS 平台，設定 CNAME

打開你購買網域的平台（例如 GoDaddy、Cloudflare、Route 53），前往該網域的 DNS 設定區：

新增一筆 CNAME 記錄，內容如下：

✅ 有些平台會要求 Value 加上一個句點（.）結尾，有些則會自動補上，兩種都可以，記得依照平台指引填寫。

步驟 3：儲存後進行測試

1. 等待幾分鐘讓 DNS 生效（根據 TTL 設定，通常 1～5 分鐘）
2. 在瀏覽器中輸入：https://www.example.com
3. 若一切設置正確，應該會看到你部署在 AWS 上的網站成功開啟（且顯示 🔒 HTTPS）

💡 小補充：如果你想指向其他子網域？

假如你有其他子網域（例如 app.example.com, blog.example.com），也可以依樣畫葫蘆設定更多 CNAME：

這樣不同子網域也能共用同一個 ELB（或你可以建立不同的 ELB 分流）。

⚠️ 常見錯誤提醒

如果要連根網域（example.com）怎麼辦？

當我們在設定 DNS 記錄時，很多人會有一個常見的需求：

「我希望輸入 example.com（不是 www.example.com）就能開啟我的網站，而且要有 HTTPS 鎖頭 🔒。」

這聽起來很合理，但背後其實藏著一個技術限制：

🚫 為什麼根網域不能使用 CNAME？

在 DNS 的標準規範中：

• CNAME 記錄的作用是「讓一個網域別名指向另一個網域名稱」。
• 但根網域（如 example.com）通常已經綁定了其他關鍵記錄（像是 NS、SOA 記錄），無法再設定為 CNAME。

換句話說：你只能為 www.example.com 設 CNAME，但不能為 example.com 設 CNAME。

那該怎麼辦？

🛠️ 替代方案：使用 A 記錄 或平台提供的「類似功能」

不同的 DNS 平台，針對這個問題提供了不一樣的解法。你可以參考以下整理：

🔍 什麼是「CNAME Flattening」與「Alias Record」？

✅ 最佳做法建議

🧠 延伸補充：為什麼這很重要？

現代網站使用者輸入網址時，很可能只輸入 example.com 而非 www.example.com。如果你沒有處理好根網域的解析：

• 訪客可能會看到「無法連上網站」
• 或跳出錯誤的 HTTP 頁面（例如 403、錯誤 ELB 預設頁）

這會直接影響你的 SEO、品牌形象與網站使用體驗。

總結

看完這篇，你應該已經知道為什麼網站一定要有 SSL 憑證，以及傳統安裝流程有多麻煩。

AWS Certificate Manager（ACM）就是為了解決這些痛點而生，讓你在 AWS 上架站時，SSL 憑證的申請、驗證、安裝、續期全都自動化，幾乎不用自己動手。

不管是 DNS 設定、CNAME 驗證還是根網域解析，文中都幫你整理了常見問題和解法。

只要你的網站架在 AWS，ACM 幾乎就是最省事的選擇；如果用其他平台，Let’s Encrypt 也是不錯的免費方案。

希望這篇教學能幫你把 SSL 憑證這件事一次搞懂，讓你的網站安全又專業！