溫馨提示×
您好，登錄后才能下訂單哦！
點(diǎn)擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》
您好，登錄后才能下訂單哦！
本文以X.509證書為例，為大家詳細(xì)介紹了X.509證書的概念和證書結(jié)構(gòu)，以及X.509證書的使用方法，閱讀完整文相信大家對X.509證書有了一定的認(rèn)識。
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)識（主機(jī)名、組織或個(gè)人），并由證書頒發(fā)機(jī)構(gòu)（CA）簽名（或自簽名）。對于一份經(jīng)由可信的證書簽發(fā)機(jī)構(gòu)簽名（或者可以通過其它方式驗(yàn)證）的證書，證書的擁有者就可以用證書及相應(yīng)的私鑰來創(chuàng)建安全的通信，以及對文檔進(jìn)行數(shù)字簽名。
X.509最早與X.500一起發(fā)布于1988年7月3日，它假定頒發(fā)證書的證書頒發(fā)機(jī)構(gòu)（CA）具有嚴(yán)格的層次結(jié)構(gòu)。這與Web信任模型（如PGP）形成了鮮明對比，因?yàn)镻GP方案是任何人都以簽名（而不僅僅是地位特殊的CA），從而證明其他人的密鑰證書的有效性。X.509 V3證書的設(shè)計(jì)非常靈活，除了對網(wǎng)橋拓?fù)浼軜?gòu)網(wǎng)絡(luò)的支持，還可以支持用于點(diǎn)對點(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工作組已對該標(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，包括對IETF的PKIX證書和證書吊銷列表（CRL Profile），通常也稱為公鑰基礎(chǔ)設(shè)施。
在X.509系統(tǒng)中，證書申請者通過發(fā)起“證書簽名請求（CSR）”來得到一份被簽名的證書。為此，它需要生成一個(gè)密鑰對，然后用其中的私鑰對CSR簽名（私鑰本身要妥善保存，對外保密），CSR包含申請人的身份信息、用于驗(yàn)真CSR的申請人的公鑰，以及所請求證書的專有名稱（DN），CSR還可能帶有CA要求的其它有關(guān)身份證明的信息，然后CA對這個(gè)專有名稱發(fā)布一份證書，并綁定一個(gè)公鑰。
組織機(jī)構(gòu)可以把受信的根證書分發(fā)給所有的成員，這樣就可以使用公司的PKI系統(tǒng)了。像Firefox, IE, Opera, Safari 以及Google Chrome這些瀏覽器都預(yù)裝了一組CA根證書，所以可以直接使用這些主流CA發(fā)布的SSL證書。瀏覽器的開發(fā)者直接影響它的用戶對第三方的信任。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版本號
● 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ā)者唯一標(biāo)識符（可選）
● Subject Unique Identifier (optional)主題唯一標(biāo)識符（可選）
● 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ò)展的用途，就要拒絕使用它。但對于非決定性的擴(kuò)展，不認(rèn)識可以予以忽略。RFC 1422給出了v1的證書結(jié)構(gòu)，ITU-T在v2里增加了頒發(fā)者和主題唯一標(biāo)識符，從而可以在一段時(shí)間后重用。重用的一個(gè)例子是當(dāng)一個(gè)CA破產(chǎn)了，它的名稱也在公共列表里清除掉了，一段時(shí)間之后另一個(gè)CA可以用相同的名稱來注冊，即使它與之前的并沒有任何瓜葛。不過IETF并不建議重用同名注冊。另外v2也沒有在Internet里大范圍的使用。v3引入了擴(kuò)展，CA使用擴(kuò)展來發(fā)布一份特定使用目的的證書（比如說僅用于代碼簽名）。
對于所有的版本，同一個(gè)CA頒發(fā)的證書序列號都必須是唯一的。
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í)，會同時(shí)對這個(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è)文件中交換公共和私有對象。
證書鏈（也就是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è)證書，從而建立完全不同的證書鏈。 這對于PKI與其他應(yīng)用程序之間的交叉認(rèn)證至關(guān)重要，詳見以下示例。
下圖每個(gè)框代表一個(gè)證書，主題以粗體顯示，A→B表示“ A由B簽名”（或更準(zhǔn)確地說，A由B包含公鑰相對應(yīng)的私鑰簽名），具有相同顏色（非白色/透明）的證書包含相同的公鑰。
例1：兩個(gè)PKI之間，在根證書頒發(fā)機(jī)構(gòu)（CA）級別上進(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è)是新的私鑰對舊的公鑰進(jìn)行簽名，另一個(gè)是舊的私鑰對新的公鑰的簽名，這兩個(gè)證書都是自頒發(fā)的，但都不是自簽名。注：另外還存在新舊兩個(gè)自簽名證書。
假設(shè)cert1和cert3包含相同的公鑰（舊的公鑰），對于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í)體證書中的證書主體是不能使用證書所對應(yīng)的私鑰簽發(fā)證書的。最終實(shí)體與CA是兩個(gè)相對的概念：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)識符（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書保存在眾多安全層之后，以確保其密鑰絕對不可訪問。由于根證書簽署了中間證書，因此中間證書可用于簽署客戶安裝和維護(hù)的SSL“信任鏈”。
注意：如果不使用已頒發(fā)的SSL證書安裝中間證書，則可能無法建立可信鏈證書。這意味著，當(dāng)訪問者試圖訪問您的網(wǎng)站時(shí)，他們可能會收到一個(gè)“安全警報(bào)”錯(cuò)誤，指示“安全證書是由您未選擇信任的公司頒發(fā)的…”面對這樣的警告，潛在客戶很可能會將其業(yè)務(wù)轉(zhuǎn)移到其他地方。
以下是中間證書的實(shí)例，此證書被CA根證書簽署，并簽署了上面的最終實(shí)體證書。
注意：此中間證書的subject字段與它所簽署的最終實(shí)體證書的issuer字段相同、中間證書的subject key identifier（主題密鑰標(biāo)識符）字段與最終實(shí)體證書的的authority key identifier（頒發(fā)者的密鑰標(biāo)識符）字段相同。
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（主題，使用者字段）是相同的，能夠使用自己的公鑰對簽名進(jìn)行驗(yàn)證，信任鏈的驗(yàn)證必須在此結(jié)束。如果驗(yàn)證程序在其信任存儲中有此根證書，就可以認(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ī)的情況下就會出現(xiàn)誤判，因?yàn)楫?dāng)CRL不可用時(shí)，大多數(shù)客戶端都會信任證書，于是攻.擊者可以通過切斷信道來禁用CRL。谷歌（Google）的亞當(dāng)?蘭利（Adam Langley）曾表示，CRL軟故障檢查就像一條安全帶，只有在發(fā)生事故時(shí)才起作用。
● CRL的尺寸較大且分布模式復(fù)雜，因此它不是一個(gè)很好的選擇，
● OCSP語義模糊，缺乏歷史撤銷狀態(tài)；
● 未解決根證書吊銷的問題
● 聚合問題：身份聲明（通過標(biāo)識符進(jìn)行身份驗(yàn)證）、屬性聲明（提交一包經(jīng)過審核的屬性）和策略聲明組合在一個(gè)容器中，這會引發(fā)隱私、策略映射和維護(hù)問題。
● 委派問題：從技術(shù)上講，CA無法限制下級CA在有限的名稱空間或?qū)傩约忸C發(fā)證書；X.509的此功能未被使用。因此，互聯(lián)網(wǎng)上存在大量的CA，對它們進(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）證書不會阻止頒發(fā)對同一主機(jī)名較低驗(yàn)證證書的頒發(fā)，這意味著較高的EV驗(yàn)證級別無法抵御中間人攻.擊。
如果是主體而不是依賴方購買證書，通常會使用最便宜的頒發(fā)者，頒發(fā)者出于成本考慮，往往采用擴(kuò)展驗(yàn)證證書來解決問題，但是在安全專家看來，信任價(jià)值正在下降。
● 證書頒發(fā)機(jī)構(gòu)否認(rèn)對用戶（包括主題或依賴方）的幾乎所有保證。
● 有效期應(yīng)用于限制密鑰強(qiáng)度被視為時(shí)間足夠，此參數(shù)被證書頒發(fā)機(jī)構(gòu)濫用以向客戶端收取擴(kuò)展費(fèi)。這給使用密鑰滾動的用戶帶來了不必要的負(fù)擔(dān)。（沒看懂啥意思）
●“用戶使用未定義的認(rèn)證請求協(xié)議來獲取證書，該證書發(fā)布于不存在的目錄中的不明確位置，從而無有效手段來撤銷它?！?
與所有企業(yè)一樣，CA受其經(jīng)營站點(diǎn)的法律管轄，并可能被迫損害其客戶和用戶的利益。情報(bào)機(jī)構(gòu)還利用了通過CA的法外妥協(xié)發(fā)出的虛假證書（例如DigiNotar）來進(jìn)行中間人攻.擊。另一個(gè)例子是荷蘭政府CA的撤銷請求，由于新的荷蘭法律自2018年1月1日起生效，為荷蘭情報(bào)和安全部門賦予了新的權(quán)力。
X.509實(shí)現(xiàn)存在設(shè)計(jì)缺陷、錯(cuò)誤、對標(biāo)準(zhǔn)的不同解釋以及不同標(biāo)準(zhǔn)的互操作性問題，一些問題是：
● 許多實(shí)現(xiàn)關(guān)閉吊銷檢查：
● 策略被視為障礙，沒有得到執(zhí)行
● 如果默認(rèn)情況下在所有瀏覽器（包括代碼簽名）中都打開了它，可能會破壞基礎(chǔ)結(jié)構(gòu)
● DN很復(fù)雜且不容易理解（缺乏規(guī)范化、國際化問題……）
● RFC822名稱有2種表示法
● 幾乎不支持名稱和策略約束
● keyUsage被忽略，使用列表中的第一個(gè)證書
● 自定義oid的實(shí)施很困難
● 不應(yīng)將屬性設(shè)為強(qiáng)制屬性，因?yàn)樗鼤箍蛻舳吮罎?/span>
● 未指定的屬性長度會導(dǎo)致特定于產(chǎn)品的限制
● X.509存在實(shí)現(xiàn)錯(cuò)誤，例如允許在證書中使用以空值結(jié)尾的字符串，或通過代碼注入攻.擊來偽造使用者名稱。
● 通過使用對象標(biāo)識符的0x80填充子標(biāo)識符，錯(cuò)誤的實(shí)現(xiàn)或通過使用客戶端瀏覽器的整數(shù)溢出，攻.擊者可以在CSR中包含一個(gè)未知屬性，CA會將其簽名，客戶端錯(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è)證書包含相同的簽名，并且只在公鑰上不同，這是通過對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é)會議上，麥格理大學(xué)（Macquarie University）的澳大利亞研究人員提出了“自動差分路徑搜索SHA-1”，研究人員能夠推導(dǎo)出一種將碰撞的可能性增加了幾個(gè)數(shù)量級的方法。
● 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ī)因素（通常是序列號）可以在某種程度上緩解這種情況。自2011年以來，CA /瀏覽器論壇已在其基準(zhǔn)要求第7.1節(jié)中要求序列號熵。
所以，序列號是作為一個(gè)隨機(jī)干擾源而存在，它是保密的，在簽署證書之前不能對外泄露。
自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)樵摴颈Ａ袅藢λ鼈兊目刂茩?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對消息摘要的加密，隨后合并到PKCS＃1中。
● PKCS＃3 1.4 Diffie-Hellman密鑰協(xié)商標(biāo)準(zhǔn)，一種加密協(xié)議，它允許彼此不具有先驗(yàn)知識的雙方在不安全的通信信道上共同建立共享的秘密密鑰。
● 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)，定義對舊的v1 X.509證書規(guī)范的擴(kuò)展，被v3淘汰。
● PKCS＃7 1.5加密消息語法標(biāo)準(zhǔn)，請參閱RFC2315。用于在PKI下對消息進(jìn)行簽名和/或加密。也用于證書分發(fā)（例如作為對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)，請參見RFC5958。用于攜帶私鑰證書密鑰對（加密或未加密）。
● PKCS＃9 2.0選定的屬性類型[，請參見RFC2985。定義選定的屬性類型，以便在PKCS＃6擴(kuò)展證書、PKCS＃7數(shù)字簽名消息、PKCS＃8私鑰信息和PKCS＃10證書簽名請求中使用。
● PKCS＃10 1.7認(rèn)證請求標(biāo)準(zhǔn)，請參閱RFC2986。發(fā)送給認(rèn)證機(jī)構(gòu)以請求公鑰證書的消息格式，請參閱證書簽名請求。
● PKCS＃11 2.40密碼令牌接口，也稱為“ Cryptoki”。定義密碼令牌通用接口的API（另請參閱硬件安全模塊）。常用于單點(diǎn)登錄，公共密鑰加密和磁盤加密[10]系統(tǒng)。 RSA Security已將PKCS＃11標(biāo)準(zhǔn)的進(jìn)一步開發(fā)移交給了OASIS PKCS 11技術(shù)委員會。
● PKCS＃12 1.1個(gè)人信息交換語法標(biāo)準(zhǔn)，請參閱RFC7292。定義一種文件格式，個(gè)人信息交換語法標(biāo)準(zhǔn)[11]見RFC 7292。定義一種文件格式，通常用于存儲私鑰和附帶的公鑰證書，并使用基于Password的對稱密鑰進(jìn)行保護(hù)。PFX是PKCS#12的前身。
此容器格式可以包含多個(gè)嵌入式對象，例如多個(gè)證書。通常使用密碼進(jìn)行保護(hù)/加密?？捎米鱆ava密鑰存儲的格式，并在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)識自己，而與應(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)意味著要處理密鑰對之中的私鑰和公鑰證書。
我們要?jiǎng)?chuàng)建的第一個(gè)密鑰對就是根對。這包括根密鑰（ca.key.pem）和根證書（ca.cert.pem）。這個(gè)“根對”構(gòu)成了你的CA的身份。
通常，根CA不會直接為服務(wù)器或客戶端證書簽名，根CA僅用于創(chuàng)建一個(gè)或多個(gè)中間CA，這些中間CA被根CA信任，并代表根CA簽署證書，這是最佳實(shí)踐，它允許根密鑰保持脫機(jī)狀態(tài)并盡可能減少使用的次數(shù)，因?yàn)閷Ω娜魏瓮{都是災(zāi)難性的。
注意：
最佳實(shí)踐是在安全的環(huán)境中創(chuàng)建根對。理想情況下，該計(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)。
[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]部分包含一系列默認(rèn)值，其中的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簽名應(yīng)用policy_strict，因?yàn)楦鵆A僅用于創(chuàng)建中間CA。 [ policy_strict] # 根CA只對匹配的中間證書進(jìn)行簽名 # 請參閱“man ca”的策略格式部分。 countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional 如果值是“ match”，意為請求文件的該字段取值，必須與簽署時(shí)輸入的CA證書的對應(yīng)字段取值一模一樣；如果值是“supplied”，那么它必須存在。如果該值為“optional”，則可選（可留空）；所以我們將對所有中間CA簽名應(yīng)用policy_loose而不是policy_strict，因?yàn)橹虚gCA正在對可能來自各種第三方的服務(wù)器和客戶端證書進(jìn)行簽名。 [ policy_loose ] # 允許中間CA簽署更多種證書 # 請參見`ca`手冊頁的“策略格式”部分 countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional 在創(chuàng)建證書或證書簽名請求時(shí)，將應(yīng)用[req]部分中的選項(xiàng)。 [ req ] #req”工具的選項(xiàng)（“man req”） default_bits = 2048 distinguished_name = req_distinguished_name string_mask = utf8only # HA-1已棄用，因此請改用SHA-2 default_md = sha256 # 使用-x509選項(xiàng)時(shí)要添加的擴(kuò)展項(xiàng)。 x509_extensions = v3_ca [req_distinguished_name]聲明證書簽名請求中通常所需的信息，您可以選擇指定一些默認(rèn)值。 [ 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 = 接下來的幾個(gè)部分是在簽署證書時(shí)可以應(yīng)用的擴(kuò)展項(xiàng)，例如 -extensions v3_ca命令行參數(shù)將應(yīng)用[v3_ca]中設(shè)置的選項(xiàng)。 我們將在創(chuàng)建根證書時(shí)應(yīng)用[v3_ca]擴(kuò)展： [ v3_ca ] #典型的CA擴(kuò)展 (`查看x509v3_config手冊`). subjectKeyIdentifier = hash autorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true keyUsage = critical, digitalSignature, cRLsign, keyCertSign 我們將在創(chuàng)建中間證書時(shí)應(yīng)用v3_ca_intermediate extension（中間擴(kuò)展項(xiàng)），pathlen:0保證在中間CA下面不能有其他證書頒發(fā)機(jī)構(gòu)： [ v3_intermediate_ca ] # 典型的中間CA的擴(kuò)展 (`查看x509v3_config手冊`). subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true, pathlen:0 keyUsage = critical, digitalSignature, cRLSign, keyCertSign 我們將在簽署server_cert（服務(wù)器證書，例如用于web服務(wù)器的證書）時(shí)應(yīng)用服務(wù)器證書擴(kuò)展： [ 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 創(chuàng)建證書吊銷列表時(shí)，將自動應(yīng)用crl_ext擴(kuò)展項(xiàng)： [ crl_ext ] # CRL的擴(kuò)展(`查看x509v3_config手冊`). authorityKeyIdentifier=keyid:always 在簽署在線證書狀態(tài)協(xié)議（OCSP）證書時(shí)，我們將使用ocsp擴(kuò)展項(xiàng)： [ ocsp ] # OCSP簽名證書的擴(kuò)展項(xiàng)(`man ocsp`). basicConstraints = CA:FALSE subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer keyUsage = critical, digitalSignature extendedKeyUsage = critical, OCSPSigning
創(chuàng)建根私鑰（ca.key.pem）并確保其絕對安全，因?yàn)槿魏螕碛懈借€的人都可以頒發(fā)“可信證書”，建議使用AES 256算法和復(fù)雜的強(qiáng)密碼加密根私鑰。
注意：出于安全考慮，對所有根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
使用根密鑰（ca.key.pem）創(chuàng)建根證書（ca.cert.pem），給根證書一個(gè)長的有效期，比如20年。根證書過期后，由根CA簽名的所有證書都將無效。
警告：無論何時(shí)使用req工具，都必須指定要與-config選項(xiàng)一起使用的配置文件，否則OpenSSL將默認(rèn)為/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 []:
openssl x509 -noout -text -in certs/ca.cert.pem
這行命令的輸出包括：
● 使用的簽名算法
● 證書生效期
● 公鑰位長度
● 頒發(fā)者，即簽署證書的實(shí)體
● 主體，指的是證書本身
由于證書是自簽名的，因此頒發(fā)者和主題相同。
請注意，所有根證書都是自簽名的。
注：以下的黃色漢字是注釋，并非證書的組成部分 Signature Algorithm: sha256WithRSAEncryption # 使用的簽名算法 Issuer: C=GB, ST=England, O=Alice Ltd, OU=Alice Ltd Certificate Authority, CN=Alice Ltd Root CA # 頒發(fā)者 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) # 公鑰位長度
中間證書授權(quán)（CA）是可以代表根CA簽署證書的實(shí)體，根CA簽署中間證書，這就形成了信任鏈。
使用中間證書的目的主要是：根密鑰可以保持脫機(jī)狀態(tài)，并盡可能不頻繁地使用。如果中間密鑰被泄露，根CA可以撤銷中間證書并創(chuàng)建新的中間密鑰對。
根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復(fù)制到/root/CA/intermediate/openssl.cnf。注意與根CA配置文件相比，以下五個(gè)選項(xiàng)變化了： [ 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) 創(chuàng)建中間密鑰
創(chuàng)建中間密鑰（intermediate.key.pem），并使用AES 256算法和復(fù)雜的強(qiáng)密碼將其加密保護(hù)。
# 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) 創(chuàng)建中間證書
使用中間證書創(chuàng)建證書簽名請求（CSR），詳細(xì)信息通常應(yīng)與根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 []:
要?jiǎng)?chuàng)建中間證書，請使用帶有v3_intermediate_CA擴(kuò)展項(xiàng)的根CA對中間CSR進(jìn)行簽名。中間證書的有效期應(yīng)短于根證書。十年是合理的。
警告：指定根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工具存儲證書數(shù)據(jù)庫的位置，請勿手動刪除或編輯此文件。現(xiàn)在它應(yīng)該包含剛才創(chuàng)建的中間證書： V 250408122707Z 1000 unknown ... /CN=Alice Ltd Intermediate CA
6-3-4) 驗(yàn)證中間證書
正如我們對根證書所做的那樣，請檢查中間證書的詳細(xì)信息是否正確：
# openssl x509 -noout -text -in intermediate/certs/intermediate.cert.pem
intermediate.cert.pem: OK
當(dāng)應(yīng)用程序（如web瀏覽器）嘗試驗(yàn)證由中間CA簽名的證書時(shí)，它必須對照根證書驗(yàn)證中間證書。要完成信任鏈，請創(chuàng)建CA證書鏈以呈現(xiàn)給應(yīng)用程序。
要?jiǎng)?chuàng)建CA證書鏈，請將中間證書和根證書連接在一起，我們稍后將使用此文件來驗(yàn)證由中間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
注意：證書鏈文件必須包含根證書，因?yàn)樾枰?/span>客戶端應(yīng)用程序找到它。更好的選擇（尤其是在管理Intranet的情況下）是在需要連接的每個(gè)客戶端上安裝根證書，在這種情況下，證書鏈文件僅需要包含您的中間證書。
我們將使用中間 CA 簽署證書。您可以在各種情況下使用這些證書，例如保護(hù)與 Web 服務(wù)器的連接或?qū)B接到服務(wù)器的客戶端進(jìn)行身份驗(yàn)證。
注意：以下步驟是CA替申請者創(chuàng)建私鑰和簽名請求（CSR），但申請者從安全角度考慮也可以自己創(chuàng)建私鑰和請求，其中的私鑰妥善保存于本地，把CSR交給CA，CA則還給它一個(gè)簽名的證書。在這種情況下，跳過 genrsa 和 req 命令。
我們的根密鑰對和中間密鑰對是4096位，服務(wù)器證書和客戶端證書通常在一年后過期，因此我們可以安全地使用2048位。
注意：盡管4096位比2048位更安全，但它會減慢TLS握手速度并顯著增加握手期間的處理器負(fù)載。因此，大多數(shù)網(wǎng)站使用2048位的密鑰對。
譯者注：2048位已經(jīng)不再安全，建議使用4096或8192位。
如果要?jiǎng)?chuàng)建用于網(wǎng)絡(luò)服務(wù)器的密鑰對，每次重啟該服務(wù)器時(shí)都需要輸保護(hù)密碼，如果嫌麻煩可以不使用-aes256選項(xiàng)以創(chuàng)建沒有密碼的私鑰。
# 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) 創(chuàng)建證書
使用私鑰創(chuàng)建證書簽名請求（CSR），并且CSR的詳細(xì)信息無需與中間CA相匹配。對于服務(wù)器證書，Common Name（公用名）必須是FQDN（完全限定的域名，例如，www.example.com），而對于客戶端證書，Common Name可以是任何唯一標(biāo)識符（例如電子郵件地址），請注意，客戶端證書的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 []:
要?jiǎng)?chuàng)建證書，請使用中間CA對CSR進(jìn)行簽名。如果要在服務(wù)器上使用證書，請使用 server_cert擴(kuò)展項(xiàng);如果證書將用于用戶身份驗(yàn)證，請使用usr_cert擴(kuò)展項(xiàng)。證書的有效期通常為一年，不過為了方便起見，CA通常會多給幾天時(shí)間。
# 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應(yīng)該出現(xiàn)包含該證書的行： V 160420124233Z 1000 unknown ... /CN=www.example.com
6-4-3) 驗(yàn)證證書
# openssl x509 -noout -text -in intermediate/certs/www.example.com.cert.pem
Issuer（頒發(fā)者）是中間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擴(kuò)展。創(chuàng)建證書時(shí)，您使用了server_cert或usr_cert擴(kuò)展項(xiàng)，相應(yīng)配置部分中的選項(xiàng)將反映在輸出中： 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 使用我們先前創(chuàng)建的CA證書鏈文件（ca-chain.cert.pem）來驗(yàn)證新證書是否具有有效的信任鏈。 # 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) 部署證書
現(xiàn)在，您可以將新證書部署到服務(wù)器，也可以將證書分發(fā)給客戶端。部署到服務(wù)器應(yīng)用程序（例如Apache）時(shí)，確保以下文件可用：
ca-chain.cert.com
www.example.com.key.pem
www.example.com.cert.pem
如果您是從第三方獲得CSR，那就無需使用它的私鑰，因此只需將證書鏈文件（ca-chain.cert.pem）和證書（www.example.com.cert.pem）發(fā)回給它們。
證書吊銷列表 （CRL，見RFC5280） 提供已吊銷的證書的列表。客戶端應(yīng)用程序（如 Web 瀏覽器）可以使用 CRL 檢查服務(wù)器的真實(shí)性。服務(wù)器應(yīng)用程序（如Apache或OpenV.P.N）可以使用 CRL 拒絕訪問不再受信任的客戶端。
在公共可訪問的位置（例如http://example.com/intermediate.crl.pem）發(fā)布 CRL，第三方可以從此位置獲取 CRL，以檢查他們依賴的證書是否已被吊銷。
注意：一些應(yīng)用程序供應(yīng)商已棄用CRL，而是使用聯(lián)機(jī)證書狀態(tài)協(xié)議（OCSP，百度RFC2560，有中文版）。
證書頒發(fā)機(jī)構(gòu)在簽署證書時(shí)，通常會將CRL位置編碼到證書中，將crlDistributionPoints添加到適當(dāng)?shù)牟糠郑瑢τ诒纠?，將其添加?/span>[server_cert]部分。
[ server_cert ]
# ... snipped ...
crlDistributionPoints = URI:http://example.com/intermediate.crl.pem
# cd /root/ca
# openssl ca -config intermediate/openssl.cnf -gencrl -out intermediate/crl/intermediate.crl.pem
注意：ca手冊頁的CRL OPTIONS部分包含有關(guān)如何創(chuàng)建CRL的更多信息。
您可以使用 crl 工具檢查 CRL 的內(nèi)容：
openssl crl -in intermediate/crl/intermediate.crl.pem -noout -text
尚未吊銷任何證書，因此輸出將顯示“無吊銷證書”
您應(yīng)該定期重新創(chuàng)建CRL。默認(rèn)情況下，CRL在30天后過期。這由[CA_default]部分的default_crl_days選項(xiàng)控制。
讓我們看一個(gè)例子。愛麗絲（Alice）正在運(yùn)行Apache服務(wù)器，并有一個(gè)私人文件夾，上面放著可愛的小貓圖片。 愛麗絲想授予她的朋友鮑勃（Bob）訪問此收藏的權(quán)限。
①Bob創(chuàng)建一個(gè)私鑰和證書簽名請求（CSR）:
cd /home/bob openssl genrsa -out bob@example.com.key.pem 2048 openssl req -new -key bob@example.com.key.pem -out bob@example.com.csr.pem 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 []:bob@example.com Email Address []:
②Bob將自己的CSR發(fā)送給愛麗絲，愛麗絲隨后對其進(jìn)行簽名：
cd /root/ca openssl ca -config intermediate/openssl.cnf -extension usr_cert -notext -md sha256 -in intermediate/csr/bob@example.com.csr.pem -out intermediate/certs/bob@example.com.cert.pem
③Alice 驗(yàn)證證書是否有效：
openssl verify -CAfile intermediate/certs/ca-chain.cert.pem intermediate/certs/bob@example.com.cert.pem bob@example.com.cert.pem: OK
現(xiàn)在index.txt文件應(yīng)包含一個(gè)新條目：
V 160420124740Z 1001 unknown ... /CN=bob@example.com
Alice向Bob發(fā)送簽名證書，Bob將證書安裝在自己的網(wǎng)絡(luò)瀏覽器中，現(xiàn)在可以訪問愛麗絲的小貓圖片，歡呼吧！
④但可悲的是，事實(shí)證明Bob行為不端，Bob將Alice的小貓圖片發(fā)布到了《***新聞》上，聲稱是他自己的照片并廣受歡迎，愛麗絲發(fā)現(xiàn)了，需要立即撤銷了他的訪問權(quán)限：
cd /root/ca openssl ca -config intermediate/openssl.cnf -revoke intermediate/certs/bob@example.com.cert.pem Enter pass phrase for intermediate.key.pem: secretpassword Revoking Certificate 1001. Data Base Updated
現(xiàn)在index.txt中與Bob的證書相對應(yīng)的行以字符R開頭，這表示證書已被吊銷：
R 160420124740Z 150411125310Z 1001 unknown ... /CN=bob@example.com
撤銷Bob的證書后，Alice必須重新創(chuàng)建CRL。
6-5-4) 服務(wù)器端使用CRL
對于客戶端證書，通常是服務(wù)器端應(yīng)用程序（如Apache）進(jìn)行驗(yàn)證。此應(yīng)用程序需要具有對CRL的本地訪問權(quán)限。
對于Alice，她可以將SSLCARevocationPath指令添加到Apache配置中，然后將CRL復(fù)制到她的Web服務(wù)器上，下次Bob連接到Web服務(wù)器時(shí)，Apache將根據(jù)CRL檢查其客戶端證書并拒絕訪問。
同樣，OpenV.P.N具有crl-verfiy指令，因此它可以阻止證書被吊銷的客戶端。
對于服務(wù)器證書，通常是服務(wù)器端應(yīng)用程序（如web瀏覽器）（譯者注：不知是否是英文原文的筆誤，Web瀏覽器應(yīng)該是客戶端程序）進(jìn)行驗(yàn)證。此應(yīng)用程序必須具有對CRL的刪除訪問權(quán)限。
如果使用包含crlDistributionPoints的擴(kuò)展項(xiàng)簽署了證書，則客戶端應(yīng)用程序可以讀取此信息并從指定位置獲取CRL。
CRL分發(fā)點(diǎn)在證書X509v3詳細(xì)信息中可見。
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) 在線證書狀態(tài)協(xié)議OCSP
百度RFC2560，有中文版。
聯(lián)機(jī)證書狀態(tài)協(xié)議（OCSP）是證書吊銷列表（CRL）的替代方案。與CRL類似，OCSP允許請求方（如web瀏覽器）確定證書的吊銷狀態(tài)。
當(dāng)CA簽署證書時(shí)，它們通常會在證書中包含OCSP服務(wù)器地址。這在功能上與用于CRL的crlDistributionPoints相似。
例如，當(dāng)服務(wù)器向web瀏覽器提供了證書，瀏覽器將向證書中指定的OCSP服務(wù)器地址發(fā)送查詢，OCSP響應(yīng)者在此地址偵聽查詢，并以證書的吊銷狀態(tài)做出響應(yīng)。
注：建議在可能的情況下使用OCSP，實(shí)際上您只需要OCSP來獲得網(wǎng)站證書，因?yàn)橐恍﹚eb瀏覽器已不再支持CRL。
要使用OCSP，CA必須將OCSP服務(wù)器位置編碼到它所簽署的證書中。在適當(dāng)?shù)牟糠种惺褂胊uthorityInfoAccess選項(xiàng)，在本例中指的是[ server_cert ]部分。
[ server_cert ]
# ... snipped ...
authorityInfoAccess = OCSP;URI:http://ocsp.example.com
OCSP響應(yīng)程序需要一個(gè)密鑰對，用來對發(fā)回給請求方的響應(yīng)進(jìn)行簽名。OCSP密鑰對必須由當(dāng)前正在檢查的證書的同一CA簽署。
創(chuàng)建私鑰并使用 AES-256 對其進(jìn)行加密保護(hù)：
# cd /root/ca # openssl genrsa -aes256 -out intermediate/private/ocsp.example.com.key.pem 4096
創(chuàng)建證書簽名請求（CSR），詳細(xì)信息通常應(yīng)與簽名CA的詳細(xì)信息匹配。但是，公用名必須是完全限定的域名：
# 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 驗(yàn)證證書具有正確的X509v3擴(kuò)展： # 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工具可以充當(dāng)OCSP響應(yīng)程序，但僅用于測試。存在可用于生產(chǎn)的OCSP響應(yīng)程序，但是這些響應(yīng)程序不在本指南的范圍內(nèi)。
創(chuàng)建要測試的服務(wù)器證書：
# 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
在本地主機(jī)上運(yùn)行OCSP響應(yīng)程序。OCSP響應(yīng)程序不會將吊銷狀態(tài)存儲在單獨(dú)的CRL文件中，而是直接讀取index.txt。響應(yīng)使用OCSP私鑰對簽名（使用-rkey和-rsigner選項(xiàng)）：
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
另一個(gè)終端向OCSP響應(yīng)程序發(fā)送查詢。-cert選項(xiàng)指定要查詢的證書：
# 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
輸出的開頭顯示：
● 是否收到成功響應(yīng)（OCSP 響應(yīng)狀態(tài)：OCSP Response Status）
● 然后是響應(yīng)者的身份（應(yīng)答器 ID：Responder Id）
● 證書的吊銷狀態(tài)（證書狀態(tài)：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
如前所述，本機(jī)運(yùn)行OCSP響應(yīng)程序，另一個(gè)終端發(fā)送查詢。這次的輸出顯示的證書狀態(tài)已經(jīng)改變：已吊銷和吊銷時(shí)間：
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) 附錄
# 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（匹配）的中間證書進(jìn)行簽名。 # 請參閱`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` 工具選項(xiàng) (`man req`). default_bits = 2048 distinguished_name = req_distinguished_name string_mask = utf8only # 不推薦使用SHA-1，請改用SHA-2。 default_md = sha256 # 使用 -x509選項(xiàng)時(shí)要添加的擴(kuò)展項(xiàng)。 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 #指定一些默認(rèn)值（可選）。 countryName_default = GB stateOrProvinceName_default = England localityName_default = 0.organizationName_default = Alice Ltd organizationalUnitName_default = emailAddress_default = [ v3_ca ] # 典型CA的擴(kuò)展（`man x509v3_config`）。 subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true keyUsage = critical, digitalSignature, cRLSign, keyCertSign [ v3_intermediate_ca ] ＃典型中間CA的擴(kuò)展（`man x509v3_config`）。 subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true, pathlen:0 keyUsage = critical, digitalSignature, cRLSign, keyCertSign [ usr_cert ] # 客戶端證書的擴(kuò)展項(xiàng)（`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 ] # 服務(wù)器證書的擴(kuò)展項(xiàng) (`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擴(kuò)展項(xiàng)(`man x509v3_config`). authorityKeyIdentifier=keyid:always [ ocsp ] # OCSP簽名證書的擴(kuò)展項(xiàng) (`man ocsp`). basicConstraints = CA:FALSE subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer keyUsage = critical, digitalSignature extendedKeyUsage = critical, OCSPSigning
# 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（匹配）的中間證書進(jìn)行簽名。 # 請參閱`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` 工具選項(xiàng) (`man req`)。 default_bits = 2048 distinguished_name = req_distinguished_name string_mask = utf8only # 不推薦使用SHA-1，請改用SHA-2。 default_md = sha256 # 使用 -x509選項(xiàng)時(shí)要添加的擴(kuò)展項(xiàng)。 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 # 指定一些默認(rèn)值（可選）。 countryName_default = GB stateOrProvinceName_default = England localityName_default = 0.organizationName_default = Alice Ltd organizationalUnitName_default = emailAddress_default = [ v3_ca ] # 典型CA的擴(kuò)展（`man x509v3_config`）。 subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true keyUsage = critical, digitalSignature, cRLSign, keyCertSign [ v3_intermediate_ca ] ＃典型中間CA的擴(kuò)展（`man x509v3_config`）。 subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true, pathlen:0 keyUsage = critical, digitalSignature, cRLSign, keyCertSign [ usr_cert ] # 客戶端證書的擴(kuò)展項(xiàng)（`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 ] # 服務(wù)器證書的擴(kuò)展項(xiàng) (`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擴(kuò)展項(xiàng)(`man x509v3_config`)。 authorityKeyIdentifier=keyid:always [ ocsp ] # OCSP簽名證書的擴(kuò)展項(xiàng) (`man ocsp`) basicConstraints = CA:FALSE subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer keyUsage = critical, digitalSignature extendedKeyUsage = critical, OCSPSigning
看完上述內(nèi)容，你們對X.509證書有進(jìn)一步的了解嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀。
免責(zé)聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點(diǎn)不代表本網(wǎng)站立場，如果涉及侵權(quán)請聯(lián)系站長郵箱：is@yisu.com進(jìn)行舉報(bào)，并提供相關(guān)證據(jù)，一經(jīng)查實(shí)，將立刻刪除涉嫌侵權(quán)內(nèi)容。
億速云公眾號
手機(jī)網(wǎng)站二維碼
