证书固定是一种安全技术，实现在建立安全会话时，仅接受已授权或已固定的证书。 使用其他证书建立安全会话的任何尝试都会被拒绝。
证书固定历史记录
证书固定最初设计为挫败中间人（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 标准规定如何执行证书钉扎，因此我们无法就如何检测其使用提供直接指导。 虽然我们不反对证书固定，但如果客户选择使用这种做法，应注意其带来的限制。
- 确保固定的证书可以在短时间内更新。
- 行业要求，如 CA/Browser 论坛颁发和管理 Publicly-Trusted 证书的基线要求 ，在某些情况下只需 24 小时轮换和撤销证书。