Cross-Zertifikate in der Zertifikatskette: Ersetzen sie ein Intermediate?
Die Zertifikatskette von letsencrypt.org besteht aus vier Zertifikaten. Zwei davon tragen den Namen einer Root-CA, sind aber von einer anderen Root-CA ausgestellt. Das sind Cross-Zertifikate. Ein Cross-Zertifikat verbindet zwei Zertifizierungsstellen, damit ein Client einer neuen Root-CA vertrauen kann, obwohl er nur die alte kennt. Seit Let’s Encrypt 2026 auf neue Root-CAs umgestellt hat, steckt in jeder ausgelieferten Kette mindestens eines, und auch die Root-CA von D-Trust aus 2023 und Sectigos Root R46 kommen mit Cross-Zertifikat. Dieser Beitrag erklärt, was ein Cross-Zertifikat technisch ist, wie Clients damit umgehen, wofür es eingesetzt wird und ob es ein Intermediate ersetzt.
Alle Ausgaben stammen von Abrufen am 20.10.2026 unter Windows 11 mit OpenSSL 3.5.3 und von einer kleinen Test-PKI, die ich dafür mit OpenSSL aufgebaut habe.
Die Begriffe in drei Sätzen
Das Zertifikat einer Root-CA ist selbst signiert und liegt im Trust Store des Clients, also in der Liste der Zertifizierungsstellen, denen Betriebssystem, Browser oder Laufzeitumgebung von Haus aus vertrauen. Ein Intermediate ist das Zertifikat einer Zertifizierungsstelle (CA), das von der Root-CA ausgestellt wurde; mit seinem Schlüssel signiert die CA die Serverzertifikate. Der Server schickt im TLS-Handshake sein eigenes Zertifikat und die Intermediates, der Client baut daraus einen Pfad bis zu einer Root-CA, die er kennt.
Was ein Cross-Zertifikat ist
RFC 5280, die Grundlage für X.509-Zertifikate im Internet, definiert Cross-Zertifikate als CA-Zertifikate, bei denen Aussteller und Inhaber verschiedene Stellen sind. In der Praxis heißt das: Eine CA A stellt ein Zertifikat für den Namen und den öffentlichen Schlüssel von CA B aus. CA B hat damit zwei Zertifikate für denselben Schlüssel: ihr eigenes, selbst signiertes, und das von A ausgestellte.
In der Test-PKI sieht das so aus. Test Root-CA Neu ist eine selbst signierte Root-CA, das Cross-Zertifikat trägt denselben Namen und denselben Schlüssel, ausgestellt von Test Root-CA Alt:
neu.crt
subject=CN=Test Root-CA Neu
issuer=CN=Test Root-CA Neu
Schluessel-SHA256: 5bcc8a63b948b547764a9aeafc83997c694acc58958d91afebf2b610d2066fc9
cross.crt
subject=CN=Test Root-CA Neu
issuer=CN=Test Root-CA Alt
Schluessel-SHA256: 5bcc8a63b948b547764a9aeafc83997c694acc58958d91afebf2b610d2066fc9Weil der Schlüssel gleich ist, lässt sich alles, was Test Root-CA Neu signiert hat, mit beiden Zertifikaten prüfen. Für ein Serverzertifikat unter dieser CA gibt es damit zwei gültige Wege: einen, der an der neuen Root-CA endet, und einen, der über das Cross-Zertifikat an der alten Root-CA endet. Der Name „Cross-Signing“ meint genau diesen Vorgang.
Wie der Client den Weg wählt
Der Client sucht einen Pfad vom Serverzertifikat zu irgendeiner Root-CA in seinem Trust Store. Was der Server schickt, ist dabei Material und keine Vorgabe. RFC 8446 (TLS 1.3) sieht vor, dass Clients mit überzähligen Zertifikaten und abweichender Reihenfolge umgehen können. Dazu kommen Zertifikate aus dem eigenen Speicher und, je nach Plattform, nachgeladene Aussteller.
In der Test-PKI ist die Kette Server → Test Intermediate CA → Test Root-CA Neu. Das Ergebnis mit openssl verify, je nachdem, was der Client kennt und was der Server schickt:
| Client kennt | Server schickt | Ergebnis | Pfad |
|---|---|---|---|
| nur die alte Root-CA | Intermediate + Cross | OK | Server → Intermediate → Cross → Root-CA Alt |
| nur die neue Root-CA | Intermediate + Cross | OK | Server → Intermediate → Root-CA Neu |
| nur die alte Root-CA | nur Intermediate | Fehler 20 unable to get local issuer certificate | kein Pfad |
Die zweite Zeile zeigt: Ein Client, der die neue Root-CA kennt, braucht das Cross-Zertifikat nicht und lässt es liegen. Genau das passiert bei www.bsi.bund.de. Der Server schickt drei Zertifikate, das dritte ist das Cross-Zertifikat der D-TRUST BR Root CA 2 2023, ausgestellt von der D-TRUST Root Class 3 CA 2 2009. OpenSSL und Windows kennen beide die Root-CA von 2023 und enden dort. Ein Client, der nur die Root-CA von 2009 kennt, nimmt den Weg über das Cross-Zertifikat.
Ersetzt ein Cross-Zertifikat ein Intermediate?
Nein. Das ausstellende Intermediate bleibt in jedem Pfad stehen. Bei www.bsi.bund.de ist das D-TRUST BR CA 2-23-1 2023, bei letsencrypt.org das Intermediate YE2. Das Cross-Zertifikat kommt oberhalb davon hinzu und verlängert die Kette um ein Glied bis zur alten Root-CA.
Für die Konfiguration verhält es sich allerdings wie ein weiteres Intermediate. Es ist ein CA-Zertifikat, das kein Trust Anchor ist, der Server schickt es mit, und Windows legt es beim Nachladen im Speicher „Zwischenzertifizierungsstellen“ (englisch: Intermediate Certification Authorities) ab. Auf meinem Rechner lag dort nach einigen Abrufen das Cross-Zertifikat Root YR, ausgestellt von ISRG Root X1.
| Root-CA | Intermediate | Cross-Zertifikat | |
|---|---|---|---|
| Aussteller | die CA selbst | eine Root-CA oder ein anderes Intermediate | eine andere CA |
| Schlüssel | eigener | eigener | derselbe wie das selbst signierte Zertifikat der CA |
| Liegt beim Client | im Trust Store | nein, kommt vom Server | nein, kommt vom Server |
| Zweck | Trust Anchor | Serverzertifikate ausstellen, Root-CA schützen | zweiten Pfad zu einer anderen Root-CA öffnen |
Einen Sonderfall gibt es: Auch ein Intermediate kann cross-signiert sein. Let’s Encrypt führt für die abgelaufenen Intermediates R3 und R4 zwei Fassungen, eine von ISRG Root X1 und eine von IdenTrust ausgestellt. Der Server schickt dann eine der beiden Fassungen. In diesem Fall tritt das Cross-Zertifikat an die Stelle der anderen Fassung desselben Intermediates, denn Name und Schlüssel sind gleich.
Wofür Cross-Zertifikate eingesetzt werden
Eine neue Root-CA bekannt machen
Eine neue Root-CA ist erst nützlich, wenn sie in den Trust Stores steht. Bis Betriebssysteme, Browser, Java, Appliances und Geräte mit seltenen Updates sie mitbringen, vergehen Jahre. Das Cross-Zertifikat überbrückt diese Zeit: Die CA stellt sofort unter der neuen Root-CA aus, und alte Clients vertrauen über die alte Root-CA.
So hat Let’s Encrypt angefangen: Die ersten Intermediates Let's Encrypt Authority X1 bis X4 gab es in einer Fassung, die IdenTrust ausgestellt hatte. Die neuen Root-CAs der „Generation Y“ (Root YE mit ECDSA, Root YR mit RSA) sind laut Let’s Encrypt (Stand 08.07.2026) noch in keinem großen Trust Store. Das Vertrauen kommt bisher vollständig über die Cross-Zertifikate von ISRG Root X2 und ISRG Root X1. Die Cross-Zertifikate, die letsencrypt.org und www.heise.de am 20.10. ausgeliefert haben, gelten vom 13.05.2026 bis zum 02.09.2032.
Google macht das Cross-Zertifikat inzwischen zur Bedingung. Die Chrome Root Program Policy 1.8 vom 05.02.2026 verlangt in Abschnitt 1.3.1.1, dass eine CA vor dem Antrag auf Aufnahme einer Ersatz-Root-CA ein Cross-Zertifikat von der abzulösenden auf die neue Root-CA ausgestellt hat.
Einen Algorithmus einführen
ISRG Root X2 hat einen ECDSA-Schlüssel und ist von der RSA-Root-CA ISRG Root X1 cross-signiert. Clients ohne X2 im Trust Store vertrauen ECDSA-Zertifikaten von Let’s Encrypt dadurch trotzdem. Bei letsencrypt.org ergibt das zwei Cross-Zertifikate hintereinander: YE2 → Root YE → ISRG Root X2 → ISRG Root X1. OpenSSL mit dem Zertifikatspaket von Git for Windows kennt X2 und endet dort, das letzte Glied bleibt ungenutzt.
Den Schlüssel der eigenen Root-CA wechseln
In einer eigenen PKI entstehen Cross-Zertifikate beim Erneuern einer Root-CA mit neuem Schlüssel. Microsoft beschreibt für die Active Directory Certificate Services (AD CS) ein Paar: eines, mit dem die alte Root-CA dem erneuerten Zertifikat vertraut, und eines für die Gegenrichtung, jeweils für die Zeit, in der sich die Laufzeiten überschneiden. Auslesen lassen sie sich an der CA mit certutil -cainfo cross+ (vorwärts) und certutil -cainfo cross- (rückwärts). Das Verwaltungsprotokoll CMP (RFC 9810, Nachfolger von RFC 4210) nennt sie Link-Zertifikate: NewWithOld enthält den neuen Schlüssel, signiert mit dem alten, OldWithNew umgekehrt.
Beim Erneuern mit demselben Schlüssel entsteht kein Cross-Zertifikat, und es wird auch keins gebraucht: Alles, was die Root-CA signiert hat, passt zu beiden Fassungen ihres Zertifikats.
Zwei PKIs verbinden
Nach einer Übernahme oder für einen Partner kann die eine CA der anderen ein Cross-Zertifikat ausstellen. Die Benutzer der einen Organisation vertrauen dann Zertifikaten der anderen, ohne eine fremde Root-CA in ihren Trust Store aufzunehmen. Microsoft nennt das in AD CS „qualified subordination“: Das Cross-Zertifikat trägt Einschränkungen, etwa Name Constraints, damit die fremde CA nur für die vereinbarten DNS-Namen oder UPN-Suffixe gilt. Festgelegt werden sie in der Datei policy.inf beim Ausstellen. Mit certutil -dspublish <datei> CrossCA landet das Cross-Zertifikat im Active Directory.
Bei mehr als zwei Partnern übernimmt eine Bridge-CA die Rolle des Knotens: Jede Organisation tauscht Cross-Zertifikate nur mit der Bridge statt mit allen anderen. RFC 4158 beschreibt, wie Clients in solchen Netzen Pfade bauen. Microsoft weist darauf hin, dass dabei sehr lange Ketten entstehen können, die jeden Handshake vergrößern.
Warum das 2026 relevant ist
Root-CAs haben inzwischen ein Verfallsdatum, das nicht im Zertifikat steht. Mozilla nimmt einer Root-CA das Vertrauen für Websites, sobald ihr Schlüssel älter als 15 Jahre ist. Nach dem Übergangsplan traf das Root-CAs mit Schlüsseln aus 2006 und 2007 am 15.04.2026, Schlüssel aus 2008 und 2009 folgen am 15.04.2027, Schlüssel aus 2010 und 2011 am 15.04.2028. Chrome hat eine gleichartige Grenze von 15 Jahren. Seit dem 15.06.2026 baut Chrome außerdem Hierarchien ab, die nicht allein TLS-Serverzertifikaten dienen.
Beides zwingt die CAs zu neuen Root-CAs, und jede neue Root-CA kommt mit Cross-Zertifikat. Die D-TRUST Root Class 3 CA 2 2009 ist am 05.11.2009 ausgestellt; ihr Cross-Zertifikat für die Root-CA von 2023 gilt bis zum 05.11.2029, also bis zum Ende der alten Root-CA. Die USERTrust RSA Certification Authority, die Sectigos neue Public Server Authentication Root R46 cross-signiert, stammt vom 01.02.2010.
Für den Betrieb folgt daraus:
- Die Kette auf dem Server sollte das Cross-Zertifikat enthalten, solange Clients im Spiel sind, die nur die alte Root-CA kennen. Das betrifft vor allem Appliances, Java mit eigenem Trust Store, Geräte ohne Updates und Partner mit fest hinterlegten Root-CAs.
- Das Cross-Zertifikat hat ein eigenes Ablaufdatum. Läuft es ab, verlieren genau die Clients ohne neue Root-CA den Weg. Clients mit neuer Root-CA merkt man nichts an.
- Die Root-CA am Ende der Kette ist keine Konstante mehr. Fest hinterlegte Root-CAs oder Intermediates, etwa im Monitoring, in einer Partnerschnittstelle oder in einer App, brauchen beim nächsten Wechsel eine Anpassung. Let’s Encrypt wählt das Intermediate bei jeder Ausstellung zufällig, damit niemand es festschreibt.
Auf dem NetScaler gilt: Die Appliance schickt nur, was verlinkt ist. Das Cross-Zertifikat wird wie ein weiteres Intermediate angelegt, und das ausstellende Intermediate bekommt es als Aussteller verlinkt:
add ssl certkey <name-cross> -cert <datei-cross>
link ssl certkey <name-intermediate> <name-cross>Ausnahmen, die 2026 keine Rolle mehr spielen
Drei Fälle tauchen in älteren Anleitungen auf und lassen sich heute einordnen.
Der Ausfall vom 30.09.2021. An diesem Tag lief die DST Root CA X3 von IdenTrust ab, über die ältere Clients Let’s Encrypt vertrauten. OpenSSL 1.0.2 bevorzugte die Kette, die der Server schickte, landete bei der abgelaufenen Root-CA und brach ab, obwohl ISRG Root X1 im Trust Store lag. OpenSSL 3.5 sucht zuerst im Trust Store, openssl verify -help nennt -trusted_first als Vorgabe. In der Test-PKI mit abgelaufenem Cross-Zertifikat und beiden Root-CAs im Trust Store:
srv.crt: OK
Chain:
depth=0: CN=srv.test (untrusted)
depth=1: CN=Test Intermediate CA (untrusted)
depth=2: CN=Test Root-CA NeuDas abgelaufene Cross-Zertifikat wird übergangen. Kennt der Client nur die alte Root-CA, endet die Prüfung mit certificate has expired. Relevant bleibt der Fall nur dort, wo OpenSSL 1.0.2 noch läuft, etwa in alten Appliances.
Der Android-Kniff. Damit Android vor Version 7.1.1 Let’s Encrypt weiter vertraut, gab es ab 2021 ein Cross-Zertifikat, das länger lief als die DST Root CA X3 selbst. Es funktionierte, weil diese Android-Versionen das Ablaufdatum einer Root-CA nicht prüfen. Seit dem 08.02.2024 liefert Let’s Encrypt diese Kette nicht mehr standardmäßig aus, am 30.09.2024 ist das Cross-Zertifikat abgelaufen. Ketten mit DST Root CA X3 in Serverkonfigurationen sind damit überholt.
Die IdenTrust-Fassungen der Intermediates. R3 und R4 sind am 15.09.2025 abgelaufen, Let's Encrypt Authority X1 bis X4 schon 2020 und 2021. Ein Kettenpaket, das noch eines davon enthält, gehört ausgetauscht.
Wie du prüfst
Die Beispiele laufen in Windows PowerShell 5.1 und PowerShell 7. openssl liegt in Git for Windows, aber nicht im Suchpfad, deshalb der volle Pfad. Was der Server schickt:
$openssl = 'C:\Program Files\Git\usr\bin\openssl.exe'
$h = 'www.bsi.bund.de'
'' | & $openssl s_client -connect "${h}:443" -servername $h -showcerts 2>$null |
Select-String '^\s*\d+ s:|^\s+i:' 0 s:C=DE, ST=Nordrhein-Westfalen, O=Bundesamt fuer Sicherheit in der Informationstechnik, CN=www.bsi.bund.de
i:C=DE, O=D-Trust GmbH, CN=D-TRUST BR CA 2-23-1 2023
1 s:C=DE, O=D-Trust GmbH, CN=D-TRUST BR CA 2-23-1 2023
i:C=DE, O=D-Trust GmbH, CN=D-TRUST BR Root CA 2 2023
2 s:C=DE, O=D-Trust GmbH, CN=D-TRUST BR Root CA 2 2023
i:C=DE, O=D-Trust GmbH, CN=D-TRUST Root Class 3 CA 2 2009Ein Eintrag, dessen Inhaber (s:) eine Root-CA ist und dessen Aussteller (i:) eine andere Root-CA, ist ein Cross-Zertifikat. Welchen Weg OpenSSL tatsächlich genommen hat, zeigen die depth-Zeilen. Sie stehen in der Fehlerausgabe, deshalb 2>&1:
'' | & $openssl s_client -connect "${h}:443" -servername $h 2>&1 |
Select-String '^depth='depth=2 C=DE, O=D-Trust GmbH, CN=D-TRUST BR Root CA 2 2023
depth=1 C=DE, O=D-Trust GmbH, CN=D-TRUST BR CA 2-23-1 2023
depth=0 C=DE, ST=Nordrhein-Westfalen, O=Bundesamt fuer Sicherheit in der Informationstechnik, CN=www.bsi.bund.deDer Pfad endet bei der Root-CA von 2023, das Cross-Zertifikat aus Eintrag 2 wurde nicht gebraucht. Windows baut seinen Pfad selbst und kann zu einem anderen Ergebnis kommen. certutil zeigt ihn:
'' | & $openssl s_client -connect "${h}:443" -servername $h 2>$null |
& $openssl x509 -outform DER -out server.cer
certutil -verify -urlfetch server.cer | Select-String 'Subject:|Issuer:|SELF_SIGNED'Gekürzt auf die Zertifikate des Pfads:
Issuer: CN=D-TRUST BR CA 2-23-1 2023, O=D-Trust GmbH, C=DE
Subject: CN=www.bsi.bund.de, O=Bundesamt fuer Sicherheit in der Informationstechnik, S=Nordrhein-Westfalen, C=DE
Issuer: CN=D-TRUST BR Root CA 2 2023, O=D-Trust GmbH, C=DE
Subject: CN=D-TRUST BR CA 2-23-1 2023, O=D-Trust GmbH, C=DE
Issuer: CN=D-TRUST BR Root CA 2 2023, O=D-Trust GmbH, C=DE
Subject: CN=D-TRUST BR Root CA 2 2023, O=D-Trust GmbH, C=DE
Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)Auch Windows endet bei der selbst signierten Root-CA von 2023. Um zu sehen, was ein Client ohne neue Root-CA erlebt, hilft openssl verify mit der alten Root-CA als einzigem Trust Anchor (-CAfile) und der vom Server gesendeten Kette als -untrusted.
Was du dir merkst
Ein Cross-Zertifikat ist ein zweites Zertifikat für den Schlüssel einer CA, ausgestellt von einer anderen CA. Es ergänzt das Intermediate um einen Weg zu einer älteren Root-CA und ersetzt es nicht. Der Client nimmt den Weg, der bei einer Root-CA endet, die er kennt. Solange Clients nur die alte Root-CA kennen, gehört das Cross-Zertifikat in die Kette auf dem Server, und sein Ablaufdatum gehört in die Überwachung.
Quellen
- RFC 5280, Abschnitt 3.2: Definition Cross-Zertifikat, selbst ausgestellt, selbst signiert
- RFC 8446, Abschnitt 4.4.2: Clients sollen mit überzähligen Zertifikaten und abweichender Reihenfolge umgehen können
- RFC 4158: Pfadaufbau, Cross-Zertifizierung und Bridge-CAs
- RFC 9810, Abschnitt 4.4: Schlüsselwechsel einer Root-CA mit den Link-Zertifikaten
NewWithOldundOldWithNew - Let’s Encrypt, Chains of Trust: Root-CAs, Intermediates und Cross-Zertifikate mit Stand
- Let’s Encrypt, Generation Y Hierarchy, 24.11.2025
- Let’s Encrypt, Shortening the Let’s Encrypt Chain of Trust, 10.07.2023
- Let’s Encrypt, Extending Android Device Compatibility, 21.12.2020: Android prüft das Ablaufdatum von Trust Anchors nicht
- Chrome Root Program Policy 1.8, 05.02.2026, Abschnitt 1.3.1.1
- Mozilla, Root CA Lifecycles: 15-Jahres-Grenze und Übergangsplan
- OpenSSL, Old Let’s Encrypt root certificate expiration and OpenSSL 1.0.2, 13.09.2021
- Microsoft, Renew a root CA certificate: Cross-Zertifikate beim Erneuern mit neuem Schlüssel
- Microsoft, Qualified subordination overview: Cross-Zertifizierung zwischen Hierarchien, Einschränkungen per
policy.inf - D-Trust, Repository:
D-TRUST BR Root CA 2 2023 (RSA) - Cross-certified
Gemessen am 20.10.2026 mit OpenSSL 3.5.3 und certutil unter Windows 11 sowie an einer Test-PKI. Welche Root-CA am Ende der Kette steht, hängt vom Trust Store des Clients ab und ändert sich mit jedem Update. Die Daten zu Root-CAs und Richtlinien trage ich datiert nach, wenn sie sich ändern.
Hinterlasse einen Kommentar
An der Diskussion beteiligen?Hinterlasse uns deinen Kommentar!