你有沒有想過，為什麼有些網站的網址前面有個小鎖頭，有些卻沒有？
那個小鎖頭代表網站有 SSL/TLS 憑證，讓你跟網站之間的傳輸是加密的、安全的。
以前要取得 SSL 憑證，你得花錢購買、手動上傳、每年還要記得更新，非常麻煩。
現在 AWS 提供了一個服務叫做 AWS Certificate Manager（簡稱 ACM），可以幫你免費申請、自動更新 SSL 憑證，整個過程省時又省事。
這篇文章會一步步帶你：
- 用 ACM 申請免費的 SSL/TLS 憑證
- 建立一個跑在 EC2 上的簡單網站
- 建立 Application Load Balancer（ALB），把憑證掛上去
- 設定讓 HTTP 自動轉向 HTTPS
讀完這篇文章，你就能讓自己的網站從「不安全」變成有小鎖頭的安全網站。
SSL/TLS 憑證是什麼？它在傳輸過程中扮演什麼角色？
要理解 ACM 在做什麼，你需要先知道 SSL/TLS 憑證的概念。
憑證解決了什麼問題：加密傳輸和驗證身份
第一：加密傳輸。
當你的瀏覽器跟網站之間傳資料，如果沒有加密，中間的人是可以看到內容的（例如你送出的表單、帳號密碼）。
SSL/TLS 憑證讓這段傳輸變成加密過的，就算被攔截也看不懂。
第二：驗證身份。
憑證是由一個受信任的機構（叫做 CA，Certificate Authority）核發的，代表「這個網站的擁有者確實是他說的那個人」。
瀏覽器上的小鎖頭，其實是在說：「這個網站的身份我查過了，傳輸也是加密的，你可以放心。」
憑證在傳輸鏈中的位置
一個使用者從輸入網址到看到你的網站，中間會經過這幾層：
憑證掛在哪裡，加密就到哪裡。
舉例來說，如果憑證掛在 Load Balancer 上，那瀏覽器到 Load Balancer 這段傳輸就是加密的。
而 Load Balancer 到伺服器這段，因為走的是 AWS 內部網路、不會經過公開的網際網路，所以通常不需要另外加密。
反過來說，如果你把憑證直接裝在伺服器上（像 Let’s Encrypt 的做法）呢？
那使用者送出的資料（像帳號密碼、表單內容），會一路加密到伺服器才被解開。
前面就算有 Load Balancer 或 CDN，它們也不負責處理加密，單純做流量分配，加密的工作全部由伺服器自己來。
這也是為什麼不同的 SSL 服務會跟不同的東西有關：
- 跟部署有關（如 Let’s Encrypt）：憑證直接裝在你的伺服器上，由伺服器自己處理加密
- 跟 CDN 有關（如 Cloudflare）：流量先進 Cloudflare 的節點，由 Cloudflare 處理加密，你的伺服器不用裝憑證
- 跟 AWS 服務有關（如 ACM）：憑證掛在 AWS 的 Load Balancer 或 CloudFront 上，由這些服務處理加密
AWS Certificate Manager（ACM）是什麼？
AWS Certificate Manager（ACM） 是 AWS 提供的一個憑證管理服務。
你可以把它想成一個「憑證的管理中心」，專門負責幫你申請、儲存、部署和自動更新 SSL/TLS 憑證。
ACM 做的事情，大概分成三塊：
如果你已經有從其他地方購買的憑證，也可以把它匯入（import）到 ACM 集中管理，非常彈性。
ACM 和其他 SSL 憑證服務有什麼差別？
你可能聽過 Let’s Encrypt、Cloudflare 或其他憑證服務，也都能拿到免費的 SSL 憑證。
那為什麼要用 ACM？
它和其他服務的差別在哪？
ACM 最大的優勢有兩個：
優勢一：跟 AWS 原生整合
申請完憑證，直接在 Load Balancer 或 CloudFront 的設定頁面選一下就掛上去了，不需要手動下載、上傳、設定。
優勢二：完全不用管更新
Let’s Encrypt 的憑證每 90 天到期一次，你必須自己在伺服器設定自動更新腳本。
ACM 只要憑證還在使用、DNS 記錄還在，就會自動幫你更新，完全不用動。
限制：憑證無法下載，只能用在 AWS 服務上
你沒辦法把憑證下載下來，裝到自己的伺服器上。
ACM 的憑證只能透過 AWS 的服務來使用（像是掛在 Load Balancer 或 CloudFront 上），沒辦法拿到憑證檔案自己安裝。
所以如果你的伺服器不在 AWS（例如放在 DigitalOcean 或自己的機房），那 Let’s Encrypt 會是更適合的選擇，因為它可以直接在任何伺服器上安裝。
為什麼不能直接把 ACM 憑證裝在 EC2 上？
這是很多人第一次碰到 ACM 時會有的疑問：免費憑證為什麼不能直接裝在 EC2 上？
原因是 ACM 的免費憑證只能跟特定的 AWS 服務搭配使用，不能直接匯出來裝到伺服器上。
目前支援 ACM 憑證的服務有：
- Elastic Load Balancing（ALB / NLB）（負載平衡器，分配流量到多台伺服器）← 這篇文章用這個
- Amazon CloudFront（CDN，讓全球使用者都能快速載入你的網站）
- Amazon Cognito（使用者登入和身份驗證服務）
- AWS Elastic Beanstalk（自動幫你部署和管理應用程式的服務）
- Amazon API Gateway（讓你建立和管理 API 的入口）
- AWS Nitro Enclave（在 EC2 裡建立隔離環境，處理高度機密的資料）
所以我們的架構是這樣的：使用者 → Load Balancer（掛著 SSL 憑證）→ EC2 實例。
Load Balancer 負責處理 HTTPS，EC2 只要正常跑 HTTP 就好。
申請 ACM 憑證前的事前準備
在開始之前，請確認你有以下兩件事：
準備一：一個可以修改 DNS 記錄的網域
你需要一個網域名稱，而且你可以新增 DNS 記錄（例如在 Route 53 購買的網域）。
為什麼需要這個？
因為 ACM 在核發憑證之前，會要求你證明「這個網域真的是你的」。
驗證的方式是：ACM 會給你一筆 CNAME 記錄，你必須把它加到你的 DNS 設定裡。
ACM 偵測到這筆記錄後，才會核發憑證給你。
所以如果你無法修改 DNS 記錄，就沒辦法完成驗證。
為什麼 ACM 用 CNAME 來驗證，而不是 TXT？
其實用 TXT 記錄來驗證網域更常見，像 Google Search Console 就是這樣做的。
但 TXT 有一個問題：驗證資料是直接寫在你的 DNS 裡的，AWS 沒辦法從遠端修改它。
CNAME 則不同，它是一個「指向」，指向 AWS 自己控制的網域。
真正的驗證資料放在 AWS 那端，AWS 可以自己管理和更新，你的 DNS 從頭到尾都不用動。
這個差別在續約的時候特別重要。
SSL 憑證是有期限的，到期前 ACM 會自動幫你續約，但續約前需要重新確認你還是網域的擁有者（因為你可能已經把網域賣掉了）。
如果用 CNAME，ACM 可以在自己那端完成這個重新驗證，全程自動，你什麼都不用做。
如果用 TXT，萬一 AWS 需要更新驗證資料，就得通知你手動去改 DNS，沒辦法全自動。
下面用具體的例子來比較兩者的差別：
用 CNAME 的情況（ACM 的做法）
你在 DNS 加的記錄長這樣：
這筆 CNAME 指向的是 _abc123.acm-validations.aws，這是 AWS 自己擁有的網域底下的一個子網域。
就像你擁有 example.com，可以在底下建立任何記錄一樣，AWS 擁有 acm-validations.aws，也可以在底下建立任何記錄。
所以 AWS 就在自己的網域底下，建了一筆 TXT 記錄在 _abc123.acm-validations.aws 這個位置，裡面放著驗證用的資料。
這不是你建的 TXT 記錄，是 AWS 在自己的網域上建的。
整個驗證流程是這樣的：
- ACM 去查
_abc123.example.com（你的網域） - 發現這是一筆 CNAME，指向
_abc123.acm-validations.aws（AWS 的網域） - 順著指向過去，找到 AWS 放在那裡的 TXT 記錄
- 比對 TXT 記錄裡的驗證資料，確認沒問題，驗證通過
續約的時候也是走同樣的流程。
如果 AWS 需要更新驗證資料，它只要改自己網域上那筆 TXT 記錄就好，因為那筆記錄本來就在 AWS 的地盤上。
你的 DNS 記錄從頭到尾都不用動，因為 CNAME 只是一個「指向」，真正的驗證資料在 AWS 自己的網域上。
如果改用 TXT 的情況（假設）
假設 ACM 改成要你直接在 DNS 加一筆 TXT 記錄：
這筆驗證資料就直接寫死在你的 DNS 裡了。
如果續約時 ACM 需要更新驗證資訊，它沒辦法幫你改，因為那筆記錄在你的 DNS、不在 AWS 的伺服器上。
你就得自己登入 DNS 去手動修改，否則驗證會失敗。
差別就在這裡： CNAME 把驗證「委託」到 AWS 的伺服器上，AWS 可以自己管理驗證資料；TXT 是把驗證資料直接放在你的 DNS，AWS 碰不到，要改就得你自己來。
準備二：確認你要使用的 AWS 區域（Region）
後續所有服務都要建立在同一個區域。
為什麼需要這個？
因為 ACM 的憑證是綁定區域的。
舉例來說，如果你在 us-east-1（美國東部）申請了一張憑證，那這張憑證只能給同樣在 us-east-1 的 Load Balancer 使用，沒辦法跨區域掛到 us-west-2（美國西部）的 Load Balancer 上。
所以在開始之前，先決定好要用哪個區域，後續的 ACM、EC2、Load Balancer 都建在同一個區域，就不會遇到找不到憑證的問題。
這篇文章使用的網域是 example.com，示範用的完整網址是 demo.example.com。
第一步：用 ACM 申請 SSL 憑證
進入 ACM 控制台
登入 AWS 後，在搜尋欄位輸入 Certificate Manager，然後點進去。
點選左側選單的「List certificates」，你會看到目前所有的憑證清單。
申請公開憑證
ACM 提供兩種憑證：
簡單來說，如果你的網站是給一般使用者瀏覽的（像部落格、電商、公司官網），就是選公開憑證。
私有憑證通常是大公司才會用到，例如公司內部有好幾台伺服器需要互相溝通，這些溝通不會經過瀏覽器，但也需要加密，這時候才會用私有憑證。
這篇文章要做的是讓網站出現小鎖頭，所以選公開憑證。
點選右上角的「Request」按鈕。
確認選的是「Request a public certificate」，然後按「Next」。
填入網域名稱（FQDN）
在「Fully Qualified Domain Name（FQDN）」欄位，填入你要保護的網址。
FQDN 的中文是「完整網域名稱」，意思是包含所有層級的完整網址。
舉個例子，example.com 是你的網域（domain），但你的網站可能跑在 demo.example.com、www.example.com 或 blog.example.com 這些不同的子網域上。
ACM 需要你填的是完整的網址，而不只是主網域，因為憑證是針對特定的完整網址來核發的。
例如：demo.example.com
如果你想用一張憑證同時保護多個子網域（像是 www.example.com、blog.example.com），不用一個一個申請，可以使用萬用字元（wildcard）的寫法，填 *.example.com 就好。
這樣所有 example.com 底下的子網域都會受到保護。
選擇驗證方式
AWS 需要確認你真的擁有這個網域，提供兩種驗證方式：
建議選「DNS validation」，因為 ACM 可以自動幫你更新憑證，不用每年手動處理。
如果選電子郵件驗證，每次憑證快到期時，AWS 都會寄一封確認信到你的網域管理員信箱，你必須手動點擊信裡的連結才能完成續約。
沒點的話，憑證就會過期失效。
選擇加密演算法
在「Key algorithm」選 RSA 2048，這是目前最廣泛支援的格式。
確認後按「Request」送出申請。
第二步：驗證網域所有權
送出申請後，憑證狀態會顯示「Pending validation」，代表還在等待驗證。
點進憑證 ID，在「Domains」區塊你會看到一筆 CNAME 記錄的資訊，你需要把這筆記錄加到你的 DNS 設定裡。
在 Route 53 新增 CNAME 記錄
如果你的網域是用 Route 53 管理的，最快的方式是直接在 ACM 頁面點「Create records in Route 53」，AWS 會自動幫你把 CNAME 記錄加到 DNS 裡，不用手動複製貼上。
如果你用的不是 Route 53，就需要手動新增。
開啟你的 DNS 服務商後台，新增一筆 CNAME 記錄，依照以下設定填入：
舉例來說，ACM 給你的值可能長這樣：
每個人拿到的值都不一樣，直接從 ACM 頁面複製貼上就好，不需要自己編。
填好後按「Create records」。
等待幾分鐘讓 DNS 傳播，當狀態顯示「In sync」就代表完成了。
確認憑證已核發
回到 ACM，重新整理頁面。
如果憑證狀態從「Pending validation」變成「Issued」，就表示憑證已成功核發。
這時「In use?」欄位會顯示「No」，因為我們還沒把憑證掛到任何服務上。
第三步：建立 EC2 實例並啟動網站
建立 EC2 實例
在 AWS 控制台搜尋「EC2」，進入後點「Launch instance」。
依照以下設定建立實例：
在「Network settings」裡，你會看到兩個重要的設定：
- VPC（Virtual Private Cloud）：你在 AWS 裡的私有網路，所有的 AWS 資源（EC2、Load Balancer 等）都要放在某個 VPC 裡面，同一個 VPC 裡的資源才能互相溝通。
- 安全群組（Security Group）：一組防火牆規則，用來控制哪些流量可以進出你的資源。例如你可以設定「只允許 HTTP 和 HTTPS 的流量進來」。
VPC 維持預設的就好。
AWS 會自動幫你建一個預設的 VPC，如果你沒有特別建過其他 VPC，這裡只會有一個選項，直接用它就好。
記下這個 VPC 的名稱或 ID（例如 vpc-0abc123def），因為後面建立 Load Balancer 時要選同一個，EC2 和 Load Balancer 必須在同一個 VPC 裡才能互相溝通。
安全群組（Security Group） 選「Create security group」讓 AWS 自動建立一個新的。
記下這個安全群組的名稱（例如 launch-wizard-1），後面建立 Load Balancer 時也要選同一個。
務必勾選允許 HTTP 和 HTTPS 流量。
在「Storage」維持預設的 8GB GP3 SSD 就好。
用 User Data 自動安裝網頁伺服器
展開「Advanced details」，找到最下方的「User data」欄位。
貼上以下指令碼，這段程式碼會自動安裝 Apache 並建立一個簡單的 Hello World 網頁：
#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Hello World from AWS Certificate Manager SSL/TLS Demo</h1>" > /var/www/html/index.html確認設定無誤後，按「Launch instance」。
確認網站正常運作
等到實例狀態從「Pending」變成「Running」，複製「Public IPv4 address」，在瀏覽器開啟。
如果看到「Hello World…」，代表 EC2 網站已正常運作。
這時網址列會顯示「不安全」，因為我們還沒有掛上 SSL 憑證，這是正常的。
第四步：建立 Application Load Balancer
進入 Load Balancer 設定頁面
在 EC2 控制台左側選單，找到「Load Balancing > Load Balancers」，點「Create load balancer」。
選擇「Application Load Balancer」，因為它支援 HTTP 和 HTTPS，適合我們的情境。
ALB 基本設定
在「Network mapping」選你的 VPC，然後選取所有 Availability Zones（至少要包含你 EC2 所在的那個區域）。
設定安全群組
移除預設的安全群組，改選你在建立 EC2 時使用的安全群組（例如 launch-wizard-2）。
建立 Target Group（目標群組）
Target Group 是告訴 Load Balancer 要把流量送到哪裡的設定。
在「Listeners and routing」區塊，HTTP 那一列按「Create target group」：
第一步：選擇目標類型
選「Instances」，因為我們要把流量導向 EC2 實例。
第二步：填入基本設定
第三步：把 EC2 加進 Target Group
前面只是建立了 Target Group，但裡面還是空的，還沒有告訴它「流量要送到哪一台機器」。
這一步就是把你的 EC2 實例加進去，這樣 Load Balancer 收到流量時，才知道要轉給誰。
在下一頁，勾選你剛建立的 EC2 實例，確認 Port 是 80（代表 Load Balancer 會把流量送到 EC2 的 80 port，也就是 Apache 網頁伺服器在監聽的 port），按「Include as pending below」，再按「Create target group」。
設定 HTTP 和 HTTPS 監聽器
監聽器（Listener）是告訴 Load Balancer「要在哪個 port 接收流量，收到後送去哪裡」。
我們需要設定兩個監聽器：
- HTTP（Port 80）：接收一般的 HTTP 流量
- HTTPS（Port 443）：接收加密的 HTTPS 流量
兩個監聽器收到流量後，都會送到同一個 Target Group（也就是你的 EC2）。
回到 Load Balancer 設定頁面，HTTP 監聽器預設已經建好了，在它的「Default action」選擇剛建立的 Target Group。
接著按「Add listener」新增 HTTPS 監聽器：
把 ACM 憑證掛到 Load Balancer 上
在「Secure listener settings」區塊：
- Certificate source 選「From ACM」
- 在下拉選單選擇你剛才申請的憑證（
demo.example.com）
其他設定維持預設，確認後按「Create load balancer」。
等待約 2 分鐘，狀態從「Provisioning」變成「Active」就完成了。
第五步：設定 DNS A 記錄指向 Load Balancer
到目前為止，Load Balancer 已經建好了、憑證也掛上去了，但使用者還沒辦法透過 demo.example.com 連到你的網站。
為什麼？因為 demo.example.com 這個網址還沒有跟 Load Balancer 連起來。
Load Balancer 有自己的位址，但那是一串很長的 AWS 內部網址（像是 sslDemoALB-123456.us-west-2.elb.amazonaws.com），沒有人會記得這種網址。
所以這一步要做的事情是：在 DNS 新增一筆 A 記錄，讓 demo.example.com 指向你的 Load Balancer。
這樣使用者輸入 demo.example.com 時，DNS 會自動把他導向 Load Balancer，Load Balancer 再把流量轉給 EC2。
這篇文章使用的是 Route 53，所以可以直接用 Alias A 記錄來指向 Load Balancer。
Load Balancer 建立完成後，在詳細資訊頁面找到「DNS name」，這是 Load Balancer 的位址。
開啟 Route 53，在你的 Hosted Zone 新增一筆 A 記錄：
按「Create records」，等待狀態變成「In sync」。
完成後，用瀏覽器開啟 https://demo.example.com，你會看到網站，而且網址列會出現小鎖頭！
如果你用的不是 Route 53 怎麼辦？
一般的 A 記錄需要填一個固定的 IP 位址（像 52.68.123.45），但 Load Balancer 沒有固定 IP，背後的 IP 會隨時變動，AWS 會根據流量自動調整。
所以你沒辦法用普通的 A 記錄指向 Load Balancer，因為根本沒有一個固定的 IP 可以填。
這時候就改用 CNAME 記錄，因為 CNAME 填的是另一個網域名稱（不是 IP），可以直接指向 Load Balancer 的 DNS 名稱。
不過要注意，CNAME 只能用在子網域（像 www.example.com、ssl-demo.example.com），不能用在根網域（像 example.com），這是 DNS 規範的限制。
這不代表根網域就不能有 SSL 憑證。
SSL 憑證和 DNS 指向是兩件不同的事：憑證負責加密，DNS 負責把流量導到正確的地方。
ACM 核發憑證只需要你證明網域是你的（就是前面講的 CNAME 驗證），跟你用哪家 DNS 服務商沒有關係。
所以就算你用 GoDaddy，ACM 一樣可以核發 example.com 的憑證，憑證照樣掛在 Load Balancer 上。
真正的問題是：使用者在瀏覽器輸入 example.com 的時候，流量要怎麼到達你的 Load Balancer？
這件事是 DNS 在處理的，跟憑證無關。
Route 53 的 Alias 怎麼解決這個問題？
Route 53 有一個特殊功能叫 Alias，它讓 A 記錄可以直接指向 AWS 的服務（像 Load Balancer）。
你只要選 Load Balancer，Route 53 會在背後自動去查目前的 IP 是什麼，然後動態回應給使用者。
對你來說看起來像是設了一筆普通的 A 記錄，但其實 Route 53 在背後幫你處理了 IP 變動的問題。
而且 Alias A 記錄不受根網域的限制，example.com 也能直接指向 Load Balancer，不需要繞路。
如果你的 DNS 服務商不支援 Alias 怎麼辦？
如果你用的是 GoDaddy 等不支援 Alias、ANAME 功能的服務商，常見的做法是：
- 用 GoDaddy 的「網域轉址（Forwarding）」功能，把
example.com自動轉到www.example.com - 再用 CNAME 把
www.example.com指向 Load Balancer
第一步：設定網域轉址
在 GoDaddy 後台的「Forwarding」設定：
第二步：新增 CNAME 記錄
在 GoDaddy 後台的「DNS Records」新增一筆：
這樣使用者不管輸入 example.com 還是 www.example.com，最終都會到 Load Balancer，而且都有 SSL 加密。
第六步：讓 HTTP 自動轉向 HTTPS
目前 HTTP 和 HTTPS 都能進入網站，但為了讓所有流量都走安全的 HTTPS，我們要修改 HTTP 監聽器的行為。
在 Load Balancer 頁面，點選「Listeners and rules」標籤。
找到 HTTP（Port 80）那一列，點「Manage listener > Edit listener」。
在「Routing actions」改選「Redirect to URL」，然後選「Full URL」，填入：
https://demo.example.com:443Status code 選「301 Moved Permanently」，按「Save changes」。
設定完成後，當使用者輸入 http://demo.example.com，瀏覽器會自動跳轉到 https://demo.example.com，完全透明、不需要使用者做任何事。
小結：從申請 ACM 憑證到啟用 HTTPS 的完整流程
這篇文章帶你完成了以下幾件事：
- 申請免費 SSL 憑證：透過 ACM 申請 DNS 驗證的公開憑證，AWS 會自動更新，不用每年手動處理。
- 建立 EC2 網站：用 User Data 自動安裝 Apache 並建立簡單網頁。
- 建立 Application Load Balancer：掛上 SSL 憑證，讓 HTTPS 流量可以安全進入。
- 設定 DNS A 記錄：讓自訂網域指向 Load Balancer。
- HTTP 自動轉 HTTPS：確保所有流量都走加密連線。
完成後，點擊瀏覽器上的小鎖頭，你可以看到憑證由 Amazon 核發，有效期超過一年，完全免費。