"證書 -- 為公鑰加上數(shù)字簽名"

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

公鑰證書(Public-Key Certificate，PKC)其實和駕照很相似栓票，里面記有姓名决左、組織、郵箱地址等個人信息走贪，以及 屬于此人的公鑰佛猛，并由認證機構(Certification Authority、Certifying Authority, CA)施加數(shù)字簽名坠狡。只要看到公 鑰證書继找，我們就可以知道認證機構認定該公鑰的確屬于此人。公鑰證書也簡稱為證書(certificate)逃沿。

可能很多人都沒聽說過認證機構婴渡，認證機構就是能夠認定 “公鑰確實屬于此人"漩勤，并能夠生成數(shù)字簽名的個人或 者組織。認證機構中有國際性組織和政府所設立的組織缩搅，也有通過提供認證服務來盈利的一般企業(yè)，此外個人 也可以成立認證機構触幼。

1. 證書的應用場景

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

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

認證機構必須是可信的堂鲤，對于“可信的第三方”，下圖中會使用Trent這個名字媒峡，這個詞是從trust(信任)一詞演 變而來的瘟栖。

證書的代表性應用場景.png

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

1. Bob生成密鑰對
   要使用公鑰密碼進行通信谅阿，首先需要生成密鑰對半哟。Bob生成了一對公鑰和私鑰，并將私鑰自行妥善保管签餐。在這里寓涨，密鑰對是由Bob自己生成的，也可以由認證機構代為生成氯檐。

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

   • 在這里Bob則將公鑰發(fā)送給了認證機構Trent戒良，這是因為Bob需要請認證機構Trent對他的公鑰加上數(shù) 字簽名(也就是生成證書)。
   • Trent收到Bob的公鑰后冠摄，會確認所收到的公鑰是否為Bob本人所有(參見專欄:身份確認和認證業(yè) 務準則)

專欄:身份確認和認證業(yè)務準則
認證機構確認"本人"身份的方法和認證機構的認證業(yè)務準則(CertificatePractice Statement, CPS糯崎，的內容有關。如果認證機構提供的是測試用的服務河泳，那么可能完全不會進行任何身份確 認沃呢。如果是政府部門運營的認證機構，可能就需要根據(jù)法律規(guī)定來進行身份確認拆挥。如果是企業(yè) 面向內部設立的認證機構樟插，那就可能會給部門負責人打電話直接確認。
例如竿刁，VeriSign的認證業(yè)務準則中將身份確認分為Class1 ~ 3共三個等級

• Class1:通過向郵箱發(fā)送件來確認本人身份
• Class2:通過第三方數(shù)據(jù)庫來確認本人身份
• Class3:通過當面認證和身份證明來確認本人身份

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

3. 認證機構Trent用自己的私鑰對Bob的公鑰施加數(shù)字簽名并生成證書
   Trent對Bob的公鑰加上數(shù)字簽名食拜。為了生成數(shù)字簽名鸵熟，需要Trent自身的私鑰，因此Trent需要事先生成好密鑰對负甸。

4. Alice得到帶有認證機構Trent的數(shù)字簽名的Bob的公鑰(證書)
   現(xiàn)在Alice需要向Bob發(fā)送密文流强，因此她從Trent處獲取證書痹届。證書中包含了Bob的公鑰。

5. Alice使用認證機構Trent的公鑰驗證數(shù)字簽名打月，確認Bob的公鑰的合法性
   Alice使用認證機構Trent的公鑰對證書中的數(shù)字簽名進行驗證队腐。如果驗證成功，就相當于確認了證書中所包含的公鑰的確是屬于Bob的奏篙。到這里柴淘，Alice就得到了合法的Bob的公鑰。

6. Alice用Bob的公鑰加密消息并發(fā)送給Bob
   Alice用Bob的公鑰加密要發(fā)送的消息秘通，并將消息發(fā)送給Bob为严。

7. Bob用自己的私鑰解密密文得到Alice的消息
   Bob收到Alice發(fā)送的密文，然后用自己的私鑰解密肺稀，這樣就能夠看到Alice的消息了第股。

上面就是利用認證機構Trent進行公鑰密碼通信的流程。其中1话原、2夕吻、3這幾個步驟 僅在注冊新公鑰時才會進行，并不是每次通信都需要繁仁。此外梭冠，步驟 4 僅在Alice第 一次用公鑰密碼向Bob發(fā)送消息時才需要進行，只要Alice將Bob的公鑰保存在電 腦中改备，在以后的通信中就可以直接使用了控漠。

2. 證書標準規(guī)范X.509

證書是由認證機構頒發(fā)的，使用者需要對證書進行驗證悬钳，因此如果證書的格式千奇百怪那就不方便了盐捷。于是， 人們制定了證書的標準規(guī)范默勾，其中使用最廣泛的是由ITU(International Telecommumcation Union碉渡，國際電信聯(lián)盟)和ISO(Intemational Organization for Standardization, 國際標準化組織)制定的X.509規(guī)范。很多應用程序都支 持x.509并將其作為證書生成和交換的標準規(guī)范母剥。

X.509是一種非常通用的證書格式滞诺。所有的證書都符合ITU-T X.509國際標準，因此(理論上)為一種應用創(chuàng)建的證書 可以用于任何其他符合X.509標準的應用环疼。X.509證書的結構是用ASN1(Abstract Syntax Notation One)進行描述數(shù)據(jù) 結構习霹，并使用ASN.1語法進行編碼。

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

一般來說熏迹，一個數(shù)字證書內容可能包括基本數(shù)據(jù)(版本、序列號) 凝赛、所簽名對象信息( 簽名算法類型注暗、簽發(fā)者信 息、有效期哄酝、被簽發(fā)人、簽發(fā)的公開密鑰)祷膳、CA的數(shù)字簽名陶衅，等等。

2.1. 證書規(guī)范

前使用最廣泛的標準為ITU和ISO聯(lián)合制定的X.509的 v3版本規(guī)范 (RFC5280), 其中定義了如下證書信息域:

• 版本號(Version Number):規(guī)范的版本號直晨，目前為版本3搀军，值為0x2;
• 序列號(Serial Number):由CA維護的為它所發(fā)的每個證書分配的一的列號，用來追蹤和撤銷證書勇皇。只要擁有簽發(fā)者信息和序列號罩句，就可以唯一標識一個證書，最大不能過20個字節(jié);
• 簽名算法(Signature Algorithm):數(shù)字簽名所采用的算法敛摘，如:

• sha256-with-RSA-Encryption
• ecdsa-with-SHA2S6

• 頒發(fā)者(Issuer):發(fā)證書單位的標識信息门烂，如 ” 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):公鑰的內容泄私。

