Re: Secure-Boot auf Leap 16.0 - wie aktivieren

Werner Franke <[email protected]> Fri, 17 Jul 2026 10:02:58 +0200
Newsgroups gmane.linux.suse.general.german
Organization Privat
Message-ID <[email protected]>
   [...]
>>
>>
>> Das Verhalten sieht für mich deutlich so aus, als ob die 2023er MS Zertifikate hier fehlen.
>>
>>
> 
> Hallo Ulf,
> 
> ein UEFI-BIOS Update brachte erst einmal keine Besserung.
> Ob es noch weitere Updates gibt, habe ich mangels Zeit noch nicht herausgefunden.
> Die ASUS Seite ist da etwas 'aufgeräumt'. Habe beispielsweise keine Infos gefunden, was in den
> BIOS Versionen geändert wurde.
> (Vielleicht nur noch nicht überall hingeklickt)
> 
> Muss nun mal schauen, was das Kommando mokutil jetzt liefert.
> Bis jetzt waren es
> - Microsoft Corporation KEK CA 2011
> - Microsoft RSA Devices Root CA 2021
> 
Hallo zusammen,

nachdem ich hier nicht weiter komme, habe ich mal https://chatgpt.com/ gefragt
und folgende Antwort bekommen:
--------------------------------------
Wenn Secure Boot unter Linux nicht funktioniert, musst du zuerst herausfinden, an welcher Stelle
die Kette scheitert: Firmware, Bootloader, Signaturen oder Kernel.

Gehe diese Schritte durch:

Prüfen, ob Secure Boot überhaupt aktiviert ist

   mokutil --sb-state

Mögliche Ausgaben:

     SecureBoot enabled → Secure Boot ist aktiv.
     SecureBoot disabled → Im UEFI deaktiviert.

Alternativ:

   cat /sys/firmware/efi/efivars/SecureBoot-*

Der letzte Byte-Wert 01 bedeutet aktiviert.
Prüfen, ob das System im UEFI-Modus gestartet wurde

test -d /sys/firmware/efi && echo UEFI || echo BIOS

Secure Boot funktioniert nur im UEFI-Modus.

Kernelmeldungen ansehen

   dmesg | grep -i secure
   dmesg | grep -i efi
   dmesg | grep -i lockdown
   dmesg | grep -i mok

Interessante Meldungen sind z. B.:

     Secure boot enabled
     Kernel is locked down
     EFI variables are not supported

Bootloader überprüfen
Wenn du GRUB verwendest:

   bootctl status

oder

   efibootmgr -v

Prüfe, ob tatsächlich der erwartete EFI-Bootloader gestartet wird.

Signaturen prüfen
Für den Kernel:

   sbverify --list /boot/vmlinuz-$(uname -r)

Falls sbverify fehlt, ist es meist im Paket sbsigntools.

MOK-Schlüssel prüfen

   mokutil --list-enrolled

Damit siehst du, welche Machine Owner Keys installiert sind.
Journal durchsuchen

     journalctl -b | grep -Ei 'secure|shim|mok|lockdown|efi'

Häufige Ursachen

     Secure Boot ist im UEFI ausgeschaltet.
     Das System wurde im Legacy-/CSM-Modus gestartet.
     Der Kernel oder ein Kernelmodul ist nicht signiert.
     Der verwendete Bootloader (shim, grubx64.efi, systemd-boot) ist nicht vertrauenswürdig signiert.
     Nach einem BIOS-/UEFI-Update wurden Schlüssel zurückgesetzt.
     Eigene Kernel oder NVIDIA-/VirtualBox-Module sind nicht mit einem MOK signiert.

Wenn du den genauen Fehler finden möchtest
Poste bitte die Ausgaben von:

   mokutil --sb-state
   bootctl status
   efibootmgr -v
   dmesg | grep -Ei 'secure|efi|mok|lockdown'
   journalctl -b | grep -Ei 'secure|shim|mok'

sowie:

   cat /etc/os-release

Dann kann ich meist ziemlich genau eingrenzen, warum
Secure Boot auf deinem System nicht funktioniert.
------------------------------------------

Ich habe alle Kommandos angewendet und die Ergebnisse in Files gespeichert,
um sie später auswerten zu können.
Fehlen noch Daten ?
Leider liefern einige Kommandos einige für mich kryptische Daten, mit denen
ich nicht wirklich etwas anfangen kann.
Oben steht, dass ich die Signaturen prüfen soll. Nur was in den Files ist die
jeweilige Signatur und mit welcher Signatur muss ich das vergleichen ?
Folgende ??

root@idefix: efibootmgr -v
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0003,0006,0007,0008,0009
Boot0001* opensuse-secureboot	HD(1,GPT,2807ff03-54c5-4006-82b7-043e1b8050c3,0x800,0x100000)/File(\EFI\OPENSUSE\SHIM.EFI)
       dp: 04 01 2a 00 01 00 00 00 00 08 00 00 00 00 00 00 00 00 10 00 00 00 00 00 03 ff 07 28 c5 54 06 40 82 b7 04 3e 1b 80 50 c3 02 02 / 04 04 32 00 5c 00 45 00 46 00 49 00 5c 00 4f 00 50 00 45 00 4e 00 53 00 55 00 53 00 45 00 5c 00 53 00 48 00 49 00 4d 00 2e 00 45 00 46 00 49 00 00 00 / 7f ff 04 00
