AWS企業認證帳號 AWS S3 靜態網站使用自訂功能功能功能域名報 SSL 證書不匹配排查
先弄清楚，錯誤到底在告訴你什麼
當你把 AWS S3 靜態網站綁上自訂網域後，瀏覽器跳出 SSL 證書不匹配，很多人第一反應是「證書壞了」或「S3 出問題了」。其實大多數情況都不是證書本身有缺陷，而是你打開的網域、實際回應的服務、以及證書上寫的名字，三者沒有對齊。瀏覽器在做 TLS 驗證時，只認一件事：你現在連到的這個主機名稱，是否在證書可接受的範圍內。如果主機名稱是 www.example.com，證書卻只給了 example.com，或者請求其實到了另一個未配置憑證的端點，就會直接報錯。
對 S3 靜態網站來說，這個問題特別容易發生，原因很簡單：S3 的網站端點本身不是一台可以直接安裝憑證的網頁伺服器。它更像是一個對外提供靜態檔案的公開端點，若你想用 HTTPS 和自訂網域，就不能只靠 S3 本身解決，通常要透過 CloudFront 這類邊緣分發服務把憑證掛在前面。很多人卡住，就是因為把「S3 網站端點」和「可直接使用 HTTPS 的自有主機」混為一談。
第一步：先判斷你現在的架構是哪一種
排查之前，先把架構分清楚。只要這一步錯了，後面做再多設定都只是在補洞。
情境一：你是直接把網域指到 S3 靜態網站端點
這種做法常見於只想快速上線的靜態頁面。你建立了 bucket，開啟靜態網站託管，然後把 DNS 指向 S3 提供的網站端點。問題在於，S3 網站端點只支援 HTTP，不支援你自行掛載憑證。也就是說，如果你希望使用 https:// 並且網址還是你自己的網域，這條路本身就走不通。當你強行在瀏覽器輸入 HTTPS，看到的不是正常網頁，而是證書不匹配或連線失敗，這不是配置細節錯了，而是架構不對。
很多人會想，既然是自訂網域，能不能直接給 S3 一張 ACM 憑證？答案是不行。S3 靜態網站端點沒有提供讓你綁定憑證的位置。真正可以放憑證的，是放在前面的 CloudFront，或其他可以終止 TLS 的服務。只要你沒有把這個邏輯先弄明白，後面很容易誤判成 DNS 問題或瀏覽器問題。
情境二：S3 當來源，前面接 CloudFront
這才是大多數正式環境的做法。S3 只負責存靜態檔案，真正對外的是 CloudFront。使用者瀏覽器先連到 CloudFront，CloudFront 再去抓 S3 的內容。這樣一來，HTTPS 的憑證是掛在 CloudFront 上，而不是掛在 S3 上。只要你的自訂網域、憑證、DNS 都指向 CloudFront，SSL 問題通常就能解掉。
但這種架構也有自己的規矩。CloudFront 需要設定替代網域名稱，也就是你的自訂網域名稱；憑證必須在正確的區域發行，通常是 us-east-1；而 DNS 要把網域指到 CloudFront 的分發網域，不是 S3 網站端點。如果其中任何一項沒對上，瀏覽器看到的憑證和你輸入的網域就會不一致。
最常見的三種不匹配來源
一、你打開的網域，不是證書涵蓋的網域
這是最直觀的一種。假設你申請的憑證只包含 example.com，但你實際打的是 www.example.com，那麼瀏覽器就會認為證書不匹配。反過來也一樣，證書只有 www.example.com，根域名 example.com 也會出問題。很多人做完主域名後再補一個 www，卻忘了把兩者都放進證書 SAN，最後導致一半可用、一半報錯。
如果你使用通配符憑證，也要注意範圍限制。*.example.com 只能匹配一層子網域，例如 www.example.com、blog.example.com，但不能匹配根域名 example.com，也不能匹配多層子域名。很多人以為有通配符就萬能，結果還是踩坑。
二、DNS 指到錯的地方
你以為自己的網域已經接上 CloudFront，但實際上 DNS 還在指向舊的 S3 網站端點、舊的 CDN、舊的主機，或一個已失效的測試環境。這時候瀏覽器連到的根本不是你以為的服務，自然也不會拿到正確的憑證。更麻煩的是，某些 DNS 變更需要時間傳播，快取還沒清掉時，你本地和別人的結果可能還不一樣。
如果你是根域名，通常要用支援別名的紀錄型態，把 apex domain 指向 CloudFront；如果是子網域，通常可以用 CNAME。不要把 CNAME 直接指到 S3 網站端點，尤其是你還想用 HTTPS 的時候，這條路基本上就是不對的。你可以把它想成：DNS 只是指路，它不會幫你補上憑證。
三、CloudFront 或前置服務本身沒綁好
CloudFront 端常見的疏漏有三個：沒有加入替代網域名稱、沒有選對證書、或者證書還沒部署完成。只要其中一項有問題，瀏覽器端就會先在 TLS 階段失敗，甚至在還沒看到你的網站內容前就直接擋下來。
還有一個常被忽略的細節，就是你以為已經更新了證書，但 CloudFront 邊緣節點尚未完全生效。這段時間內，某些地區仍可能拿到舊設定。若剛換證書不久就測試，最好先看清楚是不是部署延遲，而不是急著回頭改 S3。
排查時，請照這個順序來
不要一上來就改一堆設定。證書問題最怕亂，因為你改得越多，越難回頭找原因。最穩的方式，是按順序一項一項確認。
- 先打開無痕視窗，避免舊快取和舊憑證干擾。
- 看瀏覽器地址列，確認你實際輸入的是哪個網域，是根域名還是
www，有沒有自動跳轉。 - 檢查目前服務是直連 S3 網站端點，還是經過 CloudFront。
- 查看證書上是否包含目前的主機名稱，特別是 SAN 清單。
- 確認 DNS 是否真的指向 CloudFront，而不是還留在舊地址。
- 確認 CloudFront 的替代網域名稱是否和你的網域完全一致。
- 確認證書是否在正確區域，是否已完成部署。
- 最後再觀察瀏覽器快取、HSTS、以及本機 DNS 快取是否還在干擾。
照這個順序做，通常能很快縮小範圍。很多人一開始就去重建 bucket、重發憑證、換版本號，結果真正的問題只是 DNS 還沒切到正確的分發網域。
AWS企業認證帳號 幾個最容易被忽略的細節
根域名和 www 不要拆開思考
實務上，很多網站會同時提供 example.com 和 www.example.com。兩個地址最好都放進同一張憑證，然後選擇其中一個作為主入口，再把另一個 301 轉址過去。這樣最穩。因為 TLS 驗證發生在跳轉之前，若你先連到的那個網域本身就不在證書範圍內，瀏覽器根本等不到轉址完成。
這也是為什麼有些人明明設定了從根域名跳到 www，但還是報錯。原因很單純：瀏覽器在看到轉址前，就已經因為證書不匹配先把連線擋下了。
憑證要注意區域與來源
如果你用的是 CloudFront 搭配 ACM，憑證通常要在 us-east-1 申請或匯入。很多人明明在其他區域看得到證書，卻無法讓 CloudFront 正常使用，就是卡在這一點。對 CloudFront 來說，證書放錯區域，等於根本沒放對地方。
AWS企業認證帳號 另外，還要確認證書鏈完整。若是你匯入第三方憑證，鏈不完整有時候也會造成部分客戶端報錯。雖然這不一定表現為典型的名稱不匹配，但在實務上，使用者看到的錯誤訊息常常很接近，容易被一起誤判。
不要忽略瀏覽器 HSTS 和快取
如果你的網域曾經啟用過 HSTS，瀏覽器可能會強制把 HTTP 升級成 HTTPS。這時候即便你現在想暫時回到 HTTP 測試，也未必行得通。再加上本地 DNS 快取、瀏覽器快取、甚至公司網路的代理快取，都可能讓你看到舊結果。排查時最好換設備、換網路、換無痕模式交叉驗證，避免被快取誤導。
實戰中最常犯的錯誤配置
- 把 S3 網站端點當成 HTTPS 入口，卻沒有 CloudFront。
- 憑證只申請了主域名，忘了加
www。 - DNS 還指向舊服務，卻以為 CloudFront 已經接管。
- CloudFront 沒有加入替代網域名稱。
- 證書不在正確區域，導致前端根本無法使用。
- 更新後馬上測試，忽略了傳播與部署時間。
- 只檢查首頁，沒有檢查根域名與子域名是否都正常。
這些錯誤看起來零碎，其實本質都一樣：你以為自己改的是同一層，實際上每一層在負責不同事情。S3 負責內容，CloudFront 負責對外，憑證負責身份，DNS 負責指路。只要其中一層對不上，SSL 就會先翻臉。
如果你想要穩定上線，建議直接採用這個架構
對大多數靜態網站來說，最穩定的做法是：S3 當來源，CloudFront 當入口，ACM 憑證放在 CloudFront，DNS 指向 CloudFront，再加上需要的轉址規則。這樣做的好處很明顯。第一，你可以正常使用 HTTPS；第二，你可以綁定自訂網域；第三，你不必把 S3 公開成網站端點，安全性也更好；第四，後續要加快取、地區加速、WAF，都有延展空間。
如果你的需求只是簡單展示頁，而且完全不在乎 HTTPS，那麼直連 S3 網站端點也能用。但只要你一開始就確定要上自訂網域和 SSL，最好不要走那條省事但註定卡關的路。很多技術債，就是從「先上線再說」開始的。
AWS企業認證帳號 最後的判斷標準
當你再次看到 SSL 證書不匹配，不要先猜。先問三個問題：我現在打的是哪個網域；這個網域對應到哪個服務；這個服務上的證書是否真的包含這個網域。只要這三件事都對齊，問題通常就會消失。
對 AWS S3 靜態網站來說，真正的關鍵不是把檔案放上去，而是把「入口」設對。S3 可以很簡單，但 HTTPS 和自訂網域從來不只是把 bucket 打開這麼單純。把 CloudFront、憑證、DNS 的關係弄清楚，你會少掉一大半排查時間，也不會再被看起來很像 SSL 問題的訊息繞暈。
一句話總結：S3 靜態網站的 SSL 不匹配，多半不是證書本身壞了，而是你連到的網域、前面的入口、以及證書覆蓋範圍沒有對上。先對架構，再對設定，最後才談細節，這樣才不會越修越亂。
