Sectigo cross-sign on Windows Server

Sectigo moved issuance to R46 and E46 by validation level: EV on 15 April 2025, OV on 15 May 2025 and DV on 2 June 2025. Certificates issued before the date that applies to your product still chain up to USERTrust RSA, and there is nothing for you to do.

If the server sends the short chain to R46, these clients fail:

• iOS and iPadOS before 17.4 and macOS before 14.4. The root entered the Apple list in March 2024, so an iPhone X that cannot be updated further never receives it.
• Android 13 and older. The root reached AOSP with Android 15, and Android 14 through the Mainline update of Conscrypt.
• Java installations that never received the July 2025 update (8u461, 11.0.28, 17.0.16, 21.0.8).
• Windows machines without outbound internet access, which cannot fetch new roots from Windows Update.
• Embedded equipment, payment terminals, printers and industrial devices with a fixed trust store.

On Linux you simply add the cross-signed certificate to the chain file after the intermediate and reload the web server. The rest of this guide is about Windows, where Schannel builds the chain itself.

1. Open the machine certificate store

Run certlm.msc from a command line started as administrator. Alternatively: Win+R, mmc, File → Add/Remove Snap-in, choose Certificates, Computer account, Local computer. The machine store is what matters. Certificates in the user store take no part in the chain the server sends.

2. Import the issuing intermediate

1. Expand Intermediate Certification Authorities and click the Certificates subfolder.
2. Right-click → All Tasks → Import.
3. Select the R36 file. Switch the file type to All Files (*.*) if it does not show.
4. Confirm the store is Intermediate Certification Authorities → Finish.

3. Import the cross-sign certificate

Repeat step 2 with SectigoPublicServerAuthenticationRootR46_USERTrust.crt. The file belongs in Intermediate Certification Authorities, not in Trusted Root. It is technically an intermediate, because it was signed by someone else.

Then confirm that USERTrust RSA Certification Authority is present in Trusted Root Certification Authorities. Without the old root the server cannot build the long chain. The root ships with every maintained Windows version.

4. Quarantine the new Sectigo root

As long as Sectigo Public Server Authentication Root R46 is active in Trusted Root, Schannel builds the short chain and sends it. The cross-sign certificate then sits unused in the Intermediate store.

5. Re-export the PFX with its chain and rebind

Some services hold on to the chain that was in the PFX the certificate was imported from. Export the certificate again with the full chain and bind it to the service anew.

$pw = Read-Host -AsSecureString "PFX password"
Export-PfxCertificate -Cert Cert:\LocalMachine\My\<THUMBPRINT> `
  -FilePath C:\temp\server-with-chain.pfx -Password $pw -ChainOption BuildChain

-ChainOption BuildChain builds the chain from the machine stores, that is, after the root has been quarantined. Import the PFX again and bind it to the service that uses the certificate.

6. Restart

Chain data is cached in the process that built the chain, and in lsass and HTTP.SYS. A full Windows restart is the only way to clear all of it. Restarting the individual role does not reach the Schannel chain cache, so the service can answer with the old chain afterwards and look as though the change did not work. Plan a restart window.

Run the Sectigo IISFix-MoveSectigoSelfSignedRoots-Restore.reg, or remove the root from Untrusted Certificates and set it back to Enable all purposes in Trusted Root. Reboot the server. The cross-sign certificate can stay in the Intermediate store, because Schannel picks the short chain again as soon as the root is active.