X.509系列（一）：X.509 v3格式下的证书

目前手头上接到了一个新的任务，刚好又是和X.509证书打交道的工作，想到刚入职的时候第一份正正经经的开发任务就是写证书签发工具，感觉这部分确实应该踏踏实实做一下总结了。很难说以笔者现在的水平能不能证书这么一个基础工具讲清楚，尽力而为吧。目前规划为三部分内容，本文第一篇，剩下两部分分别为：

ASN.1详解

密码库源码分析(基于mbedtls库)

我们公钥证书可以说是PKI(Public Key Infrastructure)中非常核心的组件之一，而PKI可以说是当代互联网文明安全的基石了。如果这方面的协议出现了漏洞，可以说会对整个世界互联网都造成非常严重的冲击。笔者知识有限，所以本文对CA(Certificate Authority)将简单抽象为单层级的一个证书颁发者。

证书(Certificate) 里面主要包含三个部分：证书信息(TBS Certificate)(TBS = To Be Signed)，证书签名算法(signature Algorithm)和证书签名 (signatureValue). 证书信息里包含了证书的ID，证书拥有者的信息，签发者信息与最关键的，证书拥有者公钥信息。而证书的核心功能也是基于该公钥信息展开。

想象两个场景：

第一个场景下，可以把问题简单的规约为Alice和Bob需要拥有同样的对称秘钥，数据传输的通道上只传输由该秘钥加密过的数据。但是对称的秘钥如何传输呢？非对称密码体系解决了这个问题。在完成普通的握手之后：

Alice和Bob分别将自己的证书发给对方

Alice验证Bob的证书，验证成功后提取Bob公钥, 之后取随机数 , 计算 发送给Alice. 指使用的公钥对完成加密/验签操作. 对应ECC可以视为, RSA可以视为

Bob验证Alice的证书，验证成功后提取Alice公钥, 之后取随机数 , 计算 发送给Alice

Alice和Bob分别用自己的私钥从中解出对应的, , ，由于私钥都是仅Alice和Bob各自拥有的，网络上其他人无法解出，中间人的窃听将失效（但是中间人攻击依然是可能的，许多https的抓包软件就是基于中间人的攻击。想想为啥）

Alice和Bob拼接随机数串 ，使用协定好的秘钥派生算法，将 作为派生秘钥的种子派生出相同的秘钥，后期将使用该派生的秘钥作为加密通信的秘钥

其实上面的协议就是一个比较简化版的SSL/TLS的握手阶段，当然秘钥协商(DH: Diffie–Hellman key exchange)的方式还有很多, 但原理相差不多，会比直接加密简单一点。包括当前几乎已经是标配的HTTPS协议，底层的安全基础很大程度也是基于SSL的协议。

第二个场景就比较简单了：

简单来看，消息的摘要值保证了消息的完整性Integrity，而签名的验证保证了消息是来自Alice的不可抵赖性Non-repudiation

好了，看完了上面的问题，有没有一点疑问：那看起来证书好像只是个公钥的壳子而已，为啥不直接发公钥就完事了？还有验证证书是什么意思？

有没有想过，上述的Bob和Alice都是所谓的"好人"而已，这网络上哪有这么多好人。本质上，公钥其实只是一个很大的数，传递时也就是个二进制流。假如互联网上只有裸着的公钥传输，我怎么知道这个公钥是谁发给我的，中间有没有被别人给替换了。

现实中我们证明自己是一个公民的办法通常是去公安局去获取自己的身份证，通过身份证证明我是我，因为身份证上有我的名字、唯一身份证号、照片等等，发证机关将在身份证盖上国家神圣的公章，证明身份证的真实性。那么在网络世界中，我们也需要一张这样的身份证，证明我是该公钥的拥有人，且公钥的信息很有限，所以我们需要打包更多公钥拥有者的信息，同时我们也需要一个组织来进行发证操作，起到公安局的作用，并对证书"盖上公章"。在这种场景下，网络世界的证书自然就呼之欲出了。

现实中我们去获取身份证时候，首先也要填一个申请表吧。我们在申请证书的时候同样需要一个申请文件来发给网络世界的公安局，CA。当然，这个申请文件也是需要遵循格式标准的RFC 2986 - PKCS #10: Certification Request Syntax Specification，缩写为.csr

通过OpenSSL可以自己造一个合法格式的csr文件：

