OCSP 線上證書狀態協議：它是甚麼，如何保障簽署安全

線上證書狀態協議（Online Certificate Status Protocol，OCSP）是一種互聯網協議，讓客戶端向證書簽發機構查詢某份數碼證書當前是否仍然有效或已被撤銷，並收到一份經過簽署的實時回應——無需下載整份撤銷列表。實際應用中，當你開啟一份已簽署的 PDF 或瀏覽 TLS 加密網站時，OCSP 就是決定該簽署所依託的證書此刻能否被信任的檢查項目之一。本指南介紹 OCSP 的運作原理、與證書撤銷列表的對比、對數碼簽署和電子簽署的意義，以及它在哪些局限下需要配套的補充機制。

甚麼是線上證書狀態協議？

OCSP 由 RFC 2560 正式確立（後經 RFC 6960 更新），作為證書撤銷列表（CRL）更輕量、更快捷的替代方案。客戶端不必下載一份可能相當龐大、包含 CA 簽發過的所有已撤銷證書的列表，OCSP 允許客戶端只問一個針對性問題：「你們 CA 簽發的序號為 X 的證書還有效嗎？」CA 的回應伺服器——即 OCSP 回應伺服器——返回一份簽署回應，表明「良好」「已撤銷」或「未知」。

可能的回應狀態有三種：

良好（Good）。 證書未被撤銷。這並不保證證書在各方面都有效，只代表 CA 尚未撤銷它。
已撤銷（Revoked）。 CA 在證書到期前將其撤銷，通常是因為私鑰外洩、CA 出錯，或證書持有人的狀態有所變化。
未知（Unknown）。 回應伺服器沒有該證書的資料，常見於回應伺服器不涵蓋簽發該證書的 CA。

由於回應由 CA 或其授權的回應伺服器加密簽署，客戶端可以驗證其真確性。若想更全面了解簽發與管理這些證書的機構，我們的證書頒發機構列表說明了 CA 在瀏覽器和電子簽署信任鏈中扮演的角色。

OCSP 運作原理：證書驗證流程

OCSP 交換是 HTTP（或 HTTPS）上簡單的請求-回應過程，流程通常如下：

客戶端收到一份證書。 可能是瀏覽器連線中的 TLS 伺服器證書，也可能是已簽署 PDF 中嵌入的簽署證書。
客戶端提取證書的序號和 OCSP 回應伺服器地址。 該地址發佈在證書自身的一個欄位中，即授權資訊存取（AIA）擴展。
客戶端發送 OCSP 請求。 請求包含證書的序號和簽發者名稱，為提高效率通常經過雜湊處理。
OCSP 回應伺服器檢查數據庫，返回帶有效狀態和更新時間戳的簽署回應。
客戶端驗證回應簽署，確認其對應正確的證書，並核實回應足夠新、可以信任。

對於瀏覽器 TLS 連線，這一往返只需毫秒級時間，但同樣的機制也支撐着文件工作流程中的簽署驗證。如果你想了解產生這些供 OCSP 檢查的證書的完整簽署流程，我們的數碼簽署在業務工作流程中的運作方式指南從金鑰產生到驗證全程講解。

OCSP 與證書撤銷列表的對比

CRL 和 OCSP 解決的是同一問題——告知信賴方某份證書不應再被信任——但方式不同。兩者沒有絕對的優劣之分，選擇取決於數據量、對延遲的容忍度以及離線需求。

維度	CRL	OCSP
機制	CA 發佈已撤銷證書列表	客戶端逐張證書向回應伺服器查詢
數據量	可能很大（上千條記錄）	小，單證書回應
更新頻率	按計劃更新（數小時或數天）	近乎實時
網絡開銷	下載一次後快取	每次驗證一次請求
離線使用	下載後即可用	需要連線（除非使用 stapling）
最適用於	低頻、離線、批量檢查	實時、按連線檢查

在現代網頁與文件簽署基礎設施中，OCSP 是互動式檢查的預設選擇，而 CRL 在回應伺服器無法連接時充當後備。許多客戶端兩者皆備，哪個先到就用哪個。

OCSP 對數碼簽署與電子簽署的意義

