Where does Android store root certificates on the device?
He is moving. With the advent of Ice Cream Sandwich (ICS), three stores are used. Three stores: /data/misc/keychain (supplied by Android), /data/misc/keychain/cacerts-added (added by CA users) and /data/misc/keychain/cacerts-removed (deleted by users or updates).
Prior to ICS, they used the BouncyCastle store located at /system/etc/security/cacerts.bks . It was a static store and could not be changed. If this needs to be changed, you need to update the firmware or image.
For an explanation of stores, see ICS Trust Store Implementation. His blog is Nikolai Elenkov, and he copes with the discussion of the system, and not just where the stores are.
How can I point OpenSSL to them?
You cannot do this, because what OpenSSL expects and what Android represents is two different presentation / storage formats. OpenSSL expects the collection of trust bindings in PEM format to be combined together. But the Android trust store is not in this format.
It often happens that you download cacert.pem . You then load them by calling SSL_CTX_load_verify_locations , specifying cacert.pem as the CAfile argument.
Even if you download cacert.pem from a trusted source, such as Mozilla or cURL, you still need to go through it and make sure you are happy with the collection of trusted bindings. The package has 155 potential trust anchors:
$ cat cacert.pem | grep BEGIN | wc -l 155
But, as I said in a comment, it implicitly uses the browser security model, and this is not a very good way to do something in many cases.
when I try to establish an HTTPS connection with a known host (for example, https://google.com ), I always get the error message "The SSL certificate is not valid.
To answer this question, simply use Google Internet Authority or GeoTrust Global CA with SSL_CTX_load_verify_locations . It is probably best used by the Google Internet Authority because it restricts network transmission.
Google Internet Administration :
-----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 Global 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-----
In an ideal world, you run a private PKI, and you only trust your PKI root to certify sites and services. You do not trust the public certification authority to confirm anything because they do not give any guarantees to the relying party. Essentially, a public CA tells you that their warez are not good, even if they sell them on sites.
In the next best world, you only use the public certification authority that certified the site. This means that you use Google Internet Authority or GeoTrust Global CA to certify Google properties; not, say Diginotar .
There are other ill-conceived problems. The Google Internet Authority is a subordinate CA without restrictions , certified by GeoTrust. Google can issue certificates for any site, not just Google properties. This is usually delayed by the RA, which is in fact an independent auditor who validates the signature request in the CA before release. But in this model, the organization that creates the request (Google) is the same organization that validates the request (Google) and the same organization that issues the certificate (Google). Browsers, CA and PKI are the only instance that, as far as I know, the independent auditor has been completely removed as a balance sheet because it was too inconvenient .
If you think that a subordinate would not do this, then you would be sadly mistaken. CNICC was simply removed from several browser trust stores because one of its unconditional subordinates was caught issuing certificates for sites and services that it did not authorize.
If the browser’s security model does break, this is an opportunity for the wrong CA to certify the site. And this includes successful phishing attempts for the user. That is, the browser will happily allow connection interception, since the user was phishing.
If you think about the upcoming opening of a public key with overrides will help, then you will be sadly mistaken. Although they almost never mention overrides, an attacker can tear a well-known good pinset. And even worse, the reporting feature is disabled for a broken tweezer with SHOULD NOT RESPOND , so the browser is involved in the cover.
There is much more information available on this subject. To get started, try Peter Gutmann Engineering Safety and Audun Jøsang Trust Extortion on the Internet .