數字證書及CA詳解

1. 證書

"證書 -- 爲公鑰加上數字簽名"

要開車得先考駕照．駕照上面記有本人的照片、姓名、出生日期等個人信息．以及有效期、準駕車輛的類型等信息，並由公安局在上面蓋章。我們只要看到駕照，就可以知道公安局認定此人具有駕駛車輛的資格。

公鑰證書（Public-Key Certificate，PKC)其實和駕照很相似，裏面記有姓名、組織、郵箱地址等個人信息，以及屬於此人的公鑰，並由認證機構（Certification Authority、Certifying Authority, CA）施加數字簽名。只要看到公鑰證書，我們就可以知道認證機構認定該公鑰的確屬於此人。公鑰證書也簡稱爲證書（certificate）。

可能很多人都沒聽說過認證機構，認證機構就是能夠認定 “公鑰確實屬於此人"，並能夠生成數字簽名的個人或者組織。認證機構中有國際性組織和政府所設立的組織，也有通過提供認證服務來盈利的一般企業，此外個人也可以成立認證機構。

1.1 證書的應用場景

下面我們來通過證書的代表性應用場景來理解證書的作用。

下圖展示了Alice向Bob發送密文的場景，在生成密文時所使用的Bob的公鑰是通過認證機構獲取的。

認證機構必須是可信的，對於“可信的第三方”，下圖中會使用Trent這個名字，這個詞是從trust（信任）一詞演變而來的。

下面讓我們對照着上圖來看一看這些步驟具體都做了些什麼。

1. Bob生成密鑰對

   要使用公鑰密碼進行通信，首先需要生成密鑰對。Bob生成了一對公鑰和私鑰，並將私鑰自行妥善保管。在這裏，密鑰對是由Bob自己生成的，也可以由認證機構代爲生成。

2. Bob在認證機構Trent註冊自己的公鑰

   • 在這裏Bob則將公鑰發送給了認證機構Trent，這是因爲Bob需要請認證機構Trent對他的公鑰加上數字簽名（也就是生成證書）。

   • Trent收到Bob的公鑰後，會確認所收到的公鑰是否爲Bob本人所有（參見專欄：身份確認和認證業務準則）

     專欄：身份確認和認證業務準則

     認證機構確認"本人"身份的方法和認證機構的認證業務準則（CertificatePractice Statement, CPS，的內容有關。如果認證機構提供的是測試用的服務，那麼可能完全不會進行任何身份確認。如果是政府部門運營的認證機構，可能就需要根據法律規定來進行身份確認。如果是企業面向內部設立的認證機構，那就可能會給部門負責人打電話直接確認。

     例如，VeriSign的認證業務準則中將身份確認分爲Class1 ~ 3共三個等級

     • Class1：通過向郵箱發送件來確認本人身份
     • Class2：通過第三方數據庫來確認本人身份
     • Class3：通過當面認證和身份證明來確認本人身份

     等級越高，身份確認越嚴格。

3. 認證機構Trent用自己的私鑰對Bob的公鑰施加數字簽名並生成證書

   Trent對Bob的公鑰加上數字簽名。爲了生成數字簽名，需要Trent自身的私鑰，因此Trent需要事先生成好密鑰對。

4. Alice得到帶有認證機構Trent的數字簽名的Bob的公鑰（證書）

   現在Alice需要向Bob發送密文，因此她從Trent處獲取證書。證書中包含了Bob的公鑰。

5. Alice使用認證機構Trent的公鑰驗證數字簽名，確認Bob的公鑰的合法性

   Alice使用認證機構Trent的公鑰對證書中的數字簽名進行驗證。如果驗證成功，就相當於確認了證書中所包含的公鑰的確是屬於Bob的。到這裏，Alice就得到了合法的Bob的公鑰。

6. Alice用Bob的公鑰加密消息併發送給Bob

   Alice用Bob的公鑰加密要發送的消息，並將消息發送給Bob。

7. Bob用自己的私鑰解密密文得到Alice的消息

   Bob收到Alice發送的密文，然後用自己的私鑰解密，這樣就能夠看到Alice的消息了。

上面就是利用認證機構Trent進行公鑰密碼通信的流程。其中1、2、3這幾個步驟僅在註冊新公鑰時纔會進行，並不是每次通信都需要。此外，步驟 4 僅在Alice第一次用公鑰密碼向Bob發送消息時才需要進行，只要Alice將Bob的公鑰保存在電腦中，在以後的通信中就可以直接使用了。

1.2 證書標準規範X.509

證書是由認證機構頒發的，使用者需要對證書進行驗證，因此如果證書的格式千奇百怪那就不方便了。於是，人們制定了證書的標準規範，其中使用最廣泛的是由ITU（International TelecommumcationUnion，國際電信聯盟）和ISO（IntemationalOrganizationforStandardization, 國際標準化組織）制定的X.509規範。很多應用程序都支持x.509並將其作爲證書生成和交換的標準規範。

X.509是一種非常通用的證書格式。所有的證書都符合ITU-T X.509國際標準，因此(理論上)爲一種應用創建的證書可以用於任何其他符合X.509標準的應用。X.509證書的結構是用ASN1(Abstract Syntax Notation One)進行描述數據結構，並使用ASN.1語法進行編碼。

