如何将 OpenSSL 指向 Android 设备上的根证书？答案

【问题标题】：How to point OpenSSL to the root certificates on an Android device?如何将 OpenSSL 指向 Android 设备上的根证书？
【发布时间】：2013-02-28 19:30:51
【问题描述】：

我已经设法交叉编译 OpenSSL for ARMv6 以与 the Android NDK 一起使用，并让它在我的应用程序中运行。但是，当尝试与知名主机（例如https://google.com）建立 HTTPS 连接时，我总是收到错误消息“SSL 证书无效。”

但是，我可以在我设备的任何浏览器（常用浏览器、Chrome、Firefox 等）中显示安全页面。因此我只能假设 OpenSSL 没有找到存储在设备上的根证书。

然后我的问题分解为两个非常相关的子问题：

Android 将根证书存储在设备的什么位置？
如何将 OpenSSL 指向它们？

【问题讨论】：

标签： android android-ndk openssl root-certificate

【解决方案1】：

Android 将根证书存储在设备的什么位置？

它四处移动。随着冰淇淋三明治 (ICS) 的出现，使用了三个商店。这三个商店分别是/data/misc/keychain（Android提供）、/data/misc/keychain/cacerts-added（用户添加的CA）和/data/misc/keychain/cacerts-removed（用户删除或更新的CA）。

在 ICS 之前，他们使用位于 /system/etc/security/cacerts.bks 的 BouncyCastle 商店。这是一个静态存储，无法修改。如果需要更改，则需要更新固件或映像。

有关商店的说明，请参阅ICS Trust Store Implementation。这是 Nikolay Elenkov 的博客，他在讨论系统方面做得很好，而不仅仅是商店所在的位置。

如何将 OpenSSL 指向它们？

您无法真正做到这一点，因为 OpenSSL 期望和 Android 呈现的是两种不同的呈现/存储格式。 OpenSSL 期望将一组 PEM 格式的信任锚连接在一起。但 Android 信任库不是这种格式。

通常发生的是您下载cacert.pem。然后，通过将cacert.pem 指定为CAfile 参数，调用SSL_CTX_load_verify_locations 来加载它们。

即使您从受信任的来源（如 Mozilla 或 cURL）下载 cacert.pem，您仍应仔细检查并确保您对信任锚的集合感到满意。包中有 155 个潜在的信任锚：

$ cat cacert.pem | grep BEGIN | wc -l
     155

但就像我在评论中所说的那样，它隐含地使用了浏览器安全模型，在许多情况下它并不是一个特别好的做事方式。

在尝试与知名主机（例如https://google.com）建立 HTTPS 连接时，我总是收到错误消息“SSL 证书无效。”

要回答这个问题，只需使用Google Internet Authority 或GeoTrust Global CA 和SSL_CTX_load_verify_locations。最好使用 Google Internet Authority，因为它会限制网络投射。

谷歌互联网管理局：

GeoTrust Global CA：

在理想情况下，您运行私有 PKI，并且您只信任 PKI 的根来认证站点和服务。您不授予信任公共 CA 来证明任何内容，因为它们不对依赖方作出任何保证。从本质上讲，公共 CA 会告诉您他们的warez 并不好，即使是出于将它们出售给网站的目的。

在次优世界中，您只使用认证站点的公共 CA。这意味着您使用 Google Internet Authority 或 GeoTrust Global CA 来认证 Google 资产；而不是，比如Diginotar。

还有其他不太明显的问题。 Google Internet Authority 是一个由 GeoTrust 认证的无约束从属 CA。 Google 可以为任何网站颁发证书，而不仅仅是 Google 资产。通常，这会被 RA 捕获，它实际上是一个独立的审计员，在签发之前验证对 CA 的签名请求。但在此模型中，提出请求的组织 (Google) 与验证请求的组织 (Google) 和颁发证书的组织 (Google) 相同。浏览器、CA 和 PKI 是我知道的唯一实例，独立审计员作为检查和平衡被完全删除because it was too inconvenient。

如果你认为下属不会做这种事，那你就大错特错了。 CNICC was just removed from a few browser trust stores，因为它的一个不受约束的下属被发现为未经授权的站点和服务颁发证书。

浏览器安全模型真正出问题的地方在于错误的 CA 能够认证站点。它包括对用户的成功网络钓鱼尝试。也就是说，浏览器很乐意允许连接被拦截，因为用户被钓鱼了。

如果您认为即将发布的Public Key Pinning with Overrides 会有所帮助，那么您就大错特错了。尽管他们几乎没有提到覆盖，但攻击者可以破坏已知的良好 pinset。更糟糕的是，报告功能会因带有不得报告的损坏的 pinset 而被禁用，因此浏览器是隐瞒的同谋。

关于该主题的阅读更多。首先，试试 Peter Gutmann 的 Engineering Security 和 Audun Jøsang 的 Trust Extortion on the Internet。

【讨论】：

【解决方案2】：

android 根证书存放在哪里：

根据将证书添加到不同设备上的本地密钥库的大量问题，他们从一个版本到另一个版本，从一个设备到另一个设备。其中大多数要求设备被植根，后来 cmets 谈到解决方案会中断，因为他们在特定设备上移动或更改了格式。

如何将 openssl 指向它们：

我不确定现在是否有“好”的方法可以做到这一点。我能找到的最佳解决方法是this answer，然后将这些证书放入您自己的 openssl 理解的应用程序特定存储中。

一个不完美的解决方案，但你也许可以使用。

【讨论】：

【解决方案3】：

android在哪里存储根证书：

系统证书：这些存储在System/etc/security/cacerts.bks
第三方证书：这些证书存储在data/misc/keystore

如何将 openssl 指向他们：

android 操作系统与您的 openssl 库一起处理此问题。您不必手动指向它。

根据你提供的信息，我写在下面。

考虑到您的应用程序是 VPN 或基于云的应用程序。

问题可能是由于您在设备中安装了无效的 SSL 根 CA 来检查 SSL 流量。

希望对你有帮助

【讨论】：