Ubuntu lädt DKMS-Module unter Secure Boot nicht: Wie signiere ich Kernel-Module korrekt und halte das Setup updatefest?

Technische Grundlagen: Secure-Boot-Kette, UEFI-Trust, Shim, MOK, Kernel-Module und DKMS

Secure Boot als Kette aus Signaturen und Richtlinien

Secure Boot ist ein UEFI-Mechanismus, der sicherstellen soll, dass in den frühen Boot-Phasen ausschließlich vertrauenswürdiger Code ausgeführt wird. „Vertrauenswürdig“ bedeutet dabei nicht „fehlerfrei“, sondern „kryptografisch durch eine als gültig konfigurierte Instanz signiert“. Entscheidend ist die Kette: Jede Stufe prüft die Signatur der nächsten Stufe, bevor sie ausgeführt wird. Für Linux-Systeme ist relevant, dass diese Kette nicht beim Bootloader endet, sondern – je nach Konfiguration und Distribution – bis in den Linux-Kernel und weiter bis zu Kernel-Modulen reichen kann.

UEFI implementiert dafür ein Trust-Modell auf Basis mehrerer Datenbanken. Die Firmware hält üblicherweise eine Plattform-Schlüsselkette und erlaubte bzw. gesperrte Signaturen vor. Auf PCs ist die Vorkonfiguration häufig auf Microsofts Signatur-Infrastruktur ausgerichtet, weil damit Windows- und viele Drittanbieter-Bootloader funktionieren. Linux-Distributionen integrieren sich in dieses Modell, ohne dass Administratoren eigene Firmware-Schlüssel installieren müssen.

UEFI-Trust vs. Linux-Trust: Warum der Kernel plötzlich „mitredet“

UEFI Secure Boot entscheidet zunächst nur, ob ein EFI-Programm (z. B. ein Bootloader) starten darf. Bei Ubuntu kommt typischerweise shim zum Einsatz: shim ist so signiert, dass er von gängigen Firmware-Konfigurationen akzeptiert wird. Anschließend lädt shim den eigentlichen Bootloader (meist GRUB) und stellt eine zusätzliche, Linux-spezifische Vertrauensebene bereit.

Ab dem Kernelstart gilt eine zweite Ebene: Der Linux-Kernel kann erkennen, dass Secure Boot aktiv ist, und daraufhin Sicherheitsrichtlinien aktivieren, die das Nachladen von Kernel-Modulen verschärfen. In der Praxis äußert sich das so: Ein Kernel-Modul, das technisch korrekt gebaut wurde, wird trotzdem abgelehnt, wenn es keine gültige kryptografische Signatur trägt, die der Kernel als vertrauenswürdig einstuft. Dieses Verhalten ist nicht „ein Treiberproblem“, sondern die erwartete Konsequenz aus Secure-Boot-Policy plus Kernel-Modul-Signaturprüfung.

• UEFI-Phase: Firmware prüft EFI-Binaries gegen db/dbx, z. B. shimx64.efi.
• Shim-Phase: shim kann zusätzlich gegen die MOK-Datenbank prüfen und damit lokale Admin-Schlüssel einbeziehen.
• Kernel-Phase: Kernel prüft Kernel-Module (Dateien *.ko, oft komprimiert als *.ko.xz oder *.ko.zst) auf eine eingebettete Signatur; ohne Vertrauen in den Signierschlüssel wird das Modul nicht geladen.

Shim und Machine Owner Keys (MOK): Der kontrollierte „eigene“ Vertrauensanker

Machine Owner Keys (MOK) sind ein von shim bereitgestellter Mechanismus, um zusätzliche X.509-Zertifikate als vertrauenswürdig zu registrieren, ohne die UEFI-Firmware-Datenbanken (PK, KEK, db) anfassen zu müssen. Praktisch ist das für Systeme, die im Standardzustand bleiben sollen (z. B. OEM-Geräte), aber dennoch selbst signierte Kernel-Module benötigen.

Der Ablauf ist zweistufig: Unter Linux wird mit mokutil ein Zertifikat zur Registrierung vorgemerkt. Beim nächsten Boot erscheint der MOK-Manager (eine Oberfläche von shim), der die Registrierung interaktiv bestätigt. Erst danach steht der neue Schlüssel als Vertrauensanker für die nachgelagerten Prüfungen zur Verfügung. Damit wird der Eigentümerwechsel (wer darf neue Schlüssel hinzufügen?) nicht dem laufenden Betriebssystem allein überlassen, sondern an einen Boot-time-Bestätigungsschritt gekoppelt.