• 頒發(fā)者唯一號(Issuer Unique Identifier):代表頒發(fā)者的唯一信息房揭，僅2、3版本支持晌端，可選;

• 主體唯一號(Subject Unique Identifier):代表擁有證書實體的唯一信息捅暴，僅2，3版本支持咧纠，可選;

• 擴展(Extensions伶唯，可選):可選的一些擴展。中可能包括:

• Subject Key Identifier:實體的秘鑰標識符惧盹，區(qū)分實體的多對秘鑰;
• Basic Constraints:一指明是否屬于CA;
• Authority Key Identifier:證書頒發(fā)者的公鑰標識符;
• CRL Distribution Points: 撤銷文件的頒發(fā)地址;
• Key Usage:證書的用途或功能信息

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

2.2. 證書格式

X.509規(guī)范中一般推薦使用PEM(Privacy Enhanced Mail)格式來存儲證書相關的文件粹断。證書文件的文件名后綴一般 為 .crt 或 .cer 符欠。對應私鑰文件的文件名后綴一般為 .key。證書請求文件的文件名后綴為 .csr 瓶埋。有時候也統(tǒng)一用 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-----

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

Certificate:
    Data:
G2
    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-
    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:
         ...

2.3. CA證書

證書是用來證明某某東西確實是某某東西的東西(是不是像繞口令?)。通俗地說巫湘，證書就好比上文里面的公章装悲。通過公章，可以證明對應的證件的真實性尚氛。

理論上诀诊，人人都可以找個證書工具，自己做一個證書阅嘶。那如何防止壞人自己制作證書出來騙人呢?請看后續(xù) CA 的介紹属瓣。

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

它是負責管理和簽發(fā)證書的第三方機構, 好比一個可信任的中介公司奠涌。一般來說，CA必須是所有行業(yè)和所有公眾 都信任的磷杏、認可的溜畅。因此它必須具有足夠的權威性。就好比A极祸、B兩公司都必須信任C公司慈格，才會找 C 公司作為公 章的中介。

2.3.1. 證書信任鏈

證書直接是可以有信任關系的, 通過一個證書可以證明另一個證書也是真實可信的. 實際上遥金，證書之間的信 任關系浴捆，是可以嵌套的。比如稿械，C 信任 A1选泻，A1 信任 A2，A2 信任 A3......這個叫做證書的信任鏈。只要你信 任鏈上的頭一個證書页眯，那后續(xù)的證書梯捕，都是可以信任的。

假設 C 證書信任 A 和 B;然后 A 信任 A1 和 A2;B 信任 B1 和 B2窝撵。則它們之間傀顾，構成如下的一個樹形關系 (一個倒立的樹)。

證書信任鏈.png

