在理解了SSL與TLS協定的基本架構後，接著可以來介紹HTTPS，在進入HTTPS之前，我們先簡單了解一下HTTP。

HTTP（HyperText Transfer Protocol，超文字傳輸協定）是網際網路上最常用的協定之一，負責在客戶端（例如瀏覽器）與伺服器之間傳輸資料，包括文字、圖像、音訊、影片等。HTTP協定的作用在於統一了客戶端和伺服器之間的通訊格式。它為OSI模型的最上層（應用層）協定，專門用來處理網頁的請求與回應。當我們在瀏覽器中輸入網址並按下 Enter 鍵時，瀏覽器會透過 HTTP 協定向伺服器發送請求，然後將伺服器回應的內容呈現在瀏覽器上。

然而，HTTP本身並不具備安全性。因為傳輸的資料是以明文方式進行的，容易被攔截或竄改。因此，為了增強安全性，HTTPS應運而生。HTTPS就是在HTTP協定的基礎上，加入了一層安全協定，這層安全保護機制就是SSL/TLS，能夠加密傳輸的資料，並確保通信的安全性。

換句話說，HTTPS其實是在HTTP協定的基礎上，加上了一層安全性協定，而這層協定就是上章節提到的SSL/TLS。這層安全機制能夠提供資料加密、伺服器認證，以及資料完整性驗證。因此，當你在瀏覽器網址列看到"https"時，代表你與該網站的通信是經過加密保護的，且該網站的身分已經過可信任的憑證授權機構（CA）核發的數位憑證認證。

HTTPS的運作是由後端伺服器實現的，因為SSL/TLS憑證需要安裝在伺服器上。當伺服器安裝並配置好憑證後，便會自動進行SSL/TLS握手過程，建立起安全的連線。在接下來的內容中，我們將探討HTTPS的運作方式，而HTTP的詳細格則會在下一個章節進行解說。

憑證是什麼？

HTTPS的運作是由後端伺服器實現的。當伺服器安裝並配置好憑證後，便會自動進行SSL/TLS握手過程，建立起安全的連線。要建立起安全連線，需要有一個認證機制，而這個認證機制的內容來自於 憑證。那麼，憑證到底是什麼呢？

SSL/TLS憑證是一種數位憑證，用來驗證伺服器的身份，並加密網站與使用者之間的通信。這個憑證包含公開金鑰、伺服器的身分資訊（如網域名稱），以及憑證授權機構（CA）的數位簽章。當使用者連線到網站時，瀏覽器會檢查該憑證的真實性，確保網站身份合法。

數位憑證（SSL/TLS憑證）通常包含以下幾個主要內容：

1. **憑證持有者的資訊：**憑證所屬者的詳細資料，如組織名稱、網域名稱（FQDN，Fully Qualified Domain Name）、組織的所在地等。這些資訊能夠幫助識別該憑證屬於哪個網站或公司。
2. **公開金鑰：**憑證中會包含一個公開金鑰，這個金鑰用於在SSL/TLS握手過程中加密資料。公開金鑰是非對稱加密的一部分，與私密金鑰配對使用。
3. 憑證授權機構（CA）的資訊：簽發該憑證的憑證授權機構的名稱及其相關資訊。CA的角色是對憑證的合法性進行背書，確保憑證持有者的身份是真實的。
4. 憑證的有效期：每張憑證都有一個有效期，通常會顯示開始日期和到期日期。在這段時間內，憑證有效，可以用來建立安全的HTTPS連線。當憑證過期後，需要更新憑證以保持網站的安全性。
5. 憑證的序列號：用於識別這張憑證。憑證序列號通常在憑證管理中用於追蹤和識別特定憑證。
6. 憑證簽名演算法：這是用來對數位憑證進行簽名的演算法，通常是加密演算法的一部分，用來確保憑證的完整性和真實性。常見的簽名演算法包括SHA-256等。
7. CA的數位簽名：最後，憑證會包含CA對這份憑證的數位簽名，用於驗證憑證的真實性和完整性。只有受信任的CA才能進行這樣的簽署，並且客戶端（如瀏覽器）會使用CA的公開金鑰來驗證該數位簽名。

如果你要看網站的憑證，使用Chrome打開瀏覽器，在此處點選已建立安全連線，接著就會跳出憑證有效的選項。

