Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
证书固定是一种安全技术,其中客户端在建立安全会话时仅接受经过授权的或 固定 的证书。 客户端拒绝使用不同证书建立安全会话的任何尝试。
证书固定历史记录
安全社区最初设计出证书固定机制,是为了防范中间人攻击(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 小时内完成证书轮换和吊销。