Wichtig ist die begriffliche Trennung: MOK ersetzt nicht Secure Boot, sondern ergänzt die Liste der akzeptierten Signaturen innerhalb der durch shim kontrollierten Kette. Das ist der zentrale Grund, warum Administratoren mit MOK stabil arbeiten können, ohne Firmware-Keys zu verändern.

Kernel-Module: Aufbau, Signaturen und Konsequenzen beim Laden

Kernel-Module sind binäre Erweiterungen des Linux-Kernels, die zur Laufzeit geladen werden (z. B. GPU-Treiber, Virtualisierungs- und Filesystem-Module). Das Laden erfolgt über Werkzeuge wie modprobe, die Abhängigkeiten auflösen und dann insmod-ähnliche Kernel-Schnittstellen nutzen. Bei aktivierter Signaturprüfung erwartet der Kernel, dass am Ende des Modul-Binaries eine PKCS#7-Signatur eingebettet ist. Diese Signatur referenziert ein X.509-Zertifikat, das der Kernel als vertrauenswürdig betrachtet.

Welche Schlüssel der Kernel als vertrauenswürdig ansieht, ist distributions- und konfigurationsabhängig. Typisch sind: im Kernel eingebaute Distributionsschlüssel, Schlüssel aus der Secure-Boot-Umgebung (über Shim/MOK vermittelt) sowie ggf. weitere kernel-interne Keyrings. Für Administratoren ist praktisch entscheidend: Ist ein Modul mit einem Schlüssel signiert, der nicht in einem relevanten Kernel-Keyring landet, wird es trotz korrekter Kompilierung abgelehnt. Das wird häufig erst sichtbar, wenn ein Update neue Module erzeugt, die (noch) nicht signiert sind.

DKMS: Automatisierter Build-Prozess und warum „Build OK“ nicht „Load OK“ bedeutet

DKMS (Dynamic Kernel Module Support) automatisiert das Bauen von Drittanbieter-Kernelmodulen gegen jeweils installierte Kernel-Versionen. Nach Kernel-Updates startet DKMS typischerweise einen Rebuild, sodass für jeden Kernel ein passendes *.ko entsteht. Diese Automatisierung löst jedoch nur die Kompatibilitätsfrage (passt das Modul-ABI zum Kernel?) – nicht die Vertrauensfrage (darf der Kernel das Modul laden?).

Der häufige Fehlannahme-Kern: Wenn DKMS „successfully built“ meldet, wird das als betriebsbereit interpretiert. Unter aktivem Secure Boot ist das nicht ausreichend, weil DKMS standardmäßig nicht garantiert, dass das resultierende Modul mit einem vom Kernel akzeptierten Schlüssel signiert wurde. Ein Treiberupdate (z. B. NVIDIA), ein VirtualBox-Update oder ein WLAN-Treiber aus DKMS kann daher nach dem nächsten Reboot „verschwinden“: Das Modul existiert, wird aber beim Laden zurückgewiesen.

• Build-Ebene: DKMS kompiliert Quellcode gegen Kernel-Header, typischerweise unter /var/lib/dkms/<modul>/<version>/<kernel>/.
• Install-Ebene: Das fertige Modul wird nach /lib/modules/$(uname -r)/updates/dkms/ oder ein ähnliches Unterverzeichnis kopiert und über depmod indiziert.
• Trust-Ebene: Beim Laden prüft der Kernel die eingebettete Signatur; ohne passende Signatur oder ohne Vertrauen in den Signierschlüssel wird das Modul abgelehnt, auch wenn es technisch korrekt installiert ist.

Relevante Werkzeuge und Artefakte (Begriffe, die später in Befehlen wiederkehren)

Für das Verständnis der späteren Schritte sind einige Bausteine zentral: mokutil zur Verwaltung der MOK-Vormerkungen, der MOK-Manager beim Boot zur interaktiven Aufnahme, sowie die Modul-Signaturwerkzeuge aus den Kernel-Headern (in Ubuntu typischerweise als Skript scripts/sign-file innerhalb der installierten Kernel-Header verfügbar). Für die Signatur wird ein privater Schlüssel (meist PEM) und das passende X.509-Zertifikat benötigt; das Zertifikat wird über MOK registriert, der private Schlüssel verbleibt ausschließlich im laufenden System und muss geschützt werden.