點選後就可以看到網站所用憑證相關訊息，如下圖為www.cloudflare.com 的 SSL/TLS 憑證資訊，包含核發對象、發行者（Google Trust Services）、有效期間（2024年9月6日到2024年12月5日），以及使用的加密演算法（SHA-256 和 ECDSA）。這憑證確保網站的通訊安全與加密。

憑證類型

數位憑證（SSL/TLS憑證）有多種類型，主要是根據其驗證方式和用途來分類。以下是常見的憑證類型：

1. 域名驗證憑證（Domain Validation, DV）

• 用途：適用於保護個人網站、小型企業網站，主要用於驗證域名的所有權。
• 驗證方式：CA僅會驗證申請者對該域名的所有權，通常透過DNS記錄或電子郵件確認。
• 驗證過程簡單且快速，價格相對較低，但不提供企業或組織的驗證資訊。
• 顯示方式：使用此類憑證的網站，瀏覽器地址欄中會顯示鎖頭圖標及「https://」，但不會顯示公司名稱。
• 範例：使用 Let's Encrypt 提供免費 SSL 憑證的小型網站或個人部落格（如 https://myblog.com），點擊鎖頭圖標只會顯示網站的 HTTPS，但不會顯示公司名稱。

2. 企業驗證憑證（Organization Validation, OV）

• 用途：適用於中小企業或組織網站，提供比DV憑證更高的安全級別。
• 驗證方式：CA不僅會驗證域名所有權，還會驗證企業或組織的真實性，確認申請者為合法企業。
• 需要提交公司相關文件進行審核，驗證過程會稍微長一些。
• 顯示方式：瀏覽器地址欄顯示鎖頭圖標及「https://」，有時會顯示企業名稱，但不顯示於地址欄內。
• 範例：某中小企業的網站（如 https://smallbiz.com），當使用 OV 憑證時，瀏覽器會顯示鎖頭與 HTTPS，憑證詳細資訊中會有公司名稱和地址。

3. 擴展驗證憑證（Extended Validation, EV）

• 用途：適合大型企業、銀行、電商網站等對安全性要求較高的網站，提供最高級別的信任。
• 驗證方式：這類憑證的驗證過程最為嚴格，CA會進行深入的企業背景調查，核實企業的真實性及合法性，申請者必須提供詳細的公司文件。
• 顯示方式：使用EV憑證的網站，瀏覽器地址欄會顯示鎖頭圖標及企業名稱，增加用戶對網站的信任感。
• 安全等級最高，但申請費用及驗證時間相對較長。
• 範例：當你訪問金融網站（如 https://www.paypal.com）或大型電商網站（如 https://www.amazon.com）時，瀏覽器的地址欄會顯示鎖頭，並且顯示企業名稱（如「PayPal, Inc.」）。

4. 通配符憑證（Wildcard Certificate）

• 用途：適合需要保護主域名和所有子域名的網站。例如，保護「example.com」以及「*.example.com」（如www.example.com, mail.example.com等）。
• 驗證方式：可以是DV或OV類型的驗證，但憑證適用於該域名下的所有子域名，這使得管理多個子域名變得簡單且具成本效益。
• 優點：節省費用和時間，無需為每個子域名申請單獨的憑證。
• 範例：一家公司使用通配符憑證來保護其主域名和所有子域名，如 https://example.com、https://mail.example.com、https://shop.example.com 都使用相同的憑證。

5. 多域名憑證（Multi-Domain SSL Certificate，也稱為SAN憑證）

• 用途：適用於需要保護多個不同域名或子域名的情境，尤其是管理多個網站的企業。
• 驗證方式：可以是DV、OV或EV類型的驗證，這類憑證可以保護多達數十個不同的域名，所有域名可以共用一張憑證。
• 優點：簡化了對多個域名的管理，只需管理和續期一張憑證。
• 範例：跨國公司有多個網站域名（如 https://site1.com、https://site2.com、https://site3.com），可以使用同一張多域名憑證來保護這些不同的網站。

6. 自簽憑證（Self-Signed Certificate）

• 用途：通常用於內部測試或開發環境，這類憑證不由CA簽發，而是自行生成。
• 驗證方式：沒有由CA驗證，因此不適合用於公開網站，因為瀏覽器會標記這類網站為「不安全」。
• 優點：免費且方便，但不適合商業用途，缺乏信任機構的背書。
• 範例：開發團隊在測試環境中（如 https://localhost）使用自簽憑證，這類網站在瀏覽器中會顯示「不安全」的警告，因為沒有經過第三方機構驗證。

SSL/TLS握手過程中的憑證運作方式

