2023年7月13日发(作者：)

数字证书和证书颁发机构的基础知识

什么是数字证书数字证书是电⼦凭证，⽤于断⾔⽹络上的个⼈，计算机和其他实体的在线⾝份。数字证书的功能类似于护照和驾驶执照等⾝份证。最常见的是，它们包含公钥和所有者的⾝份。它们由证书颁发机构（CA）颁发，证书颁发机构必须在颁发证书之前和使⽤证书时验证证书持有者的⾝份。常见⽤途包括需要⾝份验证，加密和数字签名的业务场景。证书⽬的证书⽬的定义了证书的预期主要⽤途。证书⽬的可以是以下四种设置之⼀：加密。具有此⽬的的证书将包含⽤于加密和解密的加密密钥。签名。具有此⽬的的证书将包含仅⽤于签名数据的加密密钥。签名和加密。具有此⽬的的证书涵盖证书加密密钥的所有主要⽤途，包括数据加密，数据解密，初始登录或数字签名数据。签名和智能卡登录。具有此⽬的的证书允许使⽤智能卡进⾏初始登录，并对数据进⾏数字签名; 它不能⽤于数据加密。SSL可能是第⼀个使⽤数字证书的协议。现在有⼀天，它们被⼴泛⽤于需要签名和加密的地⽅。证书颁发机构证书颁发机构（CA）颁发包含公钥和所有者⾝份的数字证书。匹配的私钥不是公开的，⽽是由⽣成密钥对的最终⽤户保密。证书还是CA的确认或验证，证书中包含的公钥属于证书中标注的个⼈，组织，服务器或其他实体。CA在此类⽅案中的义务是验证申请⼈的凭证，以便⽤户和信赖⽅可以信任CA证书中的信息。CA使⽤各种标准和测试来执⾏此操作。从本质上讲，证书颁发机构负责说“是的，这个⼈就是他们所说的⼈，⽽我们，CA，验证”。如果⽤户信任CA并且可以验证CA的签名，那么他还可以验证某个公钥确实属于证书中标识的任何⼈。浏览器维护着名的CA根证书列表。除了商业CA之外，⼀些提供商还免费向公众发放数字证书。⼤型机构或政府实体可能拥有⾃⼰的在结构上是分层的。通常有三种类型的层次结构，它们由层数表⽰。单层层次结构由⼀个CA组成。单个CA既是根CA⼜是颁发CA. 根CA是PKI的信任锚的术语。信任根CA的任何应⽤程序，⽤户或计算机都信任CA层次结构颁发的任何证书。颁发CA是向最终实体颁发证书的CA. 出于安全原因，这两个⾓⾊通常是分开的。使⽤单层层次结构时，它们将合并在⼀起。

双层层次结构是最常见的。在某些⽅⾯，它是⼀层和三层等级之间的折衷。在此设计中，有⼀个脱机的根CA，以及⼀个在线的从属颁发CA. 由于根CA和颁发CA⾓⾊是分开的，因此安全级别会提⾼。但更重要的是，根CA处于脱机状态，因此可以更好地保护根CA的私钥免受攻击。它还提⾼了可扩展性和灵活性。这是因为可以存在多个从根CA到CA的颁发CA. 这可以让你有CA在不同的地理位置，以及与不同的安全级别。

具体⽽⾔，两层层次结构之间的区别在于第⼆层位于根CA和颁发CA之间。此CA的放置可能有⼏个不同的原因。第⼀个原因是将第⼆层CA⽤作策略CA. 换句话说，策略CA配置为向颁发CA颁发证书，该证书受其颁发的证书类型的限制。策略CA也可以仅⽤作管理边界。换句话说，您只从策略CA的下属颁发某些证书，并在颁发证书之前执⾏某种级别的验证，但该策略仅从管理⽽⾮技术⾓度强制执⾏。添加第⼆层的另⼀个原因是，如果由于密钥泄露⽽需要撤销多个CA，则可以在第⼆层级别执⾏它，从⽽使其他“从根分⽀”可⽤。应该注意的是，此层次结构中的第⼆层CA可以像Root⼀样保持脱机状态。

