证书固定是一种安全技术，其中客户端在建立安全会话时仅接受经过授权的或 固定 的证书。 客户端拒绝使用不同证书建立安全会话的任何尝试。
证书固定历史记录
安全社区最初设计出证书固定机制，是为了防范中间人攻击（MITM）。 证书固定这一概念最早于 2011 年因 DigiNotar 证书颁发机构 (CA) 遭入侵事件而广为人知，当时一名攻击者为包括 Google 在内的多个知名网站创建了通配符证书。 谷歌更新了 Chrome，使其固定 Google 网站当前使用的证书，并拒绝任何提供了不同证书的连接。 即使攻击者说服CA签发了伪造证书，Chrome也会认定该证书无效并拒绝连接。
尽管 Chrome 和 Firefox 等 Web 浏览器是第一个实现这项技术的应用程序之一，但用例范围迅速扩展。 物联网（IoT）设备、iOS和Android移动应用，以及各种软件应用开始使用这种技术来防御中间人攻击。
多年来，证书固定一直是一种良好的安全实践。 对公钥基础设施（PKI）环境的监管加强，使公开可信CA的发行实践更加透明。
如何在应用程序中解决证书固定问题
通常，应用程序包含授权证书的列表或证书的属性，包括主题区分名称、序列号、指纹和公钥。 应用程序可能会针对单个叶证书或最终实体证书、从属 CA 证书，甚至根 CA 证书进行固定。
如果你的应用程序明确列出了可接受的CA列表，当证书授权机构变更或过期时，可能需要定期更新置顶证书。 要检测证书钉顶，请采取以下步骤：
如果你是应用程序开发人员，请在源代码中搜索以下任何正在更改或过期的 CA 引用。 如果存在匹配项，请更新应用程序以包含缺少的 CA。
- 证书指纹
- 主题可分辨名称
- 公用名
- 序列号
- 公钥
- 其他证书属性
如果您的自定义客户端应用程序与 Azure API 或其他 Azure 服务集成，并且您不确定它是否使用证书固定，请咨询应用程序供应商。
证书绑定的限制
证书固定这种做法之所以广受争议，是因为它会带来不可接受的证书敏捷性成本。 其中一种具体实现——HTTP 公钥钉销（HPKP）已被完全弃用。
由于没有任何单一的 Web 标准规定应用程序如何执行证书固定，因此微软未就如何检测是否使用了证书固定提供直接指导。 虽然 Microsoft 并不反对使用证书固定，但如果你选择使用它，请注意这种做法会带来的局限性。
- 确保固定的证书能够及时接收更新。
- 行业要求，如 CA/浏览器论坛《公开受信任证书颁发和管理基线要求》，要求在某些情况下在短至 24 小时内完成证书轮换和吊销。