【问题标题】:Certificate chain length not valid证书链长度无效
【发布时间】:2015-11-14 19:28:15
【问题描述】:

我们遇到了一个奇怪的情况。在建立连接时,我们的应用程序会执行一系列安全检查。其中之一是检查链长是否正确。我们知道应该是3:Root、intermediate和server。

当我们使用 Android 应用程序连接到服务器时,我们得到的响应只有两个中间证书和服务器 - 没有根。但是,当我们对网络浏览器进行检查时,我们提出了一项关于 Android 5.0 的研究,我们看到了 3,而在 Android 4.3 上,我们看到了其中的两个。连接表单 iOS 生成 3 个证书。

是服务器还是安卓?我们可以做些什么来获得根证书?

编辑: 我们从浏览器下载证书(根证书和中间证书)并从中创建一个密钥库并将其放入应用程序资产中。然后在我们的 CustomTrustManager 中,我们将来自密钥库的证书与来自我们连接的服务器的证书进行比较。

基本上,我们的比较是基于证书指纹。问题是根证书不是来自服务器,无法比较它。

但我们提出了这个想法。

我们可以比较来自服务器的中间证书是由根证书签名的,根证书在应用程序中进行了编码。

我认为这已经足够安全了。

我们将只比较中间指纹。

【问题讨论】:

    标签: android ssl certificate ssl-certificate


    【解决方案1】:

    我不知道您是如何准确进行检查的,但总的来说:

    • 服务器必须将服务器证书和从服务器证书引出的所有中间证书发送到内置根 CA。如果缺少链证书,则某些浏览器(例如桌面版 Chrome)会尝试填写缺少的证书,而其他浏览器(例如不是浏览器的大多数应用程序)由于无法创建信任链而无法验证。
    • 服务器不应发送根 CA 本身,但某些服务器还是会发送。在这种情况下,服务器发送的根 CA 将被忽略。
    • 根据存储在浏览器/系统中的根 CA,可能会有不同的信任路径,通常也有不同的长度。当涉及交叉签名时尤其如此,通常在引入新的根 CA 时就是这种情况。由于这些最初不在浏览器/系统 CA 存储中,它们由信任存储中的另一个 CA 签名,但后来新的根 CA 在信任存储中,因此链更短。此过程目前也用于将使用 1024 位 RSA 的各种根 CA 替换为使用更强密钥(即 4096 位)的根 CA。

    这意味着您看到的链长取决于很多因素:

    • 你怎么看:你看服务器发的链还是系统构建的链?后者将包含根 CA,而第一个不应该但可能包含。
    • 系统上存在哪些根 CA:较旧的系统可能会构建更长的链,因为较新的根 CA 或尚未在系统中。

    【讨论】:

    • 我们从浏览器下载证书(根证书和中间证书)并从中创建一个密钥库并将其放入应用程序资产中。然后在我们的 CustomTrustManager 中,我们将来自密钥库的证书与来自我们连接的服务器的证书进行比较。基本上我们的比较是基于证书指纹。问题是根证书不是来自服务器,无法比较它。
    • @elon:目前还不清楚你为什么要做这样的事情。检查您是否连接到预期服务器的既定方法是验证服务器证书或其公钥,即certificate or public key pinning。如果服务器证书被泄露,攻击者还可以包含所有链证书,因为它们是公开的,因此比较它们也没有用。
    猜你喜欢
    • 2014-06-13
    • 2016-07-13
    • 2013-09-28
    • 2018-12-28
    • 1970-01-01
    • 1970-01-01
    • 2021-02-19
    • 2013-01-07
    • 2021-08-06
    相关资源
    最近更新 更多