Außerdem ist der Unterschied zwischen „komprimiert“ und „signiert“ wichtig: Viele Distributionen liefern Module komprimiert aus (.xz, .zst). Signiert wird immer die tatsächlich geladene Moduldatei; nachträgliche Änderungen (z. B. erneutes Komprimieren, Strippen oder Neuinstallation) machen die Signatur ungültig. In DKMS-Szenarien wird typischerweise das von DKMS erzeugte Modul signiert, bevor es in den Modulpfad übernommen wird.

Warum Module trotz erfolgreichem DKMS-Build nicht laden: Signaturpflicht, Key-Trust und typische Fehlermuster

Was „Build erfolgreich“ bei DKMS tatsächlich bedeutet (und was nicht)

Ein erfolgreicher DKMS-Build bestätigt zunächst nur, dass der Quellcode des Moduls gegen die aktuell installierten Kernel-Header kompiliert und als .ko-Datei installiert wurde (typischerweise unter /lib/modules/$(uname -r)/updates/dkms/). DKMS prüft dabei nicht, ob das fertige Modul später vom Kernel auch geladen werden darf. Genau diese „Ladeberechtigung“ wird auf Secure-Boot-Systemen zusätzlich durch die Modul-Signaturprüfung entschieden.

Die häufige Verwechslung: DKMS behandelt den Build als Software-Engineering-Schritt (Kompilieren/Installieren), während Secure Boot und die Kernel-Policy zur Modulsignatur ein Vertrauensproblem lösen (Wer darf Code im Kernel-Kontext ausführen?). Deshalb können Systeme nach Kernel- oder Treiberupdates in den Zustand geraten: Modul liegt korrekt vor, aber modprobe bzw. udev scheitert beim Laden.

Warum Secure Boot das Laden blockiert: Trust-Kette bis zur Kernel-Policy

Bei aktiviertem Secure Boot startet Ubuntu typischerweise über shim, der von Microsoft signiert ist und eine eigene Vertrauenskette für Linux etabliert. Shim lädt GRUB und den Kernel, wobei das System zwischen UEFI-Datenbanken (z. B. db/dbx) und dem MOK-Mechanismus (Machine Owner Key) unterscheidet. Der Kernel kann so konfiguriert sein, dass er nur Kernel-Module akzeptiert, deren Signatur auf einen als vertrauenswürdig eingestuften Schlüssel zurückführt.

Die entscheidende Konsequenz: Selbst wenn ein Modul technisch korrekt gebaut ist, gilt es aus Sicht des Trust-Modells als „unbekannter Code“, solange es nicht mit einem vertrauenswürdigen Schlüssel signiert wurde. Viele DKMS-Module (z. B. NVIDIA, VirtualBox, ZFS in bestimmten Konstellationen, einige WLAN/Out-of-Tree-Treiber) werden nach Updates neu gebaut; ohne automatisierte Signierung entsteht ein wiederkehrender Bruch im Vertrauenspfad.

Typische Fehlermuster im Betrieb: so zeigt sich die Signaturblockade

In der Praxis ist das Problem oft nicht sofort als Secure-Boot-Thema erkennbar, weil der Build- und Installationsprozess „grün“ ist, aber die Hardwarefunktion fehlt. Die sicherste Quelle sind Kernel-Logs und die Rückgaben von Ladeversuchen. Charakteristisch sind Meldungen, die auf eine abgelehnte oder fehlende Signatur hindeuten, sowie Statusanzeigen, die Secure Boot als aktiv ausweisen.

• Secure-Boot-Status aktiv: mokutil --sb-state
• Ladeversuch schlägt fehl: sudo modprobe <modulname>
• Kernel-Log mit Signaturhinweisen (aktuelle Boot-Session): journalctl -k -b | grep -Ei "secure|lockdown|module|signature|modsig"
• Kernel-Log über dmesg (kurzer Blick): dmesg | grep -Ei "module verification|signature|Lockdown|taint"
• Moduldatei und Pfad verifizieren: modinfo -n <modulname>
modinfo <modulname> | grep -i signer

Bei einer Blockade ist häufig zu sehen, dass der Kernel das Modul als „nicht verifiziert“ ablehnt oder im „Lockdown“-Modus bestimmte Aktionen untersagt. Ebenfalls verbreitet: Das Modul lädt nicht, und in lsmod erscheint es nicht, obwohl die .ko-Datei vorhanden ist. Je nach Treiber kann das Folgefehler erzeugen (z. B. fehlende Netzwerkschnittstelle, nicht startender Display-Manager, VirtualBox-Kernel-Treiber nicht geladen).