處于最頂上的樹根位置的那個證書碌奉，就是“ 根證書 ”短曾。除了根證書，其它證書都要依靠上一級的證書赐劣，來證明自己嫉拐。那誰來證明“根證書”可靠呢?實際上，根證書自己證明自己是可靠的(或者換句話說魁兼，根證書是 不需要被證明的)婉徘。

2.3.2. 證書有啥用

1. 驗證網站是否可信(針對HTTPS)

通常，我們如果訪問某些敏感的網頁(比如用戶登錄的頁面)璃赡，其協(xié)議都會使用 HTTPS 而不是 HTTP判哥。因為 HTTP 協(xié)議是明文的献雅，一旦有壞人在偷窺你的網絡通訊碉考，他/她就可以看到網絡通訊的內 容(比如你的密碼、銀行帳號挺身、等);而 HTTPS 是加密的協(xié)議侯谁，可以保證你的傳輸過程中，壞蛋無法偷窺章钾。

但是墙贱，千萬不要以為，HTTPS 協(xié)議有了加密贱傀，就可高枕無憂了惨撇。再舉一個例子來說明，光有加密是不夠的府寒。假設有一個壞人魁衙，搞了一個假的網銀的站點，然后誘騙你上這個站點株搔。假設你又比較單 純剖淀，一不留神，就把你的帳號纤房，口令都輸入進去了纵隔。那這個壞蛋的陰謀就得逞了。

為了防止壞人這么干，HTTPS 協(xié)議除了有加密的機制捌刮，還有一套證書的機制碰煌。通過證書來確保，某 個站點確實就是某個站點糊啡。

有了證書之后拄查，當你的瀏覽器在訪問某個 HTTPS 網站時，會驗證該站點上的 CA 證書(類似于驗證 介紹信的公章)棚蓄。如果瀏覽器發(fā)現(xiàn)該證書沒有問題(證書被某個根證書信任堕扶、證書上綁定的域名和 該網站的域名一致、證書沒有過期)梭依，那么頁面就直接打開;否則的話稍算，瀏覽器會給出一個警告， 告訴你該網站的證書存在某某問題役拴，是否繼續(xù)訪問該站點?

大多數(shù)知名的網站糊探，如果用了 HTTPS 協(xié)議，其證書都是可信的(也就不會出現(xiàn)上述警告)河闰。所以科平， 今后你如果上某個知名網站，發(fā)現(xiàn)瀏覽器跳出上述警告姜性，你就要小心啦!

3. 公鑰基礎設施(PKI)

僅制定證書的規(guī)范還不足以支持公鑰的實際運用瞪慧，我們還需要很多其他的規(guī)范，例如證書應該由誰來頒發(fā)部念，如何頒發(fā)弃酌，私鑰泄露時應該如何作廢證書，計算機之間的數(shù)據(jù)交換應采用怎樣的格式等儡炼。這一節(jié)我們將介紹能夠使公鑰的運用更加有效的公鑰基礎設施妓湘。

3.1. 什么是公鑰基礎設施

公鑰基礎設施(Public-Key infrastructure)是為了能夠更有效地運用公鑰而制定的一系列規(guī)范和規(guī)格的總稱。公 鑰基礎設施一般根據(jù)其英語縮寫而簡稱為PKI乌询。

PKI只是一個總稱榜贴，而并非指某一個單獨的規(guī)范或規(guī)格。例如妹田，RSA公司所制定的PKCS(Public-Key Cryptography Standards唬党，公鑰密碼標準)系列規(guī)范也是PKI的一種，而互聯(lián)網規(guī)格RFC(Requestfor Comments)中也有很多與 PKI相關的文檔秆麸。此外初嘹，X.509這樣的規(guī)范也是PKI的一種。在開發(fā)PKI程序時所使用的由各個公司編寫的 API(Application Programming Interface, 應用程序編程接口)和規(guī)格設計書也可以算是PKI的相關規(guī)格沮趣。

因此屯烦，根據(jù)具體所采用的規(guī)格，PKI也會有很多變種，這也是很多人難以整體理解PKI的原因之一驻龟。

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

3.2. 什么是公鑰基礎設施

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

• 用戶 --- 使用PKI的人
• 認證機構 --- 頒發(fā)證書的人
• 倉庫 --- 保存證書的數(shù)據(jù)庫

公鑰基礎設施.png

3.2.1. 用戶

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

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

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

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

  • 將消息加密后發(fā)送給接收者
  • 驗證數(shù)字簽名

3.2.2. 認證機構(CA)

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

• 生成密鑰對 (也可以由用戶生成)
  生成密鑰對有兩種方式:一種是由PKI用戶自行生成撩炊，一種是由認證機構來生成砾淌。在認證機構生成用戶密鑰 對的情況下，認證機構需要將私鑰發(fā)送給用戶狭吼，這時就需要使用PKCS#12(Personal Information Exchange Syntax Standard)等規(guī)范

