公開金鑰認證

公開金鑰認證（Public key certificate），又稱數位憑證（digital certificate）或身份憑證（identity certificate）。是用於公開金鑰基礎建設的電子檔案，用來證明公開金鑰擁有者的身份。此檔案包含了公鑰資訊、擁有者身份資訊（主體）、以及數字證書認證機構（發行者）對這份檔案的數位簽章，以保證這個檔案的整體內容正確無誤。擁有者憑著此檔案，可向電腦系統或其他使用者表明身分，從而對方獲得信任並授權存取或使用某些敏感的電腦服務。電腦系統或其他使用者可以透過一定的程式核實憑證上的內容，包括憑證有否過期、數位簽章是否有效，如果你信任簽發的機構，就可以信任憑證上的金鑰，憑公鑰加密與擁有者進行可靠的通訊。

簡而言之，認證機構用自己的私鑰對需要認證的人（或組織機構）的公鑰施加數字簽名並生成證書，即證書的本質就是對公鑰施加數字簽名。

數位憑證的其中一個最主要好處是在認證擁有者身分期間，擁有者的敏感個人資料（如出生日期、身分證號碼等）並不會傳輸至索取資料者的電腦系統上。透過這種資料交換模式，擁有者既可證實自己的身分，亦不用過度披露個人資料，對保障電腦服務存取雙方皆有好處。

人們透過信任數字證書認證機構的根證書、及其使用公開金鑰加密作數位簽章核發的公開金鑰認證，形成信任鏈架構，已在 TLS 實作並在全球資訊網的 HTTPS、在電子郵件的 SMTPS 和 STARTTLS 廣泛應用。業界現行的標準是國際電信聯盟電信標準化部門制定的 X.509，並由 IETF 發行的詳細述明。而在不少國家 / 地區，都已立法承認使用數位憑證所作的數位簽章擁有等同親筆簽名的法律效力（如歐洲聯盟、香港、臺灣、美國、加拿大）。

證書種類

1.1 自簽證書

在用於小範圍測試等目的的時候，使用者也可以自己生成數字證書，但沒有任何可信賴的人簽名，這種自簽名證書通常不會被廣泛信任，使用時可能會遇到電腦軟體的安全警告。

1.2 根證書

根證書獲得廣泛認可，通常已預先安裝在各種軟體（包括作業系統、瀏覽器、電郵軟體等），作為信任鏈的起點，來自於公認可靠的政府機關（如香港郵政、臺灣網路資訊中心）、證書頒發機構公司（如 DigiCert、Google）、非營利組織（如 Let's Encrypt）等，與各大軟體商透過嚴謹的核認程式才在不同的軟體廣泛部署。由於部署程式複雜費時，需要行政人員的授權及機構法人身份的核認，一張根證書有效期可能長達二十年以上。在某些企業，也可能會在內部電腦自行安裝企業自簽的根證書，以支援內部網的企業級軟體；但是這些證書可能未被廣泛認可，只在企業內部適用。

1.3 中介證書

認證機構的一個重要任務就是為客戶簽發證書，雖然廣泛認可的認證機構都已擁有根證書，相對應的私鑰可用以簽署其他證書，但因為金鑰管理和行政考慮，一般會先行簽發中介證書，才為客戶作數位簽署。中介證書的有效期會較根證書為短，並可能對不同類別的客戶有不同的中介證書作分工。

1.4 授權憑證

授權憑證又稱屬性憑證，本身沒有公鑰，必須依附在一張有效的數位憑證上才有意義，其用處是賦予相關擁有人簽發終端實體憑證的權力；某些情況下，如果只在短期內授予憑證機構簽發權力，便可以不改變（縮短）該機構本身持有的憑證的有效期。這種情況，類似於某人持有長達十年期的護照，而只透過簽發短期入境簽證，來個別賦予護照持有人額外權力。

1.5 終端實體證書

1.5.1 TLS 伺服器證書

伺服器通常以域名形式在網際網路上提供服務，伺服器證書上主體的通用名稱就會是相應的域名，相關機構名稱則寫在組織或單位一欄上。伺服器證書（包括公鑰）和私鑰會安裝於伺服器（例如 Apache），等待客戶端連線時協議加密細節。客戶端的軟體（如瀏覽器）會執行以確保安全，如果未能肯定加密通道是否安全（例如證書上的主體名稱不對應網站域名、伺服器使用了自簽證書、或加密演算法不夠強），可能會警告使用者。

