What should I do if my free SSL certificate is flagged as untrusted on an older phone?

　　From a user's perspective, upgrading a website from "insecure" HTTP to encrypted HTTPS should be a good thing, safeguarding visitor privacy and security. However, many website owners find that after deploying free SSL certificates, access is normal on newer mobile phones and computers, but older Android phones or Windows XP machines display a glaring "certificate untrusted" warning, preventing users from accessing the website. This problem is not uncommon, its roots deeply embedded in the technological history of PKI (Public Key Infrastructure). For website owners, the core urgent need is how to restore normal access for their existing users without having to convince all of them to upgrade their devices.

　　To understand this problem, it's essential to first understand the "trust chain" mechanism of SSL/TLS certificates. Browsers or operating systems have a built-in "trusted root certificate list." When a website presents its SSL certificate, it includes a chain from the root certificates through intermediate certificates, and finally to the website certificate. The client traces up the chain; if it eventually finds a built-in root certificate, trust is established, and the page opens securely; if not, the trust chain is broken, and the browser displays the "certificate untrusted" warning. There are generally two clear paths to solving this problem: one is to modify the server and adjust the certificate configuration to be compatible with older devices; the other is to guide the client, allowing visitors to resolve the device trust issue themselves. The latter can only be used as a supplement, while the former is the proactive and permanent solution that website administrators can take. Below are specific practical solutions for various scenarios. You can choose based on your site's specific situation, weighing cost, security, and user experience.

　　Solution 1: Server-side configuration using an "expired trust bridge" (optimal first choice)

　　This is a crucial "black technology" that you, as a website owner, should master, directly addressing the core of emergency needs. The core idea is to "actively restore" the cross-signed certificate chain on the server—a chain that is no longer officially recommended but is still compatible with older devices.

　　Current ACME automation tools (such as Certbot and acme.sh) install the latest trust chain by default after issuing certificates. To have the tool actively recover the "expired" chain, its advanced parameters are needed. Specifying the certificate chain using the `--preferred-chain` parameter achieves the following effect: the ACME client will prioritize matching certificate chains containing the specified issuer information. Even if the root certificate (DST Root CA X3) on this chain has expired, as long as it was once trusted, trust can be re-established on some older devices.

　　For users who need to maintain certificates long-term, this configuration can be set as the default using the command `acme.sh --set-default-chain --preferred-chain "DST Root CA X3"`, avoiding the need to manually specify it every time a certificate is issued. However, it should be noted that the effectiveness of this compatibility solution depends on the specific behavior logic of older systems, as expired root certificates will eventually be completely forgotten and may ultimately become invalid on some very old devices.

　　Nginx Configuration: After issuance, ensure the Nginx configuration correctly loads the complete certificate file `fullchain.cer` (containing the main certificate, intermediate certificates, and cross-signature root certificate). Simultaneously, ensure basic SSL protocol layer compatibility. However, caution is advised; manually enabling TLSv1 and TLSv1.1 protocols, as well as some older encryption suites, will inevitably lower the security rating of modern browsers. It is recommended to use this configuration only if you have a clear understanding that your user base has a large number of older devices, and consider restricting the use of lower-version protocols through mechanisms such as access whitelists.

　　Solution Two: Client-side Installation of ISRG Root X1 Root Certificate (Targeted Solution)

　　If the number of older devices that need to access your website is very small, manually "upgrading" the devices is the most direct solution. The fundamental fix is ​​to download the "ISRG Root X1" root certificate from the official trust chain page and manually install it into the device's "trusted credentials" store. After the certificate is installed, all apps and browsers that rely on the system trust library (including Chrome and WebView components) will be able to access the site normally.

　　The general procedure is as follows: On your Android device, access the Let's Encrypt official website through a browser to download the isrgrootx1.pem certificate file. Then, import and name it in the system settings under "Security" -> "Install Certificate from Storage". However, this method has certain limitations. Since Android 7, the operating system has changed its user certificate handling strategy: manually installed certificates may not be trusted by all apps by default, especially those applications that implement their own SSL/TLS verification logic.

　　Option Three: Replace with a browser that comes with its own root certificate

　　Firefox has its own built-in trust library and does not rely entirely on the operating system's root certificate list. This means that even if the Android system does not recognize ISRG Root X1, Firefox is likely to trust it. Therefore, if you cannot modify the system certificate, replacing the default browser on your older phone with the latest version of the Firefox app can bypass the system's certificate trust vulnerability and allow you to access websites using Let's Encrypt certificates normally.

　　Option Four: Replace with a More Compatible Commercial SSL Certificate

