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 ut filen så den stämmer med det certifikat du har.

1. Hämta filerna

Hämta den relevanta filen från Korssignerade certifikat du behöver ovan.

2. Öppna MMC för Computer Account

1. Tryck Win+R, skriv mmc, klicka OK. Bekräfta UAC-prompten.
2. I MMC: meny File → Add/Remove Snap-in... (eller Ctrl+M).
3. I vänsterlistan, välj Certificates → klicka Add >.
4. Välj Computer account → Next. Det här är det viktiga valet, inte "My user account".
5. Välj Local computer → Finish → OK.

3. Importera det korssignerade certifikatet till Intermediate Certification Authorities

1. I vänsterrutan, expandera Certificates (Local Computer) → Intermediate Certification Authorities → klicka på undermappen Certificates.
2. Högerklicka på Certificates-mappen → All Tasks → Import...
3. Certificate Import Wizard startar. Klicka Next.
4. Klicka Browse..., välj filen. Byt filtyps-dropdown till All Files (*.*) om filen inte visas. Välj → 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 för att bekräfta Subject (vad certifikatet säger om sig själv) och Issuer (vem som signerade det).
7. Behöver du täcka flera nivåer (t.ex. även r6r46cross2019.crt), upprepa 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. I vänsterrutan, navigera 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. Verifiera först via dubbelklick på Details-fliken 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. Eller mer precist: välj Enable only the following purposes och ta bort bocken vid Server Authentication enbart.
6. Ska servern även skicka kedjan hela vägen ner till R3 (för klienter som bara har R3 som betrodd rot), upprepa samma procedur för GlobalSign Root R6. Schannel faller då tillbaka på den långa kedjan via båda korssignerade certifikat.

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 chain-cachen i lsass, och net stop http når inte heller Schannel-cachen. Planera därför alltid ett omstartsfönster när ni inaktiverar eller byter rötter.

6. Verifiera utåt

Efter omstart, testa live 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 en annan R46-rotkopia ligger fortfarande som aktiverad i Trusted Root.

Den enda pålitliga verifieringen är att skanna servern utifrån och se den kedja klienten faktiskt tar emot. Lokal MMC visar bara vad Windows menar att kedjan borde vara, inte vad HTTP.SYS skickar efter cache-tömning.

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

Ett trasigt eller bristfälligt certifikatpaket ger slumpmässiga resultat över olika klienter. Vissa klienter hämtar själva det saknade mellanliggande certifikatet via AIA-utvidgningen i serverns cert. Andra lagrar batcher av kända mellanliggande certifikat i bakgrunden och kommer igenom ändå. Det ser ut som att "det fungerar för mig", men nästa användare med samma webbläsarversion och en kall cache träffar felet.

I praktiken är det ofta mobiltelefoner, Safari och Firefox som fallerar först när servern glömmer 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 till att bara skicka leaf-certifikatet (utan mellanliggande) och inaktiverade den relevanta roten lokalt. Första försöket: både Chrome och Firefox fallerade som väntat. Senare försök, samma server-uppsättning: Firefox fungerade, Windows fallerade fortfarande. Firefox hade under tiden själv hämtat och lagrat det saknade mellanliggande via sin "Intermediate CA Preloading"-funktion, som dagligen hämtar batcher av kända mellanliggande certifikat. Läs hans genomgång här: 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.