Ursache-Muster: Welche Schlüssel sind beteiligt, und warum „falsches Signieren“ nicht hilft

Eine Modulsignatur ist nur dann wirksam, wenn der Kernel den zugehörigen öffentlichen Schlüssel als vertrauenswürdig kennt. Dafür reichen „beliebige“ selbstsignierte Zertifikate nicht; entscheidend ist die Registrierung im passenden Trust-Store. Unter Ubuntu wird hierfür in typischen Secure-Boot-Setups der MOK-Mechanismus genutzt: Ein Administrator enrollt den öffentlichen Teil des Schlüssels per MOK-Manager, shim importiert ihn beim Booten, und der Kernel kann ihn anschließend als vertrauenswürdig heranziehen.

Fehlermuster entstehen insbesondere dann, wenn zwar signiert wurde, aber mit dem falschen Schlüssel, oder wenn der Schlüssel nicht (mehr) im MOK-Store vorhanden ist. Ebenso kritisch: Signatur vorhanden, aber sie deckt die tatsächlich geladene Datei nicht ab (z. B. weil nach dem Signieren noch komprimiert, gestrippt oder neu installiert wurde). Bei Mehrfachkernel-Setups kommt hinzu, dass ein DKMS-Modul für Kernel A korrekt signiert wurde, aber Kernel B eine andere .ko-Instanz ohne passende Signatur lädt.

Warum es oft „plötzlich“ nach Updates passiert: Rebuild, neue Kernel, neue Hashes

Kernel-Updates ändern ABI und Build-Umgebung, weshalb Out-of-Tree-Module neu gebaut werden müssen. DKMS automatisiert genau diesen Teil: Für jeden installierten Kernel wird das Modul in eine kernelversionsspezifische Ablage installiert. Aus Sicht der Signaturprüfung ist das aber jedes Mal eine neue Binärdatei. Eine frühere Signatur ist damit wertlos, und ohne nachgelagerten Signierschritt ist der nächste Boot mit Secure Boot prädestiniert für Ladesperren.

Besonders häufig fällt das in zwei Situationen auf: (1) Systeme, die unbeaufsichtigt aktualisieren, sodass beim nächsten Reboot plötzlich Grafik-/Netzwerk-/Virtualisierungstreiber fehlen; (2) Systeme mit mehreren Kerneln, bei denen nach einem Rollback auf einen älteren Kernel ein anderes, nicht signiertes Modul geladen werden soll. Beides wirkt wie „Treiber kaputt“, ist aber in der Regel eine konsistente Policy-Entscheidung des Kernels.

Praxis: Secure-Boot-Status prüfen, Schlüssel erzeugen, DKMS-Module signieren, MOK enrollen und Update-Fallen vermeiden

1) Secure-Boot-Status und Signatur-Policy verlässlich prüfen

Bevor Schlüssel erzeugt oder DKMS-Hooks angepasst werden, muss klar sein, ob Secure Boot tatsächlich aktiv ist und ob der laufende Kernel das Laden unsignierter Module blockiert. Maßgeblich sind dabei sowohl der UEFI-Status (Firmware) als auch die Kernel-Policy (Lockdown/Modulsignaturen). Zusätzlich sollte identifiziert werden, welches konkrete Modul scheitert (Name, Pfad, DKMS-Paket), damit später die Signaturprüfung nachvollziehbar bleibt.

• Secure Boot (Firmware) prüfen: mokutil --sb-state (erwartete Ausgabe bei aktivem Secure Boot: SecureBoot enabled)
• MOK-Status und vorhandene Enrollments anzeigen: mokutil --list-enrolled
mokutil --list-new (nur unmittelbar nach einer Import-Anforderung relevant)
• Kernel-Lockdown und Signaturzwang abklären: cat /sys/kernel/security/lockdown (z. B. integrity oder confidentiality)
  cat /proc/cmdline (Sonderfälle durch Boot-Parameter erkennen)
• Fehlerbild im Journal verifizieren: journalctl -k -b | grep -iE "Lockdown|module verification|Required key not available|PKCS#7|taint" (typisch sind Meldungen wie module verification failed: signature and/or required key missing oder Required key not available)
• Betroffenes Modul eindeutig benennen: modinfo -n <modulname>
dkms status (liefert, welches DKMS-Paket für welchen Kernel gebaut wurde)

2) Eigenen Modulsignaturschlüssel erzeugen (MOK-Keypair) und sauber ablegen

