Will your certificate work on Android?
Check whether a TLS certificate is configured correctly for Android clients, including older Java-based HTTP libraries that are stricter than browsers.
Why Android is stricter than browsers
Most modern browsers are very forgiving about TLS certificate configuration. When they encounter a server that has not been configured perfectly, they quietly compensate — they fetch missing intermediate certificates over the network (the AIA extension), rebuild the chain in the right order, and try multiple roots until something works. The result is that web admins often think their certificate is fine, because it looks fine in Chrome.
Android, and especially the Java HTTP stack on Android, does not do any of that. The standard HttpsURLConnection client (and older versions of OkHttp/Volley) follows the TLS spec literally: the server must present the full intermediate chain, in the correct order, signed by a CA that is already in Android's built-in trust store. If anything is off, the handshake just fails.
The most common ways this bites in production:
- Missing intermediate certificate. The server only sends the leaf. Browsers fetch the rest via AIA and never tell you. Android refuses.
- Wrong order on the wire. Server sends leaf, root, intermediate — out of order. Browsers fix it. Older Android Java clients reject the chain.
- Newer root not in old Android. Let's Encrypt's ISRG Root X1 wasn't in Android until 7.1.1. Devices stuck on 4.x–7.0 fail unless the chain crosses to an older root (DST Root CA X3, expired 2021-09-30).
- SAN missing or wrong. Android has ignored the CN field for years. Without a matching Subject Alternative Name, the cert is rejected even if everything else is right.
- Validity over 398 days. Certificates issued after 2020-09-01 with longer validity are rejected on Android 11+.
The checks on this page are designed to catch all of these before they reach a user's device.