Boot0003* UEFI: PXE IPv4 Realtek PCIe GBE Family Controller	PciRoot(0x0)/Pci(0x2,0x1)/Pci(0x0,0x0)/MAC(a0ad9f568ce6,0)/IPv4(0.0.0.00.0.0.0,0,0)0000424f
       dp: 02 01 0c 00 d0 41 03 0a 00 00 00 00 / 01 01 06 00 01 02 / 01 01 06 00 00 00 / 03 0b 25 00 a0 ad 9f 56 8c e6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 / 03 0c 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 / 7f ff 04 00
     data: 00 00 42 4f
Boot0006* UEFI: PXE IP4 Network Card	PciRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/MAC(00e04c02b203,0)/Wi-Fi(00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00)/IPv4(0.0.0.00.0.0.0,0,0)0000424f
       dp: 02 01 0c 00 d0 41 03 0a 00 00 00 00 / 01 01 06 00 02 02 / 01 01 06 00 00 00 / 03 0b 25 00 00 e0 4c 02 b2 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 / 03 1c 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 / 03 0c 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 / 7f ff 04 00
     data: 00 00 42 4f
Boot0007* UEFI:CD/DVD Drive	BBS(129,,0x0)
       dp: 05 01 09 00 81 00 00 00 00 / 7f ff 04 00
Boot0008* UEFI:Removable Device	BBS(130,,0x0)
       dp: 05 01 09 00 82 00 00 00 00 / 7f ff 04 00
Boot0009* UEFI:Network Device	BBS(131,,0x0)
       dp: 05 01 09 00 83 00 00 00 00 / 7f ff 04 00


root@idefix: sbverify --list /boot/vmlinuz-$(uname -r)
signature 1
image signature issuers:
  - /CN=SUSE Linux Enterprise Secure Boot CA/C=DE/L=Nuremberg/O=SUSE Linux Products GmbH/OU=Build Team/[email protected]
image signature certificates:
  - subject: /CN=ALP Secure Boot Signkey/C=DE/L=Nuremberg/O=SUSE Linux Products GmbH/OU=Build Team/[email protected]
    issuer:  /CN=SUSE Linux Enterprise Secure Boot CA/C=DE/L=Nuremberg/O=SUSE Linux Products GmbH/OU=Build Team/[email protected]


root@idefix: mokutil --sb-state
[key 1]
Owner: 605dab50-e046-4300-abb6-3dd810dd8b23
SHA1 Fingerprint: bc:a4:e3:8e:d1:84:2b:c8:6f:f7:6d:4d:a7:49:51:f1:62:88:59:f8
Certificate:
     Data:
         Version: 3 (0x2)
         Serial Number: 1 (0x1)
         Signature Algorithm: sha256WithRSAEncryption
         Issuer: CN=SUSE Linux Enterprise Secure Boot CA, C=DE, L=Nuremberg, O=SUSE Linux Products GmbH, OU=Build Team/[email protected]
         Validity
             Not Before: Apr 18 14:33:41 2013 GMT
             Not After : Mar 14 14:33:41 2035 GMT
         Subject: CN=SUSE Linux Enterprise Secure Boot CA, C=DE, L=Nuremberg, O=SUSE Linux Products GmbH, OU=Build Team/[email protected]
         Subject Public Key Info:
             Public Key Algorithm: rsaEncryption
                 Public-Key: (2048 bit)
                 Modulus:
                     00:cd:fd:ab:d7:2a:84:f8:81:c3:36:35:50:35:2c:
                     ...
                 Exponent: 65537 (0x10001)
         X509v3 extensions:
             X509v3 Basic Constraints: critical
                 CA:TRUE
             X509v3 Subject Key Identifier:
                 EC:AB:0D:42:C4:56:CF:77:04:36:B9:73:99:38:62:96:5E:87:26:2F
             X509v3 Authority Key Identifier:
                 keyid:EC:AB:0D:42:C4:56:CF:77:04:36:B9:73:99:38:62:96:5E:87:26:2F
                 DirName:/CN=SUSE Linux Enterprise Secure Boot CA/C=DE/L=Nuremberg/O=SUSE Linux Products GmbH/OU=Build Team/[email protected]
                 serial:01
             X509v3 Key Usage: critical
                 Digital Signature, Certificate Sign, CRL Sign
     Signature Algorithm: sha256WithRSAEncryption
     Signature Value:
         12:be:2c:85:85:5a:94:59:cd:49:51:08:17:c1:d9:63:27:29:
         ...

Das Thema ist für mich nicht wirklich entscheidend wichtig. ich kann auch weiterhin
mit deaktiviertem Secure-Boot leben, vor allem auch weil ich Suspend-To-Disk auf jeden Fall
weiter nutzen will.
Aber ich würde das Thema doch verstehen wollen.

viele Grüße
   Werner