Korssignerat mellanliggande certifikat på Windows Server

AlphaSSL-exempel: importera det korssignerade certifikatet r3r6cross2019.crt i Intermediate Certification Authorities och inaktivera GlobalSign Root R6 i Trusted Root. Byt till den fil som hör till ditt certifikat.

1. Hämta filerna

Hämta rätt fil från Korssignerade certifikat du behöver ovan.

2. Öppna MMC för Computer Account

1. Tryck Win+R, skriv mmc och klicka på OK. Bekräfta frågan från UAC.
2. I MMC: menyn File → Add/Remove Snap-in... (eller Ctrl+M).
3. Välj Certificates i den vänstra listan → klicka på Add >.
4. Välj Computer account → Next. Välj just detta, inte "My user account".
5. Välj Local computer → Finish → OK.

3. Importera det korssignerade certifikatet till Intermediate Certification Authorities

1. I den vänstra rutan expanderar du Certificates (Local Computer) → Intermediate Certification Authorities → klicka på undermappen Certificates.
2. Högerklicka på mappen Certificates → All Tasks → Import...
3. Certificate Import Wizard startar. Klicka på Next.
4. Klicka på Browse... och välj filen. Ändra filtypen i listrutan till All Files (*.*) om filen inte visas. Välj filen → Open → Next.
5. Bekräfta att lagret är Intermediate Certification Authorities → Next → Finish → OK.
6. Tryck F5. Det korssignerade certifikatet finns nu i listan. Dubbelklicka på det och kontrollera Subject (vem certifikatet är utfärdat till) och Issuer (vem som har signerat det).
7. Behöver du täcka flera nivåer (t.ex. även r6r46cross2019.crt), upprepar du steg 2-6 för varje fil.

4. Inaktivera den nya CA-roten i Trusted Root

Annars hittar Schannel den nya roten i Trusted Root och bygger den korta kedjan, och ditt korssignerade certifikat ligger oanvänt i Intermediate-lagret.

1. Gå i den vänstra rutan till Trusted Root Certification Authorities → Certificates.
2. Hitta den nya CA-roten som motsvarar den nya kedjan. För AlphaSSL R6-hierarkin: GlobalSign Root R6. För R46-eran efter 27 juli 2026: GlobalSign Root R46.
3. Dubbelklicka först på certifikatet och kontrollera på fliken Details att Subject = Issuer (det är en rot, inte ett korssignerat certifikat).
4. Högerklicka på certifikatet → Properties → fliken General.
5. Välj Disable all purposes for this certificate → OK. Mer precist: välj Enable only the following purposes och avmarkera bara Server Authentication.
6. Ska servern även skicka kedjan hela vägen ner till R3 (för klienter som bara har R3 som betrodd rot), upprepar du samma procedur för GlobalSign Root R6. Schannel faller då tillbaka på den långa kedjan via båda de korssignerade certifikaten.

4b. Disallowed-lagret är den robusta metoden

Inaktivering via Disable all purposes fungerar, men Microsoft varnar själv för att inställningen kan rullas tillbaka. I KB 2831004 står det: "if the Turn off Automatic Root Certificates Update Group Policy setting is disabled or not configured on the server, the certificate ... you don't want to use may be enabled or installed when the next chain building occurs."

Windows hämtar rotcertifikat från Windows Update när kedjan byggs. Raderar du roten kommer den tillbaka. Stänger du av den automatiska rotuppdateringen på hela servern förlorar servern också de rötter den behöver som TLS-klient. Den robusta metoden är därför att flytta roten till Disallowed-lagret:

1. Högerklicka på Untrusted Certificates i den vänstra rutan → Certificates.
2. All Tasks → Import och välj rotfilen för den nya roten.
3. Roten ligger nu i Disallowed-lagret, där den automatiska rotuppdateringen inte kan sätta tillbaka den.

Sectigo publicerar färdiga reg-filer för sina egna rötter, IISFix-MoveSectigoSelfSignedRoots-Disallowed.reg och IISFix-MoveSectigoSelfSignedRoots-Restore.reg. För GlobalSign och DigiCert gör du det manuellt enligt ovan.

5. Starta om Windows Server

Efter ändringar i Trusted Root och Intermediate-lagren är en fullständig omstart av Windows det enda pålitliga sättet att tömma Schannel- och HTTP.SYS-cachen för certifikatkedjor. iisreset ensamt når inte kedjecachen i lsass, och net stop http når inte heller Schannel-cachen. Planera därför alltid in en omstart när ni inaktiverar eller byter rötter.

6. Verifiera utifrån

Testa efter omstarten från internet med FairSSL SSL Scanner eller SSL Labs. Den översta roten i den levererade kedjan ska nu vara den gamla (R3 eller R6 beroende på ditt val), inte den nya R46. Slutar kedjan fortfarande på R46 har inaktiveringen inte trätt i kraft, eller så ligger en annan kopia av R46-roten fortfarande aktiverad i Trusted Root.

Den enda pålitliga verifieringen är att skanna servern utifrån och se den kedja klienten faktiskt tar emot. MMC på servern visar bara hur Windows anser att kedjan borde se ut, inte vad HTTP.SYS skickar efter att cachen har tömts.

• Internetexponerad server: använd FairSSL SSL Scanner. Den visar hela kedjan servern levererar och simulerar olika typer av klienter.
• Intern server (utan åtkomst från internet): använd testssl.sh från en annan maskin i nätverket. Kommando: testssl.sh --chain server.intern.se:443 visar hela kedjan servern skickar.

En ofullständig kedja ger olika resultat i olika klienter. Vissa klienter hämtar själva det saknade mellanliggande certifikatet via AIA-fältet i servercertifikatet. Andra har en lokal samling kända mellanliggande certifikat som uppdateras i bakgrunden och lyckas ändå. Det ser ut som att "det fungerar för mig", men nästa användare med samma webbläsarversion och tom cache får felet.

I praktiken är det ofta mobiltelefoner, Safari och Firefox som misslyckas först när servern inte skickar med det mellanliggande certifikatet. Windows och Chrome kan ofta göra ett AIA-uppslag och rädda situationen, vilket döljer felet. Fungerar sidan i Edge på en Windows-maskin antar man att den fungerar för alla, och upptäcker problemet först när en kund ringer från en iPhone.

Scott Helmes experiment visar precis denna oförutsägbarhet. Han konfigurerade en server att bara skicka slutcertifikatet, utan mellanliggande certifikat, och den gamla roten var inte betrodd i klienten. I första försöket misslyckades både Chrome och Firefox, som väntat. Sedan lät han servern skicka det ISRG-signerade mellanliggande certifikatet en gång, och då lyckades båda. När servern åter bara skickade slutcertifikatet fungerade Firefox ändå, medan Windows misslyckades: Firefox hade sparat det mellanliggande certifikat den just hade sett, och Windows hade bara den gamla DST-signerade varianten sparad sedan tidigare. Firefox hämtar även mellanliggande certifikat i bakgrunden, men bara 100 om dagen, så det var inte det som räddade anslutningen. Klienten svarar utifrån vad den råkar ha kvar från tidigare anslutningar. Läs hans genomgång: Cross-signing & alternate trust paths: how they work.

Lita aldrig på att klienten räddar en bristfällig kedja. Servern ska skicka det kompletta paketet med alla mellanliggande certifikat, och behöver du täcka äldre klienter via en korssignerad kedja måste servern aktivt skicka den kedjan, inte räkna med att klienterna själva hittar den.