Das Wichtigste zuerst: Eure Systeme werden nicht einfach abrauchen

Kurze Antwort vorweg: Solange eure Red Hat Enterprise Linux-Systeme aktuell booten, werden sie das auch nach dem 27. Juni 2026 noch tun. Das ablaufende Zertifikat ist kein Kippschalter, der um Mitternacht eure gesamte Infrastruktur lahmlegt. Was sich allerdings ändert: Neue Boot-Komponenten können ab dann nicht mehr mit dem alten Schlüssel signiert werden.

Warum ist das überhaupt ein Thema? Secure Boot ist Microsofts Mechanismus, der dafür sorgt, dass nur kryptografisch signierte Betriebssystem-Loader und Kernel beim Startvorgang zugelassen werden. Das Signaturzertifikat von 2011 hat treue Dienste geleistet. Aber Zertifikate haben nun mal ein Verfallsdatum – und die Uhr läuft.

Was steht wirklich auf dem Spiel?

Hier wird es wichtig, genau hinzuschauen:

• Bereits vertrauenswürdige Komponenten: Die laufen weiter. Das Zertifikat macht Signaturen nicht rückwirkend ungültig. Was zum Zeitpunkt der Erstellung gültig war, bleibt gültig.

• Neue Boot-Komponenten: Hier kommt der Knackpunkt ins Spiel. Neue Kernel, Shim-Loader oder Bootloader, die nach dem Zertifikatsablauf signiert werden, müssen zwingend einen neuen Signaturschlüssel verwenden.

Für die meisten von euch, die mit stabilen, etablierten Systemen arbeiten: Euer Alltag wird nicht plötzlich stoppen. Aber wenn ihr in den kommenden Monaten neue Infrastruktur aufbaut, Systeme neu aufsetzt oder Boot-Komponenten aktualisiert – dann solltet ihr diesen Stichtag im Hinterkopf behalten.

Das Shim-Dilemma

Jetzt wird's etwas kniffliger. Der Shim – diese dünne Schicht zwischen eurer Firmware und dem OS-Bootloader – spielt ebenfalls eine Rolle. Red Hat pflegt seinen eigenen Shim, und ihn aktuell zu halten, gehört zu den empfohlenen Best Practices.

Shim-Updates kommen normalerweise über die normalen Systemaktualisierungen. Ein halbwegs aktuelles RHEL-System sollte euch also in eine gute Ausgangslage bringen. Aber wenn ihr gerade bei dem einen produktiven Server die Updates scheut – dem „stabilen" System, das niemand anfassen will – dann wäre jetzt vielleicht der richtige Moment für ein Wartungsfenster.

Was ihr konkret tun solltet

Eure praktische Checkliste:

1. Keine Panik. Laufende Systeme hören nicht von selbst auf zu booten.

2. Updates einspielen. Das ist nicht nur Cyber-Hygiene – aktuelle Systeme bringen die Shim- und Bootloader-Pakete mit, die für diesen Übergang vorbereitet sind.

3. Neue Deployments vorausplanen. Wenn ihr nach Juni 2026 neue RHEL-Instanzen hochzieht, stellt sicher, dass eure Basis-Images und Installationsmedien aktuell sind.

4. In der Staging-Umgebung testen. Nutzt nicht-kritische Testumgebungen, um zu verifizieren, dass eure Deployment-Prozesse mit aktuellen Paketen reibungslos funktionieren.

5. Den Ist-Zustand dokumentieren. Zu wissen, welche Systeme welche Versionen von Shim und Bootloader nutzen, verschafft euch eine klare Ausgangsbasis.

Das Fazit

Ablaufende Sicherheitszertifikate klingen immer dramatisch – erinnert an das mulmige Gefühl, wenn das SSL-Zertifikat auf einer Produktivseite abgelaufen ist. Aber hier sind die Auswirkungen deutlich begrenzter, als man vielleicht befürchtet.

Die Secure-Boot-Zertifikatsexpiration 2026 ist ein gesteuerter Übergang, keine Krise. Microsoft und Red Hat arbeiten daran, und die Linux-Welt hatte Jahre Zeit, sich vorzubereiten. Eure Aufgabe ist überschaubar: Systeme aktuell halten, die Entwicklung im Blick behalten und Deployment-Prozesse testen.

Betrachtet es als sanften Anstoß, endlich diese Staging-Umgebung auf Vordermann zu bringen, die ihr schon länger vor euch herschiebt. Euer zukünftiges Ich – und eure Sicherheitslage – werden es euch danken.

Bleibt sicher da draußen.