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.
Why Older Devices Show SSL Certificate Errors
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 🔗
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 Apache, NGINX, or other non-Windows platforms use a different configuration method.
Why Windows Internet Information Services (IIS) Chooses the Wrong Chain
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 re-exporting and re-binding the SSL Certificate so that Internet Information Services (IIS) immediately presents the corrected chain. Learn About Intermediate Certificates and Downloads 🔗
Before You Begin
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.
Step 1 - Download the Correct Cross-Chain Intermediate SSL Certificate
The correct cross-chain Intermediate SSL Certificate 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.
For 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) 🔗
For 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 - Import the Cross-Chain Intermediate SSL Certificate
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 - Move the Self-Signed Root to Untrusted Certificates
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.
Step 4 - Export the SSL Certificate as a Personal Information Exchange (PFX) File
The SSL Certificate must now be re-exported as a Personal Information Exchange (PFX) file. When Internet Information Services (IIS) imports this file, it rebuilds the chain from the current store configuration and will use the cross-chain path going forward.
In the Local Machine store, expand Personal and select Certificates. Locate the SSL Certificate for the domain, which is typically named after the domain it was issued for. Right-click the SSL Certificate, 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 and click Next. 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).
Step 5 - Import and Bind the Updated SSL Certificate in Internet Information Services (IIS)
Open Internet Information Services (IIS) Manager. In the Connections panel on the left, click on the server name at the top of the tree. In the center pane, double-click Server Certificates. In the Actions pane on the right, click Import.
Browse to the Personal Information Exchange (PFX) file created in Step 4, enter the password set during export, and click OK. The SSL Certificate will appear in the Server Certificates list with the corrected chain applied.
To update the site binding, expand Sites in the Connections panel and select the relevant website. Click Bindings in the Actions pane. Select the existing https binding and click Edit. In the SSL Certificate dropdown, select the SSL Certificate just imported and click OK to save the binding.
Note : The old SSL Certificate and the newly imported one may appear in the dropdown with similar names. If uncertain, check the expiry date or friendly name to confirm the correct selection before clicking OK.
Step 6 - Restart Internet Information Services (IIS) and Verify
Restart Internet Information Services (IIS) to apply the updated binding immediately. Open Command Prompt as Administrator and run the following command :
iisreset
Once the restart completes, 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 Steps 4 through 6. Trustico® provides online tools that can verify SSL Certificate chain configuration without requiring OpenSSL to be installed locally. Explore SSL Conversion and Tools 🔗
Maintaining the Fix After Windows Updates and Reissuances
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 OpenSSL verification command after every Windows update cycle and after each SSL Certificate reissuance 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 🔗
