英文原文：https://blog.csdn.net/blue0bird/article/details/78656536
創(chuàng)新互聯(lián)于2013年成立，公司以成都網(wǎng)站設計、做網(wǎng)站、系統(tǒng)開發(fā)、網(wǎng)絡推廣、文化傳媒、企業(yè)宣傳、平面廣告設計等為主要業(yè)務，適用行業(yè)近百種。服務企業(yè)客戶超過千家，涉及國內(nèi)多個省份客戶。擁有多年網(wǎng)站建設開發(fā)經(jīng)驗。為企業(yè)提供專業(yè)的網(wǎng)站建設、創(chuàng)意設計、宣傳推廣等服務。 通過專業(yè)的設計、獨特的風格，為不同客戶提供各種風格的特色服務。
????????????????????????? ?https://jamielinux.com/docs/openssl-certificate-authority/index.html
本文源于兩篇英文文檔，將其合二為一，翻譯過程參考了網(wǎng)上的其它翻譯以求更加準確，再此對這些翻譯文檔的作者表示感謝！
文中介紹的OpenSSL版本較老，與現(xiàn)有的版本有很多不符之處，但萬變不離其宗，核心原理還是很有參考價值的。
X.509標準是密碼學里公鑰證書的格式標準。X.509 證書己應用在包括TLS/SSL（WWW萬維網(wǎng)安全瀏覽的基石）在內(nèi)的眾多 Internet協(xié)議里，同時它也有很多非在線的應用場景，比如電子簽名服務。X.509證書含有公鑰和標識（主機名、組織或個人），并由證書頒發(fā)機構（CA）簽名（或自簽名）。對于一份經(jīng)由可信的證書簽發(fā)機構簽名（或者可以通過其它方式驗證）的證書，證書的擁有者就可以用證書及相應的私鑰來創(chuàng)建安全的通信，以及對文檔進行數(shù)字簽名。
X.509最早與X.500一起發(fā)布于1988年7月3日，它假定頒發(fā)證書的證書頒發(fā)機構（CA）具有嚴格的層次結構。這與Web信任模型（如PGP）形成了鮮明對比，因為PGP方案是任何人都以簽名（而不僅僅是地位特殊的CA），從而證明其他人的密鑰證書的有效性。X.509 V3證書的設計非常靈活，除了對網(wǎng)橋拓撲架構網(wǎng)絡的支持，還可以支持用于點對點方式的Mesh網(wǎng)，類似于OpenPGP那樣的web信任機制，不過這樣方式在2004年之前很少使用。
X.500系統(tǒng)僅由主權國家實施，以實現(xiàn)國家身份信息共享條約的實施目的，而IETF的公鑰基礎設施（X.509）或PKIX工作組已對該標準進行了調整，以適應更靈活的互聯(lián)網(wǎng)組織結構。事實上X.509認證指的是RFC5280里定義的X.509 v3，包括對IETF的PKIX證書和證書吊銷列表（CRL Profile），通常也稱為公鑰基礎設施。
在X.509系統(tǒng)中，證書申請者通過發(fā)起“證書簽名請求（CSR）”來得到一份被簽名的證書。為此，它需要生成一個密鑰對，然后用其中的私鑰對CSR簽名（私鑰本身要妥善保存，對外保密），CSR包含申請人的身份信息、用于驗真CSR的申請人的公鑰，以及所請求證書的專有名稱（DN），CSR還可能帶有CA要求的其它有關身份證明的信息，然后CA對這個專有名稱發(fā)布一份證書，并綁定一個公鑰。
組織機構可以把受信的根證書分發(fā)給所有的成員，這樣就可以使用公司的PKI系統(tǒng)了。像Firefox, IE, Opera, Safari 以及Google Chrome這些瀏覽器都預裝了一組CA根證書，所以可以直接使用這些主流CA發(fā)布的SSL證書。瀏覽器的開發(fā)者直接影響它的用戶對第三方的信任。FireFox就提供了一份csv/html格式的列表。
X.509還包括證書吊銷列表（CRL）實現(xiàn)標準，這是PKI系統(tǒng)經(jīng)常被忽略的方面。IETF批準的檢查證書有效性的方法是在線證書狀態(tài)協(xié)議（OCSP），F(xiàn)irefox 3默認情況下啟用OCSP檢查，從Vista開始的高版本W(wǎng)indows也是如此。
X.509證書的結構是用ASN.1(Abstract Syntax Notation One：抽象語法標記)來描述其數(shù)據(jù)結構，并使用ASN1語法進行編碼。
X.509 v3數(shù)字證書的結構如下：
●?????????Certificate?證書
●?Version Number版本號
●?Serial Number序列號
●?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ā)者唯一標識符（可選）
●?Subject Unique Identifier (optional)主題唯一標識符（可選）
●?Extensions (optional)證書的擴展項（可選）
…
●?Certificate Sigature Algorithm證書簽名算法
●?Certificate Signature證書的簽名
所有擴展都有一個ID，由object identifier來表達，它是一個集合，并且有一個標記指示這個擴展是不是決定性的。證書使用時，如果發(fā)現(xiàn)一份證書帶有決定性標記的擴展，而這個系統(tǒng)并不清楚該擴展的用途，就要拒絕使用它。但對于非決定性的擴展，不認識可以予以忽略。RFC 1422給出了v1的證書結構，ITU-T在v2里增加了頒發(fā)者和主題唯一標識符，從而可以在一段時間后重用。重用的一個例子是當一個CA破產(chǎn)了，它的名稱也在公共列表里清除掉了，一段時間之后另一個CA可以用相同的名稱來注冊，即使它與之前的并沒有任何瓜葛。不過IETF并不建議重用同名注冊。另外v2也沒有在Internet里大范圍的使用。v3引入了擴展，CA使用擴展來發(fā)布一份特定使用目的的證書（比如說僅用于代碼簽名）。
對于所有的版本，同一個CA頒發(fā)的證書序列號都必須是唯一的。
RFC 5280（及后續(xù)版本）定義了數(shù)字證書擴展項，用于指示如何使用證書。它們大多來自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，每一個都指定一種用途。例如{id pkix 31}表示用于服務器端的TLS/SSL連接；{id pkix 34}表示密鑰可以用于保護電子郵件。
通常情況下，當一份證書有多個限制用途的擴展時，所有限制條件都應該滿足才可以使用。RFC 5280有一個例子，該證書同時含有keyUsage和extendedKeyUsage，這樣的證書只能用在被這兩個擴展指定的用途，例如網(wǎng)絡安全服務決定證書用途時，會同時對這個擴展進行判斷。
1-3）證書文件擴展名
X.509證書有幾種常用的文件擴展名，但要注意：其中一些擴展名也有其它用途，就是說具有這個擴展名的文件可能并不是證書，比如說可能只是保存了私鑰。
●?.pem：（隱私增強型電子郵件），DER編碼的證書再進行Base64編碼，數(shù)據(jù)存放于“--- BEGIN CERTIFICATE ---”和“ --- END CERTIFICATE ---”之間
●?.cer，.crt，.der：通常采用二進制DER形式，但Base64編碼也很常見
●?.p7b，.p7c-PKC＃7：SignedData結構，沒有數(shù)據(jù)，僅有證書或CRL
●?.p12-PKCS＃12：可以包含證書（公鑰），也可同時包含受密碼保護的私鑰
●?.pfx ：PKCS＃12的前身（通常用PKCS＃12格式，例如IIS產(chǎn)生的PFX文件）
PKCS#7是簽名或加密數(shù)據(jù)的格式標準，官方稱之為容器。由于證書是可驗真的簽名數(shù)據(jù)，所以可以用SignedData結構表述。.P7C文件是退化的SignedData結構，沒有包括簽名的數(shù)據(jù)。
PKCS＃12從個人信息交換（PFX）標準發(fā)展而來，用于在單個文件中交換公共和私有對象。
證書鏈（也就是RFC 5280里的證書路徑）指的是以最終實體證書開頭，后跟一個或多個CA證書，且通常最后一個是自簽名證書，具有如下關系：
1.除了鏈上的最后一個證書外，每個證書的頒發(fā)者等于其后一個證書的主題（主題就是使用者）。
2.除了鏈上的最后一個證書外，每個證書都是由其后的一個證書簽名。
3.最后一個證書是信任錨：由于是通過某種可信的過程得到的，所以你可以信任它。
證書鏈用來檢查目標證書（鏈中的第一個證書）中包含的公鑰和其他數(shù)據(jù)是否屬于其主題。檢查是這么做的，用證書鏈中的下一個證書的公鑰來驗證它的簽名，一直檢查到證書鏈的尾端，由于最后一個證書是信任錨，成功達到該證書將證明目標證書可以信任。
上段中的描述是根據(jù)RFC5280定義的認證路徑驗證過程的簡化過程，實際上涉及額外的檢查，例如驗證證書的有效日期、查找CRL等。
在研究證書鏈的構建和驗證方式時，需要特別注意的是，具體的證書可以是不同的證書鏈的一部分（鏈上的所有證書都有效）。 這是因為可以為相同的主題和公鑰生成多個CA證書，但使用不同的私鑰（來自不同的CA或來自同一CA的不同的私鑰）進行簽名。 因此，盡管單個X.509證書只能具有一個頒發(fā)者和一個CA簽名，但是它可以有效地鏈接到多個證書，從而建立完全不同的證書鏈。 這對于PKI與其他應用程序之間的交叉認證至關重要，詳見以下示例。
下圖每個框代表一個證書，主題以粗體顯示，A→B表示“ A由B簽名”（或更準確地說，A由B包含公鑰相對應的私鑰簽名），具有相同顏色（非白色/透明）的證書包含相同的公鑰。
例1：兩個PKI之間，在根證書頒發(fā)機構（CA）級別上進行交叉認證
為了讓PKI 2的用戶證書也得到PKI 1的信任，CA1簽署包含CA2公鑰的證書cert2.1，此時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得到認證。
例2：CA證書更新
? ?閱讀這篇文章：了解認證路徑構建（PDF，PKI論壇，2002）
????????證書頒發(fā)者為了從舊的私鑰平滑地轉移到新的私鑰，他可以頒發(fā)兩個證書，其中一個是新的私鑰對舊的公鑰進行簽名，另一個是舊的私鑰對新的公鑰的簽名，這兩個證書都是自頒發(fā)的，但都不是自簽名。注：另外還存在新舊兩個自簽名證書。
假設cert1和cert3包含相同的公鑰（舊的公鑰），對于cert5來說有兩條合法的證書鏈，cert5 → cert1 和 cert5 → cert3 → cert2, cert6的情況也類似。這樣就允許老的用戶證書可以在新舊兩個根證書之間平滑轉移。?
? ? ? ? 以下是維基百科網(wǎng)站W(wǎng)ikipedia.org和其他幾家Wikipedia網(wǎng)站的X.509證書解碼實例，由GlobalSign發(fā)布，它的頒發(fā)者字段（Subject）將Wikipedia描述為一個組織，Subject Alternative Name字段描述可以使用的主機名。Subject Public Key Info字段包含一個ECDSA公鑰，而底部的簽名由GlobalSign的RSA私鑰生成。
? 3-1）最終實體證書
????????網(wǎng)摘：最終實體證書就是大家通常說的用戶證書，有別于CA證書，最終實體證書中的證書主體是不能使用證書所對應的私鑰簽發(fā)證書的。最終實體與CA是兩個相對的概念：CA可以利用其私鑰簽發(fā)證書，而最終實體不能。雖然在X.509標準中并未明確定義最終實體證書，但是定義了“最終實體公鑰證書吊銷列表 （End-entity public-key certificate revocation list）”的概念，由此可見最終實體證書就是指用戶證書。最終實體可以是各種類型的實體，如自然人、組織機構、設備、Web服務器等。
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: ?????????...
????????要驗證此最終實體證書，需要一個與其頒發(fā)者和頒發(fā)機構密鑰標識符（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連接中，作為握手過程的一部分，正確配置的服務器將提供該中間層，但也可以通過從最終實體證書中提取“ CA Issuers” URL來檢索中間證書。
3-2）中間證書
網(wǎng)摘：什么是中間證書？
? ? ? 中間證書用作根證書的替代。我們使用中間證書作為代理，因為我們必須將根證書保存在眾多安全層之后，以確保其密鑰絕對不可訪問。由于根證書簽署了中間證書，因此中間證書可用于簽署客戶安裝和維護的SSL“信任鏈”。
? ? ? ?注意：如果不使用已頒發(fā)的SSL證書安裝中間證書，則可能無法建立可信鏈證書。這意味著，當訪問者試圖訪問您的網(wǎng)站時，他們可能會收到一個“安全警報”錯誤，指示“安全證書是由您未選擇信任的公司頒發(fā)的…”面對這樣的警告，潛在客戶很可能會將其業(yè)務轉移到其他地方。
? ? ? ?以下是中間證書的實例，此證書被CA根證書簽署，并簽署了上面的最終實體證書。
? ? ? ?注意：此中間證書的subject字段與它所簽署的最終實體證書的issuer字段相同、中間證書的subject key identifier（主題密鑰標識符）字段與最終實體證書的的authority key identifier（頒發(fā)者的密鑰標識符）字段相同。
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ā)機構的自簽名根證書示例，Issuer（頒發(fā)者字段）和Subject（主題，使用者字段）是相同的，能夠使用自己的公鑰對簽名進行驗證，信任鏈的驗證必須在此結束。如果驗證程序在其信任存儲中有此根證書，就可以認為在TLS連接中使用的最終實體證書是可信的。否則，最終實體證書被視為不可信。
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ā)表了許多有關PKI問題的出版物。
? 4-1）架構缺陷
????????將無效的證書列入黑名單（使用CRL和OCSP）。
????????PKI的魅力之一是脫機功能，但如果客戶端僅使用CRL來判斷證書的有效性，在脫機的情況下就會出現(xiàn)誤判，因為當CRL不可用時，大多數(shù)客戶端都會信任證書，于是攻.擊者可以通過切斷信道來禁用CRL。谷歌（Google）的亞當?蘭利（Adam Langley）曾表示，CRL軟故障檢查就像一條安全帶，只有在發(fā)生事故時才起作用。
????????● CRL的尺寸較大且分布模式復雜，因此它不是一個很好的選擇，
????????● OCSP語義模糊，缺乏歷史撤銷狀態(tài)；
????????● 未解決根證書吊銷的問題
????????● 聚合問題：身份聲明（通過標識符進行身份驗證）、屬性聲明（提交一包經(jīng)過審核的屬性）和策略聲明組合在一個容器中，這會引發(fā)隱私、策略映射和維護問題。
????????● 委派問題：從技術上講，CA無法限制下級CA在有限的名稱空間或屬性集之外頒發(fā)證書；X.509的此功能未被使用。因此，互聯(lián)網(wǎng)上存在大量的CA，對它們進行分類和策略是一項不可完成的任務，一個組織內(nèi)部的授權不能像一般的商業(yè)慣例那樣處理。
????????● 聯(lián)合身份驗證問題：證書鏈是從屬CA、橋接CA和交叉簽名的結果，這使得驗證復雜且處理時間上昂貴、路徑驗證語義可能不明確。具有第三方受信任方的層次結構是唯一的模型。如果已經(jīng)建立了雙邊信任關系，這將很不方便。
????????為主機名頒發(fā)擴展驗證（EV）證書不會阻止頒發(fā)對同一主機名較低驗證證書的頒發(fā)，這意味著較高的EV驗證級別無法抵御中間人攻.擊。
????????如果是主體而不是依賴方購買證書，通常會使用最便宜的頒發(fā)者，頒發(fā)者出于成本考慮，往往采用擴展驗證證書來解決問題，但是在安全專家看來，信任價值正在下降。
????????● 證書頒發(fā)機構否認對用戶（包括主題或依賴方）的幾乎所有保證。
????????● 有效期應用于限制密鑰強度被視為時間足夠，此參數(shù)被證書頒發(fā)機構濫用以向客戶端收取擴展費。這給使用密鑰滾動的用戶帶來了不必要的負擔。（沒看懂啥意思）
????????●“用戶使用未定義的認證請求協(xié)議來獲取證書，該證書發(fā)布于不存在的目錄中的不明確位置，從而無有效手段來撤銷它?！?/p>
與所有企業(yè)一樣，CA受其經(jīng)營站點的法律管轄，并可能被迫損害其客戶和用戶的利益。情報機構還利用了通過CA的法外妥協(xié)發(fā)出的虛假證書（例如DigiNotar）來進行中間人攻.擊。另一個例子是荷蘭政府CA的撤銷請求，由于新的荷蘭法律自2018年1月1日起生效，為荷蘭情報和安全部門賦予了新的權力。
????????X.509實現(xiàn)存在設計缺陷、錯誤、對標準的不同解釋以及不同標準的互操作性問題，一些問題是：
????????● 許多實現(xiàn)關閉吊銷檢查：
????????● 策略被視為障礙，沒有得到執(zhí)行
????????● 如果默認情況下在所有瀏覽器（包括代碼簽名）中都打開了它，可能會破壞基礎結構
????????● DN很復雜且不容易理解（缺乏規(guī)范化、國際化問題……）
????????● RFC822名稱有2種表示法
????????● 幾乎不支持名稱和策略約束
????????● keyUsage被忽略，使用列表中的第一個證書
????????● 自定義oid的實施很困難
????????● 不應將屬性設為強制屬性，因為它會使客戶端崩潰
????????● 未指定的屬性長度會導致特定于產(chǎn)品的限制
????????● X.509存在實現(xiàn)錯誤，例如允許在證書中使用以空值結尾的字符串，或通過代碼注入攻.擊來偽造使用者名稱。
????????● 通過使用對象標識符的0x80填充子標識符，錯誤的實現(xiàn)或通過使用客戶端瀏覽器的整數(shù)溢出，攻.擊者可以在CSR中包含一個未知屬性，CA會將其簽名，客戶端錯誤地將其解釋為“CN”（OID = 2.5.4.3）
????????數(shù)字簽名系統(tǒng)依賴于密碼散列函數(shù)（哈希函數(shù)）的安全性。如果公鑰基礎結構（PKI）使用了不再安全的哈希函數(shù)，攻.擊者可以利用哈希函數(shù)中的弱點來偽造證書。具體來說，如果攻.擊者能夠實現(xiàn)“哈希碰撞”，他們可以先說服CA用看似無害的內(nèi)容簽名證書，但這些內(nèi)容的哈希與攻.擊者創(chuàng)建的另一組惡意的證書內(nèi)容的哈希相同，然后，攻.擊者可以將CA提供的簽名附加到其惡意證書之中，從而生成“似乎由CA簽名”的惡意證書。由于惡意證書內(nèi)容由攻.擊者定制，因此它們的有效日期或主機名可能與無害證書不同；惡意證書甚至可以包含“CA:true”字段，從而使其能夠頒發(fā)其他受信任證書。
????????● 基于MD2的證書使用了很長時間，容易受到預映像攻.擊。由于根證書已經(jīng)有一個自簽名，攻.擊者可以使用此簽名并將其用于中間證書。
????????● 2005年，Arjen Lenstra和Benne de Weger演示了“如何使用哈希碰撞“構造兩個X.509證書，這兩個證書包含相同的簽名，并且只在公鑰上不同，這是通過對MD5散列函數(shù)的碰撞攻.擊實現(xiàn)的。
????????● 2008年，Alexander Sotirov和Marc Stevens在Chaos Communication Congress上提出了一個實用的攻.擊，基于RapidSSL仍在發(fā)布基于MD5的X.509證書這一事實，他們創(chuàng)建了一個被所有普通瀏覽器接受的流氓證書頒發(fā)機構。
????????● 2009年4月，在歐洲密碼學會議上，麥格理大學（Macquarie University）的澳大利亞研究人員提出了“自動差分路徑搜索SHA-1”，研究人員能夠推導出一種將碰撞的可能性增加了幾個數(shù)量級的方法。
????????● 2017年2月，由Marc Stevens領導的一組研究人員制造了一次SHA-1碰撞，證明了SHA-1的弱點。
????????利用哈希碰撞來偽造X.509簽名的前提是，攻.擊者能夠預測證書頒發(fā)機構將要簽名的數(shù)據(jù)。通過在CA簽署的證書中生成一個隨機因素（通常是序列號）可以在某種程度上緩解這種情況。自2011年以來，CA /瀏覽器論壇已在其基準要求第7.1節(jié)中要求序列號熵。
? ? ? ? 所以，序列號是作為一個隨機干擾源而存在，它是保密的，在簽署證書之前不能對外泄露。
????????自2016年1月1日起，基線要求禁止使用SHA-1頒發(fā)證書。截至2017年初，Chrome 和Firefox拒絕使用SHA-1的證書。截至2017年5月，Edge和Safari都在拒絕SHA-1證書，非瀏覽器的X.509驗證程序尚未拒絕SHA-1證書。
? ? ? ?5）PKCS標準概述
?????????在密碼學里，PKCS代表“公鑰密碼學標準”。這是一組由RSA Security Inc.設計和發(fā)布的公鑰密碼標準，始于20世紀90年代初，該公司發(fā)布這些標準是為了推廣使用他們擁有專利的密碼技術，如RSA算法、Schnorr簽名算法和其他一些算法。盡管不是行業(yè)標準（因為該公司保留了對它們的控制權），但近年來某些標準已經(jīng)開始進入IETF和PKIX工作組等相關標準化組織的“標準跟蹤”過程。
????????● PKCS＃1 2.2 RSA加密標準參見RFC8017。定義了RSA公鑰和私鑰（以明文編碼的ASN.1）的數(shù)學屬性和格式，以及執(zhí)行RSA加密、解密和生成及驗證簽名的基本算法和編碼/填充方案。
????????● PKCS＃2-已撤回，從2010年起不再有效，涵蓋了RSA對消息摘要的加密，隨后合并到PKCS＃1中。
????????● PKCS＃3 1.4 Diffie-Hellman密鑰協(xié)商標準，一種加密協(xié)議，它允許彼此不具有先驗知識的雙方在不安全的通信信道上共同建立共享的秘密密鑰。
????????● PKCS＃4-已撤回自2010年起不再有效，涵蓋了RSA密鑰語法，隨后合并到PKCS＃1中。
????????● PKCS＃5 2.1基于Password的加密標準，參見RFC 8018和PBKDF2。
????????● PKCS＃6 1.5擴展證書語法標準，定義對舊的v1 X.509證書規(guī)范的擴展，被v3淘汰。
????????● PKCS＃7 1.5加密消息語法標準，請參閱RFC2315。用于在PKI下對消息進行簽名和/或加密。也用于證書分發(fā)（例如作為對PKCS＃10消息的響應），形成了S /MIME的基礎，S /MIME于2010年基于RFC 5652（一種更新的加密消息語法標準（CMS））建立，通常用于單點登錄。
????????● PKCS＃8 1.2私鑰信息語法標準，請參見RFC5958。用于攜帶私鑰證書密鑰對（加密或未加密）。
????????● PKCS＃9 2.0選定的屬性類型[，請參見RFC2985。定義選定的屬性類型，以便在PKCS＃6擴展證書、PKCS＃7數(shù)字簽名消息、PKCS＃8私鑰信息和PKCS＃10證書簽名請求中使用。
????????● PKCS＃10 1.7認證請求標準，請參閱RFC2986。發(fā)送給認證機構以請求公鑰證書的消息格式，請參閱證書簽名請求。
????????● PKCS＃11 2.40密碼令牌接口，也稱為“ Cryptoki”。定義密碼令牌通用接口的API（另請參閱硬件安全模塊）。常用于單點登錄，公共密鑰加密和磁盤加密[10]系統(tǒng)。RSA Security已將PKCS＃11標準的進一步開發(fā)移交給了OASIS PKCS 11技術委員會。
????????● PKCS＃12 1.1個人信息交換語法標準，請參閱RFC7292。定義一種文件格式，個人信息交換語法標準[11]見RFC 7292。定義一種文件格式，通常用于存儲私鑰和附帶的公鑰證書，并使用基于Password的對稱密鑰進行保護。PFX是PKCS#12的前身。
????????此容器格式可以包含多個嵌入式對象，例如多個證書。通常使用密碼進行保護/加密。可用作Java密鑰存儲的格式，并在Mozilla Firefox中建立客戶端身份驗證證書，可供Apache Tomcat使用。
????????簡單的說，PKCS#12可以包含證書（公鑰），也可以包含受密碼保護的私鑰
????????● PKCS＃13 橢圓曲線密碼技術標準（已廢棄，唯一的參考是1998年的提案）
????????● PKCS＃14 偽隨機數(shù)生成（已廢棄，沒有文檔）
????????● PKCS＃15 1.1加密令牌信息格式標準，定義了一個標準，允許加密令牌的用戶向應用程序標識自己，而與應用程序的Cryptoki實現(xiàn)（PKCS＃11）或其他API無關。RSA放棄了該標準中與IC卡相關的部分，并改為ISO / IEC 7816-15。
????????本指南演示如何使用OpenSSL命令行工具充當您自己的證書頒發(fā)機構（CA）。這在許多情況下都很有用，例如頒發(fā)服務器證書以保護intranet網(wǎng)站，或向客戶端頒發(fā)證書以允許客戶端向服務器進行身份驗證。
? ? ? OpenSSL是一個免費的開源加密庫，它提供了一些用于處理數(shù)字證書的命令行工具，其中一些工具（也就是命令）可以充當證書頒發(fā)機構。
????????證書頒發(fā)機構是為數(shù)字證書簽名的實體。許多網(wǎng)站需要讓其客戶知道連接是安全的，因此他們向國際證書頒發(fā)機構（CA）支付費用，以為其域簽署證書。
? ? ? ?在某些情況下，自己做自己CA（而不是向DigiCert這樣的CA付錢）更有意義，比如保護intranet網(wǎng)站的安全，或向客戶端頒發(fā)證書以允許客戶端向服務器進行身份驗證。
????????充當證書頒發(fā)機構意味著要處理密鑰對之中的私鑰和公鑰證書。
??? ? ??我們要創(chuàng)建的第一個密鑰對就是根對。這包括根密鑰（ca.key.pem）和根證書（ca.cert.pem）。這個“根對”構成了你的CA的身份。
????????通常，根CA不會直接為服務器或客戶端證書簽名，根CA僅用于創(chuàng)建一個或多個中間CA，這些中間CA被根CA信任，并代表根CA簽署證書，這是最佳實踐，它允許根密鑰保持脫機狀態(tài)并盡可能減少使用的次數(shù)，因為對根的任何威脅都是災難性的。
????????注意：
????????最佳實踐是在安全的環(huán)境中創(chuàng)建根對。理想情況下，該計算機應該是完全加密并且空氣隔離（含義是沒有任何網(wǎng)絡接口的機器，即不能通過外部網(wǎng)絡連接），可以考慮卸載無線網(wǎng)卡，并用膠水塞滿以太網(wǎng)口。
6-2-1）準備目錄
mkdir?/root/ca 創(chuàng)建目錄結構。index.txt和serial文件充當平面文件數(shù)據(jù)庫，以跟蹤已簽名的證書。 cd?/root/ca mkdir?certs?crl?newcerts?private chmod?700?private touch?index.txt echo?1000?>?serial
????????您必須創(chuàng)建一個配置文件以供OpenSSL使用。
? ? ? ??將根CA配置文件從Appendix復制到/root/CA/openssl.cnf，其中的[ca]部分為必填項，這里告訴OpenSSL使用[CA_default]部分中的選項。
重慶分公司
重慶分公司