您可以从商业CA获取业务证书。商业CA的发⾏实体提供成本证书。您可以从商业CA获取业务证书。商业CA的发⾏实体提供成本证书。⽤户可以直接联系发证CA，在这种情况下，发⾏CA将代表⽤户⽣成密钥对。将私钥移交给⽤户，并在根据CA的策略进⾏所有必要的验证后，提供包含公钥的证书和颁发CA的签名。⽤户还可以使⽤Java中的Keytool等⼯具⽣成⾃⼰的密钥对，并再次使⽤某个⼯具⽣成证书签名请求（CSR），例如Keytool，然后将CSR发送给颁发CA以获取证书。CSR以发布CA通常期望的格式包含⽤户的公钥和⽤户⾝份信息。⽤户必须保密私钥。如果私钥被泄露或丢失，则必须通知CA。这类似于丢失信⽤卡。CA将证书保留在证书撤销列表中，其私钥被认为已被泄露或丢失。您⾃⼰可以成为CA并颁发⾃⼰的证书，这些证书称为⾃签名证书，但出于商业⽬的，您的⾃签名证书将不受信任。只有已建⽴且知名的CA⾃签名证书才是可信的。CA的根证书始终是⾃签名的。

当您从商业CA获得公钥证书时，您的证书将与证书链相关联，或者有时称为信任链。链中的证书数量取决于CA的层次结构。下图显⽰了双层CA的证书链。所有者/⽤户证书由颁发CA签名，颁发CA证书由根CA签名。根CA的证书是⾃签名的。

在⽤户通过浏览器或程序验证证书期间，浏览器需要通过查找下⼀个颁发CA或中间CA的公钥来验证签名。该过程将继续，直到达到根证书。根CA是⾃签名的，最后必须由浏览器信任。浏览器将所有知名的CA根证书保存在其信任库中。当客户端或应⽤程序验证证书时，它不仅需要验证正在使⽤的证书，还需要验证整个证书链。换句话说，应⽤程序或客户端需要来⾃链中每个CA的证书，该证书以发布CA开始并以根CA结束。如果应⽤程序或客户端⽆法访问本地链中的证书，则应⽤程序或客户端需要从中获取证书的位置。此位置称为“授权信息访问”或AIA。AIA位置是存储CA证书的存储库，以便客户端或验证证书的应⽤程序可以下载它。AIA位置包含在证书的AIA扩展中。CRL分发点（CDP）是验证证书的客户端或应⽤程序下载证书吊销列表（CRL）以获取吊销状态的位置。CA定期发布CRL以允许客户端和应⽤程序确定证书是否已被撤销。CRL包含已撤销的证书的序列号，指⽰证书被撤销的时间戳以及撤销的原因。证书剖析数字证书通过提供有关证书主题，证书有效性以及可以使⽤证书的应⽤程序和服务的信息，将⽤户，计算机或服务的标识绑定到公钥。PKI中颁发的证书的结构是为了根据互联⽹⼯程任务组（IETF）的公钥基础设施（X.509）⼯作组（PKIX）制定的标准来实现这些⽬标。下图显⽰了X.509版本3证书的内容X.509版本3证书⽀持⾃X.509版本1以来⽀持的以下字段：主题：提供CA颁发证书的计算机，⽤户，⽹络设备或服务的名称。主题名称通常使⽤X.500或轻量级⽬录访问协议（LDAP）格式表⽰。序列号：为CA颁发的每个证书提供唯⼀标识符。颁发者：为颁发证书的CA提供专有名称。发⾏者名称通常使⽤X.500或LDAP格式表⽰。有效⾃：提供证书⽣效的⽇期和时间。