　　If you absolutely cannot find a solution using any of the above methods (cannot modify server configuration, users cannot or are unwilling to install the certificate themselves, and cannot ask existing users to switch browsers), then the most straightforward and thorough solution is to replace the certificate—with a commercial, paid certificate.

　　This can be understood as follows: Free certificates use root certificates (ISRG Root X1) which were developed later and have low penetration on older devices, thus breaking the trust chain. Commercial, paid certificates (such as DigiCert, Sectigo, etc.) use root certificates that were pre-embedded in almost all operating systems in the late 1990s or early 2000s—these are "veteran" root certificates. These root certificates are already trusted by all versions, including Android 2.x. Therefore, regardless of the age of the device, the trust chain of commercial certificates is inherently complete.

　　It should be noted that commercial certificates are not superior to free certificates in all aspects. The security at the HTTPS data encryption layer is exactly the same (both use the RSA 2048-bit/SHA-256 standard). The difference lies in the added value aspects such as verification depth, trust breadth, enterprise assurance, and customer support. If your website belongs to a high-trust scenario such as a government agency, enterprise portal, or e-commerce platform, choosing a paid OV/EV certificate will also bring higher brand credibility.

　　Option Five: Check the Completeness of the Certificate Chain Configuration

　　Sometimes, the problem is not with the root certificate, but with an incomplete certificate chain configuration on the server side. Some website owners may only upload the main certificate during deployment, forgetting to upload intermediate certificates. This is more common in self-signed certificates or manual deployment. When an intermediate certificate is missing, newer browsers can automatically complete the certificate chain through AI or caching, but older devices do not have this capability, and will immediately report "Unknown issuer" or "Incomplete certificate chain" errors.

　　The most intuitive troubleshooting method is to use SSL Labs' free online testing tool, which will show the complete certificate chain returned by the website in detail. If any missing information is found, you should correctly configure the certificate file, including the entire certificate chain, according to your web server software (Nginx, Apache, IIS, etc.) and the documentation provided by your service provider.

　　Solution Six: Check the accuracy of the device's local time

　　The security function of an SSL/TLS certificate relies heavily on the "effective date" and "expiration date" specified on the certificate. When the device's local time deviates significantly from real-world time (e.g., a dead battery or a CMOS battery failure causing the year to reset to zero), the system may misjudge whether the current time is within the certificate's validity period, resulting in an error message such as "certificate untrusted" or "certificate expired."

　　Troubleshooting approach: First, verify that the system time and timezone on the older device are consistent with the current actual time. After calibration, try accessing the website again. Although this is an easily overlooked detail, for troubleshooting older devices, it may be the simplest operation that requires no configuration changes and yields immediate results.

　　Option Seven: Migrate Business to Isolate Compatibility Impact (Engineering Solution)

　　When all the above solutions are impractical, the last thing you can do is implement "physical isolation" at the engineering level:

　　Targeted Traffic Redirection: Identify access requests from older devices based on visitor User-Agent or other characteristics, and then redirect them via 301 to another older domain or subdomain that still uses a compatible certificate (specifically to extend the life of older devices). For example, allow older devices to access secure-old.example.com, while newer devices continue to access www.example.com. Configure different SSL certificate schemes for the two subdomains.

　　Site Degradation: For older devices where compatibility issues cannot be resolved, maintain a clear HTTP backup entry point at the site level, while prominently displaying a message to users: "For security reasons, your device may not be able to access encrypted pages properly. We recommend upgrading your system or replacing your device."

　　While this engineering solution is more complex, it may be a respectable last-mile measure to maintain compatibility for enterprise-level products or businesses with a large number of loyal users that cannot be easily abandoned.

　　The issue of free SSL certificates being untrusted on older mobile phones is essentially an inevitable growing pain of the digital trust system's upgrade. Old root certificates have reached the end of their lifespan, and new root certificates are gradually being rolled out across various platforms, while the bridge built through "cross-signature" has been closed. For website owners, the real risk lies not in the existence of the problem, but in its invisibility—the certificate works correctly, users are blocked, and you have no way of knowing.

　　Therefore, it is recommended to periodically check several worst-case access scenarios (such as simulating access from an Android 6.0 device) to gain a true understanding of compatibility. Based on the characteristics of your website's audience, one of the seven solutions provided in this article should help you find a balance—whether to continue compatibility by using the "expired trust bridge," solve the terminal problem by changing browsers, or completely switch to a commercial certificate to save effort depends on how much maintenance cost you are willing to invest for that last 5% of users.