當你用數碼證書簽署文件時，簽署的法律與技術價值取決於證書在簽署時是否有效——以及日後有人驗證該文件時證書是否仍然有效。OCSP 正是回答這兩個問題的機制。

設想一張簽發給某企業的簽署證書。如果該企業的私鑰外洩，CA 會撤銷證書。沒有 OCSP，任何在撤銷之後驗證以該證書簽署的文件的人，都無法得知證書已不可信。有了 OCSP，驗證者能即時得到經過簽署的答覆。

這在受監管的簽署場景中尤為重要——eIDAS 框架下的合資格電子簽署、印度的數碼簽署證書等——簽署證書的可信是法律可執行性的前提。我們的 DSC 代表甚麼指南說明了數碼簽署證書如何融入這些工作流程；而針對這一切背後的安全問題——電子簽署安全嗎——OCSP 是結構性答案之一：它提供撤銷檢查，讓信任鏈在簽發之後保持可信。

OCSP 的局限與需留意之處

OCSP 很有效，但不是萬靈丹。有四個局限值得關注：

延遲與可用性。 如果 OCSP 回應伺服器緩慢或無法連接，客戶端必須決定是「開放失敗」（接受證書）還是「關閉失敗」（拒絕證書）。瀏覽器歷來採用「開放失敗」以避免破壞網站運作，這會削弱保護。
私隱。 普通的 OCSP 請求會直接發給 CA，因此 CA 能知道用戶正在檢查哪個網站或證書。OCSP stapling——伺服器在 TLS 握手時附帶預先取得的 OCSP 回應——透過省去客戶端到 CA 的往返來緩解這個問題。
時效窗口。 快取的 OCSP 回應只在有限時間內有效。如果證書在快取更新之間被撤銷，依賴過期回應的客戶端可能接受一份已撤銷的證書。
「未知」回應。 如果回應伺服器返回「未知」，客戶端得不到確切答案，只能退回 CRL 或直接拒絕證書。

對構建簽署工作流程的團隊而言，這些局限意味着 OCSP 應是縱深防禦中的一層，而非唯一檢查。把它與防篡改偵測——參見我們的如何識別偽造或篡改的數碼簽署指南——以及 AES-256 加密標準指南中涵蓋的強加密實踐配合使用，你就能獲得更全面的安全態勢。

證書狀態檢查清單

在評估某個簽署平台或文件工作流程是否正確處理證書撤銷時，用這份清單確認涵蓋範圍：

[ ] 平台將簽署證書的證書鏈驗證回受信任的根 CA。
[ ] 撤銷透過 OCSP 檢查，回應伺服器無法連接時以 CRL 作為後備。
[ ] 簽署平台在簽署時把 OCSP 回應（或帶時間戳的撤銷狀態）記錄進審計軌跡。
[ ] 長期驗證（LTV）嵌入驗證數據，使簽署在多年後仍可驗證，即使 CA 或回應伺服器已離線。
[ ] OCSP 回應檢查時效——不超過平台設定的最大時限。
[ ] OCSP 檢查失敗觸發既定政策：高價值交易採取「關閉失敗」，低風險工作流程採取「開放失敗」並記錄日誌。

能逐項滿足的平台，能給你證據證明簽署在簽署時有效、事後仍可驗證——這正是審計師和法院所看重的。

Nota Sign 讓每份簽署都帶有證書級信任

證書撤銷檢查不是抽象問題——它決定了簽署能否被強制執行，還是無法自證。Nota Sign，法大大旗下的全球電子簽名平台，把這種信任建進簽署管道：每份簽署都依託可驗證的證書鏈，審計記錄擷取信賴方需要的證據，簽署在 100 多個國家和地區產生法律效力。

在 IDC 中國電子簽名軟件市場歷屆年度報告中排名第一的 Nota Sign，把亞太合規做成了出廠配置，而不是留給客戶自行拼裝：香港 iAM Smart 和新加坡 Singpass 身份核驗、SES 到 AES 到 QES 的簽署等級、對接數據駐留預期的區域數據中心。定價是另一個驚喜——不按席位收費，同樣的證書級簽署嚴謹度小團隊用得起，中端市場和大型企業客戶可選擇度身訂造方案。如果你需要經受得住撤銷審查的簽署，聯絡 Nota Sign，看看在你所在司法管轄區的落地流程。