1.5.1.1 萬用字元證書

如果伺服器證書上主體的通用名稱（或）一欄以萬用字元字首，則該證書可以用於旗下的所有子域名，特別適合較具規模、或設有多個子網站的機構一次過申領，套用於多個伺服器上；即使未來建立新的子域名，也可以套用。但萬用字元不可用於擴充套件認證證書上。

1.5.2 TLS 客戶端證書

有時候，某些 TLS 伺服器可能會在建立加密通道時，要求客戶端提供客戶端證書，以驗證身份及控制存取許可權。客戶端證書包含電子郵件地址或個人姓名，而不是主機名。但客戶端證書比較不常見，因為考慮到技術門檻及成本因素，通常都是由服務提供者驗證客戶身份，而不是依賴第三方認證機構。通常，需要使用到客戶端證書的服務都是內部網的企業級軟體，他們會設立自己的內部根證書，由企業的技術人員在企業內部的電腦安裝相關客戶端證書以便使用。在公開的網際網路，大多數網站都是使用登入密碼和 Cookie 來驗證使用者，而不是客戶端證書。

在臺灣，中華民國內政部憑證管理中心根據電子簽章法負責簽發自然人憑證，讓國民在網路使用各種政府服務。

客戶端證書在 RPC 系統中更常見，用於驗證連線裝置的許可授權。

內容欄位

一般遵從 X.509 格式規範的憑證，會有以下的內容，它們以欄位的方式表示：

版本：現行通用版本是 V3
序號：用以辨識每一張憑證，特別在撤消憑證的時候有用
主體：擁有此憑證的法人或自然人身份或機器，包括：
國家（C，Country）
州 / 省（S，State）
地域 / 城市（L，Location）
組織 / 單位（O，Organization）
通用名稱（CN，Common Name）：在 TLS 應用上，此欄位一般是網域
發行者：以數位簽章形式簽署此憑證的數字證書認證機構
有效期開始時間：此憑證的有效開始時間，在此前該憑證並未生效
有效期結束時間：此憑證的有效結束時間，在此後該憑證作廢
公開金鑰用途：指定憑證上公鑰的用途，例如數位簽章、伺服器驗證、使用者端驗證等
公開金鑰
公開金鑰指紋
數位簽章
：例如一個網站可能會有多個網域（www.wikipedia.org, zh.wikipedia.org, zh.m.wikipedia.org 都是維基百科）、一個組織可能會有多個網站（.wikipedia.org, .wikibooks.org, *.wikidata.org 都是維基媒體基金會旗下的網域），不同的網域可以一併使用同一張憑證，方便實作應用及管理

申領及使用

數字證書一般由數字證書認證機構簽發，簡單的程式如下：

3.1 申領

鮑伯在自己的機器上使用密碼學安全偽隨機數生成器產生一對足夠強的金鑰，鮑伯的私鑰不會向任何人傳送。
鮑伯把他的公鑰，連同主體訊息、使用目的等組成，傳送給認證機構伊凡。
伊凡（用另外一些渠道）核實鮑伯的身份。
如果伊凡信任這個請求，他便使用鮑伯的公鑰和主體訊息，加上憑證有效期、用途等限制條件，組成憑證的基本資料。
伊凡用自己的私鑰對鮑勃的公鑰加上數字簽名並生成證書。
伊凡把生成的憑證傳送給鮑伯（伊凡也可以透過證書透明度公佈他簽發了新的證書）。

3.2 使用

鮑伯可以隨便把憑證向外釋出。
鮑伯與愛麗絲事先可能互不認識，但鮑伯與愛麗絲都信任伊凡，愛麗絲使用認證機構伊凡的公鑰驗證數字簽名，如果驗證成功，便可以信任鮑勃的公鑰是真正屬於鮑伯的。
愛麗絲可以使用憑證上的鮑勃的公鑰加密明文，得到密文並傳送給鮑伯。
鮑伯可以可以用自己的私鑰把密文解密，得到明文。

3.3 儲存格式

電子證書可以二進位制或 Base64 形式儲存，常見的副檔名有 .cer、.crt、.der 和.pem。如果把證書和私鑰一起儲存，則可以使用 PKCS#12（.p12）格式。

