An SSL connection error on Android usually looks like a full-page warning that says “Your connection is not private,” and it can appear in Chrome, inside an app’s built-in browser, or as a silent failure in a native app that simply refuses to load anything. The message is generic on purpose, so it tells you very little about what actually went wrong.
Android also handles certificate trust differently from a desktop computer, which is why a site can load perfectly on your laptop and still fail on your phone. This tutorial explains what makes Android different, how to read the error you are getting, and what to do about it as a visitor and as a website owner.
Why Android is different: two trust stores on one phone
Every HTTPS connection ends with the client deciding whether it trusts the certificate the server presented. On a desktop, there is normally one answer per browser. On Android, there are two, and they belong to different parts of the system:
- Chrome for Android uses the Chrome Root Store, Google’s own list of trusted certificate authorities, enabled by default since Chrome 115 in 2023. It ships with Chrome and updates when Chrome updates.
- WebView, in-app browsers, and native apps use the Android system trust store, which ships with the operating system. A link you open inside Facebook or Instagram renders in that app’s own WebView browser rather than in Chrome, even when Chrome is your default browser. Not every in-app browser works this way, though: apps such as X and Slack hand links to a Custom Tab, which is Chrome itself in a stripped-down window, so those use the Chrome Root Store.
- Firefox for Android carries a third, independent trust store of its own, which is why it sometimes loads a site that everything else on the phone rejects.
This is the single most useful diagnostic signal on Android. If a page fails in one app but loads in another on the same phone, on the same network, seconds apart, the phone is not broken and the network is not blocking you. You have found a difference between two trust stores, and that difference is almost always caused by the certificate chain the server sends.
On Android 14 and later, the system trust store can also be updated through Google Play system updates instead of waiting for a full OS upgrade, so newer devices pick up certificate authority changes faster than older ones did.
Why a missing intermediate breaks Android first
A missing intermediate certificate is the most common server-side cause of SSL connection errors on Android, and there is a specific technical reason why a phone notices it when a desktop does not.
When a server forgets to send its intermediate certificate, the chain from the site’s certificate up to a trusted root has a hole in it. Desktop browsers usually paper over this. They read the Authority Information Access (AIA) field in the certificate and download the missing intermediate themselves, a repair known as AIA fetching. Between the two, the hole is normally filled before you ever see it.
Android has neither cushion. Its system certificate validation, which every native app relies on, does not fetch missing intermediates at all, which is why apps fail with “Trust anchor for certification path not found” against a site that a laptop loads without complaint. Chrome for Android and WebView do attempt an AIA fetch, but it only succeeds when the certificate carries a usable issuer URL and the download completes inside the verifier’s time limit, and a phone starts with no store of previously seen intermediates to fall back on. The repair that is invisible and dependable on a desktop is neither on a phone. If you are a site owner and users report an Android-only problem, check the chain before you check anything else.
Read the error code first
The “Your connection is not private” screen hides the useful part. In Chrome for Android, tap Advanced on the warning page and read the error code underneath. It narrows the cause immediately:
- NET::ERR_CERT_AUTHORITY_INVALID: the device cannot build a trusted chain. On Android this usually means a missing intermediate certificate, a self-signed certificate, or a root your device does not have. This is the most common Android code.
- NET::ERR_CERT_DATE_INVALID: the certificate is outside its validity window. Either it genuinely expired, or your phone’s clock is wrong. Check the clock first, because it is the one cause you can fix yourself in ten seconds.
- NET::ERR_CERT_COMMON_NAME_INVALID: the certificate is valid, but it was not issued for the address you typed. Common when a site covers example.com but not www.example.com.
- NET::ERR_CERT_REVOKED: the certificate authority withdrew the certificate before its expiry date. Only the site owner can resolve this, by requesting a replacement.
- Trust anchor for certification path not found: the WebView and native-app version of the same failure as ERR_CERT_AUTHORITY_INVALID. You will see it in an in-app browser or in an app’s own error screen rather than in Chrome. It means the app could not build a chain to a root it trusts, and a missing intermediate is again the usual explanation.
If the warning appears on one specific site while everything else loads normally, the problem is on that site’s server and no setting on your phone will fix it. If it appears on every site you open, the cause is on your device or your network, and the steps below apply.
How to fix the SSL connection error on Android as a website visitor
Work through these in order. They are arranged from the most common and most easily fixed cause to the least.
1. Check whether it is one site or every site
Open two or three well-known sites in the same browser. This single test splits the problem in half:
- Other sites load normally. Your device, its clock, and its trust store are fine. The certificate on the site you were visiting is the problem. Skip to the website owner section, or report it to the site.
- Every site fails. The cause is on your device or your network. Continue with the steps below.
Then repeat the failing page in a second app, for example open it in Chrome if it failed in an in-app browser, or paste it into an in-app browser if it failed in Chrome. A different result between the two confirms a trust store difference rather than a device fault.
2. Correct the date and time
Certificates are only valid between two timestamps. If your phone’s clock is wrong by more than a day, valid certificates start to look expired or not yet valid, and every HTTPS site on the device begins to fail at once. A phone that has been switched off for a long time, or one with a drained backup battery, is the classic case.
- Open Settings and go to System, then Date & time. On Samsung devices this lives under General management instead.
- Turn on Set time automatically and Set time zone automatically.
- If they were already on, switch them off, set the correct date and time by hand, then switch them back on. That forces a fresh synchronization.
3. Sign in to the Wi-Fi network first
Public Wi-Fi in hotels, airports, cafés, and trains often uses a captive portal, the login or terms-of-use page you have to accept before the network lets you out. Until you do, the network intercepts your requests and answers them itself. Because it cannot present a valid certificate for the site you asked for, HTTPS pages come back as certificate warnings.
Android usually detects this and posts a Sign in to network notification. Tap it. If no notification appears, open your browser and load any plain HTTP address, one that starts with http:// rather than https://. An unencrypted request has no certificate to validate, so the portal can redirect it and its login page will appear. Once you have signed in, reload the original site.
Switching to mobile data will also load the page, but that is a way around the network rather than a fix. It is still a useful test: if the site loads on mobile data and fails on Wi-Fi, the Wi-Fi network is what is interfering.
4. Check whether your Android version still receives updates
A trust store that stops being updated slowly stops working. Certificate authorities issue new roots, and a device that never receives them fails on more of the web each year. Two specific cutoffs affect Android devices in use right now:
- Android 7.0 and earlier. Let’s Encrypt certificates used to chain through a cross-signature from an older root, DST Root CA X3, so that devices predating Let’s Encrypt could still trust them. That cross-signature expired on 30 September 2024 and cannot be renewed. Android 7.1 and later ship with the replacement root, ISRG Root X1, but Android 7.0 and earlier generally do not, so a large part of the web now fails on those devices. Site owners cannot fix this from their end.
- Android 8 and 9. Chrome 139, released in August 2025, raised Chrome’s minimum requirement to Android 10. Devices on Android 8 or 9 are frozen on Chrome 138, and a frozen Chrome means a frozen Chrome Root Store that will never receive another new certificate authority.
Check your version under Settings, then About phone, then Android version. For context, Android 17 was released in June 2026. If you are on Android 7.0 or older and cannot upgrade the device, installing Firefox for Android is the practical workaround, because Firefox carries its own trust store and trusts ISRG Root X1 regardless of how old the system store is. That fixes browsing only. Native apps on the device will keep using the outdated system store.
5. Turn off VPN, DNS filtering, or ad-blocking apps
Desktop guides tell you to disable your antivirus. On Android that advice does not transfer, because Android antivirus apps do not intercept HTTPS traffic the way desktop security suites do. The apps that genuinely cause certificate warnings on a phone are the ones that sit in the network path:
- VPN apps, which route your traffic elsewhere and occasionally through a filtering proxy.
- Ad blockers and content filters that register themselves as a local VPN in order to inspect traffic.
- Private DNS settings pointing at a filtering resolver that returns a block page instead of the real site.
Look for a key icon in the status bar, which means a VPN is active. Turn the app off, reload the page, and turn it back on afterwards. To check Private DNS, open Settings, go to Network & internet, then Private DNS, and set it to Automatic while you test.
6. Look for certificates installed on the device
If the phone is managed by an employer, or if someone installed a certificate on it at some point, an extra certificate authority may be sitting in the user trust store and re-signing traffic. This is normal on a corporate device with a work profile, and worth investigating on a personal one.
On Android 14 and later, open Settings, go to Security & privacy, then More security settings, then Encryption & credentials, and open User credentials or Trusted credentials. On earlier versions the same screens sit under Settings, then Security, then Encryption & credentials. Samsung phones file them elsewhere again: Settings, then Biometrics and security, then Other security settings. Anything under the User tab was added to the device rather than shipped with it. If you do not recognize an entry and the device is not managed by your employer, removing it is reasonable.
Two things are worth knowing before you touch this screen. First, since Android 7, apps ignore user-installed certificate authorities by default and trust only the system store, so installing a certificate here often has no effect on the app you were trying to fix. Chrome is an exception and does honour user-installed authorities. Second, and more important: never install a root certificate that a website, a download page, or a support chat asks you to install in order to clear a warning. A certificate authority you add is trusted for the entire web, not just for that one site, and adding an untrustworthy one lets whoever controls it read traffic you believe is encrypted. A legitimate public website never needs you to install anything.
7. Delete browsing data
Clearing the cache rarely resolves a certificate error, because certificate validation happens live on every connection rather than being served from cache. It is worth trying in one situation: the site owner has just installed a new certificate and your browser is still holding on to a cached error page or a stale HSTS state. Try it last, not first.
- Open Chrome and tap the three-dot menu in the top right corner.
- Tap Delete browsing data. In older Chrome versions this is labelled Clear browsing data and sits under Settings, then Privacy and security.
- The default time range is Last 15 minutes. Tap More options to reach the full list, then set the time range to All time.
- Select Cookies and site data and Cached images and files. You do not need to clear your browsing history for this.
- Tap Delete data, then reload the site.
If a link opened inside another app rather than in Chrome, clear that app’s storage instead, since WebView keeps its own cache. Open Settings, go to Apps, choose the app, then Storage & cache, and tap Clear cache.
8. Report it to the site owner
If other sites load normally and only one keeps failing, you have reached the end of what a visitor can do. The certificate is served by that site, and only its owner can replace or reconfigure it. Sending them the exact error code you saw, along with the fact that it happens on Android, is genuinely useful information, because Android-only certificate failures are easy for an owner to miss when the site looks fine in desktop Chrome.
In the meantime, do not tap through the warning to reach the site anyway. The warning means the connection cannot be verified, so anything you type into the page, including passwords and payment details, may not be protected.
How to fix the SSL connection error on Android as a website owner
If your visitors report certificate warnings on Android while the site looks correct in your desktop browser, assume the chain first. Desktop browsers hide exactly the defect that Android exposes.
1. Serve the complete certificate chain
Your server must send its own certificate and every intermediate certificate above it, stopping short of the root. Certificate authorities supply these as a CA bundle alongside your certificate, and skipping the bundle during installation is the single most common cause of Android-only errors.
Run a scan with our free SSL Checker and look at the chain it reports. If it flags a missing or incomplete chain, that is your answer, even if the site loads without complaint on your own machine. You can confirm the same thing from a terminal:
openssl s_client -connect example.com:443 -servername example.com -showcertsRead the certificate chain the server returns. It should list your certificate first, then each intermediate. If only one certificate comes back and the output ends in a verify error about a local issuer, the intermediate is missing. Reinstall the certificate together with the CA bundle your certificate authority provided, then restart the web server and scan again.
2. Check the expiry date and renew on time
An expired certificate produces a warning on every device and every browser at once, so if Android is the only platform complaining, expiry is not your cause. It is still worth confirming before you go further, because it takes seconds and it rules out the simplest explanation.
3. Confirm the certificate covers the hostname visitors use
A certificate issued for example.com does not automatically cover www.example.com, and neither covers a subdomain such as shop.example.com unless it is listed in the certificate or the certificate is a wildcard. Check the Subject Alternative Name list in your certificate and make sure every hostname visitors actually reach is present, including the one your redirects send them to.
4. Know what you can and cannot fix for very old Android devices
If your analytics show visitors on Android 7.0 and earlier, some of them will see certificate errors on a correctly configured site. Since the DST Root CA X3 cross-signature expired in September 2024, there is no chain a Let’s Encrypt subscriber can serve that those devices will trust. Switching to a certificate authority whose root has been in the Android trust store for longer is the only server-side option, and how much it is worth depends entirely on how much of your traffic those devices represent.
5. Test on Android, not only on desktop
Because desktop browsers repair broken chains silently, both by fetching the missing intermediate and by reusing one they already hold, desktop testing cannot reliably detect the defect that breaks Android. After any certificate change, load the site on a real Android phone, then open it a second time from inside an app whose built-in browser is WebView, such as Facebook or Instagram, so the request is validated against the system trust store rather than Chrome’s. Those two checks, plus an SSL Checker scan, catch nearly every Android-specific certificate problem before your visitors do.
Frequently Asked Questions
Almost always because the server is not sending its intermediate certificate. Desktop browsers hide that in two ways: they fetch the missing piece automatically using the AIA field in the certificate, and they usually already hold it from earlier browsing. Android has neither cushion. Native apps do not fetch missing intermediates at all, and the attempt Chrome for Android makes works only when the certificate carries a usable issuer URL and the fetch completes in time. The site is genuinely misconfigured, and the phone is simply the first thing to notice.
No, and it is not worth attempting. Certificate warnings are produced by the certificate the website serves, by your device’s clock, or by something sitting in your network path, and a factory reset erases every app, photo, and file on the phone without addressing any of them. The one situation where wiping the device would change anything is a phone carrying an unwanted certificate authority or a rogue filtering app, and both can be dealt with individually: remove the authority from the credentials screen in Settings, and uninstall the app. Neither needs a reset.
It is the message Android shows when an app or WebView cannot build a chain from a site’s certificate up to a root it trusts. It is the same underlying failure as NET::ERR_CERT_AUTHORITY_INVALID in Chrome, worded differently because it comes from Android’s own certificate validation rather than from the browser. A missing intermediate certificate on the server is the usual cause, followed by a self-signed certificate.
Because they consult different trust stores. Chrome for Android uses the Chrome Root Store, which updates with Chrome, while many in-app browsers are built on WebView and use the Android system trust store, which updates with the operating system. A certificate authority present in one and absent or outdated in the other produces exactly this split. It is a strong indication that the fault is in the certificate chain rather than in your phone.
No. A root certificate you install is trusted for every site you visit, not only the one showing the warning, so an untrustworthy one can be used to decrypt traffic you believe is private. No legitimate public website requires you to install anything to browse it. The only normal reason to have an extra certificate authority on a phone is a work profile managed by your employer, and in that case your IT department installs it, not a web page.
Not on any page where you enter information. The warning means your device could not verify who it is talking to, so the connection may be intercepted. Proceeding to read a public article on a site whose certificate expired yesterday carries little risk, but signing in, entering payment details, or submitting personal data behind an unverified certificate is exactly the situation the warning exists to prevent.
A wrong device clock or an unfinished captive portal login, in that order. Both break every certificate check at once, which is why the failure looks so dramatic. Set the date and time to automatic, and if you are on public Wi-Fi, load any plain HTTP page to bring up the network’s sign-in screen. If the clock is right and the network is fine, check whether your Android version is old enough to have an outdated trust store.
The general causes are the same, but the trust model is not. iOS does not use the Chrome Root Store even in Chrome, because Apple requires every browser’s certificate validation to go through the system. That means iPhones have one trust store rather than two, so on iOS the “fails in one app, works in another” split never points at a trust-store difference the way it does on Android. It can still happen there for a different reason, namely an app that pins a specific certificate, which is covered in our separate guide on the SSL connection error on iPhone.
For more SSL error troubleshooting, check our detailed tutorials about fixing different SSL errors, including the general “Your connection is not private” warning and the expired intermediate certificate error.
Save 10% on SSL Certificates when ordering from SSL Dragon today!
Fast issuance, strong encryption, 99.99% browser trust, dedicated support, and 25-day money-back guarantee. Coupon code: SAVE10
