189 8069 5689
英文原文：https://blog.csdn.net/blue0bird/article/details/78656536
创新互联于2013年成立，公司以成都网站设计、做网站、系统开发、网络推广、文化传媒、企业宣传、平面广告设计等为主要业务，适用行业近百种。服务企业客户超过千家，涉及国内多个省份客户。拥有多年网站建设开发经验。为企业提供专业的网站建设、创意设计、宣传推广等服务。 通过专业的设计、独特的风格，为不同客户提供各种风格的特色服务。
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]部分中的选项。