為何 HTTPS 連線老是失敗？從一個常見錯誤揭開 5 個網路加密的驚人真相

TLS - Transport Layer Secure

1.0 開場：一個惱人的錯誤，一堂關於信任的課

如果你曾嘗試架設個人網站或伺服器，你可能遇過一個令人沮喪的畫面：當滿心期待地在網址列輸入 https://，看到的卻不是漂亮的網站，而是一行冰冷的錯誤訊息：

ERR_SSL_UNRECOGNIZED_NAME_ALERT

這個錯誤看似技術性十足，令人卻步，但它其實是一把鑰匙，能為我們打開現代網路安全基石 —— HTTPS 的運作大門。本文將帶你從這個經典錯誤出發，層層剝繭，揭示 HTTPS 背後五個關於驗證、加密與信任的驚人真相。

2.0 重點一：HTTP 與 HTTPS 不只是差一個 S

「普通櫃檯」與「VIP 密室」的差別

許多人以為 HTTPS 只是 HTTP 的加密版，但它們的根本差異，從連線的第一毫秒就開始了。

ERR_SSL_UNRECOGNIZED_NAME_ALERT 的發生，正是因為瀏覽器（訪客）表明了預約的名字，但伺服器（管理員）在名單上找不到，無法出示正確證件，守衛只好直接把你趕走。

3.0 重點二：在開口說話前，伺服器必須先出示「身分證」

前文提到的「握手」，專業術語是 TLS 握手 (TLS Handshake)。在現代網路架構中，一個 IP 位址可能同時運行數百個網站，這引發了一個問題：伺服器該拿哪張憑證給你？

這項關鍵技術稱為 SNI (Server Name Indication)：

1. 瀏覽器告知： 在加密開始前，先告訴伺服器：「我要找的是 A 網站」。
2. 伺服器回應： 根據 SNI 請求，從憑證庫挑選對應的 SSL 憑證（身分證）。
3. 失敗結果： 若伺服器找不到對應憑證，握手就會立刻中斷。

核心差異：HTTP (80): 先連線，再說要找誰。HTTPS (443): 必須先說要找誰，驗完證件，才准連線。

4.0 重點三：最安全的加密只用在最初幾秒

為了交換一把「臨時鑰匙」

HTTPS 採用了一個聰明的混合策略，在「極致安全」與「傳輸效能」之間取得平衡：

• 非對稱加密（公鑰/私鑰）： 安全性極高但運算極慢。僅用於連線最初的幾秒，用來安全地交換資訊。
• 對稱加密（Session Key）： 加密速度極快。一旦雙方透過上述步驟拿到這把「臨時鑰匙」，後續所有資料（影片、圖片）都改用它傳輸。

生動比喻：

「我們先用『昂貴的保險箱』送出一把『便宜的儲物櫃鑰匙』，之後我們就直接用那把『便宜鑰匙』開櫃子換東西，速度快了幾百倍。」

5.0 重點四：公鑰與私鑰的魔法

一把只能上鎖，另一把專門解鎖

非對稱加密的原理可以用「特製掛鎖」來理解：

• 公鑰 (Public Key)： 像是一個已經打開的掛鎖，伺服器發給全世界。任何人都能用它鎖上資訊，但鎖上後自己也打不開。
• 私鑰 (Private Key)： 伺服器秘密保管的唯一實體鑰匙。

這背後是基於數學上的「單向陷阱函數」。舉例來說，伺服器給出的公鑰是 187：

• 加密容易： 使用 187 進行數學運算。
• 解密極難： 除非你知道它的質因數分解 11 x 17（這就是私鑰）。

當數字長達數千位時，全世界的電腦運算幾萬年也解不開，這正是現代網路加密的基石。

6.0 重點五：一旦用了 HTTPS，就很難「回去」了

當你設定好 HTTPS 後，瀏覽器會「固執地」自動跳轉，這歸功於三種安全機制：

1. 強制跳轉 (Force SSL)： 伺服器端設定規則，將 80 port 的流量引導至 443 port。
2. HSTS (HTTP Strict Transport Security)： 伺服器命令瀏覽器：「記住！未來一年內訪問我，絕對不准用不安全的 HTTP」。
3. 瀏覽器 HTTPS 優先模式： 現代瀏覽器（Chrome, Firefox）會主動嘗試以 HTTPS 「敲門」，成功後便會記住。

7.0 結論：從錯誤訊息看見信任基石

從一個看似單純的 ERR_SSL_UNRECOGNIZED_NAME_ALERT 錯誤出發，我們看見了一場關於驗證、加密與信任的優雅舞蹈。下次當你在網址列看到那個綠色鎖頭時，你就會知道，這背後有多少複雜的機制在默默守護著你的資訊安全。