LexiSuite Docs

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 all or Restore Factory Keys as a substitute for Append. Those operations can remove existing trusted certificates, disrupt another installed OS or create a recovery event.

Before touching firmware

  1. Download, check and flash the newest LexiSuite-<id>-secureboot-dev.img.xz image. It carries EFI/LEXIOS/OWNER.DER on the LEXIOS volume.

  2. 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.

  3. Identify the expected certificate by its display name CN=LexiSuite Development Secure Boot and 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:44

    Use 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)

  1. Insert the flashed USB drive, reboot and enter the machine's UEFI setup, not the one-time boot menu.
  2. 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.
  3. Open the Authorized Signatures (db) database. Choose Append / Add certificate, not overwrite or delete.
  4. Browse the LEXIOS FAT volume to EFI/LEXIOS/OWNER.DER. Choose Public Key Certificate if prompted. When the firmware accepts only EFI signature lists, use LexiSuite-Development-SecureBoot.esl copied onto FAT32 storage, as provided with the release.
  5. Check the added LexiSuite development certificate appears alongside, not instead of, existing trusted keys. Save without restoring factory defaults.
  6. Re-enter the firmware menu to verify the appended entry survived saving. Switch back to Standard mode only if doing so keeps the new db entry.

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

  1. Choose 1 LexiKernel or 2 LexiOS on Linux 7.4 (7.4-rc1). Before enrollment, the unknown development signature should be rejected.
  2. 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.
  3. The console status should include DEVELOPMENT-signed image; NOT production qualified and Secure Boot: ON; firmware verified boot chain (dev certificate in db). This is a reported state, not a substitute for independently checking firmware configuration.
  4. 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.