數位簽章（Digital Signature）
數位簽章（Digital Signature）是密碼學中用來驗證資料真實性、完整性與簽署者身份的重要機制，就像「電子世界的手寫簽名 + 印章 + 防偽膠帶」。
數位簽章是用私鑰對資料雜湊值進行加密，接收方可用對應公鑰來驗證。
我們直接看維基百科
📘 小故事：RSA 的誕生
在 1977 年，麻省理工的三位科學家 Ron Rivest、Adi Shamir 和 Leonard Adleman 發明了 RSA 演算法，打破了「雙方必須先共享密鑰」的限制，標誌著非對稱加密的時代正式到來。
這個發現讓數位通訊世界得以大規模擴展，是密碼學史上的一大里程碑。
TLS（Transport Layer Security）
TLS（Transport Layer Security）的歷史其實是從 SSL（Secure Sockets Layer） 演變而來的，這段歷程不僅涉及技術的進化，也映照了互聯網安全威脅的不斷升級與應對。以下是一個結合「故事性」與「技術重點」的 TLS 發展簡史：
為何從 SSL 改名為 TLS？
當年 SSL 是 Netscape 的私有標準，IETF（網際網路工程任務小組）接手後改為開放標準，並重命名為 TLS。技術上雖與 SSL 3.0 相近，但：
- 命名上強調脫離私有規範
- 引入更強安全模型
- 更重視模組化與可擴充性
為什麼不應再使用 SSL 和 TLS 1.0/1.1？
SSL 2.0 / 3.0、TLS 1.0 / 1.1 都已被列為不安全協議，主要原因包括：
- 容易受到 POODLE、BEAST、Heartbleed 等漏洞攻擊
- 使用已不建議的雜湊演算法（如 MD5、SHA-1）
- 無法支援現代 AEAD 加密模式（例如 AES-GCM）
主流瀏覽器與網站皆已於 2020 年前後停止支援這些舊版本。
小故事：Heartbleed 大漏洞（2014）
TLS 的一大轉捩點是 2014 年爆發的 Heartbleed 漏洞（OpenSSL 實作的 TLS 擴充錯誤），攻擊者可以從記憶體中讀出機密資料（如私鑰）。這次事件促使大量機構更新 OpenSSL，並加速 TLS 1.2/1.3 的導入。
- 小結：TLS 的演進趨勢
- 安全性更高：淘汰老舊的加密與協商機制
- 性能更快：TLS 1.3 減少握手次數
- 隱私更強：支援 Forward Secrecy，避免過去通訊被破解
TLS Handshake 步驟
- Client Hello
- 瀏覽器送出支援的 TLS 版本、加密演算法清單、亂數（client random）等資訊
- Server Hello
- 伺服器送出選擇的加密參數、伺服器憑證（含公開金鑰）
- 憑證驗證
- 瀏覽器用「內建 CA 憑證」驗證伺服器憑證是否合法（CA 簽章驗證）
- 密鑰協商（如 ECDHE）
- 雙方協議出對稱加密的 session key（例如 AES 金鑰）
- Finished
- 雙方用 session key 加密資料並開始傳輸
TLS憑證是什麼？
TLS 憑證（即 X.509 憑證）是由 憑證授權單位（CA, Certificate Authority）簽發的，內容包括：
公開金鑰：網站的 RSA 或 ECC 公開金鑰
主體資訊：網站的域名、公司名稱等
簽發者（CA）資訊：發證的機構名稱（如 DigiCert、Let's Encrypt）
有效期限：憑證起始與過期日期
數位簽章：CA 對憑證本身做的簽章，證明其真實性
- TLS 憑證的作用
身份驗證：證明網站是合法的擁有者（不是釣魚網站）
對稱金鑰協商：用於安全地協議出 AES 等對稱加密用的 session key
數位簽章驗證：用來驗證憑證沒有被竄改
Certificate Authority（CA，憑證授權單位）
Certificate Authority（CA，憑證授權單位）是公開金鑰基礎建設（PKI）的核心角色，負責簽發、驗證、撤銷數位憑證，用來建立網路世界的信任鏈。
- CA 的核心職責
- 簽發憑證
- 接收來自網站或企業的 CSR（Certificate Signing Request）
- 驗證請求者的身份（依憑證類型：DV、OV、EV）
- 用自己的私鑰簽署該憑證，生成 X.509 格式
- 建立信任鏈
- CA 自身的根憑證（Root Certificate）被瀏覽器、作業系統預先信任
- 透過中繼憑證（Intermediate CA）建立階層式信任架構
- 維護撤銷列表
- 若憑證被盜或失效，CA 負責將其加入 CRL（Certificate Revocation List）或回應 OCSP 驗證請求
- 確保私鑰安全
- CA 的根私鑰是整個 PKI 信任鏈的核心，通常存放在 HSM（硬體安全模組）中並有嚴格的實體安全管控
CA 在憑證鏈中的角色
Root CA (最上層，自簽憑證)
│
├─ Intermediate CA (中繼憑證)
│ │
│ └─ End-Entity Certificate (網站/伺服器憑證)
- Root CA：由 OS/瀏覽器內建信任，通常離線保護
- Intermediate CA：負責實際簽發網站憑證
- End-Entity Certificate：使用者網站安裝的伺服器憑證
常見的 CA
- 商業 CA：DigiCert、Sectigo、GlobalSign、Entrust
- 免費 CA：Let’s Encrypt（自動化簽發 DV 憑證）
- 政府 / 企業內部 CA：用於內部 PKI 與 VPN
為什麼要信任 CA？
- 作業系統與瀏覽器內建了一份「可信 Root CA 名單」
- 當網站憑證是由這些 CA 簽署，瀏覽器就會認為該網站「可信」
- 整個機制依賴Root CA 私鑰不洩漏與 CA 不濫用權力
CA非常重要：臺灣首度引爆憑證信任危機（一）：中華電信憑證失效，連自家網站的憑證都要跟別人買
憑證頒發（Certificate Issuance）
- 網站產生金鑰對（Key Pair）
- 網站伺服器產生一組公開金鑰（Public Key）與私密金鑰（Private Key）。
- 私密金鑰永遠保留在伺服器中，不對外公開。
- 網站向 CA 提出憑證簽署請求（CSR）
- CSR（Certificate Signing Request）內容包含： 公開金鑰 網域名稱（CN） 組織資訊
- 提交給一個可信任的憑證機構（CA, Certificate Authority）。
- CA 驗證網站身分
- 依照憑證等級（如 DV、OV、EV）進行網域驗證或公司身份核實。
- 驗證成功後，用 CA 的私鑰對網站資訊與公開金鑰雜湊後簽章，生成 X.509 格式的憑證（即數位憑證）。
- 網站取得憑證
- 憑證中包含： 公開金鑰 網站資訊 憑證有效期間 發行 CA 資訊 數位簽章（由 CA 私鑰簽署）
憑證驗證（Certificate Verification）
當用戶端（例如瀏覽器）連到網站時：
- 伺服器送出憑證（或憑證鏈）
- 通常包括： 伺服器自己的憑證 中繼憑證（Intermediate CA） 根憑證（Root CA，通常由瀏覽器事先信任）
- 瀏覽器驗證憑證鏈
- 檢查每個憑證是否由上一層 CA 有效簽署。
- 最上層的根憑證（Root CA）是否在瀏覽器內建信任名單中。
- 檢查憑證有效性
- 是否過期？
- 網域名稱是否匹配？
- 有無被撤銷？（使用 CRL 或 OCSP 查詢）
- 驗證 CA 簽章
- 對憑證內容計算雜湊值。
- 使用上層 CA 的公開金鑰驗證該雜湊是否與簽章匹配。
✅ 若驗證成功：進入 TLS 握手、協議出對稱金鑰，完成安全通訊。
❌ 若失敗：瀏覽器會跳出警告「此網站的安全憑證不受信任」。
常見的憑證驗證錯誤
- 憑證過期：憑證有效期已過
- 憑證不被信任：根 CA 不在瀏覽器信任名單中
- 憑證與網域不匹配：憑證是給 abc.com，但卻用在 xyz.com
- 憑證已撤銷（revoked）：CA 發現被盜用、撤銷憑證
- 憑證鏈不完整或格式錯誤：缺少中繼憑證或憑證損壞
公開金鑰基礎建設
公開金鑰基礎建設（英語：Public Key Infrastructure，縮寫：PKI），又稱公開金鑰基礎架構、公鑰基礎建設、公鑰基礎設施、公開密碼匙基礎建設或公鑰基礎架構，是一組由硬體、軟體、參與者、管理政策與流程組成的基礎架構，其目的在於創造、管理、分配、使用、儲存以及復原數位憑證。
維基百科
PKCS 概覽表
為何 PKCS 重要？
- 📦 跨平台互通性：例如 OpenSSL、Java、Windows 都支持 PKCS 格式。
- 🧩 模組化整合：讓開發者可以依據標準整合金鑰、簽章與加密流程。
- 🔐 安全與一致性：避免各自實作導致安全漏洞，統一格式、流程、填充方式等。
- 小提示
- 現今應用中，PKCS #1、#5、#7、#10、#12 是最常見的。
- 雖然有些標準（如 #3）已過時，但仍常在歷史文件中見到。
- 很多 PKCS 被納入其他標準（例如 IETF 的 RFC 2315, 3447）。
X.509與私鑰如何組裝為PKCS#12
要將 X.509 憑證（通常是 .crt 或 .cer 格式）與私鑰（.key）打包成一個 PKCS#12 (.p12 或 .pfx) 檔案，可以使用 OpenSSL 工具完成。這個過程通常會把：
- 憑證（certificate）
- 私鑰（private key）
- 以及（可選）中繼憑證或 CA 憑證
整合成一個加密的 .p12 檔案，方便在 Windows、macOS、瀏覽器、Java Keystore 等環境匯入使用。
以下是操作方式：
🔧 指令範例（使用 OpenSSL）：
openssl pkcs12 -export \
-in your_cert.crt \
-inkey your_key.key \
-certfile intermediate_CA.crt \
-out output.p12 \
-name "My Certificate"
參數說明：
- -in 主憑證（X.509 格式）
- -inkey 對應的私鑰
- -certfile 中繼 CA 憑證（可選，若有鏈）
- -out 輸出的 .p12 檔案名稱
- -name 憑證別名，讓匯入時容易識別（例如 Java Keystore）
⚠️ 輸出時會要求你設定一組匯入密碼，這是保護 .p12 檔案的密碼，導入時會使用。
📁 常見組件：
- your_cert.crt：你申請回來的伺服器憑證（PEM 格式）
- your_key.key：私鑰檔案（與憑證匹配）
- intermediate_CA.crt：CA 提供的中繼憑證（有些環境需要）
🔐 檢查 .p12 是否正確：
openssl pkcs12 -info -in output.p12
若你使用 Windows，可以直接用 certmgr.msc 導入 .p12；若你用 Java，可用 keytool 導入 Java Keystore (.jks)。