接下來解釋憑證如何在SSL/TLS交握時作用，以下引用Cloudflare 的圖片來解釋 SSL/TLS 握手的完整過程，從 TCP 連線建立到加密通信的開始。握手過程的每個步驟都關係到如何透過加密技術確保客戶端（Client）和伺服器（Server）之間的安全通信。以下是圖片的詳細解釋：

1. TCP 連線建立

• SYN 和 ACK：這是握手開始之前的步驟，屬於 TCP 的三次握手過程，用來建立基礎的連接。具體流程如下：

  • 客戶端發送 SYN 封包，向伺服器請求連接。
  • 伺服器回應 SYN ACK，表示同意連接。
  • 客戶端確認收到 SYN ACK，回應 ACK，連接成功建立。

  這個過程大約需要 50ms 左右，是建立基礎連接的步驟。

2. ClientHello

• 客戶端（Client）向伺服器發送 ClientHello 訊息，這個訊息包含：

  • 支援的 SSL/TLS 版本：例如 TLS 1.2 或 1.3。
  • 支援的 加密演算法（cipher suites）：這是客戶端能夠使用的加密算法列表，如 RSA、ECDSA、AES 等。
  • 隨機數據：用於後續的密鑰生成，這部分隨機數據與伺服器的隨機數據一起生成會話金鑰。

  這一步是握手過程的開始，告訴伺服器客戶端支持的加密協議。

3. ServerHello 和憑證傳輸

• 伺服器收到 ClientHello 後，回應 ServerHello 訊息，包含：

  • 確認的 SSL/TLS 版本 和 加密演算法：伺服器選擇一個客戶端支持且自己也支持的加密算法。
  • 伺服器憑證（Certificate）：這是伺服器提供的數位憑證，包含伺服器的公開金鑰及憑證授權機構（CA）的簽名，用於身份驗證。
  • ServerHelloDone：表示伺服器已完成回應，等待客戶端進一步的操作。

  憑證在此階段至關重要，因為客戶端需要通過憑證來驗證伺服器的身份。這確保客戶端連接到的是受信任的伺服器，而非惡意攻擊者。

4. ClientKeyExchange 和加密通信準備

• 客戶端在驗證伺服器憑證之後，進行 ClientKeyExchange：

  • 客戶端生成一個隨機的 預主密鑰（Pre-Master Secret），並使用伺服器的公開金鑰對其加密，然後將加密後的預主密鑰發送給伺服器。
  • 伺服器收到後，使用其私密金鑰解密，從而獲得預主密鑰。

  接下來，雙方基於這個預主密鑰以及之前的隨機數據，生成對稱加密密鑰，用於後續的加密通信。在這一步，客戶端也會發送 ChangeCipherSpec 訊息，表示後續的通信將會使用新的加密算法和密鑰。

5. ChangeCipherSpec 和握手完成

• 伺服器回應：伺服器解密預主密鑰後，也會生成相同的對稱加密密鑰，並回應 ChangeCipherSpec 訊息，表示後續的通信將會加密進行。
• Finished 訊息：伺服器最後回應 Finished 訊息，表示握手過程完成，雙方現在都準備好進行加密通信。

6. 安全通信(資料傳輸)

• 握手過程完成後，雙方建立了對稱加密的通道。接下來的所有資料傳輸都會使用這個對稱密鑰進行加密，確保通信的私密性和完整性。

在了解完 SSL/TLS 握手中的憑證作用流程後，我們可以進一步使用ByteBytego這張圖來詳細解釋 HTTPS 的整體流程。這張圖非常直觀地展示了 HTTPS 如何通過非對稱加密與對稱加密的結合來保護資料傳輸的安全性。

• TCP 握手階段 (TCP Handshake)

  客戶端和伺服器進行 TCP 三次握手。客戶端發送 SYN，伺服器回應 SYN + ACK，然後客戶端再回應 ACK。這樣，TCP 連線就正式建立，為後續的 HTTPS 連線打好基礎。這個步驟確保雙方建立可靠的連接，所有數據都可以有序傳送。

• 憑證驗證 (Certificate Check)

  • 客戶端發送 ClientHello，伺服器回應 ServerHello，並附帶伺服器的 數位憑證(藍鑰匙)。客戶端檢查伺服器的憑證是否有效（例如由受信任的 CA 簽發）。
  • 此時，非對稱加密開始發揮作用：伺服器的 公開金鑰 用於加密客戶端生成的預主密鑰（session key），而只有伺服器的 私密金鑰 能夠解密這個訊息，確保數據的安全傳輸。

