该篇章将着重讲解关于CA的基础知识。

什么是CA机构

我相信大部分人在接触数字证书时，都会好奇，为什么数字证书是由一个叫做 CA 的机构颁发，CA 到底是什么。
CA 的全名叫证书颁发机构（Certificate Authority），是用于颁发数字证书的地方。
有些人可能会将 CA 经常和 RA 混在一起，那是因为部分小型 CA 机构仅签发[[证书类型介绍#DV证书|DV证书]]，因为规模很小，所以这部分小型 CA 机构，就会将 RA 与 CA 的职责合并在一起，统称为 CA。

CA机构的类型

正常的CA机构有两种类型：

自签 CA 机构
权威 CA 机构
这两种机构分别对应着不同的用处。

自签CA机构

如果说权威 CA 机构是官方机构，那么自签 CA 机构就是一个小区。
官方机构颁发身份证，小区颁发通行证。

当然，自签CA的安全等级差异很大，有些场景下的自签CA具有极高的安全保障的，就比如不公开的内网自签CA机构，因为CA处在内网里，互联网无法访问到该CA，所以该CA理论上会比在公网上的权威CA机构更安全。

正因如此，自签 CA 机构很多时候也被用在局域网内的验证，比如著名的[[关于mTLS的理解| mTLS]]。
自签 CA 实际上很简单，通过 OpenSSL 等工具即可完成搭建。
同样的，因为自签 CA 太过于简单，没有信息认证，所以自签 CA 也时常被别有用心的人用于攻击。

需要注意的是，自签 CA 签发的证书通常仅在内部环境中使用，且不具备公共信任，部署到互联网上的平台，会因为签发的 CA 机构未被其他终端信任，而提示告警。

权威CA机构

权威 CA 机构是经过国际认可、被主流操作系统和浏览器信任的 CA 机构。
我们的数字证书就是由这些机构颁发。
这些机构也存在级别层级。
具体的层级关系将在证书链章节中详述。

权威CA机构的审核非常繁琐，需要经过WebTrust审计或ETSI审计等合规认证（具体要求因根证书计划而异），并由各操作系统/浏览器的根证书计划（如 Mozilla Root Store Policy、Microsoft Trusted Root Program）审核后纳入。
值得注意的是，不同的根证书计划要求的合规认证是不一样的，就比如Mozilla就接受WebTrust审计或ETSI审计，而Apple可能只认WebTrust。

权威CA机构的类型

因为世界上有着数不尽的设备，如果全部依靠单一的几台位于根部的权威 CA 机构，那么会让整个数字证书颁发体系变得冗长、繁琐且具有高耦合性，为了能够更好地服务大众，权威 CA 机构就下分出两种类型：

根权威 CA 机构
中间权威 CA 机构

根权威CA机构

根权威 CA 机构是整个数字证书的最开头，若是按数据结构的说法，那么根权威 CA 机构就是 Root 。
这类机构通常是自签的证书，但是却拥有超乎寻常的保护。

中间权威CA机构

该类型的机构承担着向客户端，或者更下级的 CA 机构颁发证书，因为他们有着根权威 CA 机构颁发的证书，所以完全无需自己线下交换公钥，方便非常多。

CA机构的公钥在哪？

我相信在我讲到这里时，有很多人会问，明明都是在说公钥私钥的，私钥放在 CA 的内部，那公钥呢，如果在互联网传输，那还不是会有被人篡改的风险。

这其实就很特别了，我们目前安装的系统，其实都有内置权威 CA 的 CA 根证书，这就是为什么我们可以直接验证经过权威 CA 的数字证书。

在这里有一点需要注意，盗版系统的其中一个问题，就是让系统信任了非正规 CA ，导致隐私泄露，所以安装系统时请务必使用正版！

证书链

CA 的证书实际上也是需要被颁发，颁发 CA 证书的机构也需要数字证书，换句话说，整个证书链实际上就一条链条，每个证书的签名都需要由上级CA的私钥生成，验证时又需要用上级CA证书中的公钥来校验。
这点在之前的中间权威 CA 机构中里有提到，且根权威 CA 机构，则是完全自签的。

但是很有意思的是，因为数字证书的颁发原理，所有证书实际上都是逐级签发，换句话说，所有证书都是链在一起的，每层证书的签名由上级 CA 的私钥生成，形成逐级信任的链式结构。

什么是RA机构

这时候大概已经有人想着自己动手签一个了，但是稍等一下，实际上还有一个知识点，那就是 RA 。
RA（Registration Authority，注册机构），是专门负责审核客户端发来的签发请求。
如果说 CA 是发身份证的窗口，那么RA就是审核申请人的地方。

RA 机构和 CA 机构其实是分离的，在标准流程中，客户端申请数字证书时都是发送给 RA，而非 CA。
而在数量上，RA 机构和 CA 机构也是呈现多对一的形式，这样确保了审核速度，也确保了信息最小泄露面积。

很有意思的是，一部分只签发 DV 证书的小型 CA 机构，会将 RA 职能合并到 CA 内部，不再单独设立RA。

RA验证签名和身份

RA 在收到客户端的 CSR 后，会进行一系列操作：

用 CSR 自带的公钥验签 CSR 文件
DNS 验证
文件验证
邮箱验证
人工验证
需要注意的是，这上面的验证只是最基础的一些验证，在复杂严苛的证书颁发场景，验证手段只会只多不少。
而验证的手段也会随着证书类型的变化而变化，廉价快捷的证书，几乎只会用到第 1 种和 2 ~ 4 的其中一种。
更贵、等保要求^1更高的证书，则可能除了这 5 种外，添加更多验证手段。

接下来，我会讲解上述的5种 RA 验证的方法。

用CSR自带的公钥验签CSR文件

这个我相信大家都能理解，如果 CSR 的公钥连文件的信息都验签不出来，或者说验签出来后是无意义数据，那么完全可以断定，该 CSR 附带的公钥，与对 CSR 进行签名的私钥，不是一对的。
所以验签 CSR 文件就变得非常重要。

DNS验证

RA 可以要求申请人在[[“域名注册商”、“DNS服务商”的区别#域名注册商|域名注册商]]的 DNS 解析记录上，添加一个指定的 TXT 记录。
当 RA 会在一段时间后发起 DNS 查询，比对解析出的 TXT 记录与预期值是否一致，确认与预期一致，就可以得知当前 DNS 属于申请人，否则就不是。

有趣的是，早期 X.509 v1 / v2 的证书是基于 [[X.509 V1 数字证书内部结构介绍#颁发者_子字段|DN 标识]][^2] 的，不强制绑定域名。
而在 v3 中，引入了 SAN 扩展[^3]，这让数字证书的域名绑定变得标准化且灵活。

文件验证

我们申请数字证书时，经常是为已经构建好的平台申请。
既然如此那么我们可以要求申请人在已经构建好的平台上的指定位置，进行指定操作。
基本上与 DNS 验证没有太大区别，都是在指定位置添加指定信息。
就比如，在http://域名/.well-known/pki-validation/xxx.txt下存放指定内容文件，然后 RA 直接通过 HTTP 访问该路径，检查内容。
该检查项主要是检查，该站点是否属于申请人。

邮箱验证

在 DNS 验证那栏我们有提到，绑定域名是最常见的方式，而域名申请很多时候需要有[[“域名注册商”、“DNS服务商”的区别#域名注册商| DNS 服务商]]的参与，而在向[[“域名注册商”、“DNS服务商”的区别#域名注册商|域名注册商]]申请域名时，又需要填写域名的一系列信息才能申请。

因此 RA 可以通过向 WHOIS 数据库或 RDAP[^4] 查询获取该域名的公开记录，以获取管理员邮箱，若查询时发现开启了隐私保护，则通常退回到 admin@ 域名等标准管理邮箱进行确认。
若是客户端能收到邮件，并且点击确认了，那么就代表管理邮箱是正确的，间接证明该域名是数字证书申请者的。

这和注册网址后要求激活邮箱是一样的操作，只不过这次换成了 RA 验证数字证书。

人工验证

人工验证大多是验证企业信息，例如 [[证书类型介绍#OV证书|OV]] 或者 [[证书类型介绍#EV证书|EV]] 等，该类证书需要经过严格审核，比如营业执照、工商备案号等，繁琐，但是也更为安全。

验证完成

若是在上述的验证都完成后，RA 确定该公钥是归属于申请人，那么 RA 就会将需要颁发证书的 [[文件格式类型介绍#CSR|CSR]] 发给 CA 。
RA 在核实申请者对域名的所有权和身份信息这个过程，[[证书类型介绍#数字证书的类型|不同类型的证书]]会持续不同的时间，最多半个月，最快十几分钟。

[^2]: [[X.509 V1 数字证书内部结构介绍#颁发者_子字段|可分辨名字标识]]，Distinguished Name (DN)

[^3]: 使用者可选名扩展，Subject Alternative Name (SAN)

[^4]: 注册数据访问协议，Registration Data Access Protocol (RDAP)

CA类型介绍