Cross-signed intermediate on Windows Server

AlphaSSL example: import the cross-cert r3r6cross2019.crt into Intermediate Certification Authorities and disable GlobalSign Root R6 in Trusted Root. Swap the cross-cert file to match the certificate you actually have.

1. Get the files

Grab the relevant cross-cert file from Cross-cert files you need above.

2. Open MMC for Computer Account

1. Press Win+R, type mmc, click OK. Confirm the UAC prompt.
2. In MMC: menu File → Add/Remove Snap-in... (or Ctrl+M).
3. In the left list, select Certificates → click Add >.
4. Select Computer account → Next. This is the choice that matters, not "My user account".
5. Select Local computer → Finish → OK.

3. Import the cross-cert into Intermediate Certification Authorities

1. In the left pane, expand Certificates (Local Computer) → Intermediate Certification Authorities → click the Certificates sub-folder.
2. Right-click the Certificates folder → All Tasks → Import...
3. The Certificate Import Wizard starts. Click Next.
4. Click Browse..., select the cross-cert file. Switch the file-type dropdown to All Files (*.*) if the file is not visible. Select → Open → Next.
5. Confirm the store is Intermediate Certification Authorities → Next → Finish → OK.
6. Press F5. The cross-cert file is now in the list. Double-click to verify Subject (what the certificate says about itself) and Issuer (who signed it).
7. If you need to cover several layers (e.g. also r6r46cross2019.crt), repeat steps 2-6 for each file.

4. Disable the new CA root in Trusted Root

Otherwise Schannel finds the new root in Trusted Root and builds the short chain, leaving your cross-cert sitting unused in the Intermediate store.

1. In the left pane, navigate to Trusted Root Certification Authorities → Certificates.
2. Find the new CA root that matches the new chain. For the AlphaSSL R6 hierarchy: GlobalSign Root R6. For the R46 era after 27 July 2026: GlobalSign Root R46.
3. First verify by double-clicking the Details tab that Subject = Issuer (it is a root, not a cross-cert).
4. Right-click the certificate → Properties → General tab.
5. Select Disable all purposes for this certificate → OK. Or, more precisely: select Enable only the following purposes and clear the checkbox next to Server Authentication alone.
6. If the server also needs to send the chain all the way down to R3 (for clients that only have R3 trusted), repeat the same procedure for GlobalSign Root R6. Schannel then falls back to the long chain via both cross-certs.

5. Restart Windows Server

After changes to Trusted Root and Intermediate stores, a full Windows restart is the only reliable way to flush the Schannel and HTTP.SYS cache for cert chains. iisreset alone does not touch the chain cache in lsass, and net stop http does not touch the Schannel cache either. Always plan a reboot window when disabling or swapping roots.

6. Verify from outside

After the reboot, test live from the internet with the FairSSL SSL Scanner or SSL Labs. The top root in the delivered chain should now be the old one (R3 or R6, depending on your choice), not the new R46. If the chain still ends at R46, the deactivation has not taken effect, or another R46 root copy is still "enabled" in Trusted Root.

The only reliable verification is to scan the server from outside and see the chain the client actually receives. Local MMC only shows what Windows thinks the chain should be, not what HTTP.SYS sends after a cache flush.

• Internet-facing server: use the FairSSL SSL Scanner. It shows the full chain the server delivers and simulates several client populations.
• Internal server (no internet access): use testssl.sh from another machine on the network. Command: testssl.sh --chain server.internal.local:443 shows the entire chain the server sends.

A broken or incomplete certificate bundle produces random results across clients. Some clients fetch the missing intermediate themselves via the AIA extension in the server cert. Others keep batches of known intermediates cached in the background and get through anyway. It looks like "it works for me", but the next user with the same browser version and a cold cache hits the failure.

In practice, mobile phones, Safari, and Firefox are usually the first to fail when the server forgets the intermediate. Windows and Chrome can often perform an AIA lookup and rescue the situation, which masks the bug. If the page works in Edge on a Windows machine, the assumption is that it works for everyone, and the problem only surfaces when a customer calls in from an iPhone.

Scott Helme's experiment shows this unpredictability exactly. He configured a server to send only the leaf certificate (no intermediate) and disabled the relevant root locally. First attempt: both Chrome and Firefox failed as expected. A later attempt with the same server setup: Firefox worked, Windows still failed. Firefox had in the meantime fetched and cached the missing intermediate via its "Intermediate CA Preloading" feature, which pulls batches of known intermediates daily. Read his walkthrough here: Cross-signing & alternate trust paths: how they work.

Never rely on the client to rescue an incomplete chain. The server has to send the complete bundle with all intermediates, and if you need to cover older clients via a cross-cert chain, the server has to actively send that chain, not assume the clients will find it themselves.