Cross-signed intermediate på Windows Server

AlphaSSL-eksempel: importér cross-cert r3r6cross2019.crt i Intermediate Certification Authorities og deaktiver GlobalSign Root R6 i Trusted Root. Udskift Cross-Sign certifikatet så det passer med det certifikat du har.

1. Hent filerne

Hent den relevante cross-cert-fil fra Cross-cert filer du skal bruge ovenfor.

2. Åbn MMC for Computer Account

1. Tryk Win+R, skriv mmc, klik OK. Bekræft UAC-prompt.
2. I MMC: menu File → Add/Remove Snap-in... (eller Ctrl+M).
3. I venstre liste, vælg Certificates → klik Add >.
4. Vælg Computer account → Next. Dette er det vigtige valg, ikke "My user account".
5. Vælg Local computer → Finish → OK.

3. Importér cross-cert til Intermediate Certification Authorities

1. I venstre rude, udvid Certificates (Local Computer) → Intermediate Certification Authorities → klik på undermappen Certificates.
2. Højreklik på Certificates-mappen → All Tasks → Import...
3. Certificate Import Wizard starter. Klik Next.
4. Klik Browse..., vælg cross-cert-filen. Skift filtype-dropdown til All Files (*.*) hvis filen ikke vises. Vælg → Open → Next.
5. Bekræft at lageret er Intermediate Certification Authorities → Next → Finish → OK.
6. Tryk F5. Cross-cert-filen er nu i listen. Dobbeltklik for at bekræfte Subject (hvad certifikatet siger om sig selv) og Issuer (hvem signerede det).
7. Skal du dække flere lag (fx også r6r46cross2019.crt), gentag trin 2-6 for hver fil.

4. Deaktiver den nye CA-rod i Trusted Root

Schannel finder ellers den nye rod i Trusted Root og bygger den korte kæde, og dit cross-cert ligger ubrugt i Intermediate-lageret.

1. I venstre rude, naviger til Trusted Root Certification Authorities → Certificates.
2. Find den nye CA-rod, der svarer til den nye kæde. For AlphaSSL R6-hierarkiet: GlobalSign Root R6. For R46-eraen efter 27. juli 2026: GlobalSign Root R46.
3. Verificér først via dobbeltklik på Details-fanen at Subject = Issuer (det er en rod, ikke en cross-cert).
4. Højreklik certifikatet → Properties → fanen General.
5. Vælg Disable all purposes for this certificate → OK. Eller mere præcist: vælg Enable only the following purposes og fjern fluebenet ved Server Authentication alene.
6. Skal serveren også sende kæden helt ned til R3 (for klienter der kun har R3 som betroet rod), gentag samme procedure for GlobalSign Root R6. Schannel falder så tilbage på den lange kæde via begge cross-certs.

4b. Disallowed-lageret er den robuste metode

Deaktivering via Disable all purposes virker, men Microsoft advarer selv om, at indstillingen kan blive rullet tilbage. I KB 2831004 står der: "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 henter rodcertifikater fra Windows Update under kædeopbygning. Sletter du roden, kommer den tilbage. Slår du den automatiske rodopdatering fra på hele serveren, mister serveren også de rødder, den har brug for som TLS-klient. Den robuste metode er derfor at flytte roden til Disallowed-lageret:

1. Højreklik Untrusted Certificates i venstre rude → Certificates.
2. All Tasks → Import og vælg rodfilen for den nye rod.
3. Roden ligger nu i Disallowed-lageret, hvor den automatiske rodopdatering ikke kan sætte den tilbage.

Sectigo udgiver færdige reg-filer til deres egne rødder, IISFix-MoveSectigoSelfSignedRoots-Disallowed.reg og IISFix-MoveSectigoSelfSignedRoots-Restore.reg. For GlobalSign og DigiCert gøres det manuelt som ovenfor.

5. Genstart Windows Server

Efter ændringer i Trusted Root og Intermediate-lagrene er en fuld Windows-genstart den eneste pålidelige måde at tømme Schannel- og HTTP.SYS-cache for cert-kæder. iisreset alene rammer ikke chain-cache i lsass, og net stop http rammer heller ikke Schannel-cache. Planlæg derfor altid et reboot-vindue når I deaktiverer eller skifter rødder.

6. Verificér udadtil

Efter reboot, test live fra internettet med FairSSL SSL Scanner eller SSL Labs. Den øverste rod i den udleverede kæde skal nu være den gamle (R3 eller R6 alt efter dit valg), ikke den nye R46. Hvis kæden stadig ender på R46, er deaktiveringen ikke trådt i kraft, eller en anden R46-rodkopi ligger stadig som aktiv i Trusted Root.

Den eneste pålidelige verifikation er at scanne serveren udefra og se den kæde, klienten faktisk modtager. Lokalt MMC viser kun hvad Windows mener kæden burde være, ikke hvad HTTP.SYS sender efter cache-flush.

• Internet-vendt server: brug FairSSL SSL Scanner. Den viser den fulde kæde serveren udleverer og simulerer flere klient-populationer.
• Intern server (uden adgang fra internettet): brug testssl.sh fra en anden maskine på netværket. Kommando: testssl.sh --chain server.intern.dk:443 viser hele kæden serveren sender.

En brudt eller mangelfuld certifikatpakke giver tilfældige resultater på tværs af klienter. Nogle klienter henter selv det manglende intermediate via AIA-udvidelsen i serverens cert. Andre gemmer batches af kendte intermediates i baggrunden og kommer igennem alligevel. Det ser ud som om "det virker for mig", men den næste bruger med samme browser-version og en kold cache rammer fejlen.

I praksis er det ofte mobiltelefoner, Safari og Firefox, der fejler først, når serveren glemmer intermediate. Windows og Chrome kan ofte lave et AIA-opslag og redde situationen, hvilket skjuler fejlen. Fungerer siden i Edge på en Windows-maskine, antager man at den fungerer for alle, og opdager først problemet, når en kunde ringer fra en iPhone.

Scott Helmes eksperiment viser præcis denne uforudsigelighed. Han konfigurerede en server til kun at sende leaf-certifikatet, uden intermediate, med den gamle rod utroet i klienten. Første forsøg: både Chrome og Firefox fejlede som forventet. Han lod derefter serveren sende det ISRG-signerede intermediate én gang, hvorefter begge kom igennem. Da han satte serveren tilbage til kun at sende leaf, virkede Firefox stadig, mens Windows fejlede: Firefox havde beholdt det intermediate den lige havde set, og Windows havde kun den gamle DST-signerede udgave gemt fra tidligere. Firefox henter også intermediates i baggrunden, men kun 100 om dagen, så det var ikke dét der reddede forbindelsen. Klienten svarer ud fra hvad den tilfældigvis har liggende fra tidligere forbindelser. Læs hans gennemgang her: Cross-signing & alternate trust paths: how they work.

Stol aldrig på, at klienten redder en mangelfuld kæde. Serveren skal sende den komplette certifikatpakke med alle intermediates, og hvis du har brug for at dække ældre klienter via en cross-cert-kæde, skal serveren aktivt sende den kæde, ikke regne med at klienterne selv finder den.