本文以X.509证书为例，为大家详细介绍了X.509证书的概念和证书结构，以及X.509证书的使用方法，阅读完整文相信大家对X.509证书有了一定的认识。
目前创新互联建站已为超过千家的企业提供了网站建设、域名、网站空间、成都网站托管、企业网站设计、广西网站维护等服务，公司将坚持客户导向、应用为本的策略，正道将秉承"和谐、参与、激情"的文化，与客户和合作伙伴齐心协力一起成长，共同发展。
1）证书
X.509标准是密码学里公钥证书的格式标准。X.509 证书己应用在包括TLS/SSL（WWW万维网安全浏览的基石）在内的众多 Internet协议里，同时它也有很多非在线的应用场景，比如电子签名服务。X.509证书含有公钥和标识（主机名、组织或个人），并由证书颁发机构（CA）签名（或自签名）。对于一份经由可信的证书签发机构签名（或者可以通过其它方式验证）的证书，证书的拥有者就可以用证书及相应的私钥来创建安全的通信，以及对文档进行数字签名。
X.509最早与X.500一起发布于1988年7月3日，它假定颁发证书的证书颁发机构（CA）具有严格的层次结构。这与Web信任模型（如PGP）形成了鲜明对比，因为PGP方案是任何人都以签名（而不仅仅是地位特殊的CA），从而证明其他人的密钥证书的有效性。X.509 V3证书的设计非常灵活，除了对网桥拓扑架构网络的支持，还可以支持用于点对点方式的Mesh网，类似于OpenPGP那样的web信任机制，不过这样方式在2004年之前很少使用。
X.500系统仅由主权国家实施，以实现国家身份信息共享条约的实施目的，而IETF的公钥基础设施（X.509）或PKIX工作组已对该标准进行了调整，以适应更灵活的互联网组织结构。事实上X.509认证指的是RFC5280里定义的X.509 v3，包括对IETF的PKIX证书和证书吊销列表（CRL Profile），通常也称为公钥基础设施。
在X.509系统中，证书申请者通过发起“证书签名请求（CSR）”来得到一份被签名的证书。为此，它需要生成一个密钥对，然后用其中的私钥对CSR签名（私钥本身要妥善保存，对外保密），CSR包含申请人的身份信息、用于验真CSR的申请人的公钥，以及所请求证书的专有名称（DN），CSR还可能带有CA要求的其它有关身份证明的信息，然后CA对这个专有名称发布一份证书，并绑定一个公钥。
组织机构可以把受信的根证书分发给所有的成员，这样就可以使用公司的PKI系统了。像Firefox, IE, Opera, Safari 以及Google Chrome这些浏览器都预装了一组CA根证书，所以可以直接使用这些主流CA发布的SSL证书。浏览器的开发者直接影响它的用户对第三方的信任。FireFox就提供了一份csv/html格式的列表。
X.509还包括证书吊销列表（CRL）实现标准，这是PKI系统经常被忽略的方面。IETF批准的检查证书有效性的方法是在线证书状态协议（OCSP），Firefox 3默认情况下启用OCSP检查，从Vista开始的高版本Windows也是如此。
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，这样的证书只能用在被这两个扩展指定的用途，例如网络安全服务决定证书用途时，会同时对这个扩展进行判断。
X.509证书有几种常用的文件扩展名，但要注意：其中一些扩展名也有其它用途，就是说具有这个扩展名的文件可能并不是证书，比如说可能只是保存了私钥。
● .pem：（隐私增强型电子邮件），DER编码的证书再进行Base64编码，数据存放于“--- BEGIN CERTIFICATE ---”和“ --- END CERTIFICATE ---”之间
● .cer，.crt，.der：通常采用二进制DER形式，但Base64编码也很常见
● .p7b，.p7c-PKC＃7：SignedData结构，没有数据，仅有证书或CRL
● .p12-PKCS＃12：可以包含证书（公钥），也可同时包含受密码保护的私钥
● .pfx ：PKCS＃12的前身（通常用PKCS＃12格式，例如IIS产生的PFX文件）
PKCS#7是签名或加密数据的格式标准，官方称之为容器。由于证书是可验真的签名数据，所以可以用SignedData结构表述。.P7C文件是退化的SignedData结构，没有包括签名的数据。
PKCS＃12从个人信息交换（PFX）标准发展而来，用于在单个文件中交换公共和私有对象。
2）证书链和交叉认证
证书链（也就是RFC 5280里的证书路径）指的是以最终实体证书开头，后跟一个或多个CA证书，且通常最后一个是自签名证书，具有如下关系：
1.除了链上的最后一个证书外，每个证书的颁发者等于其后一个证书的主题（主题就是使用者）。
2.除了链上的最后一个证书外，每个证书都是由其后的一个证书签名。
3.最后一个证书是信任锚：由于是通过某种可信的过程得到的，所以你可以信任它。
证书链用来检查目标证书（链中的第一个证书）中包含的公钥和其他数据是否属于其主题。检查是这么做的，用证书链中的下一个证书的公钥来验证它的签名，一直检查到证书链的尾端，由于最后一个证书是信任锚，成功达到该证书将证明目标证书可以信任。
上段中的描述是根据RFC5280定义的认证路径验证过程的简化过程，实际上涉及额外的检查，例如验证证书的有效日期、查找CRL等。
在研究证书链的构建和验证方式时，需要特别注意的是，具体的证书可以是不同的证书链的一部分（链上的所有证书都有效）。 这是因为可以为相同的主题和公钥生成多个CA证书，但使用不同的私钥（来自不同的CA或来自同一CA的不同的私钥）进行签名。 因此，尽管单个X.509证书只能具有一个颁发者和一个CA签名，但是它可以有效地链接到多个证书，从而建立完全不同的证书链。 这对于PKI与其他应用程序之间的交叉认证至关重要，详见以下示例。
下图每个框代表一个证书，主题以粗体显示，A→B表示“ A由B签名”（或更准确地说，A由B包含公钥相对应的私钥签名），具有相同颜色（非白色/透明）的证书包含相同的公钥。
为了让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得到认证。
阅读这篇文章：了解认证路径构建（PDF，PKI论坛，2002）
证书颁发者为了从旧的私钥平滑地转移到新的私钥，他可以颁发两个证书，其中一个是新的私钥对旧的公钥进行签名，另一个是旧的私钥对新的公钥的签名，这两个证书都是自颁发的，但都不是自签名。注：另外还存在新旧两个自签名证书。
假设cert1和cert3包含相同的公钥（旧的公钥），对于cert5来说有两条合法的证书链，cert5 → cert1 和 cert5 → cert3 → cert2, cert6的情况也类似。这样就允许老的用户证书可以在新旧两个根证书之间平滑转移。
3）X.509证书的例子
以下是维基百科网站Wikipedia.org和其他几家Wikipedia网站的X.509证书解码实例，由GlobalSign发布，它的颁发者字段（Subject）将Wikipedia描述为一个组织，Subject Alternative Name字段描述可以使用的主机名。Subject Public Key Info字段包含一个ECDSA公钥，而底部的签名由GlobalSign的RSA私钥生成。
网摘：最终实体证书就是大家通常说的用户证书，有别于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来检索中间证书。
网摘：什么是中间证书？
中间证书用作根证书的替代。我们使用中间证书作为代理，因为我们必须将根证书保存在众多安全层之后，以确保其密钥绝对不可访问。由于根证书签署了中间证书，因此中间证书可用于签署客户安装和维护的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:
...
以下是证书颁发机构的自签名根证书示例，Issuer（颁发者字段）和Subject（主题，使用者字段）是相同的，能够使用自己的公钥对签名进行验证，信任链的验证必须在此结束。如果验证程序在其信任存储中有此根证书，就可以认为在TLS连接中使用的最终实体证书是可信的。否则，最终实体证书被视为不可信。
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
04:00:00:00:00:01:15:4b:5a:c3:94
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
Validity
Not Before: Sep 1 12:00:00 1998 GMT
Not After : Jan 28 12:00:00 2028 GMT
Subject: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:da:0e:e6:99:8d:ce:a3:e3:4f:8a:7e:fb:f1:8b:
...
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B
Signature Algorithm: sha1WithRSAEncryption
d6:73:e7:7c:4f:76:d0:8d:bf:ec:ba:a2:be:34:c5:28:32:b5:
4）安全
Bruce Schneier，Peter Gutmann和其他安全专家发表了许多有关PKI问题的出版物。
将无效的证书列入黑名单（使用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。
6）OpenSSL证书颁发机构
本指南演示如何使用OpenSSL命令行工具充当您自己的证书颁发机构（CA）。这在许多情况下都很有用，例如颁发服务器证书以保护intranet网站，或向客户端颁发证书以允许客户端向服务器进行身份验证。
OpenSSL是一个免费的开源加密库，它提供了一些用于处理数字证书的命令行工具，其中一些工具（也就是命令）可以充当证书颁发机构。
证书颁发机构是为数字证书签名的实体。许多网站需要让其客户知道连接是安全的，因此他们向国际证书颁发机构（CA）支付费用，以为其域签署证书。
在某些情况下，自己做自己CA（而不是向DigiCert这样的CA付钱）更有意义，比如保护intranet网站的安全，或向客户端颁发证书以允许客户端向服务器进行身份验证。
充当证书颁发机构意味着要处理密钥对之中的私钥和公钥证书。
我们要创建的第一个密钥对就是根对。这包括根密钥（ca.key.pem）和根证书（ca.cert.pem）。这个“根对”构成了你的CA的身份。
通常，根CA不会直接为服务器或客户端证书签名，根CA仅用于创建一个或多个中间CA，这些中间CA被根CA信任，并代表根CA签署证书，这是最佳实践，它允许根密钥保持脱机状态并尽可能减少使用的次数，因为对根的任何威胁都是灾难性的。
注意：
最佳实践是在安全的环境中创建根对。理想情况下，该计算机应该是完全加密并且空气隔离（含义是没有任何网络接口的机器，即不能通过外部网络连接），可以考虑卸载无线网卡，并用胶水塞满以太网口。
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 ]
# 参看.
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 =&nb
网页标题：X.509证书的介绍和使用
分享网址：http://cdkjz.cn/article/pdejed.html