有效收件⼈：提供证书不再有效的⽇期和时间。应⽤程序或服务评估证书的⽇期必须介于证书的Valid From和Valid To字段之间，以使证书有效。公钥：包含与证书关联的密钥对的公钥。签名算法：⽤于签署证书的算法。签名值：包含数字签名的位串。除版本1字段外，X.509版本3证书还包括为证书提供附加功能和功能的扩展。这些扩展是可选的，并不⼀定包含在CA颁发的每个证书中：主题替代名称：主题可以以多种不同的格式呈现。例如，如果证书必须包含LDAP专有名称，电⼦邮件名称和⽤户主体名称（UPN）格式的⽤户帐户名，则可以通过添加证书中的电⼦邮件名称或UPN包含这些附加名称格式的主题备⽤名称扩展名。CRL分发点（CDP）： 当⽤户，服务或计算机提供证书时，应⽤程序或服务必须确定证书是否在其有效期到期之前被撤销。CDP扩展提供⼀个或多个URL，应⽤程序或服务可以从中检索证书吊销列表（CRL）。授权信息访问（AIA）： 在应⽤程序或服务验证证书后，还必须评估颁发证书的CA的证书（也称为⽗CA）的撤销和有效性。AIA扩展提供⼀个或多个URL，应⽤程序或服务可以从中检索颁发的CA证书。

增强型密钥⽤法（EKU）： 此属性包括可⽤于证书的每个应⽤程序或服务的对象标识符（OID）。每个OID都是来⾃全球注册机构的唯⼀数字序列。

证书策略： 描述组织在颁发证书之前验证证书请求者⾝份所采取的措施。OID⽤于表⽰验证过程，并且可以包括策略限定的URL，该URL完整地描述了验证⾝份所采取的措施。商业CA将类的概念⽤于不同类型的数字证书。例如，具有以下分类⽤于个⼈的1级，⽤于电⼦邮件。组织的第2类，需要⾝份证明。服务器和软件签名的第3类，由发证机构对其进⾏独⽴验证和检查⾝份和权限。第4类⽤于公司之间的在线业务交易。私⼈组织或政府安全的第5类。其他供应商可能会选择使⽤不同的类或根本没有类，因为规范中没有指定，但⼤多数供应商都选择以某种形式使⽤类。X.509数字证书格式使⽤ASN.1或抽象语法表⽰法⼀来定义，是⼀种国际标准组织（ISO）数据表⽰格式，⽤于实现平台之间的互操作性。X.509 v3数字证书的当前结构如下所⽰。这基本上定义了如何编写证书内容。你可以在查看详细信息。证书:: = SEQUENCE { tbsCertificate TBSCertificate， signatureAlgorithm AlgorithmIdentifier， signatureValue BIT STRING}TBSCertificate :: = SEQUENCE { version [0] EXPLICIT Version DEFAULT v1， serialNumber CertificateSerialNumber， 签名AlgorithmIdentifier， 发⾏⼈姓名， 有效性， 主题名称， subjectPublicKeyInfo SubjectPublicKeyInfo， issuerUniqueID [1] IMPLICIT UniqueIdentifier可选， - 如果存在，版本必须是v2或v3 subjectUniqueID [2] IMPLICIT UniqueIdentifier可选， - 如果存在，版本必须是v2或v3 extensions [3] EXPLICIT Extensions可选 - 如果存在，版本必须是v3 }

AlgorithmIdentifier :: = SEQUENCE { 算法OBJECT IDENTIFIER， 参数ANY DEFINED BY algorithm OPTIONAL}

....更多定义将遵循CertificateSerialNumber，Name，Validity等......您可以将其视为Java类或XML架构。它确实定义了如何编码证书内容以存储在⽂件中。两种常⽤的编码模式⽤于在⽂件，DER和PEM中存储X.509证书，如下⼀节所述。可以将这种ASN.1定义的编码形式与Java中的.class⽂件进⾏⽐较。X.509证书⽂件最常⽤的编码⽅案是PEM（隐私增强邮件）编码。PEM的完整规范在。但是在X.509证书上进⾏PEM编码的想法⾮常简单：使⽤Base64编码对内容进⾏编码。将Base64编码输出括在两⾏之间：“----- BEGIN CERTIFICATE -----”和“----- END CERTIFICATE -----”

这是PEM编码的结构⽰例X.509证书：-----BEGIN CERTIFICATE-----

<

...

Cgfs2kXj/IQCFDC5GT5IrLTIFxAyPUo1tJo2DPkK

