英文原文：https://blog.csdn.net/blue0bird/article/details/78656536
https://jamielinux.com/docs/openssl-certificate-authority/index.html
本文源於兩篇英文文檔，將其合二爲一，翻譯過程參考了網上的其它翻譯以求更加準確，再此對這些翻譯文檔的作者表示感謝！
文中介紹的OpenSSL版本較老，與現有的版本有很多不符之處，但萬變不離其宗，核心原理還是很有參考價值的。
1）證書
X.509標準是密碼學裏公鑰證書的格式標準。X.509 證書己應用在包括TLS/SSL（WWW萬維網安全瀏覽的基石）在內的衆多 Internet協議裏，同時它也有很多非在線的應用場景，比如電子簽名服務。X.509證書含有公鑰和標識（主機名、組織或個人），並由證書頒發機構（CA）簽名（或自簽名）。對於一份經由可信的證書籤發機構簽名（或者可以通過其它方式驗證）的證書，證書的擁有者就可以用證書及相應的私鑰來創建安全的通信，以及對文檔進行數字簽名。
歷史和用法
X.509最早與X.500一起發佈於1988年7月3日，它假定頒發證書的證書頒發機構（CA）具有嚴格的層次結構。這與Web信任模型（如PGP）形成了鮮明對比，因爲PGP方案是任何人都以簽名（而不僅僅是地位特殊的CA），從而證明其他人的密鑰證書的有效性。X.509 V3證書的設計非常靈活，除了對網橋拓撲架構網絡的支持，還可以支持用於點對點方式的Mesh網，類似於OpenPGP那樣的web信任機制，不過這樣方式在2004年之前很少使用。
X.500系統僅由主權國家實施，以實現國家身份信息共享條約的實施目的，而IETF的公鑰基礎設施（X.509）或PKIX工作組已對該標準進行了調整，以適應更靈活的互聯網組織結構。事實上X.509認證指的是RFC5280裏定義的X.509 v3，包括對IETF的PKIX證書和證書吊銷列表（CRL Profile），通常也稱爲公鑰基礎設施。
在X.509系統中，證書申請者通過發起“證書籤名請求（CSR）”來得到一份被簽名的證書。爲此，它需要生成一個密鑰對，然後用其中的私鑰對CSR簽名（私鑰本身要妥善保存，對外保密），CSR包含申請人的身份信息、用於驗真CSR的申請人的公鑰，以及所請求證書的專有名稱（DN），CSR還可能帶有CA要求的其它有關身份證明的信息，然後CA對這個專有名稱發佈一份證書，並綁定一個公鑰。
組織機構可以把受信的根證書分發給所有的成員，這樣就可以使用公司的PKI系統了。像Firefox, IE, Opera, Safari 以及Google Chrome這些瀏覽器都預裝了一組CA根證書，所以可以直接使用這些主流CA發佈的SSL證書。瀏覽器的開發者直接影響它的用戶對第三方的信任。FireFox就提供了一份csv/html格式的列表。
X.509還包括證書吊銷列表（CRL）實現標準，這是PKI系統經常被忽略的方面。IETF批准的檢查證書有效性的方法是在線證書狀態協議（OCSP），Firefox 3默認情況下啓用OCSP檢查，從Vista開始的高版本Windows也是如此。
1-1）證書的結構
X.509證書的結構是用ASN.1(Abstract Syntax Notation One：抽象語法標記)來描述其數據結構，並使用ASN1語法進行編碼。
X.509 v3數字證書的結構如下：
● Certificate 證書
● Version Number版本號
● Serial Number序列號
● ID Signature Algorithm ID簽名算法
● Issuer Name頒發者名稱
● Validity period 有效期
● Not before起始日期
● Not after截至日期
● Subject Name主題名稱
● Subject pbulic Key Info 主題公鑰信息
● Public Key Algorithm公鑰算法
● Subject Public Key主題公鑰
● Issuer Unique Identifier (optional)頒發者唯一標識符（可選）
● Subject Unique Identifier (optional)主題唯一標識符（可選）
● Extensions (optional) 證書的擴展項（可選）
…
● Certificate Sigature Algorithm證書籤名算法
● Certificate Signature證書的簽名
1-2）指示證書特定用法的擴展項
所有擴展都有一個ID，由object identifier來表達，它是一個集合，並且有一個標記指示這個擴展是不是決定性的。證書使用時，如果發現一份證書帶有決定性標記的擴展，而這個系統並不清楚該擴展的用途，就要拒絕使用它。但對於非決定性的擴展，不認識可以予以忽略。RFC 1422給出了v1的證書結構，ITU-T在v2裏增加了頒發者和主題唯一標識符，從而可以在一段時間後重用。重用的一個例子是當一個CA破產了，它的名稱也在公共列表裏清除掉了，一段時間之後另一個CA可以用相同的名稱來註冊，即使它與之前的並沒有任何瓜葛。不過IETF並不建議重用同名註冊。另外v2也沒有在Internet裏大範圍的使用。v3引入了擴展，CA使用擴展來發布一份特定使用目的的證書（比如說僅用於代碼簽名）。
對於所有的版本，同一個CA頒發的證書序列號都必須是唯一的。
RFC 5280（及後續版本）定義了數字證書擴展項，用於指示如何使用證書。它們大多來自joint-iso-ccitt（2）ds（5）id-ce（29）OID。第4.2.1節中定義的一些最常見的是：
● Basic Constraints,{id ce 19}，用於指示一份證書是不是CA證書。
● Key Usage, {id ce 15}，指定了這份證書包含的公鑰可以執行的密碼操作，例如只能用於簽名，但不能用來加密。
●Extended Key Usage{id ce 37}，典型用法是指定葉子證書中的公鑰的使用目的。它包括一系列的OID，每一個都指定一種用途。例如{id pkix 31}表示用於服務器端的TLS/SSL連接；{id pkix 34}表示密鑰可以用於保護電子郵件。
通常情況下，當一份證書有多個限制用途的擴展時，所有限制條件都應該滿足纔可以使用。RFC 5280有一個例子，該證書同時含有keyUsage和extendedKeyUsage，這樣的證書只能用在被這兩個擴展指定的用途，例如網絡安全服務決定證書用途時，會同時對這個擴展進行判斷。
1-3）證書文件擴展名
X.509證書有幾種常用的文件擴展名，但要注意：其中一些擴展名也有其它用途，就是說具有這個擴展名的文件可能並不是證書，比如說可能只是保存了私鑰。
● .pem：（隱私增強型電子郵件），DER編碼的證書再進行Base64編碼，數據存放於“--- BEGIN CERTIFICATE ---”和“ --- END CERTIFICATE ---”之間
● .cer，.crt，.der：通常採用二進制DER形式，但Base64編碼也很常見
● .p7b，.p7c-PKC＃7：SignedData結構，沒有數據，僅有證書或CRL
● .p12-PKCS＃12：可以包含證書（公鑰），也可同時包含受密碼保護的私鑰
● .pfx ：PKCS＃12的前身（通常用PKCS＃12格式，例如IIS產生的PFX文件）
PKCS#7是簽名或加密數據的格式標準，官方稱之爲容器。由於證書是可驗真的簽名數據，所以可以用SignedData結構表述。.P7C文件是退化的SignedData結構，沒有包括簽名的數據。
PKCS＃12從個人信息交換（PFX）標準發展而來，用於在單個文件中交換公共和私有對象。
2）證書鏈和交叉認證
證書鏈（也就是RFC 5280裏的證書路徑）指的是以最終實體證書開頭，後跟一個或多個CA證書，且通常最後一個是自簽名證書，具有如下關係：
1.除了鏈上的最後一個證書外，每個證書的頒發者等於其後一個證書的主題（主題就是使用者）。
2.除了鏈上的最後一個證書外，每個證書都是由其後的一個證書籤名。
3.最後一個證書是信任錨：由於是通過某種可信的過程得到的，所以你可以信任它。
證書鏈用來檢查目標證書（鏈中的第一個證書）中包含的公鑰和其他數據是否屬於其主題。檢查是這麼做的，用證書鏈中的下一個證書的公鑰來驗證它的簽名，一直檢查到證書鏈的尾端，由於最後一個證書是信任錨，成功達到該證書將證明目標證書可以信任。
上段中的描述是根據RFC5280定義的認證路徑驗證過程的簡化過程，實際上涉及額外的檢查，例如驗證證書的有效日期、查找CRL等。
在研究證書鏈的構建和驗證方式時，需要特別注意的是，具體的證書可以是不同的證書鏈的一部分（鏈上的所有證書都有效）。 這是因爲可以爲相同的主題和公鑰生成多個CA證書，但使用不同的私鑰（來自不同的CA或來自同一CA的不同的私鑰）進行簽名。 因此，儘管單個X.509證書只能具有一個頒發者和一個CA簽名，但是它可以有效地鏈接到多個證書，從而建立完全不同的證書鏈。 這對於PKI與其他應用程序之間的交叉認證至關重要，詳見以下示例。
下圖每個框代表一個證書，主題以粗體顯示，A→B表示“ A由B簽名”（或更準確地說，A由B包含公鑰相對應的私鑰簽名），具有相同顏色（非白色/透明）的證書包含相同的公鑰。
例1：兩個PKI之間，在根證書頒發機構（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）
證書頒發者爲了從舊的私鑰平滑地轉移到新的私鑰，他可以頒發兩個證書，其中一個是新的私鑰對舊的公鑰進行簽名，另一個是舊的私鑰對新的公鑰的簽名，這兩個證書都是自頒發的，但都不是自籤名。注：另外還存在新舊兩個自簽名證書。
假設cert1和cert3包含相同的公鑰（舊的公鑰），對於cert5來說有兩條合法的證書鏈，cert5 → cert1 和 cert5 → cert3 → cert2, cert6的情況也類似。這樣就允許老的用戶證書可以在新舊兩個根證書之間平滑轉移。
3）X.509證書的例子
以下是維基百科網站Wikipedia.org和其他幾家Wikipedia網站的X.509證書解碼實例，由GlobalSign發佈，它的頒發者字段（Subject）將Wikipedia描述爲一個組織，Subject Alternative Name字段描述可以使用的主機名。Subject Public Key Info字段包含一個ECDSA公鑰，而底部的簽名由GlobalSign的RSA私鑰生成。
3-1）最終實體證書
網摘：最終實體證書就是大家通常說的用戶證書，有別於CA證書，最終實體證書中的證書主體是不能使用證書所對應的私鑰簽發證書的。最終實體與CA是兩個相對的概念：CA可以利用其私鑰簽發證書，而最終實體不能。雖然在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: ...
要驗證此最終實體證書，需要一個與其頒發者和頒發機構密鑰標識符（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）中間證書
網摘：什麼是中間證書？
中間證書用作根證書的替代。我們使用中間證書作爲代理，因爲我們必須將根證書保存在衆多安全層之後，以確保其密鑰絕對不可訪問。由於根證書籤署了中間證書，因此中間證書可用於簽署客戶安裝和維護的SSL“信任鏈”。
注意：如果不使用已頒發的SSL證書安裝中間證書，則可能無法建立可信鏈證書。這意味着，當訪問者試圖訪問您的網站時，他們可能會收到一個“安全警報”錯誤，指示“安全證書是由您未選擇信任的公司頒發的…”面對這樣的警告，潛在客戶很可能會將其業務轉移到其他地方。
以下是中間證書的實例，此證書被CA根證書籤署，並簽署了上面的最終實體證書。
注意：此中間證書的subject字段與它所簽署的最終實體證書的issuer字段相同、中間證書的subject key identifier（主題密鑰標識符）字段與最終實體證書的的authority key identifier（頒發者的密鑰標識符）字段相同。
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）根證書
以下是證書頒發機構的自簽名根證書示例，Issuer（頒發者字段）和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:
4）安全
Bruce Schneier，Peter Gutmann和其他安全專家發表了許多有關PKI問題的出版物。
4-1）架構缺陷
將無效的證書列入黑名單（使用CRL和OCSP）。
PKI的魅力之一是脫機功能，但如果客戶端僅使用CRL來判斷證書的有效性，在脫機的情況下就會出現誤判，因爲當CRL不可用時，大多數客戶端都會信任證書，於是攻.擊者可以通過切斷信道來禁用CRL。谷歌（Google）的亞當•蘭利（Adam Langley）曾表示，CRL軟故障檢查就像一條安全帶，只有在發生事故時才起作用。
● CRL的尺寸較大且分佈模式複雜，因此它不是一個很好的選擇，
● OCSP語義模糊，缺乏歷史撤銷狀態；
● 未解決根證書吊銷的問題
● 聚合問題：身份聲明（通過標識符進行身份驗證）、屬性聲明（提交一包經過審覈的屬性）和策略聲明組合在一個容器中，這會引發隱私、策略映射和維護問題。
● 委派問題：從技術上講，CA無法限制下級CA在有限的名稱空間或屬性集之外頒發證書；X.509的此功能未被使用。因此，互聯網上存在大量的CA，對它們進行分類和策略是一項不可完成的任務，一個組織內部的授權不能像一般的商業慣例那樣處理。
● 聯合身份驗證問題：證書鏈是從屬CA、橋接CA和交叉簽名的結果，這使得驗證複雜且處理時間上昂貴、路徑驗證語義可能不明確。具有第三方受信任方的層次結構是唯一的模型。如果已經建立了雙邊信任關係，這將很不方便。
爲主機名頒發擴展驗證（EV）證書不會阻止頒發對同一主機名較低驗證證書的頒發，這意味着較高的EV驗證級別無法抵禦中間人攻.擊。
4-2）證書頒發機構的問題
如果是主體而不是依賴方購買證書，通常會使用最便宜的頒發者，頒發者出於成本考慮，往往採用擴展驗證證書來解決問題，但是在安全專家看來，信任價值正在下降。
● 證書頒發機構否認對用戶（包括主題或依賴方）的幾乎所有保證。
● 有效期應用於限制密鑰強度被視爲時間足夠，此參數被證書頒發機構濫用以向客戶端收取擴展費。這給使用密鑰滾動的用戶帶來了不必要的負擔。（沒看懂啥意思）
●“用戶使用未定義的認證請求協議來獲取證書，該證書發佈於不存在的目錄中的不明確位置，從而無有效手段來撤銷它。”
與所有企業一樣，CA受其經營站點的法律管轄，並可能被迫損害其客戶和用戶的利益。情報機構還利用了通過CA的法外妥協發出的虛假證書（例如DigiNotar）來進行中間人攻.擊。另一個例子是荷蘭政府CA的撤銷請求，由於新的荷蘭法律自2018年1月1日起生效，爲荷蘭情報和安全部門賦予了新的權力。
4-3）實施問題
X.509實現存在設計缺陷、錯誤、對標準的不同解釋以及不同標準的互操作性問題，一些問題是：
● 許多實現關閉吊銷檢查：
● 策略被視爲障礙，沒有得到執行
● 如果默認情況下在所有瀏覽器（包括代碼簽名）中都打開了它，可能會破壞基礎結構
● DN很複雜且不容易理解（缺乏規範化、國際化問題……）
● RFC822名稱有2種表示法
● 幾乎不支持名稱和策略約束
● keyUsage被忽略，使用列表中的第一個證書
● 自定義oid的實施很困難
● 不應將屬性設爲強制屬性，因爲它會使客戶端崩潰
● 未指定的屬性長度會導致特定於產品的限制
● X.509存在實現錯誤，例如允許在證書中使用以空值結尾的字符串，或通過代碼注入攻.擊來僞造使用者名稱。
● 通過使用對象標識符的0x80填充子標識符，錯誤的實現或通過使用客戶端瀏覽器的整數溢出，攻.擊者可以在CSR中包含一個未知屬性，CA會將其簽名，客戶端錯誤地將其解釋爲“CN”（OID = 2.5.4.3）
4-4）加密的漏洞
數字簽名系統依賴於密碼散列函數（哈希函數）的安全性。如果公鑰基礎結構（PKI）使用了不再安全的哈希函數，攻.擊者可以利用哈希函數中的弱點來僞造證書。具體來說，如果攻.擊者能夠實現“哈希碰撞”，他們可以先說服CA用看似無害的內容簽名證書，但這些內容的哈希與攻.擊者創建的另一組惡意的證書內容的哈希相同，然後，攻.擊者可以將CA提供的簽名附加到其惡意證書之中，從而生成“似乎由CA簽名”的惡意證書。由於惡意證書內容由攻.擊者定製，因此它們的有效日期或主機名可能與無害證書不同；惡意證書甚至可以包含“CA:true”字段，從而使其能夠頒發其他受信任證書。
● 基於MD2的證書使用了很長時間，容易受到預映像攻.擊。由於根證書已經有一個自簽名，攻.擊者可以使用此簽名並將其用於中間證書。
● 2005年，Arjen Lenstra和Benne de Weger演示了“如何使用哈希碰撞“構造兩個X.509證書，這兩個證書包含相同的簽名，並且只在公鑰上不同，這是通過對MD5散列函數的碰撞攻.擊實現的。
● 2008年，Alexander Sotirov和Marc Stevens在Chaos Communication Congress上提出了一個實用的攻.擊，基於RapidSSL仍在發佈基於MD5的X.509證書這一事實，他們創建了一個被所有普通瀏覽器接受的流氓證書頒發機構。
● 2009年4月，在歐洲密碼學會議上，麥格理大學（Macquarie University）的澳大利亞研究人員提出了“自動差分路徑搜索SHA-1”，研究人員能夠推導出一種將碰撞的可能性增加了幾個數量級的方法。
● 2017年2月，由Marc Stevens領導的一組研究人員製造了一次SHA-1碰撞，證明了SHA-1的弱點。
4-4-1）針對加密漏洞的緩解措施
利用哈希碰撞來僞造X.509簽名的前提是，攻.擊者能夠預測證書頒發機構將要簽名的數據。通過在CA簽署的證書中生成一個隨機因素（通常是序列號）可以在某種程度上緩解這種情況。自2011年以來，CA /瀏覽器論壇已在其基準要求第7.1節中要求序列號熵。
所以，序列號是作爲一個隨機幹擾源而存在，它是保密的，在簽署證書之前不能對外泄露。
自2016年1月1日起，基線要求禁止使用SHA-1頒發證書。截至2017年初，Chrome 和Firefox拒絕使用SHA-1的證書。截至2017年5月，Edge和Safari都在拒絕SHA-1證書，非瀏覽器的X.509驗證程序尚未拒絕SHA-1證書。
5）PKCS標準概述
在密碼學裏，PKCS代表“公鑰密碼學標準”。這是一組由RSA Security Inc.設計和發佈的公鑰密碼標準，始於20世紀90年代初，該公司發佈這些標準是爲了推廣使用他們擁有專利的密碼技術，如RSA算法、Schnorr簽名算法和其他一些算法。儘管不是行業標準（因爲該公司保留了對它們的控制權），但近年來某些標準已經開始進入IETF和PKIX工作組等相關標準化組織的“標準跟蹤”過程。
● PKCS＃1 2.2 RSA加密標準參見RFC8017。定義了RSA公鑰和私鑰（以明文編碼的ASN.1）的數學屬性和格式，以及執行RSA加密、解密和生成及驗證簽名的基本算法和編碼/填充方案。
● PKCS＃2-已撤回，從2010年起不再有效，涵蓋了RSA對消息摘要的加密，隨後合併到PKCS＃1中。
● PKCS＃3 1.4 Diffie-Hellman密鑰協商標準，一種加密協議，它允許彼此不具有先驗知識的雙方在不安全的通信信道上共同建立共享的祕密密鑰。
● PKCS＃4-已撤回自2010年起不再有效，涵蓋了RSA密鑰語法，隨後合併到PKCS＃1中。
● PKCS＃5 2.1基於Password的加密標準，參見RFC 8018和PBKDF2。
● PKCS＃6 1.5擴展證書語法標準，定義對舊的v1 X.509證書規範的擴展，被v3淘汰。
● PKCS＃7 1.5加密消息語法標準，請參閱RFC2315。用於在PKI下對消息進行簽名和/或加密。也用於證書分發（例如作爲對PKCS＃10消息的響應），形成了S /MIME的基礎，S /MIME於2010年基於RFC 5652（一種更新的加密消息語法標準（CMS））建立，通常用於單點登錄。
● PKCS＃8 1.2私鑰信息語法標準，請參見RFC5958。用於攜帶私鑰證書密鑰對（加密或未加密）。
● PKCS＃9 2.0選定的屬性類型[，請參見RFC2985。定義選定的屬性類型，以便在PKCS＃6擴展證書、PKCS＃7數字簽名消息、PKCS＃8私鑰信息和PKCS＃10證書籤名請求中使用。
● PKCS＃10 1.7認證請求標準，請參閱RFC2986。發送給認證機構以請求公鑰證書的消息格式，請參閱證書籤名請求。
● PKCS＃11 2.40密碼令牌接口，也稱爲“ Cryptoki”。定義密碼令牌通用接口的API（另請參閱硬件安全模塊）。常用於單點登錄，公共密鑰加密和磁盤加密[10]系統。 RSA Security已將PKCS＃11標準的進一步開發移交給了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 僞隨機數生成（已廢棄，沒有文檔）
● PKCS＃15 1.1加密令牌信息格式標準，定義了一個標準，允許加密令牌的用戶嚮應用程序標識自己，而與應用程序的Cryptoki實現（PKCS＃11）或其他API無關。RSA放棄了該標準中與IC卡相關的部分，並改爲ISO / IEC 7816-15。
6）OpenSSL證書頒發機構
本指南演示如何使用OpenSSL命令行工具充當您自己的證書頒發機構（CA）。這在許多情況下都很有用，例如頒發服務器證書以保護intranet網站，或向客戶端頒發證書以允許客戶端向服務器進行身份驗證。
6-1）簡介
OpenSSL是一個免費的開源加密庫，它提供了一些用於處理數字證書的命令行工具，其中一些工具（也就是命令）可以充當證書頒發機構。
證書頒發機構是爲數字證書籤名的實體。許多網站需要讓其客戶知道連接是安全的，因此他們向國際證書頒發機構（CA）支付費用，以爲其域簽署證書。
在某些情況下，自己做自己CA（而不是向DigiCert這樣的CA付錢）更有意義，比如保護intranet網站的安全，或向客戶端頒發證書以允許客戶端向服務器進行身份驗證。
6-2) 創建根對
充當證書頒發機構意味着要處理密鑰對之中的私鑰和公鑰證書。
我們要創建的第一個密鑰對就是根對。這包括根密鑰（ca.key.pem）和根證書（ca.cert.pem）。這個“根對”構成了你的CA的身份。
通常，根CA不會直接爲服務器或客戶端證書籤名，根CA僅用於創建一個或多箇中間CA，這些中間CA被根CA信任，並代表根CA簽署證書，這是最佳實踐，它允許根密鑰保持脫機狀態並儘可能減少使用的次數，因爲對根的任何威脅都是災難性的。
注意：
最佳實踐是在安全的環境中創建根對。理想情況下，該計算機應該是完全加密並且空氣隔離（含義是沒有任何網絡接口的機器，即不能通過外部網絡連接），可以考慮卸載無線網卡，並用膠水塞滿以太網口。
6-2-1）準備目錄
mkdir /root/ca 創建目錄結構。index.txt和serial文件充當平面文件數據庫，以跟蹤已簽名的證書。 cd /root/ca mkdir certs crl newcerts private chmod 700 private touch index.txt echo 1000 > serial
6-2-2）準備配置文件
您必須創建一個配置文件以供OpenSSL使用。
將根CA配置文件從Appendix複製到/root/CA/openssl.cnf，其中的[ca]部分爲必填項，這裏告訴OpenSSL使用[CA_default]部分中的選項。
[ca] default_ca = CA_default he [CA_default] section contains a range of defaults. Make sure you declare the directory you chose earlier(/root/ca). [CA_default]部分包含一系列默認值，其中的dir字段取值一定要是剛纔選擇/root/ca： [CA_defalut] #目錄和文件位置 dir = /root/ca certs = $dir/certs crl_dir = $dir/crl new_certs_dir = $dir/newcerts database = $dir/index.txt serial = $dir/serial RANDFILE = $dir/private/.rand # 根密鑰和根證書 private_key = $dir/private/ca.key.pem certificate = $dir/certs/ca.cert.pem # 證書吊銷列表 crlnumber = $dir/crlnumber crl = $dir/crl/ca.crl.pem crl_extension = crl_ext default_crl_days = 30 # HA-1已棄用，因此請改用SHA-2 defualt_md = sha256 name_opt = ca_default cert_opt = ca_default default_days = 375 preserve = no policy = plicy_strict 我們將對所有根CA簽名應用policy_strict，因爲根CA僅用於創建中間CA。 [ policy_strict] # 根CA只對匹配的中間證書進行簽名 # 請參閱“man ca”的策略格式部分。 countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional 如果值是“ match”，意爲請求文件的該字段取值，必須與簽署時輸入的CA證書的對應字段取值一模一樣；如果值是“supplied”，那麼它必須存在。如果該值爲“optional”，則可選（可留空）；所以我們將對所有中間CA簽名應用policy_loose而不是policy_strict，因爲中間CA正在對可能來自各種第三方的服務器和客戶端證書進行簽名。 [ policy_loose ] # 允許中間CA簽署更多種證書 # 請參見`ca`手冊頁的“策略格式”部分 countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional 在創建證書或證書籤名請求時，將應用[req]部分中的選項。 [ req ] #req”工具的選項（“man req”） default_bits = 2048 distinguished_name = req_distinguished_name string_mask = utf8only # HA-1已棄用，因此請改用SHA-2 default_md = sha256 # 使用-x509選項時要添加的擴展項。 x509_extensions = v3_ca [req_distinguished_name]聲明證書籤名請求中通常所需的信息，您可以選擇指定一些默認值。 [ req_distinguished_name ] # 參看<https://en.wikipedia.org/wiki/Certificate_signing_request>. countryName = Country Name (2 letter code) stateOrProvinceName = State or Province Name localityName = Locality Name 0.organizationName = Organization Name organizationalUnitName = Organizational Unit Name commonName = Common Name emailAddress = Email Address # Optionally, specify some defaults. countryName_default = GB stateOrProvinceName_default = England localityName_default = 0.organizationName_default = Alice Ltd #organizationalUnitName_default = #emailAddress_default = 接下來的幾個部分是在簽署證書時可以應用的擴展項，例如 -extensions v3_ca命令行參數將應用[v3_ca]中設置的選項。 我們將在創建根證書時應用[v3_ca]擴展： [ v3_ca ] #典型的CA擴展 (`查看x509v3_config手冊`). subjectKeyIdentifier = hash autorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true keyUsage = critical, digitalSignature, cRLsign, keyCertSign 我們將在創建中間證書時應用v3_ca_intermediate extension（中間擴展項），pathlen:0保證在中間CA下面不能有其他證書頒發機構： [ v3_intermediate_ca ] # 典型的中間CA的擴展 (`查看x509v3_config手冊`). subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true, pathlen:0 keyUsage = critical, digitalSignature, cRLSign, keyCertSign 我們將在簽署server_cert（服務器證書，例如用於web服務器的證書）時應用服務器證書擴展： [ server_cert ] # Extensions for server certificates (`查看x509v3_config手冊`). basicConstraints = CA:FALSE nsCertType = server nsComment = "OpenSSL Generated Server Certificate" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer:always keyUsage = critical, digitalSignature, keyEncipherment extendedKeyUsage = serverAuth 創建證書吊銷列表時，將自動應用crl_ext擴展項： [ crl_ext ] # CRL的擴展(`查看x509v3_config手冊`). authorityKeyIdentifier=keyid:always 在簽署在線證書狀態協議（OCSP）證書時，我們將使用ocsp擴展項： [ ocsp ] # OCSP簽名證書的擴展項(`man ocsp`). basicConstraints = CA:FALSE subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer keyUsage = critical, digitalSignature extendedKeyUsage = critical, OCSPSigning
6-2-3）創建根私鑰
創建根私鑰（ca.key.pem）並確保其絕對安全，因爲任何擁有根私鑰的人都可以頒發“可信證書”，建議使用AES 256算法和複雜的強密碼加密根私鑰。
注意：出於安全考慮，對所有根CA和中間CA使用4096位私鑰。
cd /root/ca openssl genrsa -aes256 -out private/ca.key.pem 4096 Enter pass phrase for ca.key.pem: secretpassword Verifying - Enter pass phrase for ca.key.pem: secretpassword chmod 400 private/ca.key.pem
6-2-4）創建根證書
使用根密鑰（ca.key.pem）創建根證書（ca.cert.pem），給根證書一個長的有效期，比如20年。根證書過期後，由根CA簽名的所有證書都將無效。
警告：無論何時使用req工具，都必須指定要與-config選項一起使用的配置文件，否則OpenSSL將默認爲/etc/pki/tls/OpenSSL.cnf
cd /root/ca openssl req -config openssl.cnf -key private/ca.key.pem -new -x509 -days 7300 -sha256 -extensions v3_ca -out certs/ca.cert.pem Enter pass phrase for ca.key.pem: secretpassword You are about to be asked to enter information that will be incorporated into your certificate request. ----- Country Name (2 letter code) [XX]:GB State or Province Name []:England Locality Name []: Organization Name []:Alice Ltd Organizational Unit Name []:Alice Ltd Certificate Authority Common Name []:Alice Ltd Root CA Email Address []:
6-2-5）驗證根證書
openssl x509 -noout -text -in certs/ca.cert.pem
這行命令的輸出包括：
● 使用的簽名算法
● 證書生效期
● 公鑰位長度
● 頒發者，即簽署證書的實體
● 主體，指的是證書本身
由於證書是自簽名的，因此頒發者和主題相同。
請注意，所有根證書都是自簽名的。
注：以下的黃色漢字是註釋，並非證書的組成部分 Signature Algorithm: sha256WithRSAEncryption # 使用的簽名算法 Issuer: C=GB, ST=England, O=Alice Ltd, OU=Alice Ltd Certificate Authority, CN=Alice Ltd Root CA # 頒發者 Validity # 證書有效期 Not Before: Apr 11 12:22:58 2015 GMT Not After : Apr 6 12:22:58 2035 GMT Subject: C=GB, ST=England, O=Alice Ltd, OU=Alice Ltd Certificate Authority, CN=Alice Ltd Root CA # 主體 Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) # 公鑰位長度
6-3）創建中間證書密鑰對
中間證書授權（CA）是可以代表根CA簽署證書的實體，根CA簽署中間證書，這就形成了信任鏈。
使用中間證書的目的主要是：根密鑰可以保持脫機狀態，並儘可能不頻繁地使用。如果中間密鑰被泄露，根CA可以撤銷中間證書並創建新的中間密鑰對。
6-3-1）準備目錄
根CA文件保存在/ root / ca中，選擇其他目錄（/root/ca/intermediate）來存儲中間CA文件。
cd /root/ca/intermediate mkdir certs crl csr newcerts private chmod 700 private touch index.txt echo 1000 > serial 將crlnumber文件添加到中間CA目錄樹，crlnumber用於跟蹤證書吊銷列表： echo 1000 > /root/ca/intermediate/crlnumber 將中間CA配置文件從Appendix複製到/root/CA/intermediate/openssl.cnf。注意與根CA配置文件相比，以下五個選項變化了： [ CA_default ] dir = /root/ca/intermediate private_key = $dir/private/intermediate.key.pem certificate = $dir/certs/intermediate.cert.pem crl = $dir/crl/intermediate.crl.pem policy = policy_loose
6-3-2) 創建中間密鑰
創建中間密鑰（intermediate.key.pem），並使用AES 256算法和複雜的強密碼將其加密保護。
# cd /root/ca # openssl genrsa -aes256 -out intermediate/private/intermediate.key.pem 4096 Enter pass phrase for intermediate.key.pem: secretpassword Verifying - Enter pass phrase for intermediate.key.pem: secretpassword # chmod 400 intermediate/private/intermediate.key.pem
6-3-3) 創建中間證書
使用中間證書創建證書籤名請求（CSR），詳細信息通常應與根CA相同。但 Common Name（證書持有者通用名/FQDN）必須不同：
警告：請確保命令行指定的中間 CA 配置文件存在（intermediate/openssl.cnf）。
# cd /root/ca # openssl req -config intermediate/openssl.cnf -new -sha256 -key intermediate/private/intermediate.key.pem -out intermediate/csr/intermediate.csr.pem Enter pass phrase for intermediate.key.pem: secretpassword You are about to be asked to enter information that will be incorporated into your certificate request. ----- Country Name (2 letter code) [XX]:GB State or Province Name []:England Locality Name []: Organization Name []:Alice Ltd Organizational Unit Name []:Alice Ltd Certificate Authority Common Name []:Alice Ltd Intermediate CA Email Address []:
要創建中間證書，請使用帶有v3_intermediate_CA擴展項的根CA對中間CSR進行簽名。中間證書的有效期應短於根證書。十年是合理的。
警告：指定根CA配置文件 /root/ca/openssl.cnf。
# cd /root/ca # openssl ca -config openssl.cnf -extensions v3_intermediate_ca -days 3650 -notext -md sha256 -in intermediate/csr/intermediate.csr.pem -out intermediate/certs/intermediate.cert.pem Enter pass phrase for ca.key.pem: secretpassword Sign the certificate? [y/n]: y # chmod 444 intermediate/certs/intermediate.cert.pem index.txt文件是OpenSSL CA工具存儲證書數據庫的位置，請勿手動刪除或編輯此文件。現在它應該包含剛纔創建的中間證書： V 250408122707Z 1000 unknown ... /CN=Alice Ltd Intermediate CA
6-3-4) 驗證中間證書
正如我們對根證書所做的那樣，請檢查中間證書的詳細信息是否正確：
# openssl x509 -noout -text -in intermediate/certs/intermediate.cert.pem
intermediate.cert.pem: OK
6-3-5) 創建證書鏈文件
當應用程序（如web瀏覽器）嘗試驗證由中間CA簽名的證書時，它必須對照根證書驗證中間證書。要完成信任鏈，請創建CA證書鏈以呈現給應用程序。
要創建CA證書鏈，請將中間證書和根證書連接在一起，我們稍後將使用此文件來驗證由中間CA簽名的證書。
# cat intermediate/certs/intermediate.cert.pem certs/ca.cert.pem > intermediate/certs/ca-chain.cert.pem # chmod 444 intermediate/certs/ca-chain.cert.pem
注意：證書鏈文件必須包含根證書，因爲需要讓客戶端應用程序找到它。更好的選擇（尤其是在管理Intranet的情況下）是在需要連接的每個客戶端上安裝根證書，在這種情況下，證書鏈文件僅需要包含您的中間證書。
6-4) 簽署服務器和客戶端證書
我們將使用中間 CA 簽署證書。您可以在各種情況下使用這些證書，例如保護與 Web 服務器的連接或對連接到服務器的客戶端進行身份驗證。
注意：以下步驟是CA替申請者創建私鑰和簽名請求（CSR），但申請者從安全角度考慮也可以自己創建私鑰和請求，其中的私鑰妥善保存於本地，把CSR交給CA，CA則還給它一個簽名的證書。在這種情況下，跳過 genrsa 和 req 命令。
6-4-1) 創建私鑰
我們的根密鑰對和中間密鑰對是4096位，服務器證書和客戶端證書通常在一年後過期，因此我們可以安全地使用2048位。
注意：儘管4096位比2048位更安全，但它會減慢TLS握手速度並顯着增加握手期間的處理器負載。因此，大多數網站使用2048位的密鑰對。
譯者注：2048位已經不再安全，建議使用4096或8192位。
如果要創建用於網絡服務器的密鑰對，每次重啓該服務器時都需要輸保護密碼，如果嫌麻煩可以不使用-aes256選項以創建沒有密碼的私鑰。
# cd /root/ca # openssl genrsa -aes256 -out intermediate/private/www.example.com.key.pem 2048 # chmod 400 intermediate/private/www.example.com.key.pem
6-4-2) 創建證書
使用私鑰創建證書籤名請求（CSR），並且CSR的詳細信息無需與中間CA相匹配。對於服務器證書，Common Name（公用名）必須是FQDN（完全限定的域名，例如，www.example.com），而對於客戶端證書，Common Name可以是任何唯一標識符（例如電子郵件地址），請注意，客戶端證書的Common Name與根證書或中間證書的Common Name不同。
# cd /root/ca #openssl req -config intermediate/openssl.cnf -key intermediate/private/www.example.com.key.pem -new -sha256 -out intermediate/csr/www.example.com.csr.pem Enter pass phrase for www.example.com.key.pem: secretpassword You are about to be asked to enter information that will be incorporated into your certificate request. ----- Country Name (2 letter code) [XX]:US State or Province Name []:California Locality Name []:Mountain View Organization Name []:Alice Ltd Organizational Unit Name []:Alice Ltd Web Services Common Name []:www.example.com Email Address []:
要創建證書，請使用中間CA對CSR進行簽名。如果要在服務器上使用證書，請使用 server_cert擴展項;如果證書將用於用戶身份驗證，請使用usr_cert擴展項。證書的有效期通常爲一年，不過爲了方便起見，CA通常會多給幾天時間。
# cd /root/ca #openssl ca -config intermediate/openssl.cnf -extensions server_cert -days 375 -notext -md sha256 -in intermediate/csr/www.example.com.csr.pem -out intermediate/certs/www.example.com.cert.pem # chmod 444 intermediate/certs/www.example.com.cert.pem intermediate/index.txt應該出現包含該證書的行： V 160420124233Z 1000 unknown ... /CN=www.example.com
6-4-3) 驗證證書
# openssl x509 -noout -text -in intermediate/certs/www.example.com.cert.pem
Issuer（頒發者）是中間CA，Subject（主題）是指證書本身： Signature Algorithm: sha256WithRSAEncryption Issuer: C=GB, ST=England,O=Alice Ltd, OU=Alice Ltd Certificate Authority,CN=Alice Ltd Intermediate CA Validity Not Before: Apr 11 12:42:33 2015 GMT Not After : Apr 20 12:42:33 2016 GMT Subject: C=US, ST=California, L=Mountain View,O=Alice Ltd, OU=Alice Ltd Web Services,CN=www.example.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) 輸出還將顯示X509v3擴展。創建證書時，您使用了server_cert或usr_cert擴展項，相應配置部分中的選項將反映在輸出中： X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Server Netscape Comment: OpenSSL Generated Server Certificate X509v3 Subject Key Identifier: B1:B8:88:48:64:B7:45:52:21:CC:35:37:9E:24:50:EE:AD:58:02:B5 X509v3 Authority Key Identifier: keyid:69:E8:EC:54:7F:25:23:60:E5:B6:E7:72:61:F1:D4:B9:21:D4:45:E9 DirName:/C=GB/ST=England/O=Alice Ltd/OU=Alice Ltd Certificate Authority/CN=Alice Ltd Root CA serial:10:00 X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication 使用我們先前創建的CA證書鏈文件（ca-chain.cert.pem）來驗證新證書是否具有有效的信任鏈。 # openssl verify -CAfile intermediate/certs/ca-chain.cert.pem intermediate/certs/www.example.com.cert.pem www.example.com.cert.pem: OK
6-4-4) 部署證書
現在，您可以將新證書部署到服務器，也可以將證書分發給客戶端。部署到服務器應用程序（例如Apache）時，確保以下文件可用：
ca-chain.cert.com
www.example.com.key.pem
www.example.com.cert.pem
如果您是從第三方獲得CSR，那就無需使用它的私鑰，因此只需將證書鏈文件（ca-chain.cert.pem）和證書（www.example.com.cert.pem）發回給它們。
6-5) 證書吊銷列表
證書吊銷列表 （CRL，見RFC5280） 提供已吊銷的證書的列表。客戶端應用程序（如 Web 瀏覽器）可以使用 CRL 檢查服務器的真實性。服務器應用程序（如Apache或OpenV.P.N）可以使用 CRL 拒絕訪問不再受信任的客戶端。
在公共可訪問的位置（例如http://example.com/intermediate.crl.pem）發佈 CRL，第三方可以從此位置獲取 CRL，以檢查他們依賴的證書是否已被吊銷。
注意：一些應用程序供應商已棄用CRL，而是使用聯機證書狀態協議（OCSP，百度RFC2560，有中文版）。
6-5-1) 準備配置文件
證書頒發機構在簽署證書時，通常會將CRL位置編碼到證書中，將crlDistributionPoints添加到適當的部分，對於本例，將其添加到[server_cert]部分。
[ server_cert ]
# ... snipped ...
crlDistributionPoints = URI:http://example.com/intermediate.crl.pem
6-5-2) 創建CRL
# cd /root/ca
# openssl ca -config intermediate/openssl.cnf -gencrl -out intermediate/crl/intermediate.crl.pem
注意：ca手冊頁的CRL OPTIONS部分包含有關如何創建CRL的更多信息。
您可以使用 crl 工具檢查 CRL 的內容：
openssl crl -in intermediate/crl/intermediate.crl.pem -noout -text
尚未吊銷任何證書，因此輸出將顯示“無吊銷證書”
您應該定期重新創建CRL。默認情況下，CRL在30天后過期。這由[CA_default]部分的default_crl_days選項控制。
讓我們看一個例子。愛麗絲（Alice）正在運行Apache服務器，並有一個私人文件夾，上面放着可愛的小貓圖片。 愛麗絲想授予她的朋友鮑勃（Bob）訪問此收藏的權限。
①Bob創建一個私鑰和證書籤名請求（CSR）:
cd /home/bob openssl genrsa -out [email protected] 2048 openssl req -new -key [email protected] -out [email protected] You are about to be asked to enter information that will be incorporated into your certificate request. ----- Country Name [XX]:US State or Province Name []:California Locality Name []:San Francisco Organization Name []:Bob Ltd Organizational Unit Name []: Common Name []:[email protected] Email Address []:
②Bob將自己的CSR發送給愛麗絲，愛麗絲隨後對其進行簽名：
cd /root/ca openssl ca -config intermediate/openssl.cnf -extension usr_cert -notext -md sha256 -in intermediate/csr/[email protected] -out intermediate/certs/[email protected]
③Alice 驗證證書是否有效：
openssl verify -CAfile intermediate/certs/ca-chain.cert.pem intermediate/certs/[email protected] [email protected]: OK
現在index.txt文件應包含一個新條目：
V 160420124740Z 1001 unknown ... /[email protected]
Alice向Bob發送簽名證書，Bob將證書安裝在自己的網絡瀏覽器中，現在可以訪問愛麗絲的小貓圖片，歡呼吧！
④但可悲的是，事實證明Bob行爲不端，Bob將Alice的小貓圖片發佈到了《***新聞》上，聲稱是他自己的照片並廣受歡迎，愛麗絲髮現了，需要立即撤銷了他的訪問權限：
cd /root/ca openssl ca -config intermediate/openssl.cnf -revoke intermediate/certs/[email protected] Enter pass phrase for intermediate.key.pem: secretpassword Revoking Certificate 1001. Data Base Updated
現在index.txt中與Bob的證書相對應的行以字符R開頭，這表示證書已被吊銷：
R 160420124740Z 150411125310Z 1001 unknown ... /[email protected]
撤銷Bob的證書後，Alice必須重新創建CRL。
6-5-4) 服務器端使用CRL
對於客戶端證書，通常是服務器端應用程序（如Apache）進行驗證。此應用程序需要具有對CRL的本地訪問權限。
對於Alice，她可以將SSLCARevocationPath指令添加到Apache配置中，然後將CRL複製到她的Web服務器上，下次Bob連接到Web服務器時，Apache將根據CRL檢查其客戶端證書並拒絕訪問。
同樣，OpenV.P.N具有crl-verfiy指令，因此它可以阻止證書被吊銷的客戶端。
6-5-5) 客戶端服使用CRL
對於服務器證書，通常是服務器端應用程序（如web瀏覽器）（譯者注：不知是否是英文原文的筆誤，Web瀏覽器應該是客戶端程序）進行驗證。此應用程序必須具有對CRL的刪除訪問權限。
如果使用包含crlDistributionPoints的擴展項簽署了證書，則客戶端應用程序可以讀取此信息並從指定位置獲取CRL。
CRL分發點在證書X509v3詳細信息中可見。
opnessl x509 -in cute-kitten-pictures.example.com.cert.pem -noout -text X509v3 CRL Distribution Points: Full Name: URI:http://example.com/intermediate.crl.pem
6-6) 在線證書狀態協議OCSP
百度RFC2560，有中文版。
聯機證書狀態協議（OCSP）是證書吊銷列表（CRL）的替代方案。與CRL類似，OCSP允許請求方（如web瀏覽器）確定證書的吊銷狀態。
當CA簽署證書時，它們通常會在證書中包含OCSP服務器地址。這在功能上與用於CRL的crlDistributionPoints相似。
例如，當服務器向web瀏覽器提供了證書，瀏覽器將向證書中指定的OCSP服務器地址發送查詢，OCSP響應者在此地址偵聽查詢，並以證書的吊銷狀態做出響應。
注：建議在可能的情況下使用OCSP，實際上您只需要OCSP來獲得網站證書，因爲一些web瀏覽器已不再支持CRL。
6-6-1) 準備配置文件
要使用OCSP，CA必須將OCSP服務器位置編碼到它所簽署的證書中。在適當的部分中使用authorityInfoAccess選項，在本例中指的是[ server_cert ]部分。
[ server_cert ]
# ... snipped ...
authorityInfoAccess = OCSP;URI:http://ocsp.example.com
6-6-2) 創建OCSP密鑰對
OCSP響應程序需要一個密鑰對，用來對發回給請求方的響應進行簽名。OCSP密鑰對必須由當前正在檢查的證書的同一CA簽署。
創建私鑰並使用 AES-256 對其進行加密保護：
# cd /root/ca # openssl genrsa -aes256 -out intermediate/private/ocsp.example.com.key.pem 4096
創建證書籤名請求（CSR），詳細信息通常應與簽名CA的詳細信息匹配。但是，公用名必須是完全限定的域名：
# cd /root/ca # openssl req -config intermediate/openssl.cnf -new -sha256 -key intermediate/private/ocsp.example.com.key.pem -out intermediate/csr/ocsp.example.com.csr.pem Enter pass phrase for intermediate.key.pem: secretpassword You are about to be asked to enter information that will be incorporated into your certificate request. ----- Country Name (2 letter code) [XX]:GB State or Province Name []:England Locality Name []: Organization Name []:Alice Ltd Organizational Unit Name []:Alice Ltd Certificate Authority Common Name []:ocsp.example.com Email Address []: 使用中間 CA 簽署 CSR: # openssl ca -config intermediate/openssl.cnf -extensions ocsp -days 375 -notext -md sha256 -in intermediate/csr/ocsp.example.com.csr.pem -out intermediate/certs/ocsp.example.com.cert.pem 驗證證書具有正確的X509v3擴展： # openssl x509 -noout -text \ -in intermediate/certs/ocsp.example.com.cert.pem X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: critical OCSP Signing
6-6-3) 吊銷證書
OpenSSL ocsp工具可以充當OCSP響應程序，但僅用於測試。存在可用於生產的OCSP響應程序，但是這些響應程序不在本指南的範圍內。
創建要測試的服務器證書：
# cd /root/ca # openssl genrsa -out intermediate/private/test.example.com.key.pem 2048 # openssl req -config intermediate/openssl.cnf -key intermediate/private/test.example.com.key.pem -new -sha256 -out intermediate/csr/test.example.com.csr.pem # openssl ca -config intermediate/openssl.cnf -extensions server_cert -days 375 -notext -md sha256 -in intermediate/csr/test.example.com.csr.pem -out intermediate/certs/test.example.com.cert.pem
在本地主機上運行OCSP響應程序。OCSP響應程序不會將吊銷狀態存儲在單獨的CRL文件中，而是直接讀取index.txt。響應使用OCSP私鑰對簽名（使用-rkey和-rsigner選項）：
openssl ocsp -port 127.0.0.1:2560 -text -sha256 -index intermediate/index.txt -CA intermediate/certs/ca-chain.cert.pem -rkey intermediate/private/ocsp.example.com.key.pem -rsigner intermediate/certs/ocsp.example.com.cert.pem -nrequest 1
另一個終端向OCSP響應程序發送查詢。-cert選項指定要查詢的證書：
# openssl ocsp -CAfile intermediate/certs/ca-chain.cert.pem -url http://127.0.0.1:2560 -resp_text -issuer intermediate/certs/intermediate.cert.pem -cert intermediate/certs/test.example.com.cert.pem
輸出的開頭顯示：
● 是否收到成功響應（OCSP 響應狀態：OCSP Response Status）
● 然後是響應者的身份（應答器 ID：Responder Id）
● 證書的吊銷狀態（證書狀態：Cert Status）
OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: ... CN = ocsp.example.com Produced At: Apr 11 12:59:51 2015 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: E35979B6D0A973EBE8AEDED75D8C27D67D2A0334 Issuer Key Hash: 69E8EC547F252360E5B6E77261F1D4B921D445E9 Serial Number: 1003 Cert Status: good This Update: Apr 11 12:59:51 2015 GMT
吊銷證書：
# openssl ca -config intermediate/openssl.cnf -revoke intermediate/certs/test.example.com.cert.pem Enter pass phrase for intermediate.key.pem: secretpassword Revoking Certificate 1003. Data Base Updated
如前所述，本機運行OCSP響應程序，另一個終端發送查詢。這次的輸出顯示的證書狀態已經改變：已吊銷和吊銷時間：
OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: ... CN = ocsp.example.com Produced At: Apr 11 13:03:00 2015 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: E35979B6D0A973EBE8AEDED75D8C27D67D2A0334 Issuer Key Hash: 69E8EC547F252360E5B6E77261F1D4B921D445E9 Serial Number: 1003 Cert Status: revoked Revocation Time: Apr 11 13:01:09 2015 GMT This Update: Apr 11 13:03:00 2015 GMT
6-7) 附錄
6-7-1) 根CA配置文件
# OpenSSL root CA 配置文件。 # Copy to `/root/ca/openssl.cnf`. [ ca ] # `man ca` default_ca = CA_default [ CA_default ] # 目錄和文件位置。 dir = /root/ca certs = $dir/certs crl_dir = $dir/crl new_certs_dir = $dir/newcerts database = $dir/index.txt serial = $dir/serial RANDFILE = $dir/private/.rand # 根私鑰和根證書。 private_key = $dir/private/ca.key.pem certificate = $dir/certs/ca.cert.pem # 用於證書吊銷列表。 crlnumber = $dir/crlnumber crl = $dir/crl/ca.crl.pem crl_extensions = crl_ext default_crl_days = 30 # 不推薦使用SHA-1，因此請改用SHA-2。 default_md = sha256 name_opt = ca_default cert_opt = ca_default default_days = 375 preserve = no policy = policy_strict [ policy_strict ] # 根CA只對match（匹配）的中間證書進行簽名。 # 請參閱`man ca`的POLICY FORMAT部分。 countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional [ policy_loose ] # 允許中間CA簽署更多種類的證書。 # 請參閱“ca”手冊頁的“策略格式”部分。 countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional [ req ] # `req` 工具選項 (`man req`). default_bits = 2048 distinguished_name = req_distinguished_name string_mask = utf8only # 不推薦使用SHA-1，請改用SHA-2。 default_md = sha256 # 使用 -x509選項時要添加的擴展項。 x509_extensions = v3_ca [ req_distinguished_name ] # See <https://en.wikipedia.org/wiki/Certificate_signing_request>. countryName = Country Name (2 letter code) stateOrProvinceName = State or Province Name localityName = Locality Name 0.organizationName = Organization Name organizationalUnitName = Organizational Unit Name commonName = Common Name emailAddress = Email Address #指定一些默認值（可選）。 countryName_default = GB stateOrProvinceName_default = England localityName_default = 0.organizationName_default = Alice Ltd organizationalUnitName_default = emailAddress_default = [ v3_ca ] # 典型CA的擴展（`man x509v3_config`）。 subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true keyUsage = critical, digitalSignature, cRLSign, keyCertSign [ v3_intermediate_ca ] ＃典型中間CA的擴展（`man x509v3_config`）。 subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true, pathlen:0 keyUsage = critical, digitalSignature, cRLSign, keyCertSign [ usr_cert ] # 客戶端證書的擴展項（`man x509v3_config`）。 basicConstraints = CA:FALSE nsCertType = client, email nsComment = "OpenSSL Generated Client Certificate" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment extendedKeyUsage = clientAuth, emailProtection [ server_cert ] # 服務器證書的擴展項 (`man x509v3_config`). basicConstraints = CA:FALSE nsCertType = server nsComment = "OpenSSL Generated Server Certificate" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer:always keyUsage = critical, digitalSignature, keyEncipherment extendedKeyUsage = serverAuth [ crl_ext ] # CRL擴展項(`man x509v3_config`). authorityKeyIdentifier=keyid:always [ ocsp ] # OCSP簽名證書的擴展項 (`man ocsp`). basicConstraints = CA:FALSE subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer keyUsage = critical, digitalSignature extendedKeyUsage = critical, OCSPSigning
6-7-2) 中間CA配置文件
# OpenSSL中間CA配置文件。 # Copy to `/root/ca/intermediate/openssl.cnf`. [ ca ] # `man ca` default_ca = CA_default [ CA_default ] # 目錄和文件位置。 dir = /root/ca/intermediate certs = $dir/certs crl_dir = $dir/crl new_certs_dir = $dir/newcerts database = $dir/index.txt serial = $dir/serial RANDFILE = $dir/private/.rand # 根私鑰和根證書。 private_key = $dir/private/intermediate.key.pem certificate = $dir/certs/intermediate.cert.pem # 用於證書吊銷列表。 crlnumber = $dir/crlnumber crl = $dir/crl/intermediate.crl.pem crl_extensions = crl_ext default_crl_days = 30 # 不推薦使用SHA-1，請改用SHA-2。 default_md = sha256 name_opt = ca_default cert_opt = ca_default default_days = 375 preserve = no policy = policy_loose [ policy_strict ] # 根CA只對match（匹配）的中間證書進行簽名。 # 請參閱`man ca`的POLICY FORMAT部分。 countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional [ policy_loose ] # 允許中間CA簽署更多種類的證書。 # 請參閱“ca”手冊頁的“策略格式”部分。 countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional [ req ] # `req` 工具選項 (`man req`)。 default_bits = 2048 distinguished_name = req_distinguished_name string_mask = utf8only # 不推薦使用SHA-1，請改用SHA-2。 default_md = sha256 # 使用 -x509選項時要添加的擴展項。 x509_extensions = v3_ca [ req_distinguished_name ] # See <https://en.wikipedia.org/wiki/Certificate_signing_request>. countryName = Country Name (2 letter code) stateOrProvinceName = State or Province Name localityName = Locality Name 0.organizationName = Organization Name organizationalUnitName = Organizational Unit Name commonName = Common Name emailAddress = Email Address # 指定一些默認值（可選）。 countryName_default = GB stateOrProvinceName_default = England localityName_default = 0.organizationName_default = Alice Ltd organizationalUnitName_default = emailAddress_default = [ v3_ca ] # 典型CA的擴展（`man x509v3_config`）。 subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true keyUsage = critical, digitalSignature, cRLSign, keyCertSign [ v3_intermediate_ca ] ＃典型中間CA的擴展（`man x509v3_config`）。 subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true, pathlen:0 keyUsage = critical, digitalSignature, cRLSign, keyCertSign [ usr_cert ] # 客戶端證書的擴展項（`man x509v3_config`）。 basicConstraints = CA:FALSE nsCertType = client, email nsComment = "OpenSSL Generated Client Certificate" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment extendedKeyUsage = clientAuth, emailProtection [ server_cert ] # 服務器證書的擴展項 (`man x509v3_config`)。 basicConstraints = CA:FALSE nsCertType = server nsComment = "OpenSSL Generated Server Certificate" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer:always keyUsage = critical, digitalSignature, keyEncipherment extendedKeyUsage = serverAuth [ crl_ext ] # CRL擴展項(`man x509v3_config`)。 authorityKeyIdentifier=keyid:always [ ocsp ] # OCSP簽名證書的擴展項 (`man ocsp`) basicConstraints = CA:FALSE subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer keyUsage = critical, digitalSignature extendedKeyUsage = critical, OCSPSigning