• 密鑰交換 (Key Exchange)

  • 客戶端生成 Session Key（會話密鑰），並使用伺服器的 公開金鑰 進行加密，然後將加密的 session key 傳送給伺服器。伺服器使用自己的 私密金鑰 解密這個密鑰。
  • 這一階段使用的是 非對稱加密（圖中標示為「public key」和「private key」），目的是安全地交換用於後續加密通信的對稱密鑰。

• 數據傳輸 (Data Transmission)

  • 握手完成後，客戶端與伺服器之間開始使用 對稱加密 進行數據傳輸。這時，雙方都使用相同的 Session Key 來加密和解密數據，確保通信過程中的安全性。
  • 對稱加密比非對稱加密更快且更適合大量數據的傳輸，因此 HTTPS 使用非對稱加密來安全地傳輸密鑰，而使用對稱加密來進行實際的數據通信。

Session Key 是用來加密 當次連線期間 的數據的對稱加密密鑰，通常以隨機生成的一串位元組（bytes）來表示，並根據加密演算法的不同有不同的長度和格式。例如十六進位表示的 Session Key（256 位 AES）：

9f2c7b2df3120b4b4e5e4a08cf96324e5b8c9f68c9d5f8b7e4b2f3b123456789

在了解完 SSL/TLS 憑證的驗證流程後，接下來你可能會想知道：那麼憑證該如何申請呢？以下我們簡單介紹數位憑證的申請過程，以及選擇憑證授權機構（CA）的注意事項。

憑證申請

憑證授權機構（Certificate Authority，簡稱 CA）是專門負責發行數位憑證的受信第三方組織。數位憑證用來驗證網站或個人的身份，並提供公鑰，以確保資料能夠在網路上安全傳輸。申請數位憑證的過程通常包括以下幾個步驟：

1. 申請證書：首先，你需要向 CA 提出申請，並提供相關的個人或組織資訊，以及你的公開金鑰。

2. 驗證身份：接著，CA 會核實你提供的資訊。這可能包括確認你的身份、驗證你的組織是否合法，並檢查你是否擁有申請的網域。驗證過程的嚴格程度取決於你申請的憑證類型。舉例來說，如果你申請的是擴展驗證（Extended Validation，簡稱 EV）憑證，可能需要提供較多文件來證明身份與合法性。

3. 簽署證書：一旦身份驗證完成，CA 會使用他們的私密金鑰來簽署你的公鑰和其他資訊，生成數位憑證。這個憑證將證明你的公鑰與身份資訊的關聯性，並且只要擁有 CA 的公開金鑰，任何人都可以驗證這個簽名的真實性。

許多網站伺服器軟體（例如 Apache、Nginx）以及雲端平台（如 AWS、Google Cloud）都提供工具來協助生成公私鑰對，並幫助完成憑證申請和安裝流程。

申請數位憑證通常需要支付費用，具體費用取決於選擇的 CA 和憑證的類型。不過，有些組織（如 Let's Encrypt）提供免費的憑證，以推動網路安全發展。

需要注意的是，申請及安裝數位憑證需要具備一定的技術知識，並且必須妥善保管你的私密金鑰，因為一旦私密金鑰被他人取得，他們便能解密你的加密通信。

當你從 CA 獲得 SSL/TLS 憑證後，還需要將其安裝到伺服器上。這通常包括上傳憑證文件並修改伺服器的配置，讓伺服器能夠使用該憑證。這樣一來，當客戶端透過 HTTPS 連接到你的網站時，伺服器就能提供憑證並建立安全連線。

憑證機構

SSL/TLS 憑證由憑證授權機構（Certificate Authorities，縮寫為 CAs）簽發。在全球範圍內，有許多知名的 CA 供你選擇，例如 DigiCert、GeoTrust、Thawte 等。

購買憑證的價格會根據憑證類型和選擇的 CA 而有所不同。較簡單的域名驗證（DV）憑證每年可能只需數十美元，而擴展驗證（EV）憑證則可能需要數百甚至數千美元。

近年來一些組織開始提供免費的 SSL/TLS 憑證，其中最著名的是 Let's Encrypt。Let's Encrypt 是一個非營利組織，致力於提升網路的安全性。他們提供免費的憑證，並且提供自動化工具來簡化安裝和管理流程，這對於個人用戶和小型網站來說非常方便。