憑證是什麼？
SSL/TLS 憑證是一種數位證書，用於驗證網站身份，並保護使用者與伺服器之間的通訊安全。它通常由 CA 頒發，負責確認網站的合法性與可被信任程度。
使用憑證的好處
- 瀏覽器不會顯示不安全網站
- 對網頁的SEO有幫助
- 使用者與伺服器間的通訊不會以HTTP明文傳送
不裝憑證的影響
現在所有主流瀏覽器（Chrome、Safari、Edge）只要遇到 HTTP 網站，都會在網址列強制顯示紅色「不安全」警示，嚴重打擊訪客信任度！
憑證中記載了什麼？
| 欄位 | 說明 |
|---|---|
| Version（版本） | 憑證使用的 X.509 版本 |
| Serial Number（序號） | 每張憑證唯一的編號，用於識別與撤銷 |
| Signature Algorithm（簽名演算法） | CA 使用的簽名演算法，例如 sha256WithRSAEncryption |
| Issuer（簽發者） | 簽發憑證的 CA |
| Validity（有效期間） | 憑證的有效開始與到期時間 |
| Subject（主體） | 憑證所代表的實體，例如網站、公司名稱、機構等 |
| Subject Public Key Info（主體的公開金鑰資訊） | 包含演算法（如 RSA、ECDSA）和對應的公鑰 |
| Extensions（延伸欄位） | X.509 V3 中新增的欄位 |
| Signature（CA 的簽名） | 對以上資料的數位簽章，確保憑證沒被竄改 |
憑證裡面公開記載的是 公鑰（Public Key），任何人都可以查看；而用來解密的 私鑰（Private Key） 必須嚴格保存在伺服器端，絕對不能外洩或發布出來！
CA跟瀏覽器是如何保證憑證的有效性？
憑證內容的有效性如何保證？
證書內容的有效性主要以hash跟非對稱加密完成(簽名)：
因為hash function在修改文件後會完全不同，可以用來檢查證書有沒有被竄改。private key只會由持有人控制，所以可以用來做身分驗證。
-
如何製作簽名
- 對憑證內文做Hash
- 將Hash後的摘要用Issuer的private key 加密即是簽名
- 將簽名附在憑證後面
-
如何驗證憑證的簽名
- 對憑證用跟簽名時相同的hash function對內文生成摘要A
- 用Issuer 的public key對簽名解密產生摘要B
- 比對摘要A, B是否吻合
| Hash | private key |
|---|---|
| 保證文件的正確性 | 保證Issuer的身份與不可逃避性 |
簽名的意義就是幫這個certificate背書，確認它的管理人不會將背後的private key外洩，使得其他人會偽造他的身份。
我們要如何信任 Issuer 簽發的憑證？
要信任某個 Issuer（Ex: Let’s Encrypt, DigiCert, GlobalSign）所簽發的憑證，並不是因為我們個人認識這些 CA，而是因為整個瀏覽器與作業系統建立了一個「信任鏈（Chain of Trust）」與「憑證基礎建設（Public Key Infrastructure, PKI）」來幫我們建立這種信任關係。
因為瀏覽器廠商或是作業系統的審查，我們對CA做出的假設前提有以下幾點：
- CA會保管好自己的private key
- CA會遵守規範審查CSR提出人的身份
- 當private key或憑證出現漏洞時，它會撤銷簽發出去的憑證
而這整個PKI可以用以下幾點說明：
1. 根憑證（Root Certificate）被預先信任
每個OS或browaer都內建了一組預先信任的根憑證（Trusted Root Certificates）。這些憑證是經過驗證的CA持有的，並由瀏覽器/作業系統廠商預設在系統中。 這些根憑證的private key 都被嚴格保密、不直接簽發最終使用者的憑證，而是用來簽發「中介憑證（Intermediate Certificate）」。
2. 中介憑證（Intermediate Certificate）建立信任鏈
為了安全性考量，root certificate不會直接用來簽署網站憑證，而是先用private key簽出中介憑證，然後中介憑證再去簽發網站的憑證(leaf)。
因此，網站所持有的憑證會附上一串Certificate Chain來證明自己的簽名是來自於被信任的root CA。
舉例來說:
最上層的ISRG Root X1就是Let’s Encrypt的其中一個root certificate
3. 驗證過程中使用public key反推簽名
瀏覽器在連線網站時會取得伺服器傳來的憑證鏈，然後一層層檢查：
-
使用上層的公鑰驗證下層的簽名
-
檢查每張憑證的有效性（是否過期、是否被撤銷？）
-
最後確認整條鏈是否可連到系統預先信任的root certificate
只要這個驗證流程通過，瀏覽器就會認定網站可信。
4. 憑證間可能會互相簽名
新CA在剛開始時，它的root還沒被所有瀏覽器或OS信任。若等所有客戶端更新信任列表可能要很多年。因此，新 CA會請老CA為他的中間憑證交互簽名，新 CA 發出的憑證就能透過這條交互簽名建立的信任鏈，間接被舊系統信任。
舉個例子：Let’s Encrypt 剛推出時，他們的 Root ISRG Root X1還沒被所有OS信任。他們找了已被信任的CA DST Root CA X3來交叉簽名他們的中介憑證。客戶端如果不認識 ISRG，就走 DST 的信任鏈直到找到系統中儲存的root certificate
5. CA如何吊銷已存在的憑證
a. CRL（Certificate Revocation List）
- 一份由 CA 定期發布的清單，列出所有已撤銷的憑證序號。
- 用戶端下載清單，比對憑證序號是否在其中。
- 缺點：隨時間清單越來越大，更新不即時。
b. OCSP（Online Certificate Status Protocol）
- 用戶端即時向 CA 的 OCSP 伺服器查詢憑證狀態。
- 僅查詢目標憑證，比 CRL 更有效率。
- 缺點：需要額外 HTTP 請求，伺服器掛掉可能影響使用體驗。
c. OCSP Stapling
- 為了改善 OCSP 查詢效能與隱私。
- 由伺服器主動查詢 OCSP 結果並快取，TLS 握手時一併送給用戶端。
- 優點：快、減少客戶端流量、不會洩漏用戶造訪網站的行為。
如何取得憑證
1. 自己簽一個（OpenSSL）
a. 生成一個private key作為root CA
openssl req -x509 -nodes -days 3650 -newkey rsa:4096 \
-keyout rootprivate.key \
-out root.pem這個指令會生成一個x509的憑證(CSR):
- 4096 bits 的 RSA private key (
rootprivate.key) - 一張有效期限為3650天的憑證 (
root.pem) - 過程中會詢問:
C: 國家ST: 州別或省份L: 城市O: 組織名稱OU: 組織分部CN: 域名或被頒發實體名稱(最重要)
b. 用rootCA簽出
1. 設定簽發出的ext檔
[ v3_ca ]
authorityKeyIdentifier=keyid, issuer
basicConstraints=CA:FALSE
keyUsage=digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName=@alt_names
[alt_names]
DNS.1=www.example.com
DNS.2=example.comserver1.extbasicConstraints=CA:FALSE: 描述接下來簽發的憑證都不會是intermediate certificatesubjectAltName: 描述該網站的替代名稱
2. 生成伺服器的private key
openssl genrsa -out server1.key 20483. 建立CSR
openssl req -new -key server1.key -out server1.csr並完成憑證的資料填寫
4. 用root private key簽名這個CSR
openssl x509 -req -in server1.csr -CA root.pem -CAkey rootprivate.key \
-CAcreateserial -out server1.crt -days 365 -sha256 -extfile server1.ext接下來都可以重複這個步驟直到不斷簽發出以這個root作為信任依據的certificate，直到root到期
c. 加入到 Nginx 的 config 檔
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /path/to/server1.crt;
ssl_certificate_key /path/to/server1.key;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
}nginx.confsudo nginx -t
sudo systemctl reload nginxd. 加入到系統或瀏覽器信任的root certificate中
不同系統或瀏覽器會有不同作法，例如：
- Linux：將
root.pem複製到/usr/local/share/ca-certificates/，並執行sudo update-ca-certificates - macOS：透過「鑰匙圈存取（Keychain Access）」將憑證加入「系統」鑰匙圈，並設定為「永遠信任」
- Windows：使用
certmgr.msc將憑證匯入「受信任的根憑證授權單位」 - 瀏覽器（如 Firefox）：部分瀏覽器維護自己獨立的憑證存放區，需要另外在瀏覽器設定中匯入
2. 使用Certbot向Let’s Encrypt取得憑證
憑證驗證方式與 ACME 限制
TLS 憑證的常見驗證類型包括：
DV：Domain Validation（網域驗證）OV：Organization Validation（組織驗證）EV：Extended Validation（擴充驗證）
Let’s Encrypt 只支援 DV，這與它用的ACME 有關。
ACME 是什麼？
ACME（Automatic Certificate Management Environment）是一種自動化協定，由 Let’s Encrypt 推動，用來簡化憑證的申請、驗證與續期流程:
- 完全自動化
- 無需人工審核
- 僅驗證「是否控制該網域」
因此 ACME 無法處理需要人工審核與法律文件驗證的 OV / EV 憑證。
DV（Domain Validation，網域驗證）
驗證內容：確認申請者對網域有控制權。
常見挑戰方式(ACME)：
HTTP-01：在指定網址放置驗證檔案DNS-01：新增特定的 DNS TXT 紀錄TLS-ALPN-01：透過 TLS 擴充協定驗證
憑證內容：
- 只包含網域名稱
- 無組織名稱、地址等資訊
OV / EV（組織驗證與擴充驗證）
這兩種驗證會額外確認申請者的組織身分：
- OV：需提供合法的公司資料，由 CA 進行審核
- EV：驗證更嚴格，包含法人、實體存在與法律文件審查
這些流程都需要人力與官方資料驗證，因此無法透過 ACME 協定自動完成。
安裝Certbot
sudo apt update
sudo apt install certbot python3-certbot-nginx使用 Certbot 申請與安裝憑證
sudo certbot --nginxCertbot 會自動偵測伺服器設定，並引導你選擇要啟用 HTTPS 的網域，接著自動完成憑證的申請與簽發。
設定自動續期（Let’s Encrypt 憑證有效期只有 90 天）
Certbot 安裝時會自動加上定期任務（cron job）或 systemd timer。
手動測試是否能自動續期：
sudo certbot renew --dry-run檔案位置
依照上面的 Nginx 設定步驟 就可以把憑證加入到 Nginx 的設定中。
- 憑證：
/etc/letsencrypt/live/<your-domain>/fullchain.pem - private key:
/etc/letsencrypt/live/<your-domain>/privkey.pem - crt.sh（檢查憑證）
Let’s Encrypt 的免費憑證效期只有 90 天。使用 Certbot 安裝完成後，建議透過命令 certbot renew --dry-run 測試自動續期，確保 Cron job 正常運作，才不會因為憑證過期導致網站斷線
小結
- 憑證的核心是透過雜湊 + 非對稱加密達成防竄改與身份驗證。
- 我們能信任陌生 CA 簽發的憑證，是因為作業系統與瀏覽器內建的**信任鏈（Root → Intermediate → Leaf）**機制。
- DV 憑證可透過 ACME 協定（如 Let’s Encrypt / Certbot）全自動簽發；OV / EV 則需要人工審核，無法自動化。
- 正式環境建議使用 Let’s Encrypt 等受信任 CA 簽發的憑證；自簽憑證（OpenSSL）僅適合內部測試或封閉網路環境使用。