正如申请身份证需要先造个人，首先我们需要自己造一个公钥，即制造一对公私钥对，以RSA-2048为例，生成pem格式：

生成csr文件，输入自己的公钥与私钥，通常还会让你输入自己的个人信息。使用PKCS#10的标准将信息与公钥打包后，由自己私钥进行自签名：

-in选项输入公钥，-key输入私钥，-out为输出csr文件名。-new表示新建一个csr。运行命令行后然后会让你输入的个人信息。此处拆分主要为了阐述csr的生成流程。

但是上面的打印啥也看不出来，我们需要用解析完的方式来查看该文件：

这就有那味儿了，简单解析一下，顺便对应着RFC的标准看一下。先看Data这段，对应的是 CertificationRequestInfo

顺便提一下，RFC的标准都是使用ASN.1格式描述的，而日常使用中的证书等文件同样是基于ASN.1的BER格式，而PEM是对文件进行标识（如-----BEGIN CERTIFICATE REQUEST-----）后，进行base64编码的产物。ASN.1的具体细节将在(二)部分进行分析。

可以发现生成的csr的data部分是可以和CertificationRequestInfo一一对应起来的：

version：csr的版本号，当前通常是version 1，即0

subject：以Name的格式保存，一般会保存证书持有者的国籍(C:Country 两个字母表示，如美国US，中国CN), 省级行政区(ST: State or Province)，城市(L:Locality), 公司组织名(O:Organization), 组织部门名(OU: Organization Unit), 通用名(CN: Common Name), email地址等等。其实具体的规范还是比较复杂的，具体标准参考X.501规范。此处不细说了

subjectPKInfo: 最关键的部分，包含了公钥的信息，由公钥算法与公钥值组成：

顺便提一句，AlgorithmIdentifier的标识是ANS.1编码中最与众不同的方式，Object ID. 后续将提到。此处算法被标记为了rsaEncrypt

最后是attributes，他主要提供了一些证书申请者的附加信息。PKCS#9中定义了一些在此可能使用的属性类型，典型的例子是challenge-password属性：它将指定一个密码，实体可以通过该密码请求吊销证书；另一个例子是X.509证书扩展中显示的信息（例如。从PKCS #9获取的extensionRequest属性等）。此处a0:00标识了NULL

再看完整的csr结构：

certificationRequestInfo对应的就是上面的Data，已完成解释

signatureAlgorithm对应签名算法，此处为sha256WithRSAEncryption，指的是使用待签名的公钥对应的私钥，来完成自签名，签名的对象是certificationRequestInfo的sha256摘要值，签名算法为RSA

最后signature对应的就是签名值了，bit string类型

最后提一点，在证书申请的模式下，申请者只需要将公钥信息发至证书签发机构即可，保证了私钥的本地性与私密性。

完成了申请表的填写，就应该交给身份证办理人员了，类比下来csr文件生成之后，我们就要向CA发送证书申请文件，以获取证书。

CA可以翻译为数字证书认证机构，是PKI体系中的基石。维基百科于是说：

CA是证书的签发机构，它是PKI的核心。CA是负责签发证书、认证证书、管理已颁发证书的机关。它要制定政策和具体步骤来验证、识别用户身份，并对用户证书进行签名，以确保证书持有者的身份和公钥的拥有权。

由上文可以推断，CA正是承担了公安局对身份证"盖章"这一工作，盖上的便是使用CA私钥完成的对证书的数字签名。但是公安局的信用是有国家背书的，所以CA也必须得到网络上所有人的信任。当然拥有CA资格的机构也是相当有限的。

CA获取证书申请之后，首先就要检测csr的合法性，申请人信息的合法性，公钥的合法性等等。这些属于审批的范畴，技术范畴的话就是需要校验csr的签名，即certificationRequestInfo是否被篡改。过程为取出certificationRequestInfo中的公钥信息，计算certificationRequestInfo的待验证哈希值。利用提取的公钥与签名计算出签名哈希值，解padding后，判断是否与待验证哈希值一致，确定该csr的完整性与不可抵赖性。

CA在完成验证后，将下发自己的CA证书以及签发的X.509证书。CA同样是一张X.509格式的证书，往往也是一张自签名的证书，即CA私钥签发CA公钥。事实上，当前网络通讯当中（特别是浏览器）将会内置上很多权威受信任的CA证书，若通信过程中使用的CA证书并不在内置名单中，往往程序会进行提醒：当前站点CA证书不受信任。而且现在CA往往由于需要加快签发速率等原因，会使用多级CA的模式，即CA证书由上级CA签发，最后将校验链上的证书一并发送给申请者，后续校验时将进行证书的逐级校验。