-----END CERTIFICATE-----⼏乎所有应⽤程序都⽀持PEM编码的证书⽂件，证书的扩展名为.pemDER（可分辨编码规则）是另⼀种⽤于存储X.509证书⽂件的流⾏编码。ASN.1的可分辨编码规则是根据X.509对BER编码的约束得出的国际标准。DER编码是有效的BER编码。DER与BER相同，只删除了⼀个发送者的选项。例如，在BER中，布尔值true可以⽤255种⽅式编码，⽽在DER中，只有⼀种⽅法可以编码布尔值true。DER的完整规范在。DER编码的X.509证书⽂件是⼆进制⽂件，⽆法使⽤⽂本编辑器查看。⼏乎所有应⽤程序都⽀持DER编码的证书⽂件。DER编码证书的⽂件扩展名为.cer，.der，.crtPKCS是指由RSA Security设计和发布的⼀组公钥加密标准。因此，RSA Security及其研究部门RSA Labs有兴趣促进和促进公钥技术的使⽤。为此，他们（从20世纪90年代初开始）开发了PKCS标准。他们保留对他们的控制权，宣布他们会在他们认为必要的时候进⾏改变/改进，因此PKCS标准在重要意义上并不是真正的⾏业标准，尽管名称如此。近年来，有些（但不是全部）已经开始进⼊像IETF PKIX⼯作组这样的标准组织。在这种情况下，⽂件扩展名为.p7b，.p7c，.p12，.pfx等。让我们检查⼀下真正的证书，它的细节和链条。感谢上帝有证书查看器⼯具，读取这些古⽼的编码格式，并很好地显⽰证书！您可以在任何浏览器中检查任何https⽹址以检查X.509数字证书。在这⾥，我们将在Internet Explorer（IE）中检查印度国家银⾏的⽹上银⾏⽹站。

单击视图证书链接后，Windows证书查看器⼯具将打开并显⽰印度国家银⾏拥有的证书。您可以在“颁发者”字段中看到此证书由VeriSign Class 3Extended Validation SSL SGC CA颁发。证书查看器还显⽰证书的详细信息。有许多字段，“显⽰”下拉列表会过滤它们以便更好地查看。下图显⽰了⼀些称为版本1字段的基本字段。在左侧，您可以看到主题SBI及其详细信息名称（DN）。在正确的发⾏⼈的DN上。从show下拉列表中选择“Extensions Only”。请注意扩展名是可选的，但它们现在很常见。在左侧，您将看到CRL分发点和右侧AIA位置。您可以单击下载CRL。下图显⽰了CRL的外观。每个证书通常指向其发⾏⼈给出的CRL。单击“证书路径”选项卡以查看证书链。证书查看器允许您通过突出显⽰证书来查看链中的其他证书，然后单击“查看证书”按钮，如右下图所⽰。链中还显⽰VeriSign是⼀个双层CA，其中VeriSign是Root，“VeriSign Class 3 Extended Validation SSL SGC CA”是颁发CA.单击“查看证书”按钮以查看颁发者CA的证书。您也可以使⽤AIA链接，即来获得相同的证书。

发⾏⼈CA的证书如下。同样，您也可以看到根证书。请注意，对于根证书，“颁发给”或“主题”和“颁发者”或“颁发者”字段是相同的。所以这是⼀个⾃签名证书。您还可以使⽤Chrome和Firefox查看证书。Chrome使⽤IE的证书查看器，但FF使⽤⾃⼰的证书查看器。

证书验证过程在信任证书之前，浏览器/应⽤程序会执⾏验证检查以确保证书有效并且它们具有有效的证书路径。公钥证书的状态通过三个不同但相互关联的过程来确定。但这可能会因实施⽽略有不同。链构建过程将通过检查证书路径中的每个证书（从最终证书到根CA证书）来验证证书路径。从中级证书颁发机构存储，受信任的根证书颁发机构存储或证书的AIA属性中指定的URL检索证书。如果它发现路径中的某个证书存在问题，或者找不到证书，则证书路径将作为不受信任的证书路径被丢弃。为了提⾼性能，浏览器/操作系统可以将下级CA证书存储在中间证书颁发机构存储中，以便可以从存储中满⾜将来对证书的请求，⽽不是通过URL访问证书。证书存储通常包含许多证书，可能是从许多不同的CA颁发的。在Windows系统中，存在称为计算机存储的单独存储（由计算机使⽤），以及当前登录⽤户使⽤的⽤户存储或我的存储。

