Cross-signed intermediate på Windows Server
Når en CA migrerer sit rodcertifikat, sendes nye certifikater fra et nyt intermediate, der peger på en ny rod. Ældre klienter, der ikke kender den nye rod, bryder TLS-handshake. Et cross-signed intermediate bygger bro mellem den nye udstedende CA og den gamle rod, så både moderne og ældre klienter kan validere kæden.
Denne guide viser, hvordan du på Windows Server tilføjer, fremtvinger, fjerner og distribuerer cross-signed intermediates. Eksemplerne er baseret på de tre CA'er FairSSL aktivt sælger: GlobalSign og AlphaSSL, Sectigo med PositiveSSL, og DigiCert med RapidSSL.
Aktuel deadline: 27. juli 2026 for GlobalSign og AlphaSSL
GlobalSign har to parallelle rod-hierarkier, et RSA-baseret og et ECC-baseret, fordi RSA- og ECC-certifikater kræver hver sin algoritme hele vejen op gennem kæden. Den 27. juli 2026 flyttes alle nye certifikater til de TLS-dedikerede rødder R46 (RSA) og E46 (ECC). Cross-signede intermediates fra de gamle rødder R3 (RSA) og R5 (ECC) leveres ved siden af, så ældre klienter stadig kan validere. Tillid til R3 (RSA) fjernes endeligt i browsere 15. april 2027, og tillid til R5 (ECC) fjernes 15. april 2029. Kilde: GlobalSign Support: Upcoming Changes to TLS Roots.
Efter 27. juli 2026 udsteder GlobalSign nye RSA-certifikater fra R46 og nye ECC-certifikater fra E46. Tjek om jeres ældste klienter (Java 7, ældre Android, ældre embedded enheder) kan validere R46/E46 uden de gamle rødder. Kan de det, så send kun den korte kæde. Kan de ikke, så vedlæg cross-cert-versionen R46-by-R3 (RSA) eller E46-by-R5 (ECC) i serverens certifikatpakke, indtil de pågældende klienter er udskiftet.
Hvilken kæde har du?
Tjek hvilket produkt du har bestilt fra FairSSL, og hvilken cross-cert-kæde der hører til. Tabellen viser den situation, der gælder pr. 2026 efter de igangværende rod-migreringer.
| Produkt fra FairSSL | Ny udstedende CA | Cross-signed via | Officiel kilde |
|---|---|---|---|
| AlphaSSL DV (RSA) | GlobalSign GCC R6 AlphaSSL CA 2025 (under R6) → GlobalSign GCC R46 AlphaSSL CA 2025 (under R46) efter 27. jul 2026 | R6 → R46 cross-cert (R46 signeret af R6) | AlphaSSL KB |
| DomainSSL DV (RSA og ECC) | Begge nøgletyper ligger i øjeblikket under R3 (SHA-256). Migrerer til R46-baseret intermediate inden 27. jul 2026. | R46 cross-signed by R3 under overgangsperioden | Migration KB |
| OrganizationSSL OV / ExtendedSSL EV (RSA) | RSA-intermediate under R3 → R46-baseret intermediate efter 27. jul 2026 | R46 (RSA) cross-signed by R3 (RSA) | Migration KB |
| OrganizationSSL OV / ExtendedSSL EV (ECC) | ECC-intermediate under R5 → E46-baseret intermediate efter 27. jul 2026 | E46 (ECC) cross-signed by R5 (ECC) | Migration KB |
| Sectigo PositiveSSL DV (RSA) | Sectigo Public Server Authentication CA DV R36 | R46 cross-signed by USERTrust RSA CA, AAA Certificate Services | Sectigo KB |
| Sectigo OV/EV (RSA) | Sectigo Public Server Authentication CA OV/EV R36 | R46 cross-signed by USERTrust RSA CA, AAA Certificate Services | Sectigo KB |
| DigiCert Basic OV (RSA) | DigiCert Global G2 TLS RSA SHA256 2020 CA1 | G2 betroet direkte; G5 cross-sign udgår 15. maj 2026 | DigiCert KB |
| RapidSSL DV (RSA) | RapidSSL Global TLS RSA4096 SHA256 2022 CA1 (under DigiCert Global Root G2) | G2 er betroet direkte indtil 15. april 2029 | DigiCert root liste |
Sectigos officielle distributionsside lister ni varianter (rod, DV/OV/EV i RSA og ECC, plus cross-sign-bundles). Filerne blev senest opdateret juni-juli 2025 og kan downloades direkte fra crt.sh eller via Sectigos KB-side ovenfor.
Cross-cert filer du skal bruge
De konkrete filer der skal downloades og importeres på serveren. Find din CA, hent filen, og følg den procedure nedenfor der passer til dit scenarie.
GlobalSign og AlphaSSL
Officiel oversigt: GlobalSign Cross Certificates KB
- R46 signeret af R6 (RSA 4096, til 10. dec 2034) - bruges til AlphaSSL og GlobalSign RSA-certifikater under det nye R46-hierarki
r6r46cross2019.crt - R46 signeret af R3 (RSA 4096, til 18. mar 2029) - alternativ kæde mod R3-rod
r3r46cross2019.crt - E46 signeret af R5 (ECC, gyldig til 19. jan 2038) - til ECC-certifikater under det nye E46-hierarki
r5e46cross2019.crt - R6 signeret af R3 (RSA 4096, til 18. mar 2029) - til legacy-stier mod ældre R3-rod
r3r6cross2019.crt
Sectigo (PositiveSSL m.fl.)
Officiel oversigt: Sectigo Public Roots and Hierarchy KB
- USERTrust RSA Certification Authority (rod, til Trusted Root)
crt.sh/?d=1199354 - R46 signeret af USERTrust (cross-cert intermediate, til Intermediate-lager)
crt.sh/?d=11405654893 - Sectigo Public Server Authentication CA DV R36 (udstedende intermediate)
crt.sh/?d=4267304690 - OV R36: crt.sh/?d=4267304698
EV R36: crt.sh/?d=4267304687
DigiCert og RapidSSL
Officiel oversigt: DigiCert Trusted Root Authority Certificates
- DigiCert Global Root G2 er betroet direkte i alle moderne klienter indtil 15. apr 2029. Cross-cert er normalt ikke nødvendig.
- G5 cross-signed roots bliver tilbagetrukket 15. maj 2026. Erstatninger findes på samme KB-side under "G5 Cross-Signed Roots".
- Migration plan: Multipurpose → dedicated TLS root hierarchies
Tip: tjek altid filens udstedelsesdato og udløbsdato før du importerer den. CA'erne ruller løbende nye versioner ud, og en cross-cert der står her kan være erstattet med en nyere variant. Hvis du er i tvivl, gå til CA'ens officielle KB-side (linket øverst i hver kolonne) og se hvilken fil de i øjeblikket anbefaler.
Server- og klient-rolle i kædevalg
Hvad serveren gør
Serveren udleverer i TLS-handshake ÉN kæde, ikke flere. Schannel/IIS bygger kæden via CertGetCertificateChain ud fra det, der ligger i Windows-certifikatlageret, og vælger den korteste gyldige sti til en betroet rod.
For et AlphaSSL-certifikat efter 27. juli 2026 ser de to muligheder sådan ud:
- Den korte sti: server-cert → GlobalSign GCC R46 AlphaSSL CA 2025 → GlobalSign Root R46 (den nye CA-rod).
- Den lange sti via cross-cert: server-cert → GlobalSign GCC R46 AlphaSSL CA 2025 → "GlobalSign Cross Certificate R6-R46" → GlobalSign Root CA - R6.
Er begge stier mulige i serverens certifikat-store, vælger Windows Server kun at aflevere den korte udgave til klienten, selv om klienten måske har brug for den lange. Klienten får aldrig cross-cert-kæden at se.
Skal serveren tvinges til at sende cross-cert-kæden, skal den korte sti gøres ugyldig lokalt på serveren. Standardmetoden er at deaktivere den nye CA-rod (R46) i Trusted Root via MMC, mens cross-cert-versionen forbliver i Intermediate-lageret. Schannel kan så ikke længere bygge den korte kæde og falder tilbage på cross-cert-stien. Hele installationsprocessen er beskrevet i Installer cross-sign på Windows Server nedenfor.
Kæden bliver længere for hver migration
AlphaSSL peger i dag op til R6. Klienter der kun har R3 (ikke R6) som betroet rod skal bruge cross-cert R6 signeret af R3 (r3r6cross2019.crt) for at validere.
Efter 27. juli 2026 peger AlphaSSL op til R46. Klienter med kun R6 betroet skal bruge R46 signeret af R6 (r6r46cross2019.crt). Klienter med kun R3 betroet skal bruge R46 signeret af R3 (r3r46cross2019.crt) eller stable begge cross-certs for at nå hele vejen ned: r6r46cross2019.crt + r3r6cross2019.crt.
Hvad klienten gør med det
Klienten modtager den ene kæde, serveren sendte, og bygger sin egen lokale validering oven på den. Hver klient kigger efter den første rod i kæden, den selv stoler på, og stopper der.
Hvilken kæde serveren sender afhænger af, hvilke rødder serveren selv har aktiveret i sit Trusted Root. For AlphaSSL R46-eksemplet:
- Server med R46 aktiv (standard): bygger og sender kort kæde til R46. Kun klienter med R46 som betroet rod validerer.
- Server med R46 deaktiveret, R6 aktiv: bygger og sender mellemlang kæde via cross-cert
R46 signeret af R6op til R6. Klienter med R46 ELLER R6 som betroet rod validerer (R46-klienten matcher Subject = R46 i cross-cert mod sin egen R46-rod; R6-klienten matcher Issuer = R6 mod sin egen R6-rod). - Server med R46 og R6 deaktiveret, R3 aktiv: bygger og sender lang kæde via to cross-cert-led op til R3. Klienter med R46, R6 eller R3 som betroet rod validerer alle.
Vælg den server-opsætning, der dækker den ældste klient-population du skal supportere. Lange kæder koster handshake-bytes for alle klienter, så hvis ingen af jeres klienter behøver R3-stien, lad R6 være aktiv.
Den eneste måde at få serveren til at sende cross-cert-kæden er at deaktivere den nye CA-rod (og evt. den mellemste rod) lokalt, så Schannel ikke kan bygge den korte sti. Den certifikatpakke CA'en udsteder gør det ikke for dig: Microsofts Root Cert Program installerer alligevel den nye rod i Trusted Root, og Schannel vælger så den kortere sti uanset hvad pakken indeholder.
Installer cross-sign 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
- Tryk Win+R, skriv
mmc, klik OK. Bekræft UAC-prompt. - I MMC: menu File → Add/Remove Snap-in... (eller Ctrl+M).
- I venstre liste, vælg Certificates → klik Add >.
- Vælg Computer account → Next. Dette er det vigtige valg, ikke "My user account".
- Vælg Local computer → Finish → OK.
3. Importér cross-cert til Intermediate Certification Authorities
- I venstre rude, udvid Certificates (Local Computer) → Intermediate Certification Authorities → klik på undermappen Certificates.
- Højreklik på Certificates-mappen → All Tasks → Import...
- Certificate Import Wizard starter. Klik Next.
- Klik Browse..., vælg cross-cert-filen. Skift filtype-dropdown til All Files (*.*) hvis filen ikke vises. Vælg → Open → Next.
- Bekræft at lageret er Intermediate Certification Authorities → Next → Finish → OK.
- 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).
- 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.
- I venstre rude, naviger til Trusted Root Certification Authorities → Certificates.
- 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.
- Verificér først via dobbeltklik på Details-fanen at Subject = Issuer (det er en rod, ikke en cross-cert).
- Højreklik certifikatet → Properties → fanen General.
- 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.
- 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.
Hver deaktiveret rod gør hver TLS-handshake ~1 KB større. Deaktivér kun de rødder du faktisk har brug for.
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.
Skal det udrulles til mange servere? Lav en GPO der udruller cross-cert-filerne til Public Key Policies → Intermediate Certification Authorities, og udruller de rødder I vil deaktivere til Public Key Policies → Untrusted Certificates. Reboot kræves stadig på hver server, så planlæg det i forbindelse med jeres næste vedligeholdelsesvindue.
Vil I tilbage til standard? Genaktivér roden i Trusted Root (Properties → Enable all purposes eller Enable only the following purposes → Server Authentication tjekket) og genstart Windows Server. Cross-cert-filen kan blive liggende i Intermediate-lageret; Schannel vælger igen den korte sti, så længe den nye rod er aktiveret.
Verifikation
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:443viser hele kæden serveren sender.
Fejlfinding
"Chain issues: Incomplete" på SSL Labs eller FairSSL Scanner
Serveren sender ikke intermediate med i handshake. Tjek at intermediate (det udstedende eller cross-signede) ligger i Cert:\LocalMachine\CA, ikke i Cert:\CurrentUser\CA. Genstart HTTP-stakken efter import. Visse klienter (Windows, browsere) henter selv det manglende intermediate via AIA-opslag og kommer igennem alligevel, men de fleste open source-klienter venter ikke på AIA-opslag og melder fejl med det samme.
Klient melder "untrusted issuer" selvom certifikatet er gyldigt
Klientens betroede rødder indeholder ikke den øverste rod, kæden peger på. Hvis klienten kun har den gamle rod (R3) og du sender en kort kæde mod den nye (R46), så fejler valideringen. Tilføj cross-cert-versionen til serverens certifikatpakke, så klienten kan følge stien helt op til R3.
Windows ignorerer mit nyimporterede cross-cert
HTTP.SYS holder en kæde-cache pr. binding. Genstart med net stop http /y efterfulgt af net start http og net start w3svc. iisreset alene er ikke altid nok. På Exchange-bokse: stop og start MSExchangeServiceHost samt IIS Admin Service.
AIA-fetch fejler bag firewall eller proxy
Windows forsøger at hente det manglende issuer-cert via HTTP fra URL'en i AIA-udvidelsen. Hvis udgående 80/tcp er blokeret, sker det uden fejlmelding. Symptomet er en server, der bygger kæder fint i lab, men ikke i produktion. Importér intermediate til CA-lageret eksplicit, så Windows ikke behøver opslaget.
Slettet rodcertifikat dukker op igen efter genstart
Det er Microsoft Root Certificate Program. Brug GPO til at deaktivere roden, eller importér den til Untrusted-lageret. Sletning alene rulles tilbage automatisk via Windows Update. Læs Microsofts dokumentation under Microsoft Trusted Root Program requirements.
Hvorfor virker det for nogle klienter og ikke andre?
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) og deaktiverede den relevante rod lokalt. Første forsøg: både Chrome og Firefox fejlede som forventet. Senere forsøg, samme server-opsætning: Firefox virkede, Windows fejlede stadig. Firefox havde i mellemtiden selv hentet og gemt det manglende intermediate via sin "Intermediate CA Preloading"-funktion, der dagligt henter batches af kendte intermediates. 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.
Relateret indhold
Intermediate-installation
Grundlæggende guide til at installere et intermediate i forskellige formater og platforme.
Certifikatkæde-fejlsøgning
Sådan diagnosticerer du brudte kæder, manglende intermediates og hvilken rod kæden peger på.
Valg af certifikatudsteder
Den strategiske baggrund for CA-fleksibilitet, rod-migrering og hvorfor cross-signing eksisterer.
Simple-ACME guide
Automatiser hele certifikatlivscyklussen på Windows Server, inkl. import af nye kæder ved fornyelse.
SSL Scanner
Tjek live om din server udleverer en komplet kæde, og hvilken rod den peger på.
Installationsservice
FairSSL installerer cross-certs og tester kæden på jeres servere. Fast pris pr. server.
Ofte stillede spørgsmål om cross-signed intermediates
Find svar på de mest almindelige spørgsmål om SSL certifikater og FairSSL.
certutil -verify -urlfetch sti\til\server.crt og kig efter linjen "Application[0] = ... Server Authentication". Den udskriver den valgte kæde med tommelfingeraftryk på hvert led. Alternativt: åbn certifikatet i MMC, klik fanen "Certification Path". Det første led der peger op er det Windows har valgt.Cert:\LocalMachine\CA (ikke kun i CurrentUser-lageret). Genstart HTTP-tjenesten: net stop http /y && net start http && net start w3svc. Verificér efterfølgende med vores SSL Scanner eller openssl s_client -connect dit-domæne.dk:443 -showcerts.Skal vi installere cross-cert-kæden for jer?
Opret en gratis konto og udsted dit første certifikat på under 10 minutter.