还记得上面场景中提到的：Alice验证Bob的证书这一步吗？Alice正是通过CA证书中的公钥来校验Bob证书签名的。原因正是基于CA是Alice所信任的证书认证者。当然验证证书还需要对certificateInfo校验，确定Bob的身份，下章就会讲到。

终于到了重头戏，我们的主角，X.509格式的证书。再强调一次，证书是功能性的描述，而X.509只是证书一种国际上通用的格式，基于RFC3280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile(X.509 v3), 对应了PKCS#12。

这次我们直接拿上一张Google的证书来看看：

同样对照标准定义进行学习字段的意义：

可以看到Data对应了tbsCertificate, 也是整张证书最关键的部分，该字段包含证书拥有者信息、颁发者信息、公钥信息、有效期信息等，后面单独拿出来详细解析。

剩下的两个部分与csr完全一致，同样是表明了签名的算法与tbsCertificate的签名。这里要注意，签发者issuer信息表明了证书签发人，一般为受信任的CA。

核心字段，一点点手撕；先看定义

这里顺便提一句ASN.1下的定义中SEQUENCE和SET的区别在于：通常SEQUENCE是一个有序集合，即编码时必须按照顺序排列，SET则可以为无序的集合。通常解析SEQUENCE时都将按序解析。

version：X.509标准下版本，例子中证书为0x2，即v3版本。注意证书存在extensions时，版本一定是v3版本，故extension通常也称为X.509 v3 extension。

serialNumber：证书的序列号，它必须是一个唯一的整数。需要注意一点，他是一个大端数字，所以有时候他可能高位填一些0，但不影响其对比。比如例子中的证书，实际编码中高位填上了0：

序列号的作用主要在CRL中体现唯一标识的作用。可以对照到身份证上的身份证号:)

signature: 标记了证书的签名算法，与csr一样，不做赘述。

issuer：标记证书签发者CA的信息，例子中可以看到为Google Trust Services签发。具体格式类似上面的subject。

validity：标识了证书的生效时间，以起始时间与结束时间表述。可以看到例子中的证书的生效起始时间为格林威治时间的2020/08/26, 有效期至2020/11/18。时间的ASN.1通常以 YYMMDDHHMMSS来标识，结尾以Z或者时区差标识时区。Z是Zulu时间的意思，和格林威治时间同步。

subject：证书拥有者信息，同issuer。上面提到校验Bob的信息，也就是对这一段的验证。

subjectPublicKeyInfo：证书公钥信息，也和csr中的一致。

UniqueID：可选字段，这个字段必须要v2及以上版本才有，主要是用来防止issuer与subject重名的情况。例子中的证书是没有的

extension是最重头戏的字段：

通过描述可以看到Extensions是一个可选字段，其内部可以有最多MAX个拓展字段，这里当然无法单独完成阐述，挑一些例子中的标准拓展字段描述。

Authority Key Identifier/Subject Key Identifier: 这两个字段主要是在多证书的场景提供一种快速确定所需要公钥的标记。Authority Key Identifier唯一标记了该证书签发私钥对应的公钥，而Subject Key Identifier则是唯一标记了当前证书中的公钥。举个例子，一个设备当中可能有好多个证书，但是每一个app可能只需要对应证书中的公钥，那么就可以将这一串ID内置在app中，证书也不需要完整解析，先去看看对应Key Identifier字段是不是匹配即可。通常计算方式为计算公钥的SHA1值，本例子中的Subject Key Identifier即为这种方式：

Key Usage/Extended Key Usage: 确定证书中公钥的用途。以前一个为主，extended字段作为补充。例子中的证书主要就是用来做TLS通讯中的数字签名功能。Key Usage主要类型有以下几种，详细描述可以参考标准中的描述，这里不展开说了：

Certificate Policies：以OID格式体现，主要是表现申请证书时的缘由和预期的用途。例子中的2.23.140.1.2.2和1.3.6.1.4.1.11129.2.5.3是典型的OID格式，每个点隔开一个属性层级，可以通过 http://www.oid-info.com/ 进行Object的查询，如2.23.140.1.2.2表示为organization-validated，即

Certificates issued in accordance with the CA/Browser Forum's Baseline Requirements - Organization identity asserted