Für dauerhaft stabilen Betrieb ist ein eigener Schlüssel sinnvoll, der ausschließlich zum Signieren von Drittanbieter-Kernelmodulen genutzt wird. Dieser Schlüssel wird nicht in UEFI-DB/KEK/PK eingetragen, sondern über Shim/MOK verwaltet. Wichtig: Der private Schlüssel bleibt ausschließlich auf dem System (oder in einem Admin-Safe) und darf nicht in Images oder Ticketsysteme geraten. Der öffentliche Teil wird später per MOK enrolled.

• Verzeichnis mit restriktiven Rechten vorbereiten: sudo install -d -m 0700 /root/mok
• Schlüssel und Zertifikat erzeugen (RSA, 2048 Bit, mit Gültigkeit): sudo openssl req -new -x509 -newkey rsa:2048 -keyout /root/mok/MOK.priv -out /root/mok/MOK.pem -nodes -days 3650 -subj "/CN=Local DKMS Module Signing/"
• Öffentlichen Teil in DER für mokutil exportieren: sudo openssl x509 -in /root/mok/MOK.pem -outform DER -out /root/mok/MOK.der
• Dateirechte absichern: sudo chmod 0600 /root/mok/MOK.priv
sudo chmod 0644 /root/mok/MOK.pem /root/mok/MOK.der

Falls ein Hardware- oder Compliance-Setup das Ablegen privater Schlüssel auf dem Host verbietet, sollte die Signatur außerhalb (z. B. in einem administrierten Signierdienst) erfolgen. In diesem Kapitel wird der lokale, in der Praxis häufigste Ansatz beschrieben; bei externem Signieren bleibt der MOK-Enrollment-Teil identisch, nur der Signaturschritt wird verlagert.

3) DKMS-Module korrekt signieren (für den laufenden Kernel und reproduzierbar)

Ein Kernelmodul ist technisch eine .ko-Datei. Signiert wird jeweils das konkrete Artefakt unter /lib/modules/<kernel>/. Nach DKMS-Rebuilds oder Kernelupdates entstehen neue .ko-Dateien; eine frühere Signatur gilt dann nicht mehr. Ubuntu stellt dafür typischerweise das Skript sign-file aus den Kernel-Headern bereit. Damit wird eine PKCS#7-Signatur in das Modul eingebettet.

• sign-file-Skript lokalisieren: command -v kmodsign || true
ls -1 /usr/src/linux-headers-$(uname -r)/scripts/sign-file (je nach Installation kann kmodsign verfügbar sein; sonst sign-file aus den Headers verwenden)
• Betroffene Module identifizieren: modinfo -n <modulname>
find /lib/modules/$(uname -r)/updates -type f \( -name "*.ko" -o -name "*.ko.xz" -o -name "*.ko.zst" \) (DKMS landet häufig unter updates/; komprimierte Module müssen vor dem Signieren dekomprimiert und danach wieder komprimiert werden)
• Ein konkretes Modul signieren (Beispiel mit sign-file): sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 /root/mok/MOK.priv /root/mok/MOK.pem "$(modinfo -n <modulname>)"
• Modul neu laden und Prüfung erzwingen: sudo modprobe -r <modulname>
sudo modprobe <modulname>
journalctl -k -b | tail -n 200 (nach dem Laden sollten keine Verifikationsfehler mehr auftauchen)

Bei NVIDIA- oder VirtualBox-Modulen existieren teils mehrere einzelne Module (z. B. nvidia, nvidia_uvm, vboxdrv, vboxnetflt). Alle betroffenen .ko-Dateien müssen signiert werden. Für Mehrfachkernel (parallel installierte Kernelversionen) ist die Signatur pro Kernel-Tree zu wiederholen, da Pfade und Artefakte kernelversionsgebunden sind.

4) MOK enrollen: Schlüssel importieren, Boot-Enrollment durchführen, Fehlerfälle erkennen

Das Signieren allein genügt nicht. Der Kernel akzeptiert die Signatur nur, wenn die zugehörige Zertifikatskette in einem vertrauenswürdigen Keyring liegt. Unter Ubuntu mit Secure Boot geschieht das bei Drittanbieterschlüsseln typischerweise über MOK: Der öffentliche Schlüssel wird mit mokutil zur Enrollment-Warteschlange hinzugefügt und beim nächsten Neustart im Shim/MOK-Manager bestätigt.