DER 用於二進位制 DER 編碼的證書。
PEM 用於不同型別的 X.509v3 檔案，是以 “- BEGIN ...” 字首的 ASCII（Base64）資料。
CER 和 CRT 幾乎同義，證書可以被編碼為二進位制 DER 或 ASCII PEM。
PKCS7 檔案，也被稱為 P7B，通常用於 Java Keystores 和 Microsoft IIS（Windows）。它們是 ASCII 檔案，可以包含證書和 CA 證書。
PKCS12 檔案，也被稱為 PFX 檔案，通常用於在 Micrsoft IIS（Windows）中匯入和匯出證書鏈。

審核級別

法人團體申領數位憑證的時候，可以視乎其法人的地位及其實際需要申領不同級別的憑證，認證機構會作相應的審核，越高階別的通常都牽涉越嚴謹的行政程式，及需付出更高昂的費用。各大憑證機構和網頁瀏覽器軟體商透過 CA / 瀏覽器論壇共同建立和維護相關的指導方針。

4.1 域名驗證（DV）

這是最基本的審核級別，如果申領代表可以證明他擁有管理某域名的權力，認證機構就可以發放域名驗證（DV）證書。認證機構通常使用自動機制（例如或透過電郵確認）審核域名擁有權，所以成本也較低。

4.2 組織驗證（OV）

如果申領代表可以證明他擁有管理某域名的權力，而且相關組織是實際存在的法人，認證機構可以發放組織驗證（OV）證書。審核程式通常需要經過人手處理。

4.3 擴充套件驗證（EV）

這是最嚴格的審核級別，審核過程可能牽涉專業法律人員的調查及獨立審計人員的確認，成本也自然更高；成功獲得擴充套件驗證證書的網站，現代瀏覽器通常會在位址列以綠色表示相關機構的法人名稱及所屬國家程式碼。擴充套件驗證證書的主體名稱或主體別名上不可以有萬用字元。

弱點與防禦

公開金鑰基礎建設的弱點，在於人們必須循數位憑證上的信任鏈找到根證書，並信任核發根證書的數字證書認證機構，一旦憑證機構被駭客入侵，駭客可以在人們不知情下簽發了偽冒他人身份的證書，以中間人攻擊進行欺詐。業界已研發不同的防禦方法，例如憑證機構可以透過證書透明度公佈新簽發的電子憑證，讓大眾檢查手上收到的電子憑證是否可能未被正式授權（中間人攻擊不會「公佈」他偽冒了別人簽發了欺詐憑證），網站管理員也可以定期檢查是否有不明機構發出了未被授權的憑證。另一方面，HTTPS 網站可以使用 HPKP 指明其固定的公鑰，讓中間人的欺詐憑證無法使用。另外，而 OCSP 和 OCSP 裝訂也在發展中，讓使用者軟體可以透過第三方檢查憑證是否有効。

在公鑰基礎設施以外，信任網路則採用去中心化的概念，取代了依賴數字證書認證機構的公鑰基礎設施，因為每一張電子證書在信任鏈中最終只由一個根證書授權信任，信任網路的公鑰則可以累積多個使用者的信任。

5.1 根證書弱點與爭議事件

5.1.1 中國網際網路絡資訊中心發行假憑證事件

2009 年，中國網際網路絡資訊中心（CNNIC）的一名員工向 Mozilla 申請要求將 CNNIC 加入 Mozilla 的 根證書列表，並且得到了批准。後來微軟也把

CNNIC 加到了 Windows 的根證書列表裡。

2015 年，因 CNNIC 發行的一箇中級 CA 被發現發行了 Google 域名的假證書，許多使用者選擇不信任 CNNIC 頒發的數字證書。並引起對 CNNIC 濫用證書頒發權力的擔憂。

2015 年 4 月 2 日，Google 宣佈不再承認 CNNIC 所頒發的電子證書。4 月 4 日，繼 Google 之後，Mozilla 也宣佈不再承認 CNNIC 所頒發的電子證書。2016 年 8 月，CNNIC 官方網站已放棄自行發行的根證書，改用由 DigiCert 頒發的證書。

5.1.2 沃通及 StartCom 遭封殺事件

2016 年，擁有奇虎 360 背景的中國最大 CA 證書籤發機構沃通（WoSign）及其以色列子公司 StartCom，遭谷歌拒絕承認其憑證。

沃通被揭發在短短 5 日內發行了幾百個相同序列號的証書，以及對證書日期上造假。