在Java环境中，证书存储在JKS⽂件中，并由“系统属性”指向-re = $ {some path} /

-tore = $ {some path} /

-rePassword = key-store-password证书链引擎构建所有可能的证书链。构建证书链的整个图表，然后按链的“质量”排序。给定结束证书的最佳质量链作为默认链返回给调⽤应⽤程序。每个链都是使⽤证书存储中可⽤的证书和已发布的URL位置提供的证书的组合构建的。链中的每个证书都分配有⼀个状态代码。状态代码指⽰单个证书是否：签名有效签名是否有效？时间有效是否正确配置了证书开始⽇期和到期⽇期，尚未发⽣开始⽇期，或证书是否已过期？已过期证书是否已过期？已撤销证书已被撤销？时间嵌套PKI层次结构中任何更⾼的证书是否已过期？对证书的任何其他限制例如，证书是否⽤于⾮预期⽬的？每个状态代码都有⼀个优先级。例如，过期的证书优先级⾼于撤销的证书。这是因为不应检查过期证书的撤销状态。如果为证书链中的证书分配了不同的状态代码，则优先级最⾼的状态代码将应⽤于证书链并传播到证书链状态。对于链中的每个证书，证书链引擎必须选择颁发CA的证书。重复此过程（称为路径验证），直到达到⾃签名证书（通常，这是根CA证书）。可以使⽤不同的进程为颁发CA选择证书。使⽤的实际过程基于当前正在调查的证书是否已定义权限密钥标识符（AKI）扩展。检查AKI扩展将导致实施三个匹配过程之⼀：完全匹配如果AKI扩展包含颁发者的⽤户名和颁发者序列号，则在链构建过程中将仅选择与⽤户名和序列号匹配的证书。作为进⼀步测试，颁发的证书上的颁发者名称必须与颁发者证书上的主题名称匹配。

密钥匹配如果AKI扩展仅包含公钥信息，则只有在主题密钥标识符（SKI）扩展中包含指⽰公钥的证书才会被选为有效发布者。

名字匹配。如果AKI中不存在任何信息，或者证书中不存在AKI，则证书将被标记为“名称匹配”。在名称匹配中，证书的主题名称必须与当前证书中的颁发者名称匹配。证书的订单被选为有效的发⾏⼈。由于数据以⼆进制格式存储，因此名称匹配过程区分⼤⼩写。在所有情况下，即使在商店中找不到匹配的证书，当前证书仍将被标记为“完全匹配”，“密钥匹配”或“名称匹配”，因为这描述了尝试的匹配⽽不是达到的匹配。为了提⾼性能，证书链引擎使⽤最近最少使⽤（LRU）的缓存⽅案。此⽅案为构建证书链时遇到的每个证书创建⼀个缓存条⽬。每个缓存条⽬都包含证书的状态，因此可以在后续调⽤链接API时根据缓存项构建最佳证书链，⽽⽆需再次确定每个证书的状态。将证书添加到缓存后，在证书过期或被撤销之前不会将其删除。在路径验证过程中，将始终选择有效的缓存证书。如果未找到有效的⾼速缓存证书，则将执⾏商店搜索。对于颁发者证书和CRL，可能需要URL检索才能从URL中指⽰的分发点下载证书和CRL。从商店或URL中选择证书时，所有证书都存储在缓存中。唯⼀的区别是存储缓存证书的位置。证书链引擎将检查链中的每个证书，以确定证书是否已被撤销以及撤销的原因。撤销检查可以与链式构建过程⼀起进⾏，也可以在链条构建之后进⾏。如果在链中发现撤销的证书，则为该链分配较低的质量值。

进⼀步阅读