• 在注冊公鑰時對本人身份進行認證, 生成并頒發(fā)證書
  在用戶自行生成密鑰對的情況下座每，用戶會請求認證機構來生成證書。申請證書時所使用的規(guī)范是由 PKCS#10(Certification Request Syntax Standard)定義的掐松。
  認證機構根據(jù)其認證業(yè)務準則(Certification Practice Statement逞壁，CPS)對用戶的身份進行認證分瘦，并生成證 書抡诞。在生成證書時出刷，需要使用認證機構的私鑰來進行數(shù)字簽名坷檩。生成的證書格式是由PKCS#6 (Extended- Certificate Syntax Standard)和 X.509定義的。

• 作廢證書
  當用戶的私鑰丟失改抡、被盜時矢炼，認證機構需要對證書進行作廢(revoke)。此外阿纤，即便私鑰安然無恙句灌，有時 候也需要作廢證書，例如用戶從公司離職導致其失去私鑰的使用權限欠拾，或者是名稱變更導致和證書中記載 的內容不一致等情況胰锌。
  紙質證書只要撕毀就可以作廢了，但這里的證書是數(shù)字信息藐窄，即便從倉庫中刪除也無法作廢资昧，因為用戶會
  保存證書的副本，但認證機構又不能人侵用戶的電腦將副本刪除枷邪。
  要作廢證書榛搔，認證機構需要制作一張證書 作廢清單(Certificate Revocation List),簡稱為CRL 诺凡。
  CRL是認證機構宣布作廢的證書一覽表东揣，具體來說，是一張已作廢的證書序列號的清單腹泌，并由認證機構加
  上數(shù)字簽名嘶卧。證書序列號是認證機構在頒發(fā)證書時所賦予的編號，在證書中都會記載凉袱。
  PKI用戶需要從認證機構獲取最新的CRL,并查詢自己要用于驗證簽名(或者是用于加密)的公鑰證書是否已 經作廢這個步驟是非常重要的芥吟。
  假設我們手上有Bob的證書侦铜，該證書有合法的認證機構簽名，而且也在有效期內钟鸵，但僅憑這些還不能說明 該證書一定是有效的钉稍，還需要查詢認證機構最新的CRL，并確認該證書是否有效棺耍。一般來說贡未，這個檢查不 是由用戶自身來完成的，而是應該由處理該證書的軟件來完成蒙袍，但有很多軟件并沒有及時更能CRL俊卤。

認證機構的工作中，公鑰注冊和本人身份認證這一部分可以由注冊機構(Registration Authority害幅，RA) 來分擔消恍。 這樣一來，認證機構就可以將精力集中到頒發(fā)證書上以现，從而減輕了認證機構的負擔狠怨。不過，引入注冊機構也有 弊端邑遏，比如說認證機構需要對注冊機構本身進行認證取董，而且隨著組成要素的增加，溝通過程也會變得復雜无宿，容 易遭受攻擊的點也會增茵汰。

3.2.2. 倉庫

倉庫(repository)是一個保存證書的數(shù)據(jù)庫，PKI用戶在需要的時候可以從中獲取證書.它的作用有點像打電話 時用的電話本孽鸡。在本章開頭的例子中蹂午，盡管沒特別提到，但Alice獲取Bob的證書時彬碱，就可以使用倉庫豆胸。倉庫也叫 作證書目錄。

3.3. 各種各樣的PKI

公鑰基礎設施(PKI)這個名字總會引起一些誤解巷疼，比如說“面向公眾的權威認證機構只有一個"晚胡，或者“全世界的 公鑰最終都是由一個根CA來認證的"，其實這些都是不正確的嚼沿。認證機構只要對公鑰進行數(shù)字簽名就可以了估盘，因 此任何人都可以成為認證機構，實際上世界上已經有無數(shù)個認證機構了骡尽。

國家遣妥、地方政府、醫(yī)院攀细、圖書館等公共組織和團體可以成立認證機構來實現(xiàn)PKI,公司也可以出于業(yè)務需要在內部 實現(xiàn)PKI,甚至你和你的朋友也可以以實驗為目的來構建PKI箫踩。

在公司內部使用的情況下爱态，認證機構的層級可以像上一節(jié)中一樣和公司的組織層級一一對應，也可以不一一對 應境钟。例如锦担，如果公司在東京、大阪慨削、北海道和九州都成立了分公司吆豹，也可以采取各個分公司之間相互認證的結 構。在認證機構的運營方面理盆，可以購買用于構建PKI的軟件產品由自己公司運營痘煤，也可以使用VeriSign等外部認 證服務。具體要采取怎樣的方式猿规，取決于目的和規(guī)模衷快，并沒有一定之規(guī)。