Fetching the CA details from a x.509 certificate in Android

Question

I have initiated an HTTPS connection using something like

httpsCert.connect();

where httpsCert is HttpsURLConnection httpsCert.

Now I do something like Certificate[] certs = httpsCert.getServerCertificates(); to retrieve the server x.509 certificates.

I want to retrieve which root CA or the intermediary CA signed the certificate received above.

My approach has been to look at the issuer field in the certificate received above, but is it a good approach. I mean is there a better approach of doing this ?

Secondly, from developer.android.com/HttpsUrlConnection, it appears that getServerCertificates () would return the list of certificates identifying the peer with the peer's identity certificate followed by CAs. In this context, in case of some certificates, like certificates fetched by Google apps, there is a section of the certificate that says Authority Information Access: CA Issuers - URI:http://pki.google.com/GIAG2.crt however this is not the case with other apps fetching certificates signed by other authorities.

Second question is how does Android validate the certificate path for certificates signed by intermediary CAs ?

Answer 1

I want to retrieve which root CA or the intermediary CA signed the certificate received above.

If you are talking about missing certificates, then you can't. This is a well known problem in PKI called the "which directory" problem. The problem is you don't know where to look to find the missing certificates. The problem is resolved by the server sending all the certificates you need to build the chain to perform the validation.

You still have to root trust somewhere; otherwise the bad guy would send you the chain he wants you to trust and you would be no wiser. That's why user agents like browsers and cURL carry around a list like cacert.pem.

In fact, some poorly configured servers will not send the needed intermediate certificates. In this case, the browsers carry around a list of intermediates to fill in the missing pieces.

Also see Peter Gutmann's Engineering Security.

---

My approach has been to look at the issuer field in the certificate received above, but is it a good approach. I mean is there a better approach of doing this ?

That's roughly how the chain is built. When you use the issuer's name, you are using a Distinguished Name (Issuer DN in "directory speak"). There's a Subject DN, too. The Issuer is the authority, and the subject is the entity that its issued to.

When validating a chain, its called "path building". That leads you to RFC 4158, Internet X.509 Public Key Infrastructure: Certification Path Building.

The DN alone is usually not enough because a bad guy can re-use the same name and you would be no wiser. So you often use the Authority Key Identifier (AKI in "directory speak"), which is a thumbprint or digest of the the issuer's public key. The bad guy cannot do useful things by forging the AKI because he does not have the private key to go along with it.

Other things used to make the tuple unique is the Serial Number. This is important when a CA re-issues a certificate using the same DN and same public key - only the serial number differs. You will see this happen when the hash is changed from SHA-1 to SHA-256.

Re-issuing and changing only the hash has happened in the past. Its one of the more difficult path validation failures to track down because everything looks OK on the surface. It takes you a while to realize the DN and AKI are OK, but the SN does not match.

---

Second question is how does Android validate the certificate path for certificates signed by intermediary CAs ?

Android is Java, and Java follows the RFCs. Here are the three RFCs you need to consult. Its not a small topic, and you could write a book providing the full treatment:

• RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
• RFC 6125, Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)
• RFC 4158, Internet X.509 Public Key Infrastructure: Certification Path Building

The "Internet X.509 Public Key Infrastructure" is also referred to as PKIX. Its the Internet's PKI profile. Other organization's PKI's can and sometimes will be a different. That just means other organizations may have different rules than what PKIX uses and documents in the RFCs.

---

Note well: a "CA root" will be self-signed. The Subject DN will be the same as the Issuer DN, the Subject's Key Identifier (SKI in "directory speak") will be the issuer's Authority Key Identifier (AKI in "directory speak"), etc. In addition, basic constraints will have CA=true and it will probably be marked critical.

An intermediate CA certificate will be issued against (or chained to) a distinct certificate, so Subject DN will not be the same as Issuer DN. But like the self-signed root, basic constraints will have CA=true and it will probably be marked critical.

Its perfectly acceptable for you - as a relying party - to trust an intermediate but not a root, even if the intermediate was certified by the root. That's your prerogative.