If your SSL Certificate works correctly in modern browsers but visitors on older Android devices, legacy operating systems, or certain Internet of Things (IoT) systems are seeing security warnings or connection errors, the cause is almost always the SSL Certificate chain your server is sending.
This is not a fault with the SSL Certificate itself. It is a configuration issue specific to how Windows Internet Information Services (IIS) selects which chain to present, and it can be resolved by following the steps on this page.
Older Device Trust Failures
Every SSL Certificate is signed by an Intermediate Certificate Authority (CA), which is in turn signed by a trusted root Certificate Authority (CA). The complete sequence from the SSL Certificate on your server up to the root is called the chain of trust.
A connecting device validates your SSL Certificate by checking that every link in this chain is trusted. If the device does not recognize the root at the top of the chain, it will display a security warning or refuse to connect entirely.
Newer devices keep their trust stores updated and recognize the latest root Certificate Authorities (CA). Older devices do not receive these updates and only trust the root Certificate Authorities (CA) that were present when the device was manufactured or last updated.
When a server sends a chain that terminates at a newer root that an older device has never seen, that device will report an SSL Certificate error, even though the SSL Certificate is fully valid on modern systems.
The Certificate Authority (CA) that Trustico® works with to provide SSL Certificates maintains a cross-signed version of its root specifically to address this problem. The cross-signed chain routes through USERTrust RSA Certification Authority or USERTrust Elliptic Curve Cryptography (ECC) Certification Authority, both of which have been embedded in device trust stores since the year 2000. Using this cross-signed chain ensures that legacy Android devices, older desktop browsers, and many embedded systems are able to connect without any warning. Learn About Browser Ubiquity and Why It Matters for SSL Certificates 🔗
Whenever you download an issued SSL Certificate from Trustico®, the correct intermediate SSL Certificates for the widest device compatibility are provided with it. The task on this page is not to obtain a different SSL Certificate, but to make sure Windows presents that compatible chain rather than the shorter one.
Note : This page covers the fix for Windows servers running Internet Information Services (IIS). Windows has a specific chain-building behavior that actively prevents the cross-signed chain from being used unless the steps below are applied. Servers running other web server software on non-Windows platforms use a different configuration method.
The rest of this page sets out why Windows selects the wrong chain and the steps to correct it.
Windows Internet Information Services (IIS) Chain Selection
Windows Internet Information Services (IIS) automatically constructs the shortest available SSL Certificate chain when multiple valid paths exist to trusted root Certificate Authorities (CA).
On a typical Windows server, both the newer self-signed root and the older cross-signed root may be present in the Windows trust store at the same time. Windows selects the shorter path through the newer self-signed root because it is more efficient for the server.
This efficiency preference is appropriate for client machines but is the wrong behavior for a server. A server should send the chain that the widest possible range of connecting clients can validate, not the chain that is fastest for the server to assemble.
The result is that visitors on older devices receive SSL Certificate errors that never appear in standard browser testing, because testing tools typically use modern systems that already trust the newer root.
The fix requires three actions in sequence : importing the correct cross-chain Intermediate SSL Certificate into the correct store, blocking Windows from selecting the self-signed root by moving it to the Untrusted Certificates list, and refreshing the cached chain so that Internet Information Services (IIS) presents the corrected chain. Learn About Intermediate Certificates and Downloads 🔗
Preparation Before Starting
All operations on this page must be performed in the Local Machine store, not the Current User store. Internet Information Services (IIS) runs under a system account and reads only from the Local Machine store. Any changes made to the Current User store will not affect the chain sent by Internet Information Services (IIS).
To open the Local Machine store, press Win + R, type certlm.msc into the Run dialog and press Enter. Accept the administrator confirmation prompt if it appears.
Do not use certmgr.msc at any point during this process. That tool opens the Current User store and changes made there will have no effect on Internet Information Services (IIS).
Important : Changes to the Windows trust store affect every Transport Layer Security (TLS) service running on the server, not only Internet Information Services (IIS). Database connections, Application Programming Interface (API) integrations, and internal applications that use Transport Layer Security (TLS) should all be tested after completing these steps.
With the Local Machine store open, you are ready to begin.
Step 1 : Downloading Your Cross-Chain Intermediate
In many cases the correct cross-chain Intermediate SSL Certificate is already on the server. Trustico® supplies it with every issued SSL Certificate, so it is often installed alongside the self-signed version during the original installation.
Before downloading, open the Intermediate Certification Authorities store and look for a Root R46 (or Root E46) entry whose Issued By column shows USERTrust RSA Certification Authority or USERTrust Elliptic Curve Cryptography (ECC) Certification Authority. If it is already present, there is no need to download or import it, and you can move directly to Step 3.
If it is not present, the correct cross-chain Intermediate SSL Certificate to download depends on whether the SSL Certificate on the server uses RSA or Elliptic Curve Cryptography (ECC) encryption.
If the server hosts both types simultaneously, both files must be downloaded and the steps below must be completed separately for each. Resolving one chain does not affect the other.
RSA SSL Certificates
Download the Sectigo Public Server Authentication Root R46 Intermediate SSL Certificate cross-signed by USERTrust RSA Certification Authority. This is a different file from the self-signed version that Windows may have already stored automatically during earlier SSL Certificate installations.
Download Sectigo Public Server Authentication Root R46 (Cross Chain - USERTrust RSA) 🔗
Elliptic Curve Cryptography (ECC) SSL Certificates
Download the Sectigo Public Server Authentication Root E46 Intermediate SSL Certificate cross-signed by USERTrust Elliptic Curve Cryptography (ECC) Certification Authority. Servers running both RSA and Elliptic Curve Cryptography (ECC) SSL Certificates must download both files and process each independently.
Download Sectigo Public Server Authentication Root E46 (Cross Chain - USERTrust ECC) 🔗
Step 2 : Importing Your Cross-Chain Intermediate
Open the Local Machine store using certlm.msc. In the left-hand panel, expand Intermediate Certification Authorities and select Certificates. Right-click on Certificates, choose All Tasks and then select Import to open the Import Wizard.
Click Next and then Browse. Navigate to the cross-chain Intermediate SSL Certificate file downloaded in Step 1 and select it. Confirm that the destination store shown in the wizard reads Intermediate Certification Authorities and click Finish.
The cross-chain Intermediate SSL Certificate will now appear in the Intermediate Certification Authorities store alongside any other Intermediate SSL Certificates already present on the server.
Step 3 : Blocking Your Self-Signed Root
The self-signed version of the Sectigo Public Server Authentication Root R46 (or Root E46 for Elliptic Curve Cryptography (ECC) SSL Certificates) must be moved to the Untrusted Certificates list.
Moving it creates an explicit block that prevents Windows from selecting the shorter chain, while keeping it present in the store in a safe, inactive state. Simply deleting it is insufficient, as Windows may restore it automatically during a future system update.
First, check whether the self-signed root is present in the Intermediate Certification Authorities store. Expand Intermediate Certification Authorities and select Certificates. Look for an entry named Sectigo Public Server Authentication Root R46 (or Root E46) where the Issued By column also shows the same name. A self-signed entry always has identical Issued To and Issued By values. If it is present, right-click it and select Cut.
Next, check the Trusted Root Certification Authorities store. Expand Trusted Root Certification Authorities and select Certificates. Locate the same self-signed root entry, right-click it and select Cut (or select it and press Ctrl + X).
To complete the move, expand Untrusted Certificates in the left-hand panel and select Certificates. Right-click on Certificates and select Paste. The self-signed root will now appear in the Untrusted Certificates store. Windows will treat this as an explicit block and will no longer use it when building the SSL Certificate chain.
Warning : Confirm that the entry being moved to Untrusted Certificates is the self-signed version, identifiable by its Issued To and Issued By values being identical. Do not move the cross-chain Intermediate SSL Certificate imported in Step 2. Moving the wrong entry will break the SSL Certificate chain entirely and cause connection failures on all devices.
With the self-signed root blocked, the final task is to make the change take effect.
Step 4 : Activating Your Corrected Chain
The stores are now correct, but Windows caches the chain it has already served inside the HTTP service, so the change does not take effect on its own. You need to force that cache to refresh, and there are two ways to do it below. Choose whichever suits you, as the result is identical.
One thing to avoid : a plain iisreset is not enough on its own, because it restarts the web worker services but not the underlying HTTP service that holds the cached chain. Use one of the two methods that follow instead.
Restarting HTTP Services
The simplest method is to restart the service that holds the cache, or to reboot the server. Either clears the cached chain and makes Windows rebuild it from the corrected stores. To restart the service without a full reboot, open Command Prompt as Administrator and run the command to stop the HTTP service :
net stop http /y
This stops the HTTP service along with every service that depends on it. Then run the command to start your websites again, which brings the HTTP service back with them :
net start w3svc
A server reboot achieves the same result if you would rather not run the commands.
Re-Exporting Your SSL Certificate
As an alternative to restarting anything, you can re-export the SSL Certificate and import it again, which also forces the chain to refresh. In the Local Machine store, expand Personal and select Certificates. Locate the SSL Certificate for the domain, right-click it, choose All Tasks and then select Export.
In the Export Wizard, select Yes, export the private key and click Next. Select the Personal Information Exchange (PFX) format and enable the option to include all certificates in the certification path if possible. Set a strong password when prompted, save the Personal Information Exchange (PFX) file to a secure location and click Finish.
Warning : The Personal Information Exchange (PFX) file contains the Private Key for the SSL Certificate. Keep it in a secure location and do not share it. If the file is lost and no backup of the Private Key exists, the SSL Certificate must be reissued using a new Certificate Signing Request (CSR).
Open Internet Information Services (IIS) Manager, click the server name in the Connections panel, and double-click Server Certificates. In the Actions pane, click Import, browse to the Personal Information Exchange (PFX) file, enter the password set during export, and click OK. Then expand Sites, select the website, click Bindings, select the existing https binding and click Edit, choose the SSL Certificate just imported and click OK to save the binding.
Step 5 : Verifying Your Served Chain
Verify the chain being served using the following command from any machine with OpenSSL installed, replacing yourdomain.com with the actual domain name :
openssl s_client -connect yourdomain.com:443 -showcerts
In the output, locate the issuer shown at the root of the chain. For RSA SSL Certificates, the issuer should read USERTrust RSA Certification Authority. For Elliptic Curve Cryptography (ECC) SSL Certificates, the issuer should read USERTrust ECC Certification Authority.
If the output still shows Sectigo Limited as the issuer, or if the root appears self-signed, the Untrusted Certificates configuration in Step 3 has not taken effect. Review Step 3 before repeating the activation in Step 4. Trustico® provides online tools that can verify SSL Certificate chain configuration without requiring OpenSSL to be installed locally. Explore SSL Conversion and Tools 🔗
Keeping Your Corrected Chain After Updates
Windows may automatically restore the self-signed Sectigo root to the Trusted Root Certification Authorities store following a Windows Update or system change. When this happens, the shorter chain becomes available again and Internet Information Services (IIS) will revert to selecting it, causing device errors to reappear.
Trustico® recommends running the verification command after every Windows update cycle and after each SSL Certificate reissue or replacement. This takes only a few seconds and confirms the cross-chain is still being served before any visitors are affected.
If the chain has reverted, repeat Step 3 onwards to restore the correct configuration.
For background on why Windows Internet Information Services (IIS) behaves this way and how the same issue affects other server environments and Certificate Authorities (CA), refer to the detailed technical overview. Learn About Windows Internet Information Services (IIS) SSL Certificate Chain Issues 🔗
Wildcard
Wildcard
Wildcard
