溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
英文原文：https://blog.csdn.net/blue0bird/article/details/78656536
????????????????????????? ?https://jamielinux.com/docs/openssl-certificate-authority/index.html
本文源于兩篇英文文檔，將其合二為一，翻譯過程參考了網上的其它翻譯以求更加準確，再此對這些翻譯文檔的作者表示感謝！
文中介紹的OpenSSL版本較老，與現有的版本有很多不符之處，但萬變不離其宗，核心原理還是很有參考價值的。
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也是如此。
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證書的簽名
所有擴展都有一個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）標準發展而來，用于在單個文件中交換公共和私有對象。
證書鏈（也就是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的情況也類似。這樣就允許老的用戶證書可以在新舊兩個根證書之間平滑轉移。?
? ? ? ? 以下是維基百科網站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:
????????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驗證級別無法抵御中間人攻.擊。
????????如果是主體而不是依賴方購買證書，通常會使用最便宜的頒發者，頒發者出于成本考慮，往往采用擴展驗證證書來解決問題，但是在安全專家看來，信任價值正在下降。
????????● 證書頒發機構否認對用戶（包括主題或依賴方）的幾乎所有保證。
????????● 有效期應用于限制密鑰強度被視為時間足夠，此參數被證書頒發機構濫用以向客戶端收取擴展費。這給使用密鑰滾動的用戶帶來了不必要的負擔。（沒看懂啥意思）
????????●“用戶使用未定義的認證請求協議來獲取證書，該證書發布于不存在的目錄中的不明確位置，從而無有效手段來撤銷它。”
與所有企業一樣，CA受其經營站點的法律管轄，并可能被迫損害其客戶和用戶的利益。情報機構還利用了通過CA的法外妥協發出的虛假證書（例如DigiNotar）來進行中間人攻.擊。另一個例子是荷蘭政府CA的撤銷請求，由于新的荷蘭法律自2018年1月1日起生效，為荷蘭情報和安全部門賦予了新的權力。
????????X.509實現存在設計缺陷、錯誤、對標準的不同解釋以及不同標準的互操作性問題，一些問題是：
????????● 許多實現關閉吊銷檢查：
????????● 策略被視為障礙，沒有得到執行
????????● 如果默認情況下在所有瀏覽器（包括代碼簽名）中都打開了它，可能會破壞基礎結構
????????● DN很復雜且不容易理解（缺乏規范化、國際化問題……）
????????● RFC822名稱有2種表示法
????????● 幾乎不支持名稱和策略約束
????????● keyUsage被忽略，使用列表中的第一個證書
????????● 自定義oid的實施很困難
????????● 不應將屬性設為強制屬性，因為它會使客戶端崩潰
????????● 未指定的屬性長度會導致特定于產品的限制
????????● X.509存在實現錯誤，例如允許在證書中使用以空值結尾的字符串，或通過代碼注入攻.擊來偽造使用者名稱。
????????● 通過使用對象標識符的0x80填充子標識符，錯誤的實現或通過使用客戶端瀏覽器的整數溢出，攻.擊者可以在CSR中包含一個未知屬性，CA會將其簽名，客戶端錯誤地將其解釋為“CN”（OID = 2.5.4.3）
????????數字簽名系統依賴于密碼散列函數（哈希函數）的安全性。如果公鑰基礎結構（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的弱點。
????????利用哈希碰撞來偽造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。
????????本指南演示如何使用OpenSSL命令行工具充當您自己的證書頒發機構（CA）。這在許多情況下都很有用，例如頒發服務器證書以保護intranet網站，或向客戶端頒發證書以允許客戶端向服務器進行身份驗證。
? ? ? OpenSSL是一個免費的開源加密庫，它提供了一些用于處理數字證書的命令行工具，其中一些工具（也就是命令）可以充當證書頒發機構。
????????證書頒發機構是為數字證書簽名的實體。許多網站需要讓其客戶知道連接是安全的，因此他們向國際證書頒發機構（CA）支付費用，以為其域簽署證書。
? ? ? ?在某些情況下，自己做自己CA（而不是向DigiCert這樣的CA付錢）更有意義，比如保護intranet網站的安全，或向客戶端頒發證書以允許客戶端向服務器進行身份驗證。
????????充當證書頒發機構意味著要處理密鑰對之中的私鑰和公鑰證書。
??? ? ??我們要創建的第一個密鑰對就是根對。這包括根密鑰（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
????????您必須創建一個配置文件以供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
????????創建根私鑰（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
????????使用根密鑰（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?[]:
????????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)???#?公鑰位長度
????????中間證書授權（CA）是可以代表根CA簽署證書的實體，根CA簽署中間證書，這就形成了信任鏈。
使用中間證書的目的主要是：根密鑰可以保持脫機狀態，并盡可能不頻繁地使用。如果中間密鑰被泄露，根CA可以撤銷中間證書并創建新的中間密鑰對。
????????根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
????????當應用程序（如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的情況下）是在需要連接的每個客戶端上安裝根證書，在這種情況下，證書鏈文件僅需要包含您的中間證書。
??????我們將使用中間 CA 簽署證書。您可以在各種情況下使用這些證書，例如保護與?Web 服務器的連接或對連接到服務器的客戶端進行身份驗證。
????????注意：以下步驟是CA替申請者創建私鑰和簽名請求（CSR），但申請者從安全角度考慮也可以自己創建私鑰和請求，其中的私鑰妥善保存于本地，把CSR交給CA，CA則還給它一個簽名的證書。在這種情況下，跳過 genrsa 和 req 命令。
? ? ? 我們的根密鑰對和中間密鑰對是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）發回給它們。
???????證書吊銷列表 （CRL，見RFC5280） 提供已吊銷的證書的列表。客戶端應用程序（如 Web 瀏覽器）可以使用 CRL 檢查服務器的真實性。服務器應用程序（如Apache或OpenV.P.N）可以使用 CRL 拒絕訪問不再受信任的客戶端。
? ? ? ?在公共可訪問的位置（例如http://example.com/intermediate.crl.pem）發布 CRL，第三方可以從此位置獲取 CRL，以檢查他們依賴的證書是否已被吊銷。
????????注意：一些應用程序供應商已棄用CRL，而是使用聯機證書狀態協議（OCSP，百度RFC2560，有中文版）。
? ? ? 證書頒發機構在簽署證書時，通常會將CRL位置編碼到證書中，將crlDistributionPoints添加到適當的部分，對于本例，將其添加到[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部分包含有關如何創建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?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發送給愛麗絲，愛麗絲隨后對其進行簽名：
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 驗證證書是否有效：
openssl?verify?-CAfile?intermediate/certs/ca-chain.cert.pem?intermediate/certs/bob@example.com.cert.pem ? bob@example.com.cert.pem:?OK
????????現在index.txt文件應包含一個新條目：
????????V 160420124740Z 1001 unknown ... /CN=bob@example.com
????????Alice向Bob發送簽名證書，Bob將證書安裝在自己的網絡瀏覽器中，現在可以訪問愛麗絲的小貓圖片，歡呼吧！
????????④但可悲的是，事實證明Bob行為不端，Bob將Alice的小貓圖片發布到了《***新聞》上，聲稱是他自己的照片并廣受歡迎，愛麗絲發現了，需要立即撤銷了他的訪問權限：
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
????????現在index.txt中與Bob的證書相對應的行以字符R開頭，這表示證書已被吊銷：
????????R 160420124740Z 150411125310Z 1001 unknown ... /CN=bob@example.com
????????撤銷Bob的證書后，Alice必須重新創建CRL。
?6-5-4) 服務器端使用CRL
????????對于客戶端證書，通常是服務器端應用程序（如Apache）進行驗證。此應用程序需要具有對CRL的本地訪問權限。
????????對于Alice，她可以將SSLCARevocationPath指令添加到Apache配置中，然后將CRL復制到她的Web服務器上，下次Bob連接到Web服務器時，Apache將根據CRL檢查其客戶端證書并拒絕訪問。
????????同樣，OpenV.P.N具有crl-verfiy指令，因此它可以阻止證書被吊銷的客戶端。
????????對于服務器證書，通常是服務器端應用程序（如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。
????????要使用OCSP，CA必須將OCSP服務器位置編碼到它所簽署的證書中。在適當的部分中使用authorityInfoAccess選項，在本例中指的是[ server_cert ]部分。
[ server_cert ]
# ... snipped ...
authorityInfoAccess = OCSP;URI:http://ocsp.example.com
????????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) 附錄
#?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
#?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
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
