Users with Windows servers may sometimes receive an "untrusted connection" error, when connecting to their websites, despite the fact that a PKCS#7 certificate with the full chain was imported on the server. The issue is more frequent on mobile devices, rather than on desktop machines, and occurs most commonly with Sectigo certificates.

When checking the certificate installation in an online checker, you will see that the certificate is returned with one intermediate.

To understand what causes the issue and how to overcome it, we will provide a better understanding on how Windows servers work with SSL certificates. First, remember that Windows servers do not return root certificates during SSL handshake and they build up certificate chains using the shortest way they can find.

Let us investigate this issue using the example of a Sectigo PositiveSSL certificate. PositiveSSL (and other Sectigo certificates) has two variants of CA chain. One ends up with SHA-1 root certificate and the other is completed by a newer SHA-2 root, which is not included in trusted stores of most mobile devices and might be missing in old versions of desktop browsers.

After certificate installation in Windows, your server may contain self-signed Sectigo Public Server Authentication Root R46 root certificate. Some older devices may not trust this self-signed certificate, and the workaround to this issue is to uninstall the self-signed Sectigo Public Server Authentication Root R46 root and install the cross-signed Sectigo Public Server Authentication Root R46xUSERTrust instead. This should complete the certificate chain properly on both new and old devices. However, Windows servers prefer using shorter certificate chains, making cross-signed certificate unusable. In order to mitigate this, the self-signed root Sectigo Public Server Authentication Root R46 certificate has to be disabled.

You can use one of the following methods to fix the issue with the server certificates:

• Disable the usage of the root certificate that prevents building a proper certificate chain
• Use the Sectigo .reg file to disallow self-signed roots on IIS/Windows servers

How to disable the usage of the root certificate that prevents building a proper certificate chain

Follow the steps below to disable the unnecessary root certificate:

1. Press Win+R, type in mmc and click OK to open Microsoft Management Console. Make sure that you are logged in as administrator.
   
   

   

2. Click on File and choose Add/Remove Snap-in option.
   
   

   

3. Select Certificates and click Add.
   
   

   

4. Choose Computer account, and then Next.
   
   

   

5. Select Local Computer radio button and click Finish.
   
   

   

6. Click OK to apply the changes.
   
   

   

   
   This will open a certificate manager, where you will be able to see the certificates added to the trusted stores (root and intermediate certificates that are integrated to a Windows server).
   
   
7. Expand the Trusted Root Certification Authorities store and click on the Certificates folder. You will see all root certificates imported to your server here. The certificate we are interested in will be also here.
   
   

   

8. Right-click on the required certificate and click on Properties.
9. Put the radio-button on Disable all purposes for this certificate, then click on Apply and OK. The changes should be implemented instantly.
   
   

   

This should resolve the issue with the certificate chain returned by the Windows server and remove all the warnings in browser.

How to use the Sectigo .reg file to move self-signed roots to Disallowed on IIS/Windows servers.

Another workaround is to ensure maximum compatibility (i.e., your certificate works on modern and legacy clients), it's often better to force use of the cross-signed chain and avoid the self-signed root. One way to do this is to tell Windows that the self-signed Sectigo roots are untrusted/disallowed. 

The .reg file provided by Sectigo automates exactly that. It moves the self-signed R46/E46 roots into the Disallowed store in the Windows certificate registry, preventing Windows/IIS from ending the chain at those roots, so the cross-signed chain will be selected instead.

Steps for using the .reg file

• Download the .reg file “IISFix-MoveSectigoSelfSignedRoots-Disallowed.reg”.
• Run the .reg file on your Windows Server with administrator privileges.

• Restart/reload the whole server (not just IIS) so that Windows reloads its certificate trust/chain logic.

Sectigo also provides a “IISFix-MoveSectigoSelfSignedRoots-Restore.reg” .reg file, which reverts the change.

You can download the necessary .reg files from Sectigo website directly as well.

Optional:

If the file is downloaded with .txt extension and UTF-8 encoding instead of .reg, it is required to perform the following steps:

Option 1:

Simply rename the file and remove the .txt extension at the end, replacing it with .reg (e.g., IISFix-MoveSectigoSelfSignedRoots-Disallowed.reg.txt > IISFix-MoveSectigoSelfSignedRoots-Disallowed.reg)

Option 2:

• Open the file with a simple text editor, like Notepad:

  

• Save the file using “Save as” with the following options:
  • Save as type: All files
  • Encoding: ANSI

In some cases, you may also need to change the file name (for example, deleting and typing a symbol again).