Authority Information Access：标识了CA Issuer的信息，包括OCSP服务的网址与CA证书的下载地址。该部分在TLS很重要。OCSP服务会在后续CRL中提到。

CRL Distribution Points：CRL(Certificate Revocation List), 标识了当前CA下吊销列表文件的下载地址，也是TLS握手阶段重要的过程。后续将继续分析。

CT Precertificate SCTs：证书透明度(Certificate Transparency); 这个是标准中没有提到的一个比较新的拓展。CT主要搭配了CA服务器上公开的Log，将记录CA的行为日志，而每一个与当前证书相关的日志将被计入此字段，并被CA进行签名。校验阶段可以根据Log ID和timestamp查找日志中的对应操作，对证书进行审计以确定当前证书的合法性。该字段的提出主要就是防止CA被入侵者利用后获取大量非法签发证书，而透明性的日志保证了证书的签发是到受到严格监控的。

证书的有效期似乎已经能够防止回退之内的攻击了，但是万一在有效期内发生了对应私钥的泄漏事件，该怎么取消掉证书的有效性呢？这时候就需要crl出场了。

上面已经提到了CRL Distribution Points，直接从对应地址下载个crl：

还是先对应ASN.1对于crl格式的描述看一下：

可以看到这时候crl的解析出来的格式顺序已经和标准的定义略有区别，但是不影响，只要知道所有的吊销列表信息肯定都是被CA签名了的。

signatureAlgorithm和signatureValue 没啥好说的，和之前证书和申请文件没有区别。

这一段可分为主要的两个部分：吊销文件信息和吊销证书列表，这也是解析出来crl没有按照顺序排列的原因，为了打印的好看，这一段被拆分成了两部分

先看吊销文件信息：

version、signature和issuer 和之前完全一样，不再赘述。

thisUpdate：指定了本次crl签发的的时间。主要用来保证crl证书的时效性

nextUpdate：可选项，指定了下一次crl签发的时间

crlExtensions：包含了拓展信息，注意这个字段在实际的证书中是放在revokedCertificates后面的。在用例的google证书的crl中可以看到吊销证书的数量(CRL Number: 1001)和Authority Key Identifier,可以看到这个Authority Key Identifier和X.509证书中的相同字段是一模一样的。注意这个地方CRL Number是不一定等于revokedCertificates中被吊销列表数量的，其实为了加快查找效率，已经过期的被吊销证书是可以从列表中移除以减小列表的大小。

这是crl的核心部分，包含了被吊销证书的唯一序列号(userCertificate CertificateSerialNumber)，证书的吊销时间(revocationDate)，以及一些扩展，用例中包含了典型用例：吊销原因码(CRL Reason Code)。

主要看一下唯一序列号这个段，这个段是刚好对应X.509证书中的serialNumber段，这也是为什么这个段需要唯一的原因：他标识了一张独一无二的证书。

其实这时候查询一个列表是否吊销的流程已经很简单了：

但是这是唯一的方法吗？如果碰到像当年heartbleed一样的大型泄漏事件，吊销列表是不是特别大，特别大会造成两个问题：下载慢、查询慢，最终导致握手超时。

第二点问题是crl有更新不及时的问题：CA机构在吊销一张证书后，不会立刻去更新CRLs文件，客户端定期缓存的CRLs文件也不是及时更新的，所以会导致一种情况是，某张证书被吊销后，由于CRLs文件没有及时更新的缘故，身份校验通过了，认为该张证书没有问题。

所以为了解决对应的问题，SSL中包含一种新协议

OCSP（Online Certificate Status Protocol），即在线证书状态协议。同样是用来做服务器身份校验，由CA机构管理，使用数字签名技术保护，浏览器可以从中获得证书的吊销状态和吊销原因，方式是由身份校验方浏览器发送OCSP请求，等待响应来完成证书状态获取。当然OCSP的格式同样要遵照标准rfc6960。这里就不细解析OCSP格式了，可以参考标准文档。 当然OCSP最为协议当然也有request和response(其实csr就是请求，申请下来的证书就是答复)，这里贴一下request的格式

看起来X.509这一系列好像很简单的样子，然而这里打出来的其实都是完成解析之后的样子，那么解析之前的DER格式的证书是啥样子的呢：

啥啥啥，这是啥？？

其实这就是反复提到的ASN.1格式。系列下一章就是手撕ASN.1, 做一个人肉decoder(想多了...)