我已经设法为 ARMv6 交叉编译 OpenSSL 以与Android NDK一起使用，并让它在我的应用程序中运行。但是，当尝试与知名主机（例如https://google.com）建立 HTTPS 连接时，我总是收到错误消息“SSL 证书无效”。
但是，在我设备的任何浏览器（常用浏览器、Chrome、Firefox 等）中显示安全页面都没有困难。因此我只能假设 OpenSSL 没有找到存储在设备上的根证书。
然后我的问题分解为两个非常相关的子问题：
Android 将根证书存储在设备的什么位置？
它四处移动。随着冰淇淋三明治 (ICS) 的出现，使用了三个商店。这三个商店是/data/misc/keychain（由 Android 提供）、/data/misc/keychain/cacerts-added（用户添加的 CA）和/data/misc/keychain/cacerts-removed（用户删除或更新的 CA）。
在 ICS 之前，他们使用位于 的 BouncyCastle 商店/system/etc/security/cacerts.bks。这是一个静态存储，无法修改。如果需要更改，则需要更新固件或映像。
有关存储的说明，请参阅ICS 信任存储实现。这是 Nikolay Elenkov 的博客，他在讨论系统方面做得很好，而不仅仅是商店所在的位置。
我如何将 OpenSSL 指向他们？
您不能真正做到这一点，因为 OpenSSL 期望和 Android 呈现的是两种不同的呈现/存储格式。OpenSSL 期望将一组 PEM 格式的信任锚连接在一起。但 Android 信任库不是这种格式。
通常发生的事情是您下载cacert.pem. SSL_CTX_load_verify_locations然后，通过指定cacert.pem为CAfile参数调用来加载它们。
即使您cacert.pem从受信任的来源（如 Mozilla 或 cURL）下载，您仍应仔细检查并确保您对信任锚的集合感到满意。包中有 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，因为它限制了网络投射。
谷歌互联网管理局：
-----BEGIN CERTIFICATE-----
MIID8DCCAtigAwIBAgIDAjp2MA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT
MRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMRswGQYDVQQDExJHZW9UcnVzdCBHbG9i
YWwgQ0EwHhcNMTMwNDA1MTUxNTU1WhcNMTYxMjMxMjM1OTU5WjBJMQswCQYDVQQG
EwJVUzETMBEGA1UEChMKR29vZ2xlIEluYzElMCMGA1UEAxMcR29vZ2xlIEludGVy
bmV0IEF1dGhvcml0eSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AJwqBHdc2FCROgajguDYUEi8iT/xGXAaiEZ+4I/F8YnOIe5a/mENtzJEiaB0C1NP
VaTOgmKV7utZX8bhBYASxF6UP7xbSDj0U/ck5vuR6RXEz/RTDfRK/J9U3n2+oGtv
h8DQUB8oMANA2ghzUWx//zo8pzcGjr1LEQTrfSTe5vn8MXH7lNVg8y5Kr0LSy+rE
ahqyzFPdFUuLH8gZYR/Nnag+YyuENWllhMgZxUYi+FOVvuOAShDGKuy6lyARxzmZ
EASg8GF6lSWMTlJ14rbtCMoU/M4iarNOz0YDl5cDfsCx3nuvRTPPuj5xt970JSXC
DTWJnZ37DhF5iR43xa+OcmkCAwEAAaOB5zCB5DAfBgNVHSMEGDAWgBTAephojYn7
qwVkDBF9qn1luMrMTjAdBgNVHQ4EFgQUSt0GFhu89mi1dvWBtrtiGrpagS8wEgYD
VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAQYwNQYDVR0fBC4wLDAqoCig
JoYkaHR0cDovL2cuc3ltY2IuY29tL2NybHMvZ3RnbG9iYWwuY3JsMC4GCCsGAQUF
BwEBBCIwIDAeBggrBgEFBQcwAYYSaHR0cDovL2cuc3ltY2QuY29tMBcGA1UdIAQQ
MA4wDAYKKwYBBAHWeQIFATANBgkqhkiG9w0BAQUFAAOCAQEAJ4zP6cc7vsBv6JaE
+5xcXZDkd9uLMmCbZdiFJrW6nx7eZE4fxsggWwmfq6ngCTRFomUlNz1/Wm8gzPn6
8R2PEAwCOsTJAXaWvpv5Fdg50cUDR3a4iowx1mDV5I/b+jzG1Zgo+ByPF5E0y8tS
etH7OiDk4Yax2BgPvtaHZI3FCiVCUe+yOLjgHdDh/Ob0r0a678C/xbQF9ZR1DP6i
vgK66oZb+TWzZvXFjYWhGiN3GhkXVBNgnwvhtJwoKvmuAjRtJZOcgqgXe/GFsNMP
WOH7sf6coaPo/ck/9Ndx3L2MpBngISMjVROPpBYCCX65r+7bU2S9cS+5Oc4wt7S8
VOBHBw==
-----END CERTIFICATE-----
GeoTrust 全球 CA :
-----BEGIN CERTIFICATE-----
MIIDVDCCAjygAwIBAgIDAjRWMA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT
MRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMRswGQYDVQQDExJHZW9UcnVzdCBHbG9i
YWwgQ0EwHhcNMDIwNTIxMDQwMDAwWhcNMjIwNTIxMDQwMDAwWjBCMQswCQYDVQQG
EwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEbMBkGA1UEAxMSR2VvVHJ1c3Qg
R2xvYmFsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2swYYzD9
9BcjGlZ+W988bDjkcbd4kdS8odhM+KhDtgPpTSEHCIjaWC9mOSm9BXiLnTjoBbdq
fnGk5sRgprDvgOSJKA+eJdbtg/OtppHHmMlCGDUUna2YRpIuT8rxh0PBFpVXLVDv
iS2Aelet8u5fa9IAjbkU+BQVNdnARqN7csiRv8lVK83Qlz6cJmTM386DGXHKTubU
1XupGc1V3sjs0l44U+VcT4wt/lAjNvxm5suOpDkZALeVAjmRCw7+OC7RHQWa9k0+
bw8HHa8sHo9gOeL6NlMTOdReJivbPagUvTLrGAMoUgRx5aszPeE4uwc2hGKceeoW
MPRfwCvocWvk+QIDAQABo1MwUTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTA
ephojYn7qwVkDBF9qn1luMrMTjAfBgNVHSMEGDAWgBTAephojYn7qwVkDBF9qn1l
uMrMTjANBgkqhkiG9w0BAQUFAAOCAQEANeMpauUvXVSOKVCUn5kaFOSPeCpilKIn
Z57QzxpeR+nBsqTP3UEaBU6bS+5Kb1VSsyShNwrrZHYqLizz/Tt1kL/6cdjHPTfS
tQWVYrmm3ok9Nns4d0iXrKYgjy6myQzCsplFAMfOEVEiIuCl6rYVSAlk6l5PdPcF
PseKUgzbFbS9bZvlxrFUaKnjaZC2mqUPuLk/IH2uSrW4nOQdtqvmlKXBx4Ot2/Un
hw4EbNX/3aBd7YdStysVAq45pmp06drE57xNNB6pXE0zX5IJL4hmXXeXxx12E6nV
5fEWCRE11azbJHFwLJhWC9kXtNHjUStedejV0NxPNO3CBWaAocvmMw==
-----END CERTIFICATE-----
在理想的世界中，您运行一个私有 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 是我知道的唯一实例，因为它太不方便了，所以独立审计员被完全删除作为制衡。
如果你认为下属不会这样做，那你就大错特错了。CNICC 刚刚从一些浏览器信任库中删除，因为它的一个不受约束的下属被发现为未经授权的站点和服务颁发证书。
浏览器安全模型真正出问题的地方是错误的 CA 认证站点的能力。它包括对用户的成功网络钓鱼尝试。也就是说，浏览器会很高兴地允许连接被拦截，因为用户被钓鱼。
如果您认为即将推出的带有覆盖的公钥固定会有所帮助，那么您就大错特错了。尽管他们几乎没有提到覆盖，但攻击者可以破坏已知的良好 pinset。更糟糕的是，报告功能被禁用了一个损坏的 pinset 并带有MUST NOT Report，因此浏览器是掩饰的同谋。
关于这个主题有更多的阅读材料。对于初学者，请尝试 Peter Gutmann 的Engineering Security和 Audun Jøsang 的Internet 上的信任勒索。
根据将证书添加到不同设备上的本地密钥库的大量问题，他们从一个版本到另一个版本，从一个设备到另一个设备。其中大多数要求设备被植根，后来的评论谈到解决方案中断，因为它们在特定设备上移动或更改了格式。
我不确定现在是否有一种“好”的方法可以做到这一点。我能找到的最佳解决方法是这个答案，然后将这些证书放入您自己的 openssl 理解的应用程序特定存储中。
一个不完美的解决方案，但您也许可以使用。
android在哪里存储根证书：
系统证书： 这些存储在 System/etc/security/cacerts.bks
第三方证书：这些存储在data/misc/keystore
我如何将 openssl 指向他们：
与您的 openssl 库一起使用的 android 操作系统将处理此问题。您不必手动指向它。
根据您提供的信息，我在下面写。
考虑到您的应用程序是 VPN 或基于云的应用程序。
该问题可能是由于您安装在设备中以检查 SSL 流量的 SSL 根 CA 无效。
希望这可以帮助