在一份證書中，必須證明公鑰及其所有者的姓名是一致的。對X.509證書來說，認證者總是CA或由CA指定的人，一份X.509證書是一些標準字段的集合，這些字段包含有關用戶或設備及其相應公鑰的信息。X.509標準定義了證書中應該包含哪些信息，並描述了這些信息是如何編碼的(即數據格式)

一般來說，一個數字證書內容可能包括基本數據（版本、序列號) 、所簽名對象信息（ 簽名算法類型、簽發者信息、有效期、被簽發人、簽發的公開密鑰）、CA的數字簽名，等等。

1.2.1 證書規範

前使用最廣泛的標準爲ITU和ISO聯合制定的X.509的 v3版本規範 (RFC5280）, 其中定義瞭如下證書信息域：

• 版本號(Version Number）：規範的版本號，目前爲版本3，值爲0x2；

• 序列號（Serial Number）：由CA維護的爲它所發的每個證書分配的一的列號，用來追蹤和撤銷證書。只要擁有簽發者信息和序列號，就可以唯一標識一個證書，最大不能過20個字節；

• 簽名算法（Signature Algorithm）：數字簽名所採用的算法，如：

  • sha256-with-RSA-Encryption
  • ccdsa-with-SHA2S6；

• 頒發者（Issuer）：發證書單位的標識信息，如 ” C=CN，ST=Beijing, L=Beijing, O=org.example.com，CN=ca.org。example.com ”；

• 有效期(Validity): 證書的有效期很，包括起止時間。

• 主體(Subject) : 證書擁有者的標識信息（Distinguished Name），如：" C=CN，ST=Beijing, L=Beijing, CN=person.org.example.com”；

• 主體的公鑰信息(SubJect Public Key Info）：所保護的公鑰相關的信息：

  • 公鑰算法 (Public Key Algorithm）公鑰採用的算法；
  • 主體公鑰（Subject Unique Identifier）：公鑰的內容。

• 頒發者唯一號（Issuer Unique Identifier）：代表頒發者的唯一信息，僅2、3版本支持，可選；

• 主體唯一號（Subject Unique Identifier）：代表擁有證書實體的唯一信息，僅2，3版本支持，可選：

• 擴展（Extensions，可選）: 可選的一些擴展。中可能包括：

  • Subject Key Identifier：實體的祕鑰標識符，區分實體的多對祕鑰；
  • Basic Constraints：一指明是否屬於CA;
  • Authority Key Identifier：證書頒發者的公鑰標識符；
  • CRL Distribution Points: 撤銷文件的頒發地址；
  • Key Usage：證書的用途或功能信息。

此外，證書的頒發者還需要對證書內容利用自己的私鑰添加簽名， 以防止別人對證書的內容進行篡改。

1.2.2 證書格式

X.509規範中一般推薦使用PEM(Privacy Enhanced Mail）格式來存儲證書相關的文件。證書文件的文件名後綴一般爲 .crt 或 .cer 。對應私鑰文件的文件名後綴一般爲 .key。證書請求文件的文件名後綴爲 .csr 。有時候也統一用pem作爲文件名後綴。

PEM格式採用文本方式進行存儲。一般包括首尾標記和內容塊，內容塊採用Base64進行編碼。

編碼格式總結:

• X.509 DER(Distinguished Encoding Rules)編碼，後綴爲：.der .cer .crt
• X.509 BASE64編碼(PEM格式)，後綴爲：.pem .cer .crt

例如，一個PEM格式（base64編碼）的示例證書文件內容如下所示：

-----BEGIN CERTIFICATE-----
MIIDyjCCArKgAwIBAgIQdZfkKrISoINLporOrZLXPTANBgkqhkiG9w0BAQsFADBn
MSswKQYDVQQLDCJDcmVhdGVkIGJ5IGh0dHA6Ly93d3cuZmlkZGxlcjIuY29tMRUw
EwYDVQQKDAxET19OT1RfVFJVU1QxITAfBgNVBAMMGERPX05PVF9UUlVTVF9GaWRk
bGVyUm9vdDAeFw0xNzA0MTExNjQ4MzhaFw0yMzA0MTExNjQ4MzhaMFoxKzApBgNV
BAsMIkNyZWF0ZWQgYnkgaHR0cDovL3d3dy5maWRkbGVyMi5jb20xFTATBgNVBAoM
DERPX05PVF9UUlVTVDEUMBIGA1UEAwwLKi5iYWlkdS5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDX0AM198jxwRoKgwWsd9oj5vI0and9v9SB9Chl
gZEu6G9ZA0C7BucsBzJ2bl0Mf6qq0Iee1DfeydfEKyTmBKTafgb2DoQE3OHZjy0B
QTJrsOdf5s636W5gJp4f7CUYYA/3e1nxr/+AuG44Idlsi17TWodVKjsQhjzH+bK6
8ukQZyel1SgBeQOivzxXe0rhXzrocoeKZFmUxLkUpm+/mX1syDTdaCmQ6LT4KYYi
soKe4f+r2tLbUzPKxtk2F1v3ZLOjiRdzCOA27e5n88zdAFrCmMB4teG/azCSAH3g
Yb6vaAGaOnKyDLGunW51sSesWBpHceJnMfrhwxCjiv707JZtAgMBAAGjfzB9MA4G
A1UdDwEB/wQEAwIEsDATBgNVHSUEDDAKBggrBgEFBQcDATAWBgNVHREEDzANggsq
LmJhaWR1LmNvbTAfBgNVHSMEGDAWgBQ9UIffUQSuwWGOm+o74JffZJNadjAdBgNV
HQ4EFgQUQh8IksZqcMVmKrIibTHLbAgLRGgwDQYJKoZIhvcNAQELBQADggEBAC5Y
JndwXpm0W+9SUlQhAUSE9LZh+DzcSmlCWtBk+SKBwmAegbfNSf6CgCh0VY6iIhbn
GlszqgAOAqVMxAEDlR/YJTOlAUXFw8KICsWdvE01xtHqhk1tCK154Otci60Wu+tz
1t8999GPbJskecbRDGRDSA/gQGZJuL0rnmIuz3macSVn6tH7NwdoNeN68Uj3Qyt5
orYv1IFm8t55224ga8ac1y90hK4R5HcvN71aIjMKrikgynK0E+g45QypHRIe/z0S
/1W/6rqTgfN6OWc0c15hPeJbTtkntB5Fqd0sfsnKkW6jPsKQ+z/+vZ5XqzdlFupQ
29F14ei8ZHl9aLIHP5s=
-----END CERTIFICATE-----

使用openssl 工具命令:openssl x509 -in ca-cert.pem -inform pem -noout -text

證書中的解析出來的內容：

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            10:e6:fc:62:b7:41:8a:d5:00:5e:45:b6
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA-SHA256-G2
        Validity
            Not Before: Nov 21 08:00:00 2016 GMT
            Not After : Nov 22 07:59:59 2017 GMT
        Subject: C=US, ST=California, L=San Francisco, O=Wikimedia Foundation, Inc., CN=*.wikipedia.org
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub: 
                    04:c9:22:69:31:8a:d6:6c:ea:da:c3:7f:2c:ac:a5:
                    af:c0:02:ea:81:cb:65:b9:fd:0c:6d:46:5b:c9:1e:
                    ed:b2:ac:2a:1b:4a:ec:80:7b:e7:1a:51:e0:df:f7:
                    c7:4a:20:7b:91:4b:20:07:21:ce:cf:68:65:8c:c6:
                    9d:3b:ef:d5:c1
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Agreement
            Authority Information Access: 
                CA Issuers - URI:http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt
                OCSP - URI:http://ocsp2.globalsign.com/gsorganizationvalsha2g2

            X509v3 Certificate Policies: 
                Policy: 1.3.6.1.4.1.4146.1.20
                  CPS: https://www.globalsign.com/repository/
                Policy: 2.23.140.1.2.2

            X509v3 Basic Constraints: 
                CA:FALSE
            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl

            X509v3 Subject Alternative Name: 
                DNS:*.wikipedia.org, DNS:*.m.mediawiki.org, DNS:*.m.wikibooks.org, DNS:*.m.wikidata.org, DNS:*.m.wikimedia.org, DNS:*.m.wikimediafoundation.org, DNS:*.m.wikinews.org, DNS:*.m.wikipedia.org, DNS:*.m.wikiquote.org, DNS:*.m.wikisource.org, DNS:*.m.wikiversity.org, DNS:*.m.wikivoyage.org, DNS:*.m.wiktionary.org, DNS:*.mediawiki.org, DNS:*.planet.wikimedia.org, DNS:*.wikibooks.org, DNS:*.wikidata.org, DNS:*.wikimedia.org, DNS:*.wikimediafoundation.org, DNS:*.wikinews.org, DNS:*.wikiquote.org, DNS:*.wikisource.org, DNS:*.wikiversity.org, DNS:*.wikivoyage.org, DNS:*.wiktionary.org, DNS:*.wmfusercontent.org, DNS:*.zero.wikipedia.org, DNS:mediawiki.org, DNS:w.wiki, DNS:wikibooks.org, DNS:wikidata.org, DNS:wikimedia.org, DNS:wikimediafoundation.org, DNS:wikinews.org, DNS:wikiquote.org, DNS:wikisource.org, DNS:wikiversity.org, DNS:wikivoyage.org, DNS:wiktionary.org, DNS:wmfusercontent.org, DNS:wikipedia.org
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Subject Key Identifier: 
                28:2A:26:2A:57:8B:3B:CE:B4:D6:AB:54:EF:D7:38:21:2C:49:5C:36
            X509v3 Authority Key Identifier: 
                keyid:96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C

    Signature Algorithm: sha256WithRSAEncryption
         8b:c3:ed:d1:9d:39:6f:af:40:72:bd:1e:18:5e:30:54:23:35:
         ...

1.2.3 CA證書

證書是用來證明某某東西確實是某某東西的東西（是不是像繞口令？）。通俗地說，證書就好比上文裏面的公章。通過公章，可以證明對應的證件的真實性。

理論上，人人都可以找個證書工具，自己做一個證書。那如何防止壞人自己製作證書出來騙人捏？請看後續 CA 的介紹。

CA是Certificate Authority的縮寫，也叫“證書授權中心”。

它是負責管理和簽發證書的第三方機構, 好比一個可信任的中介公司。一般來說，CA必須是所有行業和所有公衆都信任的、認可的。因此它必須具有足夠的權威性。就好比A、B兩公司都必須信任C公司，纔會找 C 公司作爲公章的中介。

• CA證書

  CA 證書，顧名思義，就是CA頒發的證書。

  前面已經說了，人人都可以找工具製作證書。但是你一個小破孩製作出來的證書是沒啥用處的。因爲你不是權威的CA機關，你自己搞的證書不具有權威性。

  比如，某個壞人自己刻了一個公章，蓋到介紹信上。但是別人一看，不是受信任的中介公司的公章，就不予理睬。壞蛋的陰謀就不能得逞啦。

• 證書信任鏈

  證書直接是可以有信任關係的, 通過一個證書可以證明另一個證書也是真實可信的. 實際上，證書之間的信任關係，是可以嵌套的。比如，C 信任 A1，A1 信任 A2，A2 信任 A3…這個叫做證書的信任鏈。只要你信任鏈上的頭一個證書，那後續的證書，都是可以信任滴。

  假設 C 證書信任 A 和 B；然後 A 信任 A1 和 A2；B 信任 B1 和 B2。則它們之間，構成如下的一個樹形關係（一個倒立的樹）。

處於最頂上的樹根位置的那個證書，就是“根證書”。除了根證書，其它證書都要依靠上一級的證書，來證明自己。那誰來證明“根證書”可靠捏？實際上，根證書自己證明自己是可靠滴（或者換句話說，根證書是不需要被證明滴）。

聰明的同學此刻應該意識到了：根證書是整個證書體系安全的根本。所以，如果某個證書體系中，根證書出了問題（不再可信了），那麼所有被根證書所信任的其它證書，也就不再可信了。

• 證書有啥用

  1. 驗證網站是否可信（針對HTTPS）

     通常，我們如果訪問某些敏感的網頁（比如用戶登錄的頁面），其協議都會使用 HTTPS 而不是 HTTP。因爲 HTTP 協議是明文的，一旦有壞人在偷窺你的網絡通訊，他/她就可以看到網絡通訊的內容（比如你的密碼、銀行帳號、等）；而 HTTPS 是加密的協議，可以保證你的傳輸過程中，壞蛋無法偷窺。

     但是，千萬不要以爲，HTTPS 協議有了加密，就可高枕無憂了。俺再舉一個例子來說明，光有加密是不夠滴。假設有一個壞人，搞了一個假的網銀的站點，然後誘騙你上這個站點。假設你又比較單純，一不留神，就把你的帳號，口令都輸入進去了。那這個壞蛋的陰謀就得逞鳥。

     爲了防止壞人這麼幹，HTTPS 協議除了有加密的機制，還有一套證書的機制。通過證書來確保，某個站點確實就是某個站點。

     有了證書之後，當你的瀏覽器在訪問某個 HTTPS 網站時，會驗證該站點上的 CA 證書（類似於驗證介紹信的公章）。如果瀏覽器發現該證書沒有問題（證書被某個根證書信任、證書上綁定的域名和該網站的域名一致、證書沒有過期），那麼頁面就直接打開；否則的話，瀏覽器會給出一個警告，告訴你該網站的證書存在某某問題，是否繼續訪問該站點？下面給出 IE 和 Firefox 的抓圖：

大多數知名的網站，如果用了 HTTPS 協議，其證書都是可信的（也就不會出現上述警告）。所以，今後你如果上某個知名網站，發現瀏覽器跳出上述警告，你就要小心啦！

2. 驗證某文件是否可信（是否被篡改）

   證書除了可以用來驗證某個網站，還可以用來驗證某個文件是否被篡改。具體是通過證書來製作文件的數字簽名。製作數字簽名的過程太專業，咱就不說了。後面專門告訴大家如何驗證文件的數字簽名。考慮到大多數人用 Windows 系統，俺就拿 Windows 的例子來說事兒。

   比如，俺手頭有一個 Google Chrome的安裝文件（帶有數字簽名）。當俺查看該文件的屬性，會看到如下的界面。眼神好的同學，會注意到到上面有個“數字簽名”的標籤頁。如果沒有出現這個標籤頁，就說明該文件沒有附帶數字簽名。

一般來說，簽名列表中，有且僅有一個簽名。選中它，點“詳細信息”按鈕。跳出如下界面：

通常這個界面會顯示一行字：“該數字簽名正常”（圖中紅圈標出）。如果有這行字，就說明該文件從出廠到你手裏，中途沒有被篡改過（是原裝滴、是純潔滴）。如果該文件被篡改過了（比如，感染了病毒、被注入木馬），那麼對話框會出現一個警告提示“該數字簽名無效”

不論簽名是否正常，你都可以點“查看證書”按鈕。這時候，會跳出證書的對話框。如下：

從後一個界面，可以看到剛纔說的證書信任鏈。圖中的信任鏈有3層：

• 第1層是根證書（verisign）。
• 第2層是 symantec 專門用來簽名的證書。
• 第3層是 Google自己的證書。

目前大多數知名的公司（或組織機構），其發佈的可執行文件（比如軟件安裝包、驅動程序、安全補丁），都帶有數字簽名。你可以自己去看一下。

建議大夥兒在安裝軟件之前，都先看看是否有數字簽名？如果有，就按照上述步驟驗證一把。一旦數字簽名是壞的，那可千萬別裝。

1.3 公鑰基礎設施（PKI）

僅制定證書的規範還不足以支持公鑰的實際運用，我們還需要很多其他的規範，例如證書應該由誰來頒發，如何頒發，私鑰泄露時應該如何作廢證書，計算機之間的數據交換應採用怎樣的格式等。這一節我們將介紹能夠使公鑰的運用更加有效的公鑰基礎設施。

1.3.1 什麼是公鑰基礎設施

公鑰基礎設施（Public-Key infrastructure）是爲了能夠更有效地運用公鑰而制定的一系列規範和規格的總稱。公鑰基礎設施一般根據其英語縮寫而簡稱爲PKI。

PKI只是一個總稱，而並非指某一個單獨的規範或規格。例如，RSA公司所制定的PKCS（Public-Key Cryptography Standards，公鑰密碼標準）系列規範也是PKI的一種，而互聯網規格RFC（Requestfor Comments）中也有很多與PKI相關的文檔。此外，X.509這樣的規範也是PKI的一種。在開發PKI程序時所使用的由各個公司編寫的API（Application Programming Interface, 應用程序編程接口）和規格設計書也可以算是PKI的相關規格。

因此，根據具體所採用的規格，PKI也會有很多變種，這也是很多人難以整體理解PKI的原因之一。

爲了幫助大家整體理解PKI,我們來簡單總結一下PKI的基本組成要素（用戶、認證機構、倉庫）以及認證機構所負責的工作。

1.3.2 PKI的組成要素

PKI的組成要素主要有以下三個：

• 用戶 — 使用PKI的人
• 認證機構 — 頒發證書的人
• 倉庫 — 保存證書的數據庫

用戶

用戶就是像Alice、Bob這樣使用PKI的人。用戶包括兩種：一種是希望使用PKI註冊自己的公鑰的人，另一種是希望使用已註冊的公鑰的人。我們來具體看一下這兩種用戶所要進行的操作。

• 註冊公鑰的用戶所進行的操作

  • 生成密鑰對（也可以由認證機構生成）
  • 在認證機構註冊公鑰
  • 向認證機構申請證書
  • 根據需要申請作廢已註冊的公鑰
  • 解密接收到的密文
  • 對消息進行數字簽名

• 使用已註冊公鑰的用戶所進行的操作

  • 將消息加密後發送給接收者
  • 驗證數字簽名

  /* 
  ==================== 小知識點 ==================== 
  瀏覽器如何驗證SSL證書
  1. 在IE瀏覽器的菜單中點擊“工具 /Internet選項”，選擇“內容”標籤，點擊“證書”按鈕，然後就可以看到IE
     瀏覽器已經信任了許多“中級證書頒發機構”和“受信任的根證書頒發機 構。當我們在訪問該網站時，瀏覽器
     就會自動下載該網站的SSL證書，並對證書的安全性進行檢查。
  2. 由於證書是分等級的，網站擁有者可能從根證書頒發機構領到證書，也可能從根證書的下一級（如某個國家
     的認證中心，或者是某個省發出的證書）領到證書。假設我們正在訪問某個使用 了 SSL技術的網站，IE瀏
     覽器就會收到了一個SSL證書，如果這個證書是由根證書頒發機構簽發的，IE瀏覽器就會按照下面的步驟來
     檢查：瀏覽器使用內 置的根證書中的公鑰來對收到的證書進行認證，如果一致，就表示該安全證書是由可信
     任的頒證機構簽發的，這個網站就是安全可靠的；如果該SSL證書不是根服 務器簽發的，瀏覽器就會自動檢
     查上一級的發證機構，直到找到相應的根證書頒發機構，如果該根證書頒發機構是可信的，這個網站的SSL證
     書也是可信的。
  */
  

認證機構（CA）

認證機構（Certification Authority，CA）是對證書進行管理的人。上面的圖中我們給它起了一個名字叫作Trent。認證機構具體所進行的操作如下：

• 生成密鑰對 (也可以由用戶生成)

  生成密鑰對有兩種方式：一種是由PKI用戶自行生成，一種是由認證機構來生成。在認證機構生成用戶密鑰對的情況下，認證機構需要將私鑰發送給用戶，這時就需要使用PKCS#12（Personal Information Exchange Syntax Standard）等規範。

• 在註冊公鑰時對本人身份進行認證, 生成並頒發證書

  在用戶自行生成密鑰對的情況下，用戶會請求認證機構來生成證書。申請證書時所使用的規範是由PKCS#10（Certification Request Syntax Standard）定義的。

  認證機構根據其認證業務準則（Certification Practice Statement，CPS）對用戶的身份進行認證，並生成證書。在生成證書時，需要使用認證機構的私鑰來進行數字簽名。生成的證書格式是由PKCS#6 （Extended-Certificate Syntax Standard）和 X.509定義的。

• 作廢證書

  當用戶的私鑰丟失、被盜時，認證機構需要對證書進行作廢（revoke）。此外，即便私鑰安然無恙，有時候也需要作廢證書，例如用戶從公司離職導致其失去私鑰的使用權限，或者是名稱變更導致和證書中記載的內容不一致等情況。

  紙質證書只要撕毀就可以作廢了，但這裏的證書是數字信息，即便從倉庫中刪除也無法作廢，因爲用戶會保存證書的副本，但認證機構又不能人侵用戶的電腦將副本刪除。

  要作廢證書，認證機構需要製作一張證書==作廢清單（Certificate Revocation List),簡稱爲CRL==。

  CRL是認證機構宣佈作廢的證書一覽表，具體來說，是一張已作廢的證書序列號的清單，並由認證機構加上數字簽名。證書序列號是認證機構在頒發證書時所賦予的編號，在證書中都會記載。

  PKI用戶需要從認證機構獲取最新的CRL,並查詢自己要用於驗證簽名（或者是用於加密）的公鑰證書是否已經作廢這個步驟是非常重要的。

  假設我們手上有Bob的證書，該證書有合法的認證機構簽名，而且也在有效期內，但僅憑這些還不能說明該證書一定是有效的，還需要查詢認證機構最新的CRL，並確認該證書是否有效。一般來說，這個檢查不是由用戶自身來完成的，而是應該由處理該證書的軟件來完成，但有很多軟件並沒有及時更能CRL。

認證機構的工作中，公鑰註冊和本人身份認證這一部分可以由註冊機構（Registration Authority，RA) 來分擔。這樣一來，認證機構就可以將精力集中到頒發證書上，從而減輕了認證機構的負擔。不過，引入註冊機構也有弊端，比如說認證機構需要對註冊機構本身進行認證，而且隨着組成要素的增加，溝通過程也會變得複雜，容易遭受攻擊的點也會增。

倉庫

倉庫（repository）是一個保存證書的數據庫，PKI用戶在需要的時候可以從中獲取證書．它的作用有點像打電話時用的電話本。在本章開頭的例子中，儘管沒特別提到，但Alice獲取Bob的證書時，就可以使用倉庫。倉庫也叫作證書目錄。

1.3.3 各種各樣的PKI

公鑰基礎設施（PKI）這個名字總會引起一些誤解，比如說“面向公衆的權威認證機構只有一個"，或者“全世界的公鑰最終都是由一個根CA來認證的"，其實這些都是不正確的。認證機構只要對公鑰進行數字簽名就可以了，因此任何人都可以成爲認證機構，實際上世界上已經有無數個認證機構了。

國家、地方政府、醫院、圖書館等公共組織和團體可以成立認證機構來實現PKI,公司也可以出於業務需要在內部實現PKI,甚至你和你的朋友也可以以實驗爲目的來構建PKI。

在公司內部使用的情況下，認證機構的層級可以像上一節中一樣和公司的組織層級一一對應，也可以不一一對應。例如，如果公司在東京、大阪、北海道和九州都成立了分公司，也可以採取各個分公司之間相互認證的結構。在認證機構的運營方面，可以購買用於構建PKI的軟件產品由自己公司運營，也可以使用VeriSign等外部認證服務。具體要採取怎樣的方式，取決於目的和規模，並沒有一定之規。

2.Fabric - ca

2.1 簡介

Fabric CA項目是超級賬本Fabric內的MemberService組件, 對網絡內各個實體的身份證書的管理, 主要實現:

• 負責Fabric網絡內所有實體(Identity)的身份管理, 包括身份的註冊、註銷等

• 服務端支持基於客戶端命令行的RESTful API的交互方式

• 負責證書管理, 包括ECerts(身份證書)、TCerts(交易證書)等的發放和註銷

  Fabric CA採用Go語言進行編寫

在fabric-ca中的三種證書類型

1.登記證書（ECert）:對實體身份進行檢驗

2.通信證書（TLSCert）:保證通信鏈路安全，對遠端身份校驗

3.交易證書（TCert）:頒發給用戶，控制每個交易的權限

下圖描述了CA 服務器在Fabric 框架體系架構中的工作方式:

CA 服務器結構爲樹形結構，整個樹形結構的根節點爲根CA（Root Server），存在多箇中間CA（Intermediate CA），圖中每個中間CA服務器上可以配置一個CA服務集羣，CA服務集羣通過前置的HA實現負載均衡。

Fabric CA提供了兩種訪問方式調用Server服務，一種是通過Client調用，另一種是通過SDK調用。兩種調用都是REST風格的。本文使用的是通過Client調用。

2.2 基本組件

Fabric CA採用了典型的C/S架構， 目前包含兩個基本組件， 分別實現服務端功能和客戶端功能

• 服務端: fabric-ca-server實現核心的PKI(Public Key Infrastructure: 公鑰基礎設施)服務功能， 支持多種數據庫後臺(包括SQlite3、MySQL、PostgreSQL等), 並支持集成LDAP用爲用戶註冊管理功能

• 客戶端: fabric-ca-client封裝了服務端的RESTful API, 提供訪問服務端的命令, 供用戶與服務端進行交互

2.3 安裝

安裝服務端與客戶端二進制命令到$GOPATH/bin目錄下

$ go get -u github.com/hyperledger/fabric-ca/cmd/...

切換至源碼目錄下：

$ cd $GOPATH/src/github.com/hyperledger/fabric-ca/1

使用make命令編譯：

$ make fabric-ca-server
$ make fabric-ca-client

生成 bin 目錄, 目錄中包含 fabric-ca-client 與 fabric-ca-server 兩個可執行文件

2.4 初始化&快速啓動

返回至用戶目錄

1.$ cd ~
2.$ mkdir fabric-ca
3.$ cd fabric-ca

fabric-ca啓動:

1. 使用init進行初始化
2. 使用start啓動

初始化

$ fabric-ca-server init -b admin:pass

生成配置文件到至當前目錄

• fabric-ca-server-config.yaml: 默認配置文件
• ca-cert.pem: PEM格式的CA證書文件, 自簽名
• fabric-ca-server.db: 存放數據的sqlite數據庫
• msp/keystore/: 路徑下存放個人身份的私鑰文件(_sk文件), 對應簽名證書

快速啓動並初始化一個fabric-ca-server服務

$ fabric-ca-server start -b admin:pass

-b : 提供註冊用戶的名稱與密碼, 如果沒有使用LDAP, 這個選項爲必需. 默認的配置文件的名稱爲fabric-ca-server-config.yaml

如果之前沒有執行初始化命令, 則啓動過程中會自動先進行初始化操作. 即從主配置目錄搜索相關證書和配置文件, 如果不存在則會自動生成

2.5 服務端配置文件解析

fabric-ca-server-config.yaml配置文件包括通用配置, TLS配置, CA配置, 註冊管理配置, 數據庫配置, LDAP配置, 組織結構配置, 簽名, 證書申請等幾部分

version: 1.1.1-snapshot-e656889
port: 7054              # 指定服務的監聽端口
debug: false            # 是否啓用DEBUG模式, 輸出更多的調試信息上
crlsizelimit: 512000

# 是否在服務端啓用TLS,如果啓用TLS後進行身份驗證的證書和簽名的私鑰
tls:    
  enabled: false        # 是否啓用TLS, 默認不啓用
  certfile:         # TLS證書文件
  keyfile:          # TLS密鑰文件
  clientauth:   # 客戶端驗證配置
    type: noclientcert      # 默認不進行身份驗證
    certfiles:      # 進行客戶端身份驗證時, 信任的證書文件列表

# 包括實例的名稱、簽名私鑰文件、身份驗證證書和證書鏈文件；這些私鑰和證書文件會用來作爲生成ECert、TCert的根證書
ca:     
  name:         # CA服務名稱. 可以支持多個服務
  keyfile:      # 密鑰文件(默認: ca-key.pem)
  certfile:     # 證書文件(默認: ca-cert.pem)
  chainfile:    # 證書鏈文件(默認: chain-cert.pem)

crl:
  expiry: 24h

# 當fabric-ca-server自身提供用戶的註冊管理時使用, 此情況下需要禁用LDAP功能, 否則fabric-ca-server將會把註冊管理數據轉發到LDAP進行查詢
registry:
  # 允許同一個用戶名和密碼進行enrollment的最大次數, -1爲無限制, 0爲不支持登記
  maxenrollments: -1        
  identities:   # 註冊的實體信息, 可以進行enroll. 只有當LDAP未啓用時起作用
     - name: admin
       pass: adminpw
       type: client
       affiliation: ""
       attrs:
          hf.Registrar.Roles: "peer,orderer,client,user"
          hf.Registrar.DelegateRoles: "peer,orderer,client,user"
          hf.Revoker: true
          hf.IntermediateCA: true       # 該id是否是一箇中間層的CA
          hf.GenCRL: true
          hf.Registrar.Attributes: "*"
          hf.AffiliationMgr: true

# 數據庫支持SQLite3、MySQL、Postgres. 默認爲SQLite3類型的本地數據庫. 如果要配置集羣, 則需要選用MySQL或Postgres後端數據庫, 並在前端部署負載均衡器(如Nginx或HAProxy)
db:
  type: sqlite3
  datasource: fabric-ca-server.db       # SQLite3文件路徑
  tls:
      enabled: false    # 是否啓用TLS來連接到數據庫
      certfiles:        # PEM格式的數據庫服務器的TLS根證書, 可以指定多個, 用逗號隔開
      client:
        certfile:       # PEM格式的客戶端證書文件
        keyfile:        # PEM格式的客戶端證書私鑰文件

# 配置使用遠端的LDAP來進行註冊管理, 認證enrollment的用戶和密碼, 並獲取用戶屬性信息. 此時, 服務端將按照指定的usrfilter從LDAP獲取對應的用戶, 利用其唯一識別名(distinguidhed name)和給定的密碼進行驗證. 
# 當LDAP功能啓用時, registry中的配置將被忽略
ldap:
   enabled: false   # 是否啓用LDAP, 默認不啓用
   url: ldap://<adminDN>:<adminPassword>@<host>:<port>/<base>   # LDAP的服務地址
   tls:
      certfiles:    # PEM格式的LDAP服務器的TLS根證書, 可以爲多個, 用逗號隔開
      client:
         certfile:  # PEM格式的客戶端證書文件
         keyfile:   # PEM格式的客戶端證書私鑰文件
   attribute:    
      names: ['uid','member']     
      converters:
         - name:
           value:      
      maps:
         groups:
            - name:
              value:

# 組織結構配置
affiliations:
   org1:
      - department1
      - department2
   org2:
      - department1

# 簽發證書相關的配置包括簽名方法、證書超時時間等. fabric-ca-server可以作爲用戶證書的簽發CA(默認情況下), 也可以作爲根CA來進一步支持其它中間CA
signing:
    default:    # 默認情況下,用於簽署Ecert
      usage:    # 所簽發證書的KeyUsage extension域
        - digital signature
      expiry: 8760h
    profiles:   # 不同的簽發配置
      ca:   # 簽署中間層CA證書時的配置模板
         usage:
           - cert sign  # 所簽發證書的KeyUsage extension域
           - crl sign
         expiry: 43800h
         caconstraint:
           isca: true
           maxpathlen: 0    # 限制該中間層CA無法進一步簽署中間層CA
      tls:
         usage:
            - signing
            - key encipherment
            - server auth
            - client auth
            - key agreement
         expiry: 8760h

# CA自身證書的申請請求配置. 當CA作爲根證書服務時, 將基於請求生成一個自簽名的證書; 當CA作爲中間證書服務時, 將請求發送給上層的根證書進行簽署
csr:
   cn: fabric-ca-server     # 建議與服務器名一致
   names:
      - C: US
        ST: "North Carolina"
        L:
        O: Hyperledger
        OU: Fabric
   hosts:
     - kevin-hf
     - localhost
   ca:      # 配置後會加入到證書的擴展字段
      expiry: 131400h       # 超時時間
      pathlength: 1         # 允許產生的中間證書的深度

# 配置所選擇的加密庫
bccsp:
    default: SW
    sw:
        hash: SHA2
        security: 256
        filekeystore:
            keystore: msp/keystore      # 存放密鑰文件的路徑

# 自動創建除了默認CA外的多個CA實例, 如ca1、ca2等
cacount:

# 可以指定多個CA配置文件路徑, 每個配置文件會啓動一個CA服務,注意不同配置文件之間需要避免出現衝突(如服務端口、TLS證書等)
cafiles:


# 當CA作爲中間層CA服務時的相關配置. 包括父CA的地址和名稱、登記信息、TLS配置等.
# 注意: 當intermediate.parentserver.url非空時, 意味着本CA是中間層CA服務,否則爲根CA服務
intermediate:
  parentserver:     # 父CA相關信息
    url:
    caname:

  enrollment:       # 在父CA側的登記信息
    hosts:          # 證書主機名列表
    profile:        # 簽發所用的profile
    label:          # HSM操作中的標籤信息

  tls:      # TLS相關配置
    certfiles:      # 信任的根CA證書
    client:         # 客戶端驗證啓用時的相關文件
      certfile:
      keyfile:

2.6 客戶端命令解析

fabric-ca-client命令可以與服務端進行交互, 包括五個子命令:

• enroll: 登錄獲取ECert
• getcacert: 獲取CA服務的證書鏈
• reenroll: 再次登錄
• register: 註冊用戶實體
• revoke: 吊銷簽發的實體證書

CRL 驗證

CRL 一般用於數字證書有效性的驗證，當執行revoke 操作後會生成CRL證書作廢列表

CRL 是經過CA簽名的證書作廢列表，用於證書凍結和撤銷

一般證書會有CRL地址，供HTTP或者LDAP方式訪問，通過解析可得到CRL地址，然後下載CRL 進行驗證

CRL 會自動更新，並不是生成後不改變的

2.7 查看AKI和序列號

AKI: 公鑰標識號, 代表了對該證書進行簽發機構的身份

查看根證書的AKI與序列號信息:

$ openssl x509 -in .fabric-ca-client/msp/signcerts/cert.pem -text -noout

輸出內容如下:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:  # 序列號
            74:48:88:33:70:1a:01:a0:ad:32:29:6e:c5:ab:5a:fa:3b:91:25:a4
   ......
        X509v3 extensions:
           ......
            X509v3 Authority Key Identifier:    # keyid後面的內容就是 AKI
                keyid:45:B1:50:B6:CD:8A:8D:C5:9B:9E:5F:75:15:47:D6:C0:AD:75:FE:71

    ......

單獨獲取AKI

$ openssl x509 -in .fabric-ca-client/msp/signcerts/cert.pem -text -noout | awk '/keyid/ {gsub (/ *keyid:|:/,"",$1);print tolower($0)}'

輸出內容如下:

45b150b6cd8a8dc59b9e5f751547d6c0ad75fe71

單獨獲取序列號

$ openssl x509 -in .fabric-ca-client/msp/signcerts/cert.pem -serial -noout | cut -d "=" -f 2

輸出內容如下:

74488833701A01A0AD32296EC5AB5AFA3B9125A4

er: # 序列號
74:48:88:33:70:1a:01:a0:ad:32:29:6e:c5🆎5a:fa:3b:91:25:a4
…
X509v3 extensions:
…
X509v3 Authority Key Identifier: # keyid後面的內容就是 AKI
keyid:45:B1:50:B6:CD:8A:8D:C5:9B:9E:5F:75:15:47:D6:C0:AD:75:FE:71

......

單獨獲取AKI

````shell
$ openssl x509 -in .fabric-ca-client/msp/signcerts/cert.pem -text -noout | awk '/keyid/ {gsub (/ *keyid:|:/,"",$1);print tolower($0)}'

輸出內容如下:

45b150b6cd8a8dc59b9e5f751547d6c0ad75fe71

單獨獲取序列號

$ openssl x509 -in .fabric-ca-client/msp/signcerts/cert.pem -serial -noout | cut -d "=" -f 2

輸出內容如下:

74488833701A01A0AD32296EC5AB5AFA3B9125A4