• Öffentlichen Schlüssel zur Enrollment-Warteschlange hinzufügen: sudo mokutil --import /root/mok/MOK.der (es wird ein einmaliges Passwort für den Enrollment-Dialog gesetzt; dieses Passwort wird beim nächsten Boot benötigt)
• Neustart und Enrollment im MOK-Manager: sudo systemctl reboot (im Shim/MOK-Bildschirm: „Enroll MOK“ → „Continue“ → Passwort eingeben → „Reboot“; Navigation erfolgt je nach Firmware per Tastatur)
• Nach dem Boot Enrollment verifizieren: mokutil --list-enrolled | grep -i "Local DKMS Module Signing"
mokutil --sb-state
• Typische Enrollment-Fehler eingrenzen: mokutil --list-new (wenn weiterhin „pending“, wurde der MOK-Dialog nicht abgeschlossen)
  journalctl -k -b | grep -i mok (Hinweise auf Shim/MOK-Interaktionen)

Wenn der MOK-Manager beim Neustart nicht erscheint, sind häufig Fast-Boot-/Ultra-Fast-Boot-Firmwareoptionen, deaktiviertes Shim (z. B. bei alternativen Bootloadern) oder eine nicht genutzte EFI-Bootkette die Ursache. Ebenso kann Remote-/Headless-Betrieb scheitern, wenn keine Konsole für den Shim-Dialog verfügbar ist. In solchen Umgebungen sollte der Enrollment-Vorgang in ein geplantes Wartungsfenster mit Out-of-Band-Konsole (IPMI/iDRAC/iLO) gelegt werden.

5) Update-Fallen vermeiden: Automatisches DKMS-Rebuild und Signieren dauerhaft verdrahten

Der häufigste Grund für „lief gestern, heute nicht“ ist ein Kernel- oder DKMS-Update: DKMS baut Module neu, doch die neuen Artefakte sind unsigniert. Ziel ist daher ein stabiler Prozess, der nach jedem DKMS-Build automatisch signiert und damit ohne manuelle Nacharbeit lädt. Dafür eignen sich DKMS-Post-Build-Mechanismen oder Paket-Hooks. Welche Variante verfügbar ist, hängt vom DKMS-Paket und der lokalen Policy ab; der Kern bleibt: Nach jedem Build müssen alle erzeugten .ko-Dateien mit dem MOK-Schlüssel signiert werden.

• Vorhandene Signiermechanik prüfen (Ubuntu-Tooling): dpkg -l | grep -E "shim-signed|mokutil|dkms"
grep -R "sign-file" -n /etc/dkms /usr/lib/dkms 2>/dev/null (zeigt, ob bereits Hooks existieren, die Module signieren)
• Nach DKMS-Rebuild signierte Module stichprobenartig validieren: sudo dkms autoinstall
journalctl -k -b | grep -iE "module verification failed|Required key not available" (nach dem nächsten Boot sollten keine Verifikationsfehler mehr auftreten)
• Mehrfachkernel korrekt behandeln: ls -1 /lib/modules/
dkms status (für jeden installierten Kernel, der genutzt werden kann, müssen DKMS-Module gebaut und signiert vorliegen; sonst drohen Überraschungen nach Boot in einen anderen Kernel)
• Unattended Upgrades und Reboots einkalkulieren: grep -R "Unattended-Upgrade" -n /etc/apt/apt.conf.d/
grep -R "Automatic-Reboot" -n /etc/apt/apt.conf.d/ (automatische Reboots nach Kernelupdates können Systeme in einen Zustand bringen, in dem Module fehlen; Signier-Automation ist dann nicht optional)
• Schlüsselverwaltung dokumentieren und absichern: sha256sum /root/mok/MOK.der
openssl x509 -in /root/mok/MOK.pem -noout -fingerprint -sha256 (Fingerprints in der Betriebsdokumentation festhalten; private Schlüssel geschützt sichern; bei Schlüsselrotation: neuen MOK enrollen und alte Einträge gezielt entfernen)

Auf Systemen mit TPM-gebundener Entsperrung (z. B. LUKS mit TPM2) können Secure-Boot-/Bootkettenänderungen zusätzliche Recovery-Eingaben auslösen, weil sich Messwerte ändern. Ein MOK-Enrollment verändert zwar primär die Shim/MOK-Daten, kann aber je nach Plattform/TPM-Policy dennoch Auswirkungen haben. Deshalb sollten vor Enrollment und vor Bootloader-/Shim-Updates Wiederherstellungsmethoden (Recovery-Key, Break-Glass-Passphrase) geprüft und für Remote-Systeme bereitgelegt werden.