第 3 篇PKI——是谁在给你的网站「盖章」标签#PKI#HTTPS#网络安全#证书PKI 到底在解决什么问题第 1 篇我们讲了密码学六大构件第 2 篇讲了 TLS 握手的全过程。看起来一切都很美好——客户端拿到服务器证书用公钥验签协商出对称密钥开始加密通信。但这里藏着一个致命问题客户端第一次连服务器时怎么知道这个公钥真的属于它声称的那个网站攻击者完全可以伪造一张证书把公钥换成自己的冒充bank.com。除非客户端有办法独立验证「这个公钥确实属于 bank.com」——否则整个 TLS 都是空中楼阁。这就是PKIPublic Key Infrastructure公钥基础设施要解决的问题让地球上两个从未谋面的人能够安全地交换公钥。PKI 的四个角色PKI 不是某一项技术而是一套角色 流程 标准的组合。理解 PKI先认识这四个角色角色英文它做什么订阅人Subscriber需要证书的实体网站、应用、个人登记机构Registration Authority (RA)验证订阅人身份做签发前的尽职调查证书颁发机构Certification Authority (CA)审核通过后用自己私钥签发证书信赖方Relying Party用证书的客户端浏览器、操作系统、应用一次典型的「给网站盖章」过程站长生成一对密钥提交证书签名申请CSR给 CACA通过 RA验证「你真的拥有 example.com 吗」验证通过后CA 把站长的公钥 域名信息打包成证书用自己的私钥签字站长把证书部署到服务器浏览器访问时拿到证书用预装在系统里的 CA 根证书验证签名——这就构成了信任链冷知识CA 在 PKI 里拥有神一般的权力——只要它想可以给任何域名签发证书。所以 CA 必须严格审计、受监管、被吊销有后果。这不是技术问题是治理问题。X.509 证书一个装着公钥的「信封」证书本身是一份结构化的数字文档由 ITU-T 定义的X.509标准规定IETF 改造后变成PKIX最权威的规范是RFC 5280。版本 3 加上扩展是今天的绝对主流。一张证书包含这些字段字段含义版本几乎都是 v3序列号CA 内唯一必须是不可预测的≥ 64 位熵防选择前缀攻击签名算法CA 用什么算法签的如sha256WithRSAEncryption、ecdsa-with-SHA256颁发者CA 的可分辨名称DN有效期notBefore / notAfter2020 年起 CA/B Forum 规定最长 398 天约 13 个月主体证书持有者网站 / 个人 / 公司公钥实际的公钥 算法 OID扩展关键能力声明下文会细讲证书扩展让证书从「僵化」变「灵活」X.509 v3 最大的创新就是扩展机制——可以往证书里塞各种「能力声明」。每个扩展有一个 OID对象标识符、关键标志、和值。最常见的几个扩展扩展作用SANSubject Alternative Name把域名列表放在这里——取代了过时的 CN 字段基础约束Basic Constraints声明「我是不是 CA」、「我能签几层」EKUExtended Key Usage限制「这个密钥只能用于 serverAuth / clientAuth / codeSigning」密钥用法Key Usage更底层的限制digitalSignature、keyEncipherment 等CRL 分发点在哪里下载证书吊销列表CRLAIAAuthority Information AccessOCSP 响应地址、签发者证书下载地址SAN-ASubject Alternative Name一个证书绑多个域名 / IP名称约束Name Constraints限制子 CA「只能给*.example.com签证书」冷知识SAN 是今天判断「这张证书是不是给当前域名签的」的唯一可靠字段。Chrome / Firefox 早就不再看 CN 了——所有浏览器从 2017 年起就只认 SAN。证书链信任的传递浏览器在验证一张服务器证书时会沿着一条链一级一级往上验证服务器证书 (example.com) ↑ 由中间 CA 签发 中间 CA 证书 (Intermediate CA) ↑ 由根 CA 签发 根 CA 证书 (Root CA) ← 预装在你的操作系统 / 浏览器里为什么要拆成「根 中间 服务器」三层根 CA 私钥必须离线——通常存放在物理隔离的 HSM 里每年手动操作几次。Baseline Requirements 明确规定根密钥必须人工启动不允许自动化。中间 CA 在线——处理日常签发。万一中间 CA 被入侵只需要吊销它根 CA 依然安全。服务器证书可以随时换90 天自动续期是常态。交叉证书Cross-Certificate一个新 CA 想让它的根快速被信任最直接的方法是找已经被广泛内置的根 CA给它签一张交叉证书。这种机制让新 CA 不用等几年就能进入主流根证书库。关键洞察服务器必须把完整的证书链服务器证书 所有中间证书发给客户端。如果中间证书缺失浏览器验证会失败——这就是经典的「证书链不完整」错误。SSL Labs 的 SSL Pulse 数据显示历史上约有 5%-6% 的服务器栽在这个坑里。谁来运营根证书库每个操作系统、浏览器都有自己的「信任锚」列表信任库维护方特点Mozilla NSSMozilla公开透明、社区驱动Linux 主流发行版都用它Apple Root CA ProgramAppleiOS / macOS 自带准入严Microsoft Trusted Root CAsMicrosoftWindows / Windows Phone 自带Android System Trust StoreGoogleAndroid 自带独立维护Oracle Java cacertsOracleJava 应用单独维护与 OS 不一致要把根 CA 加进这些信任库CA 必须通过WebTrust或ETSI审计、提交商业价值说明、合规审查——门槛极高。截至 2026 年全球被信任的根 CA 大约150 个左右其中排名前 10 的 CA 占据 90% 的市场份额。证书的三种「盖章严格度」CA 签发证书前要做的「尽职调查」分三个等级类型验证内容颁发速度价格DVDomain Validation只验证「你控制这个域名」DNS 记录 / HTTP 文件 / 邮件分钟级免费Let’s EncryptOVOrganization Validation验证域名 验证公司身份几天中等EVExtended Validation域名 公司身份 法人代表 经营地址 法律文件1-2 周贵DV 证书时代的革命Let’s Encrypt ACME2015 年 Let’s Encrypt 上线配合ACME 协议RFC 8555让证书签发变成$ certbot --nginx -d example.com # 自动生成密钥 → 自动提交 ACME 挑战 → 自动验证 → 自动签发 → 自动部署90 天自动续期完全免费全自动。到 2026 年Let’s Encrypt 已经为全球超过4 亿个网站提供服务DV 证书市场几乎被它一家垄断。冷知识DV 证书和 OV / EV 证书在加密强度上没有区别——都同样能保护 HTTPS 连接。区别只在「CA 验证了网站运营者多少信息」。EV 证书曾经在地址栏显示绿色公司名但 Chrome 2019 年起移除了这个 UI 区分理由是「用户根本看不懂」。吊销怎么宣告「这张证书已经死了」证书「过期」是自动的浏览器拒绝过期证书但「吊销」是提前宣告——通常是私钥泄露或人员变更。CRLCertificate Revocation ListCA 维护一个吊销证书名单浏览器去下载它。问题列表越来越大CA 签了几亿张证书下载延迟 带宽消耗大多数浏览器已经不再检查 CRLOCSPOnline Certificate Status Protocol浏览器直接查 OCSP 服务器「这张证书现在还活着吗」优点实时缺点CA 服务器成为性能瓶颈 隐私问题CA 知道谁访问了什么网站OCSP Stapling服务端代查服务器提前问 CA「我的证书还活着吗」把答案带 CA 签名「钉」在自己的 TLS 握手里发出去ServerHello Certificate CertificateStatus ← OCSP Stapling CertificateVerify Finished这是今天的标准做法隐私、性能、安全三赢。关键洞察浏览器实际上大多采用「软失败」——OCSP 查询失败就当作证书有效。这给了主动攻击者可乘之机拦截掉 OCSP 请求证书就能继续用。必须配合 OCSP Must-Staple 扩展强制服务器必须 stapling否则拒绝才能真正发挥作用。Chrome 在 2026 年的做法Chrome 已经对大部分域名完全关闭了 CRL/OCSP 实时检查转而依赖短证书有效期90 天Certificate Transparency 日志监控。这套组合让过期证书很快失效、错发证书能被快速识别比实时吊销查询更实用。PKI 的「七寸」任何人签发任何证书理解 PKI 最关键的洞察PKI 的安全性等于最弱的那个 CA。2011 年 DigiNotar一家荷兰 CA被入侵攻击者给自己签发了 531 张假证书包括*.google.com、*.microsoft.com等高价值域名。这次事件直接导致 DigiNotar 被吊销营业执照、破产清算。类似事件还有2011 年 Comodo 代理商被入侵——签发了 google.com、login.live.com 等 9 张假证书2015 年 Symantec「误签」30000 证书——被发现系统性地绕过验证2017 年 Google 发现 WoSign / StartCom伪造证书历史——两家被彻底吊销信任2017-2018 年 Symantec 信任链转移——整个根证书被 Google 和 Mozilla 拒绝需要把客户迁移到 DigiCert冷知识所有 CA 的「审计」都是周期性快照——审计员某天来检查你当天表现好就发合格证。DigiNotar 出事之前是合规的但合规不等于安全。PKI 生态的修复方向过去十年PKI 生态做了四件大事来加强信任① Certificate TransparencyCT证书透明度CA 必须把每一张签发的证书提交到公开的、可审计的日志里。任何人都可以监控——如果 CA 给你的域名签了张证书你没申请过马上就能看到。Chrome 在 2018 年起强制所有证书提交 CT否则直接拒绝连接。CT 现在已经是事实上的强制要求。② HPKP / 浏览器内置钉扎让网站「钉」住自己信任的公钥或 CA绕过浏览器自带的信任库。Chrome 在 2011 年 DigiNotar 事件后就开始内置钉扎大型站点的密钥。③ CAA 记录DNS 里加一条 CAA 记录声明哪些 CA 可以给你的域名签证书example.com. CAA 0 issue letsencrypt.org example.com. CAA 0 issuewild ; example.com. CAA 0 iodef mailto:securityexample.comCA 在签发前必须检查 CAA否则违规。这是 2017 年起生效的标准。④ ACME 自动化 短有效期90 天证书 自动续期让「盗用证书」价值大幅缩水——90 天后证书自动作废攻击者必须持续重新盗取。给开发者的三条建议① 用 Let’s Encrypt ACME证书不再是负担别再手动买证书、手动续期。装个certbot或者直接用 Caddy自动 HTTPS从此不再操心证书问题。# 获取证书nginx 插件自动改配置sudocertbot--nginx-dexample.com-dwww.example.com# 自动续期cron / systemd timer 已默认配置sudocertbot renew② 启用 OCSP Stapling Must-StapleNginx 示例ssl_stapling on; ssl_stapling_verify on; add_header Strict-Transport-Security max-age31536000; includeSubDomains always; # 强制 OCSP Must-Staple生成 CSR 时加 tlsfeaturestatus_request如果服务器证书不支持 OCSP stapling换 CA。③ 设置 CAA 记录哪怕只允许一家 CA也要设 CAA。这是个零成本的纵深防御example.com. CAA 0 issue letsencrypt.org example.com. CAA 0 issuewild ; # 禁止签发通配符证书延伸阅读RFC 5280 — X.509 PKI Certificate and CRL Profile — 证书格式的权威规范RFC 8555 — ACME 协议 — Let’s Encrypt 的核心CA/Browser Forum Baseline Requirements — CA 必须遵守的「基本法」Certificate Transparency — CT 日志和监控工具Let’s Encrypt 文档 — ACME 证书自动化的最佳实践SSL Labs SSL Pulse — 每月发布 HTTPS 生态健康报告 第 3 篇：PKI——是谁在给你的网站「盖章」？
第 3 篇PKI——是谁在给你的网站「盖章」标签#PKI#HTTPS#网络安全#证书PKI 到底在解决什么问题第 1 篇我们讲了密码学六大构件第 2 篇讲了 TLS 握手的全过程。看起来一切都很美好——客户端拿到服务器证书用公钥验签协商出对称密钥开始加密通信。但这里藏着一个致命问题客户端第一次连服务器时怎么知道这个公钥真的属于它声称的那个网站攻击者完全可以伪造一张证书把公钥换成自己的冒充bank.com。除非客户端有办法独立验证「这个公钥确实属于 bank.com」——否则整个 TLS 都是空中楼阁。这就是PKIPublic Key Infrastructure公钥基础设施要解决的问题让地球上两个从未谋面的人能够安全地交换公钥。PKI 的四个角色PKI 不是某一项技术而是一套角色 流程 标准的组合。理解 PKI先认识这四个角色角色英文它做什么订阅人Subscriber需要证书的实体网站、应用、个人登记机构Registration Authority (RA)验证订阅人身份做签发前的尽职调查证书颁发机构Certification Authority (CA)审核通过后用自己私钥签发证书信赖方Relying Party用证书的客户端浏览器、操作系统、应用一次典型的「给网站盖章」过程站长生成一对密钥提交证书签名申请CSR给 CACA通过 RA验证「你真的拥有 example.com 吗」验证通过后CA 把站长的公钥 域名信息打包成证书用自己的私钥签字站长把证书部署到服务器浏览器访问时拿到证书用预装在系统里的 CA 根证书验证签名——这就构成了信任链冷知识CA 在 PKI 里拥有神一般的权力——只要它想可以给任何域名签发证书。所以 CA 必须严格审计、受监管、被吊销有后果。这不是技术问题是治理问题。X.509 证书一个装着公钥的「信封」证书本身是一份结构化的数字文档由 ITU-T 定义的X.509标准规定IETF 改造后变成PKIX最权威的规范是RFC 5280。版本 3 加上扩展是今天的绝对主流。一张证书包含这些字段字段含义版本几乎都是 v3序列号CA 内唯一必须是不可预测的≥ 64 位熵防选择前缀攻击签名算法CA 用什么算法签的如sha256WithRSAEncryption、ecdsa-with-SHA256颁发者CA 的可分辨名称DN有效期notBefore / notAfter2020 年起 CA/B Forum 规定最长 398 天约 13 个月主体证书持有者网站 / 个人 / 公司公钥实际的公钥 算法 OID扩展关键能力声明下文会细讲证书扩展让证书从「僵化」变「灵活」X.509 v3 最大的创新就是扩展机制——可以往证书里塞各种「能力声明」。每个扩展有一个 OID对象标识符、关键标志、和值。最常见的几个扩展扩展作用SANSubject Alternative Name把域名列表放在这里——取代了过时的 CN 字段基础约束Basic Constraints声明「我是不是 CA」、「我能签几层」EKUExtended Key Usage限制「这个密钥只能用于 serverAuth / clientAuth / codeSigning」密钥用法Key Usage更底层的限制digitalSignature、keyEncipherment 等CRL 分发点在哪里下载证书吊销列表CRLAIAAuthority Information AccessOCSP 响应地址、签发者证书下载地址SAN-ASubject Alternative Name一个证书绑多个域名 / IP名称约束Name Constraints限制子 CA「只能给*.example.com签证书」冷知识SAN 是今天判断「这张证书是不是给当前域名签的」的唯一可靠字段。Chrome / Firefox 早就不再看 CN 了——所有浏览器从 2017 年起就只认 SAN。证书链信任的传递浏览器在验证一张服务器证书时会沿着一条链一级一级往上验证服务器证书 (example.com) ↑ 由中间 CA 签发 中间 CA 证书 (Intermediate CA) ↑ 由根 CA 签发 根 CA 证书 (Root CA) ← 预装在你的操作系统 / 浏览器里为什么要拆成「根 中间 服务器」三层根 CA 私钥必须离线——通常存放在物理隔离的 HSM 里每年手动操作几次。Baseline Requirements 明确规定根密钥必须人工启动不允许自动化。中间 CA 在线——处理日常签发。万一中间 CA 被入侵只需要吊销它根 CA 依然安全。服务器证书可以随时换90 天自动续期是常态。交叉证书Cross-Certificate一个新 CA 想让它的根快速被信任最直接的方法是找已经被广泛内置的根 CA给它签一张交叉证书。这种机制让新 CA 不用等几年就能进入主流根证书库。关键洞察服务器必须把完整的证书链服务器证书 所有中间证书发给客户端。如果中间证书缺失浏览器验证会失败——这就是经典的「证书链不完整」错误。SSL Labs 的 SSL Pulse 数据显示历史上约有 5%-6% 的服务器栽在这个坑里。谁来运营根证书库每个操作系统、浏览器都有自己的「信任锚」列表信任库维护方特点Mozilla NSSMozilla公开透明、社区驱动Linux 主流发行版都用它Apple Root CA ProgramAppleiOS / macOS 自带准入严Microsoft Trusted Root CAsMicrosoftWindows / Windows Phone 自带Android System Trust StoreGoogleAndroid 自带独立维护Oracle Java cacertsOracleJava 应用单独维护与 OS 不一致要把根 CA 加进这些信任库CA 必须通过WebTrust或ETSI审计、提交商业价值说明、合规审查——门槛极高。截至 2026 年全球被信任的根 CA 大约150 个左右其中排名前 10 的 CA 占据 90% 的市场份额。证书的三种「盖章严格度」CA 签发证书前要做的「尽职调查」分三个等级类型验证内容颁发速度价格DVDomain Validation只验证「你控制这个域名」DNS 记录 / HTTP 文件 / 邮件分钟级免费Let’s EncryptOVOrganization Validation验证域名 验证公司身份几天中等EVExtended Validation域名 公司身份 法人代表 经营地址 法律文件1-2 周贵DV 证书时代的革命Let’s Encrypt ACME2015 年 Let’s Encrypt 上线配合ACME 协议RFC 8555让证书签发变成$ certbot --nginx -d example.com # 自动生成密钥 → 自动提交 ACME 挑战 → 自动验证 → 自动签发 → 自动部署90 天自动续期完全免费全自动。到 2026 年Let’s Encrypt 已经为全球超过4 亿个网站提供服务DV 证书市场几乎被它一家垄断。冷知识DV 证书和 OV / EV 证书在加密强度上没有区别——都同样能保护 HTTPS 连接。区别只在「CA 验证了网站运营者多少信息」。EV 证书曾经在地址栏显示绿色公司名但 Chrome 2019 年起移除了这个 UI 区分理由是「用户根本看不懂」。吊销怎么宣告「这张证书已经死了」证书「过期」是自动的浏览器拒绝过期证书但「吊销」是提前宣告——通常是私钥泄露或人员变更。CRLCertificate Revocation ListCA 维护一个吊销证书名单浏览器去下载它。问题列表越来越大CA 签了几亿张证书下载延迟 带宽消耗大多数浏览器已经不再检查 CRLOCSPOnline Certificate Status Protocol浏览器直接查 OCSP 服务器「这张证书现在还活着吗」优点实时缺点CA 服务器成为性能瓶颈 隐私问题CA 知道谁访问了什么网站OCSP Stapling服务端代查服务器提前问 CA「我的证书还活着吗」把答案带 CA 签名「钉」在自己的 TLS 握手里发出去ServerHello Certificate CertificateStatus ← OCSP Stapling CertificateVerify Finished这是今天的标准做法隐私、性能、安全三赢。关键洞察浏览器实际上大多采用「软失败」——OCSP 查询失败就当作证书有效。这给了主动攻击者可乘之机拦截掉 OCSP 请求证书就能继续用。必须配合 OCSP Must-Staple 扩展强制服务器必须 stapling否则拒绝才能真正发挥作用。Chrome 在 2026 年的做法Chrome 已经对大部分域名完全关闭了 CRL/OCSP 实时检查转而依赖短证书有效期90 天Certificate Transparency 日志监控。这套组合让过期证书很快失效、错发证书能被快速识别比实时吊销查询更实用。PKI 的「七寸」任何人签发任何证书理解 PKI 最关键的洞察PKI 的安全性等于最弱的那个 CA。2011 年 DigiNotar一家荷兰 CA被入侵攻击者给自己签发了 531 张假证书包括*.google.com、*.microsoft.com等高价值域名。这次事件直接导致 DigiNotar 被吊销营业执照、破产清算。类似事件还有2011 年 Comodo 代理商被入侵——签发了 google.com、login.live.com 等 9 张假证书2015 年 Symantec「误签」30000 证书——被发现系统性地绕过验证2017 年 Google 发现 WoSign / StartCom伪造证书历史——两家被彻底吊销信任2017-2018 年 Symantec 信任链转移——整个根证书被 Google 和 Mozilla 拒绝需要把客户迁移到 DigiCert冷知识所有 CA 的「审计」都是周期性快照——审计员某天来检查你当天表现好就发合格证。DigiNotar 出事之前是合规的但合规不等于安全。PKI 生态的修复方向过去十年PKI 生态做了四件大事来加强信任① Certificate TransparencyCT证书透明度CA 必须把每一张签发的证书提交到公开的、可审计的日志里。任何人都可以监控——如果 CA 给你的域名签了张证书你没申请过马上就能看到。Chrome 在 2018 年起强制所有证书提交 CT否则直接拒绝连接。CT 现在已经是事实上的强制要求。② HPKP / 浏览器内置钉扎让网站「钉」住自己信任的公钥或 CA绕过浏览器自带的信任库。Chrome 在 2011 年 DigiNotar 事件后就开始内置钉扎大型站点的密钥。③ CAA 记录DNS 里加一条 CAA 记录声明哪些 CA 可以给你的域名签证书example.com. CAA 0 issue letsencrypt.org example.com. CAA 0 issuewild ; example.com. CAA 0 iodef mailto:securityexample.comCA 在签发前必须检查 CAA否则违规。这是 2017 年起生效的标准。④ ACME 自动化 短有效期90 天证书 自动续期让「盗用证书」价值大幅缩水——90 天后证书自动作废攻击者必须持续重新盗取。给开发者的三条建议① 用 Let’s Encrypt ACME证书不再是负担别再手动买证书、手动续期。装个certbot或者直接用 Caddy自动 HTTPS从此不再操心证书问题。# 获取证书nginx 插件自动改配置sudocertbot--nginx-dexample.com-dwww.example.com# 自动续期cron / systemd timer 已默认配置sudocertbot renew② 启用 OCSP Stapling Must-StapleNginx 示例ssl_stapling on; ssl_stapling_verify on; add_header Strict-Transport-Security max-age31536000; includeSubDomains always; # 强制 OCSP Must-Staple生成 CSR 时加 tlsfeaturestatus_request如果服务器证书不支持 OCSP stapling换 CA。③ 设置 CAA 记录哪怕只允许一家 CA也要设 CAA。这是个零成本的纵深防御example.com. CAA 0 issue letsencrypt.org example.com. CAA 0 issuewild ; # 禁止签发通配符证书延伸阅读RFC 5280 — X.509 PKI Certificate and CRL Profile — 证书格式的权威规范RFC 8555 — ACME 协议 — Let’s Encrypt 的核心CA/Browser Forum Baseline Requirements — CA 必须遵守的「基本法」Certificate Transparency — CT 日志和监控工具Let’s Encrypt 文档 — ACME 证书自动化的最佳实践SSL Labs SSL Pulse — 每月发布 HTTPS 生态健康报告