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) 遭受攻击而流行起来,当时的攻击者能够为包括谷歌在内的多个知名网站创建通配符证书。 Chrome 更新为“固定”Google 网站的当前证书,如果提供了其他证书,将拒绝任何连接。 即使攻击者找到了一种方法来说服 CA 颁发欺诈性证书,Chrome 仍会将其识别为无效,并且拒绝连接。
尽管 Chrome 和 Firefox 等 Web 浏览器是最早实现此技术的应用程序,但用例范围迅速扩大。 物联网 (IoT) 设备、iOS 和 Android 移动应用,不同的软件应用程序开始使用此技术来防御中间人攻击。
几年来,证书固定被认为是良好的安全做法。 对公钥基础结构 (PKI) 领域的监督已得到改善,受公众信任的 CA 的颁布做法具有了更多透明度。
如何在应用程序中解决证书固定问题
通常,应用程序包含授权证书或证书属性的列表,包括使用者可分辨名称、指纹、序列号和公钥。 应用程序可能会针对单个叶或最终实体证书、从属 CA 证书甚至根 CA 证书进行固定。
如果应用程序显式指定了可接受 CA 的列表,则你可能需要在证书颁发机构更改或过期时定期更新已固定的证书。 若要检测证书固定,建议执行以下步骤:
如果你是应用程序开发人员,请在源代码中搜索以下任何正在更改或即将过期的 CA 引用。 如果存在匹配项,请更新应用程序以包含缺少的 CA。
- 证书指纹
- 使用者可分辨名称
- 公用名
- 序列号
- 公钥
- 其他证书属性
如果租户客户端应用程序与 Azure API 或其他 Azure 服务集成,但你不确定它是否使用证书固定,请向应用程序供应商核实。
证书固定限制
证书固定的做法广受争议,因为它带来了不可接受的证书敏捷成本。 一个具体的实现,HTTP 公钥固定 (HPKP),已完全弃用
由于没有单一的 Web 标准来说明证书固定的执行方式,我们无法提供检测其使用情况的直接指导。 虽然我们不建议禁止证书固定,但客户应在选择使用它时了解这种做法带来的限制。
- 确保可以在短时间内更新固定的证书。
- 行业要求(例如 CA/浏览器论坛针对颁发和管理公众信任的证书的基线要求)规定,在某些情况下,需要在 24 小时内轮换和吊销证书。