本文以X.509證書為例，為大家詳細(xì)介紹了X.509證書的概念和證書結(jié)構(gòu)，以及X.509證書的使用方法，閱讀完整文相信大家對(duì)X.509證書有了一定的認(rèn)識(shí)。
目前創(chuàng)新互聯(lián)建站已為超過千家的企業(yè)提供了網(wǎng)站建設(shè)、域名、網(wǎng)站空間、成都網(wǎng)站托管、企業(yè)網(wǎng)站設(shè)計(jì)、廣西網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。
X.509標(biāo)準(zhǔn)是密碼學(xué)里公鑰證書的格式標(biāo)準(zhǔn)。X.509 證書己應(yīng)用在包括TLS/SSL（WWW萬維網(wǎng)安全瀏覽的基石）在內(nèi)的眾多 Internet協(xié)議里，同時(shí)它也有很多非在線的應(yīng)用場景，比如電子簽名服務(wù)。X.509證書含有公鑰和標(biāo)識(shí)（主機(jī)名、組織或個(gè)人），并由證書頒發(fā)機(jī)構(gòu)（CA）簽名（或自簽名）。對(duì)于一份經(jīng)由可信的證書簽發(fā)機(jī)構(gòu)簽名（或者可以通過其它方式驗(yàn)證）的證書，證書的擁有者就可以用證書及相應(yīng)的私鑰來創(chuàng)建安全的通信，以及對(duì)文檔進(jìn)行數(shù)字簽名。
X.509最早與X.500一起發(fā)布于1988年7月3日，它假定頒發(fā)證書的證書頒發(fā)機(jī)構(gòu)（CA）具有嚴(yán)格的層次結(jié)構(gòu)。這與Web信任模型（如PGP）形成了鮮明對(duì)比，因?yàn)镻GP方案是任何人都以簽名（而不僅僅是地位特殊的CA），從而證明其他人的密鑰證書的有效性。X.509 V3證書的設(shè)計(jì)非常靈活，除了對(duì)網(wǎng)橋拓?fù)浼軜?gòu)網(wǎng)絡(luò)的支持，還可以支持用于點(diǎn)對(duì)點(diǎn)方式的Mesh網(wǎng)，類似于OpenPGP那樣的web信任機(jī)制，不過這樣方式在2004年之前很少使用。
X.500系統(tǒng)僅由主權(quán)國家實(shí)施，以實(shí)現(xiàn)國家身份信息共享?xiàng)l約的實(shí)施目的，而IETF的公鑰基礎(chǔ)設(shè)施（X.509）或PKIX工作組已對(duì)該標(biāo)準(zhǔn)進(jìn)行了調(diào)整，以適應(yīng)更靈活的互聯(lián)網(wǎng)組織結(jié)構(gòu)。事實(shí)上X.509認(rèn)證指的是RFC5280里定義的X.509 v3，包括對(duì)IETF的PKIX證書和證書吊銷列表（CRL Profile），通常也稱為公鑰基礎(chǔ)設(shè)施。
在X.509系統(tǒng)中，證書申請(qǐng)者通過發(fā)起“證書簽名請(qǐng)求（CSR）”來得到一份被簽名的證書。為此，它需要生成一個(gè)密鑰對(duì)，然后用其中的私鑰對(duì)CSR簽名（私鑰本身要妥善保存，對(duì)外保密），CSR包含申請(qǐng)人的身份信息、用于驗(yàn)真CSR的申請(qǐng)人的公鑰，以及所請(qǐng)求證書的專有名稱（DN），CSR還可能帶有CA要求的其它有關(guān)身份證明的信息，然后CA對(duì)這個(gè)專有名稱發(fā)布一份證書，并綁定一個(gè)公鑰。
組織機(jī)構(gòu)可以把受信的根證書分發(fā)給所有的成員，這樣就可以使用公司的PKI系統(tǒng)了。像Firefox, IE, Opera, Safari 以及Google Chrome這些瀏覽器都預(yù)裝了一組CA根證書，所以可以直接使用這些主流CA發(fā)布的SSL證書。瀏覽器的開發(fā)者直接影響它的用戶對(duì)第三方的信任。FireFox就提供了一份csv/html格式的列表。
X.509還包括證書吊銷列表（CRL）實(shí)現(xiàn)標(biāo)準(zhǔn)，這是PKI系統(tǒng)經(jīng)常被忽略的方面。IETF批準(zhǔn)的檢查證書有效性的方法是在線證書狀態(tài)協(xié)議（OCSP），F(xiàn)irefox 3默認(rèn)情況下啟用OCSP檢查，從Vista開始的高版本W(wǎng)indows也是如此。
X.509證書的結(jié)構(gòu)是用ASN.1(Abstract Syntax Notation One：抽象語法標(biāo)記)來描述其數(shù)據(jù)結(jié)構(gòu)，并使用ASN1語法進(jìn)行編碼。
X.509 v3數(shù)字證書的結(jié)構(gòu)如下：
● Certificate 證書
● Version Number版本號(hào)
● Serial Number序列號(hào)
● ID Signature Algorithm ID簽名算法
● Issuer Name頒發(fā)者名稱
● Validity period 有效期
● Not before起始日期
● Not after截至日期
● Subject Name主題名稱
● Subject pbulic Key Info 主題公鑰信息
● Public Key Algorithm公鑰算法
● Subject Public Key主題公鑰
● Issuer Unique Identifier (optional)頒發(fā)者唯一標(biāo)識(shí)符（可選）
● Subject Unique Identifier (optional)主題唯一標(biāo)識(shí)符（可選）
● Extensions (optional)證書的擴(kuò)展項(xiàng)（可選）
…
● Certificate Sigature Algorithm證書簽名算法
● Certificate Signature證書的簽名
所有擴(kuò)展都有一個(gè)ID，由object identifier來表達(dá)，它是一個(gè)集合，并且有一個(gè)標(biāo)記指示這個(gè)擴(kuò)展是不是決定性的。證書使用時(shí)，如果發(fā)現(xiàn)一份證書帶有決定性標(biāo)記的擴(kuò)展，而這個(gè)系統(tǒng)并不清楚該擴(kuò)展的用途，就要拒絕使用它。但對(duì)于非決定性的擴(kuò)展，不認(rèn)識(shí)可以予以忽略。RFC 1422給出了v1的證書結(jié)構(gòu)，ITU-T在v2里增加了頒發(fā)者和主題唯一標(biāo)識(shí)符，從而可以在一段時(shí)間后重用。重用的一個(gè)例子是當(dāng)一個(gè)CA破產(chǎn)了，它的名稱也在公共列表里清除掉了，一段時(shí)間之后另一個(gè)CA可以用相同的名稱來注冊，即使它與之前的并沒有任何瓜葛。不過IETF并不建議重用同名注冊。另外v2也沒有在Internet里大范圍的使用。v3引入了擴(kuò)展，CA使用擴(kuò)展來發(fā)布一份特定使用目的的證書（比如說僅用于代碼簽名）。
對(duì)于所有的版本，同一個(gè)CA頒發(fā)的證書序列號(hào)都必須是唯一的。
RFC 5280（及后續(xù)版本）定義了數(shù)字證書擴(kuò)展項(xiàng)，用于指示如何使用證書。它們大多來自joint-iso-ccitt（2）ds（5）id-ce（29）OID。第4.2.1節(jié)中定義的一些最常見的是：
● Basic Constraints,{id ce 19}，用于指示一份證書是不是CA證書。
● Key Usage, {id ce 15}，指定了這份證書包含的公鑰可以執(zhí)行的密碼操作，例如只能用于簽名，但不能用來加密。
●Extended Key Usage{id ce 37}，典型用法是指定葉子證書中的公鑰的使用目的。它包括一系列的OID，每一個(gè)都指定一種用途。例如{id pkix 31}表示用于服務(wù)器端的TLS/SSL連接；{id pkix 34}表示密鑰可以用于保護(hù)電子郵件。
通常情況下，當(dāng)一份證書有多個(gè)限制用途的擴(kuò)展時(shí)，所有限制條件都應(yīng)該滿足才可以使用。RFC 5280有一個(gè)例子，該證書同時(shí)含有keyUsage和extendedKeyUsage，這樣的證書只能用在被這兩個(gè)擴(kuò)展指定的用途，例如網(wǎng)絡(luò)安全服務(wù)決定證書用途時(shí)，會(huì)同時(shí)對(duì)這個(gè)擴(kuò)展進(jìn)行判斷。
1-3）證書文件擴(kuò)展名
X.509證書有幾種常用的文件擴(kuò)展名，但要注意：其中一些擴(kuò)展名也有其它用途，就是說具有這個(gè)擴(kuò)展名的文件可能并不是證書，比如說可能只是保存了私鑰。
● .pem：（隱私增強(qiáng)型電子郵件），DER編碼的證書再進(jìn)行Base64編碼，數(shù)據(jù)存放于“--- BEGIN CERTIFICATE ---”和“ --- END CERTIFICATE ---”之間
● .cer，.crt，.der：通常采用二進(jìn)制DER形式，但Base64編碼也很常見
● .p7b，.p7c-PKC＃7：SignedData結(jié)構(gòu)，沒有數(shù)據(jù)，僅有證書或CRL
● .p12-PKCS＃12：可以包含證書（公鑰），也可同時(shí)包含受密碼保護(hù)的私鑰
● .pfx ：PKCS＃12的前身（通常用PKCS＃12格式，例如IIS產(chǎn)生的PFX文件）
PKCS#7是簽名或加密數(shù)據(jù)的格式標(biāo)準(zhǔn)，官方稱之為容器。由于證書是可驗(yàn)真的簽名數(shù)據(jù)，所以可以用SignedData結(jié)構(gòu)表述。.P7C文件是退化的SignedData結(jié)構(gòu)，沒有包括簽名的數(shù)據(jù)。
PKCS＃12從個(gè)人信息交換（PFX）標(biāo)準(zhǔn)發(fā)展而來，用于在單個(gè)文件中交換公共和私有對(duì)象。
證書鏈（也就是RFC 5280里的證書路徑）指的是以最終實(shí)體證書開頭，后跟一個(gè)或多個(gè)CA證書，且通常最后一個(gè)是自簽名證書，具有如下關(guān)系：
1.除了鏈上的最后一個(gè)證書外，每個(gè)證書的頒發(fā)者等于其后一個(gè)證書的主題（主題就是使用者）。
2.除了鏈上的最后一個(gè)證書外，每個(gè)證書都是由其后的一個(gè)證書簽名。
3.最后一個(gè)證書是信任錨：由于是通過某種可信的過程得到的，所以你可以信任它。
證書鏈用來檢查目標(biāo)證書（鏈中的第一個(gè)證書）中包含的公鑰和其他數(shù)據(jù)是否屬于其主題。檢查是這么做的，用證書鏈中的下一個(gè)證書的公鑰來驗(yàn)證它的簽名，一直檢查到證書鏈的尾端，由于最后一個(gè)證書是信任錨，成功達(dá)到該證書將證明目標(biāo)證書可以信任。
上段中的描述是根據(jù)RFC5280定義的認(rèn)證路徑驗(yàn)證過程的簡化過程，實(shí)際上涉及額外的檢查，例如驗(yàn)證證書的有效日期、查找CRL等。
在研究證書鏈的構(gòu)建和驗(yàn)證方式時(shí)，需要特別注意的是，具體的證書可以是不同的證書鏈的一部分（鏈上的所有證書都有效）。 這是因?yàn)榭梢詾橄嗤闹黝}和公鑰生成多個(gè)CA證書，但使用不同的私鑰（來自不同的CA或來自同一CA的不同的私鑰）進(jìn)行簽名。 因此，盡管單個(gè)X.509證書只能具有一個(gè)頒發(fā)者和一個(gè)CA簽名，但是它可以有效地鏈接到多個(gè)證書，從而建立完全不同的證書鏈。 這對(duì)于PKI與其他應(yīng)用程序之間的交叉認(rèn)證至關(guān)重要，詳見以下示例。
下圖每個(gè)框代表一個(gè)證書，主題以粗體顯示，A→B表示“ A由B簽名”（或更準(zhǔn)確地說，A由B包含公鑰相對(duì)應(yīng)的私鑰簽名），具有相同顏色（非白色/透明）的證書包含相同的公鑰。
例1：兩個(gè)PKI之間，在根證書頒發(fā)機(jī)構(gòu)（CA）級(jí)別上進(jìn)行交叉認(rèn)證
為了讓PKI 2的用戶證書也得到PKI 1的信任，CA1簽署包含CA2公鑰的證書cert2.1，此時(shí)cert2和cert2.1具體相同的主題及公鑰，cert2.2 (User 2)就有了兩條合法的證書鏈："cert2.2 → cert2" and "cert2.2 → cert2.1 → cert1"。
CA2也可以生成類似的包含有CA1公鑰的證書cert1.1，以便PKI 1的用戶(比如User 1)的證書能在PKI 2得到認(rèn)證。
例2：CA證書更新
閱讀這篇文章：了解認(rèn)證路徑構(gòu)建（PDF，PKI論壇，2002）
證書頒發(fā)者為了從舊的私鑰平滑地轉(zhuǎn)移到新的私鑰，他可以頒發(fā)兩個(gè)證書，其中一個(gè)是新的私鑰對(duì)舊的公鑰進(jìn)行簽名，另一個(gè)是舊的私鑰對(duì)新的公鑰的簽名，這兩個(gè)證書都是自頒發(fā)的，但都不是自簽名。注：另外還存在新舊兩個(gè)自簽名證書。
假設(shè)cert1和cert3包含相同的公鑰（舊的公鑰），對(duì)于cert5來說有兩條合法的證書鏈，cert5 → cert1 和 cert5 → cert3 → cert2, cert6的情況也類似。這樣就允許老的用戶證書可以在新舊兩個(gè)根證書之間平滑轉(zhuǎn)移。
以下是維基百科網(wǎng)站W(wǎng)ikipedia.org和其他幾家Wikipedia網(wǎng)站的X.509證書解碼實(shí)例，由GlobalSign發(fā)布，它的頒發(fā)者字段（Subject）將Wikipedia描述為一個(gè)組織，Subject Alternative Name字段描述可以使用的主機(jī)名。Subject Public Key Info字段包含一個(gè)ECDSA公鑰，而底部的簽名由GlobalSign的RSA私鑰生成。
3-1）最終實(shí)體證書
網(wǎng)摘：最終實(shí)體證書就是大家通常說的用戶證書，有別于CA證書，最終實(shí)體證書中的證書主體是不能使用證書所對(duì)應(yīng)的私鑰簽發(fā)證書的。最終實(shí)體與CA是兩個(gè)相對(duì)的概念：CA可以利用其私鑰簽發(fā)證書，而最終實(shí)體不能。雖然在X.509標(biāo)準(zhǔn)中并未明確定義最終實(shí)體證書，但是定義了“最終實(shí)體公鑰證書吊銷列表 （End-entity public-key certificate revocation list）”的概念，由此可見最終實(shí)體證書就是指用戶證書。最終實(shí)體可以是各種類型的實(shí)體，如自然人、組織機(jī)構(gòu)、設(shè)備、Web服務(wù)器等。
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: ...
要驗(yàn)證此最終實(shí)體證書，需要一個(gè)與其頒發(fā)者和頒發(fā)機(jī)構(gòu)密鑰標(biāo)識(shí)符（Authority Key Identifier）匹配的中間證書：
Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2 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
在TLS連接中，作為握手過程的一部分，正確配置的服務(wù)器將提供該中間層，但也可以通過從最終實(shí)體證書中提取“ CA Issuers” URL來檢索中間證書。
3-2）中間證書
網(wǎng)摘：什么是中間證書？
中間證書用作根證書的替代。我們使用中間證書作為代理，因?yàn)槲覀儽仨殞⒏C書保存在眾多安全層之后，以確保其密鑰絕對(duì)不可訪問。由于根證書簽署了中間證書，因此中間證書可用于簽署客戶安裝和維護(hù)的SSL“信任鏈”。
注意：如果不使用已頒發(fā)的SSL證書安裝中間證書，則可能無法建立可信鏈證書。這意味著，當(dāng)訪問者試圖訪問您的網(wǎng)站時(shí)，他們可能會(huì)收到一個(gè)“安全警報(bào)”錯(cuò)誤，指示“安全證書是由您未選擇信任的公司頒發(fā)的…”面對(duì)這樣的警告，潛在客戶很可能會(huì)將其業(yè)務(wù)轉(zhuǎn)移到其他地方。
以下是中間證書的實(shí)例，此證書被CA根證書簽署，并簽署了上面的最終實(shí)體證書。
注意：此中間證書的subject字段與它所簽署的最終實(shí)體證書的issuer字段相同、中間證書的subject key identifier（主題密鑰標(biāo)識(shí)符）字段與最終實(shí)體證書的的authority key identifier（頒發(fā)者的密鑰標(biāo)識(shí)符）字段相同。
Certificate: Data: Version: 3 (0x2) Serial Number: 04:00:00:00:00:01:44:4e:f0:42:47 Signature Algorithm: sha256WithRSAEncryption Issuer: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA Validity Not Before: Feb 20 10:00:00 2014 GMT Not After : Feb 20 10:00:00 2024 GMT Subject: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2 Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:c7:0e:6c:3f:23:93:7f:cc:70:a5:9d:20:c3:0e: ... Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Subject Key Identifier: 96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C X509v3 Certificate Policies: Policy: X509v3 Any Policy CPS: https://www.globalsign.com/repository/ X509v3 CRL Distribution Points: Full Name: URI:http://crl.globalsign.net/root.crl Authority Information Access: OCSP - URI:http://ocsp.globalsign.com/rootr1 X509v3 Authority Key Identifier: keyid:60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B Signature Algorithm: sha256WithRSAEncryption 46:2a:ee:5e:bd:ae:01:60:37:31:11:86:71:74:b6:46:49:c8: ...
3-3）根證書
以下是證書頒發(fā)機(jī)構(gòu)的自簽名根證書示例，Issuer（頒發(fā)者字段）和Subject（主題，使用者字段）是相同的，能夠使用自己的公鑰對(duì)簽名進(jìn)行驗(yàn)證，信任鏈的驗(yàn)證必須在此結(jié)束。如果驗(yàn)證程序在其信任存儲(chǔ)中有此根證書，就可以認(rèn)為在TLS連接中使用的最終實(shí)體證書是可信的。否則，最終實(shí)體證書被視為不可信。
Certificate: Data: Version: 3 (0x2) Serial Number: 04:00:00:00:00:01:15:4b:5a:c3:94 Signature Algorithm: sha1WithRSAEncryption Issuer: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA Validity Not Before: Sep 1 12:00:00 1998 GMT Not After : Jan 28 12:00:00 2028 GMT Subject: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:da:0e:e6:99:8d:ce:a3:e3:4f:8a:7e:fb:f1:8b: ... Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE X509v3 Subject Key Identifier: 60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B Signature Algorithm: sha1WithRSAEncryption d6:73:e7:7c:4f:76:d0:8d:bf:ec:ba:a2:be:34:c5:28:32:b5:
Bruce Schneier，Peter Gutmann和其他安全專家發(fā)表了許多有關(guān)PKI問題的出版物。
4-1）架構(gòu)缺陷
將無效的證書列入黑名單（使用CRL和OCSP）。
PKI的魅力之一是脫機(jī)功能，但如果客戶端僅使用CRL來判斷證書的有效性，在脫機(jī)的情況下就會(huì)出現(xiàn)誤判，因?yàn)楫?dāng)CRL不可用時(shí)，大多數(shù)客戶端都會(huì)信任證書，于是攻.擊者可以通過切斷信道來禁用CRL。谷歌（Google）的亞當(dāng)?蘭利（Adam Langley）曾表示，CRL軟故障檢查就像一條安全帶，只有在發(fā)生事故時(shí)才起作用。
● CRL的尺寸較大且分布模式復(fù)雜，因此它不是一個(gè)很好的選擇，
● OCSP語義模糊，缺乏歷史撤銷狀態(tài)；
● 未解決根證書吊銷的問題
● 聚合問題：身份聲明（通過標(biāo)識(shí)符進(jìn)行身份驗(yàn)證）、屬性聲明（提交一包經(jīng)過審核的屬性）和策略聲明組合在一個(gè)容器中，這會(huì)引發(fā)隱私、策略映射和維護(hù)問題。
● 委派問題：從技術(shù)上講，CA無法限制下級(jí)CA在有限的名稱空間或?qū)傩约忸C發(fā)證書；X.509的此功能未被使用。因此，互聯(lián)網(wǎng)上存在大量的CA，對(duì)它們進(jìn)行分類和策略是一項(xiàng)不可完成的任務(wù)，一個(gè)組織內(nèi)部的授權(quán)不能像一般的商業(yè)慣例那樣處理。
● 聯(lián)合身份驗(yàn)證問題：證書鏈?zhǔn)菑膶貱A、橋接CA和交叉簽名的結(jié)果，這使得驗(yàn)證復(fù)雜且處理時(shí)間上昂貴、路徑驗(yàn)證語義可能不明確。具有第三方受信任方的層次結(jié)構(gòu)是唯一的模型。如果已經(jīng)建立了雙邊信任關(guān)系，這將很不方便。
為主機(jī)名頒發(fā)擴(kuò)展驗(yàn)證（EV）證書不會(huì)阻止頒發(fā)對(duì)同一主機(jī)名較低驗(yàn)證證書的頒發(fā)，這意味著較高的EV驗(yàn)證級(jí)別無法抵御中間人攻.擊。
如果是主體而不是依賴方購買證書，通常會(huì)使用最便宜的頒發(fā)者，頒發(fā)者出于成本考慮，往往采用擴(kuò)展驗(yàn)證證書來解決問題，但是在安全專家看來，信任價(jià)值正在下降。
● 證書頒發(fā)機(jī)構(gòu)否認(rèn)對(duì)用戶（包括主題或依賴方）的幾乎所有保證。
● 有效期應(yīng)用于限制密鑰強(qiáng)度被視為時(shí)間足夠，此參數(shù)被證書頒發(fā)機(jī)構(gòu)濫用以向客戶端收取擴(kuò)展費(fèi)。這給使用密鑰滾動(dòng)的用戶帶來了不必要的負(fù)擔(dān)。（沒看懂啥意思）
●“用戶使用未定義的認(rèn)證請(qǐng)求協(xié)議來獲取證書，該證書發(fā)布于不存在的目錄中的不明確位置，從而無有效手段來撤銷它?！?/p>
與所有企業(yè)一樣，CA受其經(jīng)營站點(diǎn)的法律管轄，并可能被迫損害其客戶和用戶的利益。情報(bào)機(jī)構(gòu)還利用了通過CA的法外妥協(xié)發(fā)出的虛假證書（例如DigiNotar）來進(jìn)行中間人攻.擊。另一個(gè)例子是荷蘭政府CA的撤銷請(qǐng)求，由于新的荷蘭法律自2018年1月1日起生效，為荷蘭情報(bào)和安全部門賦予了新的權(quán)力。
X.509實(shí)現(xiàn)存在設(shè)計(jì)缺陷、錯(cuò)誤、對(duì)標(biāo)準(zhǔn)的不同解釋以及不同標(biāo)準(zhǔn)的互操作性問題，一些問題是：
● 許多實(shí)現(xiàn)關(guān)閉吊銷檢查：
● 策略被視為障礙，沒有得到執(zhí)行
● 如果默認(rèn)情況下在所有瀏覽器（包括代碼簽名）中都打開了它，可能會(huì)破壞基礎(chǔ)結(jié)構(gòu)
● DN很復(fù)雜且不容易理解（缺乏規(guī)范化、國際化問題……）
● RFC822名稱有2種表示法
● 幾乎不支持名稱和策略約束
● keyUsage被忽略，使用列表中的第一個(gè)證書
● 自定義oid的實(shí)施很困難
● 不應(yīng)將屬性設(shè)為強(qiáng)制屬性，因?yàn)樗鼤?huì)使客戶端崩潰
● 未指定的屬性長度會(huì)導(dǎo)致特定于產(chǎn)品的限制
● X.509存在實(shí)現(xiàn)錯(cuò)誤，例如允許在證書中使用以空值結(jié)尾的字符串，或通過代碼注入攻.擊來偽造使用者名稱。
● 通過使用對(duì)象標(biāo)識(shí)符的0x80填充子標(biāo)識(shí)符，錯(cuò)誤的實(shí)現(xiàn)或通過使用客戶端瀏覽器的整數(shù)溢出，攻.擊者可以在CSR中包含一個(gè)未知屬性，CA會(huì)將其簽名，客戶端錯(cuò)誤地將其解釋為“CN”（OID = 2.5.4.3）
數(shù)字簽名系統(tǒng)依賴于密碼散列函數(shù)（哈希函數(shù)）的安全性。如果公鑰基礎(chǔ)結(jié)構(gòu)（PKI）使用了不再安全的哈希函數(shù)，攻.擊者可以利用哈希函數(shù)中的弱點(diǎn)來偽造證書。具體來說，如果攻.擊者能夠?qū)崿F(xiàn)“哈希碰撞”，他們可以先說服CA用看似無害的內(nèi)容簽名證書，但這些內(nèi)容的哈希與攻.擊者創(chuàng)建的另一組惡意的證書內(nèi)容的哈希相同，然后，攻.擊者可以將CA提供的簽名附加到其惡意證書之中，從而生成“似乎由CA簽名”的惡意證書。由于惡意證書內(nèi)容由攻.擊者定制，因此它們的有效日期或主機(jī)名可能與無害證書不同；惡意證書甚至可以包含“CA:true”字段，從而使其能夠頒發(fā)其他受信任證書。
● 基于MD2的證書使用了很長時(shí)間，容易受到預(yù)映像攻.擊。由于根證書已經(jīng)有一個(gè)自簽名，攻.擊者可以使用此簽名并將其用于中間證書。
● 2005年，Arjen Lenstra和Benne de Weger演示了“如何使用哈希碰撞“構(gòu)造兩個(gè)X.509證書，這兩個(gè)證書包含相同的簽名，并且只在公鑰上不同，這是通過對(duì)MD5散列函數(shù)的碰撞攻.擊實(shí)現(xiàn)的。
● 2008年，Alexander Sotirov和Marc Stevens在Chaos Communication Congress上提出了一個(gè)實(shí)用的攻.擊，基于RapidSSL仍在發(fā)布基于MD5的X.509證書這一事實(shí)，他們創(chuàng)建了一個(gè)被所有普通瀏覽器接受的流氓證書頒發(fā)機(jī)構(gòu)。
● 2009年4月，在歐洲密碼學(xué)會(huì)議上，麥格理大學(xué)（Macquarie University）的澳大利亞研究人員提出了“自動(dòng)差分路徑搜索SHA-1”，研究人員能夠推導(dǎo)出一種將碰撞的可能性增加了幾個(gè)數(shù)量級(jí)的方法。
● 2017年2月，由Marc Stevens領(lǐng)導(dǎo)的一組研究人員制造了一次SHA-1碰撞，證明了SHA-1的弱點(diǎn)。
利用哈希碰撞來偽造X.509簽名的前提是，攻.擊者能夠預(yù)測證書頒發(fā)機(jī)構(gòu)將要簽名的數(shù)據(jù)。通過在CA簽署的證書中生成一個(gè)隨機(jī)因素（通常是序列號(hào)）可以在某種程度上緩解這種情況。自2011年以來，CA /瀏覽器論壇已在其基準(zhǔn)要求第7.1節(jié)中要求序列號(hào)熵。
所以，序列號(hào)是作為一個(gè)隨機(jī)干擾源而存在，它是保密的，在簽署證書之前不能對(duì)外泄露。
自2016年1月1日起，基線要求禁止使用SHA-1頒發(fā)證書。截至2017年初，Chrome 和Firefox拒絕使用SHA-1的證書。截至2017年5月，Edge和Safari都在拒絕SHA-1證書，非瀏覽器的X.509驗(yàn)證程序尚未拒絕SHA-1證書。
5）PKCS標(biāo)準(zhǔn)概述
在密碼學(xué)里，PKCS代表“公鑰密碼學(xué)標(biāo)準(zhǔn)”。這是一組由RSA Security Inc.設(shè)計(jì)和發(fā)布的公鑰密碼標(biāo)準(zhǔn)，始于20世紀(jì)90年代初，該公司發(fā)布這些標(biāo)準(zhǔn)是為了推廣使用他們擁有專利的密碼技術(shù)，如RSA算法、Schnorr簽名算法和其他一些算法。盡管不是行業(yè)標(biāo)準(zhǔn)（因?yàn)樵摴颈Ａ袅藢?duì)它們的控制權(quán)），但近年來某些標(biāo)準(zhǔn)已經(jīng)開始進(jìn)入IETF和PKIX工作組等相關(guān)標(biāo)準(zhǔn)化組織的“標(biāo)準(zhǔn)跟蹤”過程。
● PKCS＃1 2.2 RSA加密標(biāo)準(zhǔn)參見RFC8017。定義了RSA公鑰和私鑰（以明文編碼的ASN.1）的數(shù)學(xué)屬性和格式，以及執(zhí)行RSA加密、解密和生成及驗(yàn)證簽名的基本算法和編碼/填充方案。
● PKCS＃2-已撤回，從2010年起不再有效，涵蓋了RSA對(duì)消息摘要的加密，隨后合并到PKCS＃1中。
● PKCS＃3 1.4 Diffie-Hellman密鑰協(xié)商標(biāo)準(zhǔn)，一種加密協(xié)議，它允許彼此不具有先驗(yàn)知識(shí)的雙方在不安全的通信信道上共同建立共享的秘密密鑰。
● PKCS＃4-已撤回自2010年起不再有效，涵蓋了RSA密鑰語法，隨后合并到PKCS＃1中。
● PKCS＃5 2.1基于Password的加密標(biāo)準(zhǔn)，參見RFC 8018和PBKDF2。
● PKCS＃6 1.5擴(kuò)展證書語法標(biāo)準(zhǔn)，定義對(duì)舊的v1 X.509證書規(guī)范的擴(kuò)展，被v3淘汰。
● PKCS＃7 1.5加密消息語法標(biāo)準(zhǔn)，請(qǐng)參閱RFC2315。用于在PKI下對(duì)消息進(jìn)行簽名和/或加密。也用于證書分發(fā)（例如作為對(duì)PKCS＃10消息的響應(yīng)），形成了S /MIME的基礎(chǔ)，S /MIME于2010年基于RFC 5652（一種更新的加密消息語法標(biāo)準(zhǔn)（CMS））建立，通常用于單點(diǎn)登錄。
● PKCS＃8 1.2私鑰信息語法標(biāo)準(zhǔn)，請(qǐng)參見RFC5958。用于攜帶私鑰證書密鑰對(duì)（加密或未加密）。
● PKCS＃9 2.0選定的屬性類型[，請(qǐng)參見RFC2985。定義選定的屬性類型，以便在PKCS＃6擴(kuò)展證書、PKCS＃7數(shù)字簽名消息、PKCS＃8私鑰信息和PKCS＃10證書簽名請(qǐng)求中使用。
● PKCS＃10 1.7認(rèn)證請(qǐng)求標(biāo)準(zhǔn)，請(qǐng)參閱RFC2986。發(fā)送給認(rèn)證機(jī)構(gòu)以請(qǐng)求公鑰證書的消息格式，請(qǐng)參閱證書簽名請(qǐng)求。
● PKCS＃11 2.40密碼令牌接口，也稱為“ Cryptoki”。定義密碼令牌通用接口的API（另請(qǐng)參閱硬件安全模塊）。常用于單點(diǎn)登錄，公共密鑰加密和磁盤加密[10]系統(tǒng)。RSA Security已將PKCS＃11標(biāo)準(zhǔn)的進(jìn)一步開發(fā)移交給了OASIS PKCS 11技術(shù)委員會(huì)。
● PKCS＃12 1.1個(gè)人信息交換語法標(biāo)準(zhǔn)，請(qǐng)參閱RFC7292。定義一種文件格式，個(gè)人信息交換語法標(biāo)準(zhǔn)[11]見RFC 7292。定義一種文件格式，通常用于存儲(chǔ)私鑰和附帶的公鑰證書，并使用基于Password的對(duì)稱密鑰進(jìn)行保護(hù)。PFX是PKCS#12的前身。
此容器格式可以包含多個(gè)嵌入式對(duì)象，例如多個(gè)證書。通常使用密碼進(jìn)行保護(hù)/加密?？捎米鱆ava密鑰存儲(chǔ)的格式，并在Mozilla Firefox中建立客戶端身份驗(yàn)證證書，可供Apache Tomcat使用。
簡單的說，PKCS#12可以包含證書（公鑰），也可以包含受密碼保護(hù)的私鑰
● PKCS＃13 橢圓曲線密碼技術(shù)標(biāo)準(zhǔn)（已廢棄，唯一的參考是1998年的提案）
● PKCS＃14 偽隨機(jī)數(shù)生成（已廢棄，沒有文檔）
● PKCS＃15 1.1加密令牌信息格式標(biāo)準(zhǔn)，定義了一個(gè)標(biāo)準(zhǔn)，允許加密令牌的用戶向應(yīng)用程序標(biāo)識(shí)自己，而與應(yīng)用程序的Cryptoki實(shí)現(xiàn)（PKCS＃11）或其他API無關(guān)。RSA放棄了該標(biāo)準(zhǔn)中與IC卡相關(guān)的部分，并改為ISO / IEC 7816-15。
本指南演示如何使用OpenSSL命令行工具充當(dāng)您自己的證書頒發(fā)機(jī)構(gòu)（CA）。這在許多情況下都很有用，例如頒發(fā)服務(wù)器證書以保護(hù)intranet網(wǎng)站，或向客戶端頒發(fā)證書以允許客戶端向服務(wù)器進(jìn)行身份驗(yàn)證。
OpenSSL是一個(gè)免費(fèi)的開源加密庫，它提供了一些用于處理數(shù)字證書的命令行工具，其中一些工具（也就是命令）可以充當(dāng)證書頒發(fā)機(jī)構(gòu)。
證書頒發(fā)機(jī)構(gòu)是為數(shù)字證書簽名的實(shí)體。許多網(wǎng)站需要讓其客戶知道連接是安全的，因此他們向國際證書頒發(fā)機(jī)構(gòu)（CA）支付費(fèi)用，以為其域簽署證書。
在某些情況下，自己做自己CA（而不是向DigiCert這樣的CA付錢）更有意義，比如保護(hù)intranet網(wǎng)站的安全，或向客戶端頒發(fā)證書以允許客戶端向服務(wù)器進(jìn)行身份驗(yàn)證。
充當(dāng)證書頒發(fā)機(jī)構(gòu)意味著要處理密鑰對(duì)之中的私鑰和公鑰證書。
我們要?jiǎng)?chuàng)建的第一個(gè)密鑰對(duì)就是根對(duì)。這包括根密鑰（ca.key.pem）和根證書（ca.cert.pem）。這個(gè)“根對(duì)”構(gòu)成了你的CA的身份。
通常，根CA不會(huì)直接為服務(wù)器或客戶端證書簽名，根CA僅用于創(chuàng)建一個(gè)或多個(gè)中間CA，這些中間CA被根CA信任，并代表根CA簽署證書，這是最佳實(shí)踐，它允許根密鑰保持脫機(jī)狀態(tài)并盡可能減少使用的次數(shù)，因?yàn)閷?duì)根的任何威脅都是災(zāi)難性的。
注意：
最佳實(shí)踐是在安全的環(huán)境中創(chuàng)建根對(duì)。理想情況下，該計(jì)算機(jī)應(yīng)該是完全加密并且空氣隔離（含義是沒有任何網(wǎng)絡(luò)接口的機(jī)器，即不能通過外部網(wǎng)絡(luò)連接），可以考慮卸載無線網(wǎng)卡，并用膠水塞滿以太網(wǎng)口。
6-2-1）準(zhǔn)備目錄
mkdir /root/ca 創(chuàng)建目錄結(jié)構(gòu)。index.txt和serial文件充當(dāng)平面文件數(shù)據(jù)庫，以跟蹤已簽名的證書。 cd /root/ca mkdir certs crl newcerts private chmod 700 private touch index.txt echo 1000 > serial
您必須創(chuàng)建一個(gè)配置文件以供OpenSSL使用。
將根CA配置文件從Appendix復(fù)制到/root/CA/openssl.cnf，其中的[ca]部分為必填項(xiàng)，這里告訴OpenSSL使用[CA_default]部分中的選項(xiàng)。
重慶分公司
重慶分公司
