公開金鑰認證

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

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

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

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

## 憑證種類

### 自簽憑證

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

### 根憑證

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

### 中介憑證

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

### 授權憑證

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

### 終端實體憑證

其他不會用作簽發其他憑證的，都可稱為終端實體憑證，在實際的軟體中部署，以便建立加密通道時應用。

#### TLS 伺服器憑證

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

##### 萬用字元憑證

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

#### 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 都是維基媒體基金會旗下的網域），不同的網域可以一併使用同一張憑證，方便實作應用及管理

## 申領及使用

數位憑證一般由數位憑證認證機構簽發，簡單的程序如下：

### 申領

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

### 使用

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

### 儲存格式

電子憑證可以二進位或 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 / 瀏覽器論壇共同建立和維護相關的指導方針。

### 域名驗證（DV）

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

### 組織驗證（OV）

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

### 擴展驗證（EV）

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

## 弱點與防禦

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

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

### 根憑證弱點與爭議事件

#### 中國互聯網絡信息中心發行假憑證事件

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 頒發的憑證。

#### 沃通及 StartCom 遭封殺事件

2016 年，擁有奇虎 360 背景的中國最大 CA 憑證簽發機構沃通（WoSign）及其以色列子公司 StartCom，遭 Google 拒絕承認其憑證。
]]
沃通被揭發在短短 5 日內發行了幾百個相同序列號的証書，以及對憑證日期上造假。

## 參見

* 根憑證

## 參考文獻