Secure Boot — development certificate enrollment
Outcome: Boot the development image while leaving Secure Boot enabled and the existing platform and Microsoft keys intact. The certificate is a development signing key, not a production or third-party certification. The verified Secure Boot boot/refusal sequence was run in a virtual machine; physical Secure Boot qualification is still open.
Never select
Replace,Update,Clear,Delete allorRestore Factory Keysas a substitute forAppend. Those operations can remove existing trusted certificates, disrupt another installed OS or create a recovery event.
Before touching firmware
Download, check and flash the newest
LexiSuite-<id>-secureboot-dev.img.xzimage. It carriesEFI/LEXIOS/OWNER.DERon theLEXIOSvolume.If the PC has BitLocker or similar disk encryption, secure the recovery key first. Modifying firmware Secure Boot policy can trigger recovery at the next start. On Windows an administrator can temporarily suspend BitLocker for one restart using
manage-bde -protectors -disable C: -RebootCount 1; do not proceed without a recovery route.Identify the expected certificate by its display name
CN=LexiSuite Development Secure Bootand SHA-256 fingerprint:6C:EF:94:48:63:C1:F2:31:AA:CF:59:DF:9C:47:13:B8:17:CA:B8:0D:91:FB:E7:58:E2:81:C9:7B:7E:9D:59:44Use the fingerprint as a cross-check against the release instructions. It is not an independent trust anchor if the release source is compromised.
Enroll once (generic UEFI sequence)
- Insert the flashed USB drive, reboot and enter the machine's UEFI setup, not the one-time boot menu.
- Go to Security or Boot → Secure Boot → Key Management (names vary by firmware version). Keep Secure Boot Enabled. Some implementations require Custom or Expert mode solely to enable key editing.
- Open the Authorized Signatures (
db) database. Choose Append / Add certificate, not overwrite or delete. - Browse the
LEXIOSFAT volume toEFI/LEXIOS/OWNER.DER. Choose Public Key Certificate if prompted. When the firmware accepts only EFI signature lists, useLexiSuite-Development-SecureBoot.eslcopied onto FAT32 storage, as provided with the release. - Check the added LexiSuite development certificate appears alongside, not instead of, existing trusted keys. Save without restoring factory defaults.
- Re-enter the firmware menu to verify the appended entry
survived saving. Switch back to Standard mode only if
doing so keeps the new
dbentry.
Firmware navigation by vendor family
Paths differ by generation; these are navigation hints, not a guarantee that the firmware permits certificate append:
| Firmware/vendor | Where to look | Special caution |
|---|---|---|
| MSI / AMI Click BIOS 5 (MAG X570 TOMAHAWK WIFI, documented) | Delete → F7 Advanced →
Settings → Advanced → Windows
OS Configuration → Secure Boot →
Custom → Key Management →
Authorized Signatures (db) →
Append |
F10 saves; avoid Update,
Delete and factory-key restore. |
| ASUS | Advanced UEFI → Boot / Secure Boot → Key Management | Some menus expose only key restoration; do not replace all keys. |
| Gigabyte / AORUS | UEFI → Boot / Secure Boot → Key Management | Verify that an append operation is actually available. |
| ASRock | Advanced UEFI → Security / Secure Boot → Key Management | Stop if editing can only erase or replace existing keys. |
| Dell | UEFI setup → Secure Boot and Expert Key Management (if offered) | Managed PCs may lock key editing; consult device administrator. |
| Lenovo / HP | UEFI setup → Security / Secure Boot or Secure Boot Configuration | Many versions do not offer owner db append in the UI;
do not assume support. |
Only the MSI path above has a device-specific walkthrough in the project context. Other entries deliberately stop at generic menus: if there is no supported append operation, do not improvise. Use a supported computer or the image with Secure Boot disabled according to your device policy, understanding that disabled Secure Boot removes boot-signature verification.
Expected boot and proof
- Choose 1 LexiKernel or 2 LexiOS on Linux 7.4 (7.4-rc1). Before enrollment, the unknown development signature should be rejected.
- On the first LexiKernel Secure Boot, the signed loader creates its
anti-rollback variable from the verified owner-signed file and logs
LK:UEFI:ROLLBACK-FIRST-CREATION:VERIFIED:V1; subsequent starts reuse it. No operator command is needed. - The console status should include
DEVELOPMENT-signed image; NOT production qualifiedandSecure Boot: ON; firmware verified boot chain (dev certificate in db). This is a reported state, not a substitute for independently checking firmware configuration. - Continue First Boot on a trusted network. The presence of a setup-code field depends on configuration; it is not present by default.
The recorded virtual-machine qualification included successful boots on both entries, repeat rollback-variable creation/use, refusal without enrollment, refusal after rollback-file tampering and refusal after kernel tampering. Do not generalize that to every physical motherboard.
If your PC does not verify the stick
Some PCs run the stick without checking it, or have Secure Boot off. A development image then shows a notice before LexiKernel starts: Secure Boot is not verifying this boot. Press Y to start LexiKernel anyway as an unverified development boot; press N, or wait two minutes, to stop. An unverified boot says so: LexiKernel's status page and the LexiOS console show Secure Boot: NOT VERIFIED by this PC's firmware. To get a verified boot, enroll the certificate as described above. Production images never start unverified.
Undo one enrollment
Return to Key Management → Authorized Signatures
(db) and select only the
LexiSuite development certificate to delete. Verify other certificates
remain and save. Removing it means the same development-signed stick
should no longer boot with Secure Boot on. Do not use reset-to-factory
as a routine removal procedure; that may affect unrelated owner keys.
Obtain your disk-encryption recovery key before changes.
Limitations and controls
| Firmware control | Effect / consequence |
|---|---|
| Secure Boot: Enabled | Requires the boot chain to be trusted by firmware policy. |
| Secure Boot Mode: Custom | On some firmware, permits owner certificate editing; may change key-management semantics. |
Authorized Signatures (db) →
Append |
Adds the development certificate while retaining other allowed signatures. |
| Replace / Clear / Restore | Potentially removes existing trust entries; do not use for this guide. |
| Standard mode | Re-enable only if the appended certificate persists unchanged. |
| Delete LexiSuite certificate | Revokes trust in that development key, without intentionally removing other entries. |
The certificate has a 30-day stated validity; the supplied procedure notes firmware ignores that date. A future build signed by a different key must be enrolled separately. See Security, Troubleshooting and Release Notes.