FOG Server 1.6 Fails to install Secureboot certificates with Custom CA and Secure Boot keys?

[Shuttleu]

Hi, hope I can get some help with a problem I’ve come across and want to get some advice before continuing too far down a rabbit hole.

We (the company I work for) run a FOG Server which we’ve used for the last year or so on 1.5, managing roughly 100 laptops/desktops.
We have a root CA which we use for all internal systems and so the certificate is pushed out via GPO to be installed in the Trusted Root Certification Store.
We also have custom Secure Boot keys to ensure we can boot the devices via network without having to disable Secure Boot.

When installing 1.5, we had the web server set up to use a certificate that we generated for FOG and manually signed the efi images with our Secure Boot keys.

Moving over to 1.6, we want to clean this up and let FOG handle all the signing on our behalf, so decided it would be best to start afresh.
Seeing as we’re going to be installing the fog agent (which removes the old fog client), server pinning wont be an issue, so long as it can use the same Secure Boot DB certificate for signing and server a web server certificate that ends in our internal CA.

We generated a new intermediate CA certificate for FOG signed by our trusted Root CA, spun up a new VM and installed a fresh copy of FOG 1.6 with the following commands

installfog.sh --install-mode embed-ca --https-redirect --web-ca-cert interca.crt --web-ca-key interca.key --web-ca-root ca.pem --internal-domain fogserver.local --secure-boot-key DB.key --secure-boot-cert DB.cert

This looks like it worked and our web interface was indeed signed by a certificate that ends in our Root CA.
Checking the Secure Boot images with sbverify also confirms that the efi files are signed correctly too.

$ sbverify --cert DB.crt /tftpboot/secureboot/ipxe-shimx64.efi
warning: data remaining[920352 vs 1048424]: gaps between PE/COFF sections?
Signature verification OK

However with this setup, ipxe refuses to load boot.php because aparently it is not built with my CA? See Github issue

This issue and its resulting fix seems to recommend pointing towards snponly.efi, which also seems to be signed correctly and boots fine.

$ sbverify --cert /home/administrator/fogcerts/DB.crt ipxe.efi
Signature verification OK

Great! lets move onto enrolling Secure Boot keys!

First we put a device in setup mode, booted FOG and choose to “Enroll Secure Boot Key (Unattended)”, but we get an error message stating that “Automatic Secure Boot enrollment failed”

Looking into the UEFI interface, the system is now in custom mode rather than setup, so it seems that the keys are indeed enrolled. Running the enrolment again says that the certificate is already trusted, so it looks like it has indeed worked after all.

To be on the safe side, we decided to try “Enroll Secure Boot Key (MOK attended setup)”. We get the blue screen, choose to install MOK.der and then reboot, but we don’t get the screen to confirm a pin code to finish enrolling the keys into MOK.

We’ve basically answered our own question about whether the keys are actually getting enrolled into the DB, it’s the messages we’re getting which are throwing us off. The Enrolment says it has failed, why is this?

We want to make sure we have all the answers and to ensure there isn’t going to be issues further down the line if we continue with the setup we currently have.

[Tom Elliott]

@Shuttleu Your machine is enrolled correctly. The “failed” message is wrong for your case, and the missing PIN screen is expected.

Why “Automatic Secure Boot enrollment failed” appears. The task writes db, then KEK, then PK. A PK write in Setup Mode takes the machine out of Setup Mode. The task then reads the SetupMode variable to confirm this. On your firmware, that check did not see the change before the reboot. Your evidence shows all three writes landed: the firmware is now in Custom Mode, and the second run found the certificate already in db. The text “still in Setup Mode” in that message is also wrong when the PK write already happened. We will fix the check and the message in FOS.

Why there is no PIN screen. The attended item opens MokManager directly. “Enroll key from disk” enrolls MOK.der at the Yes/No prompt. It does not stage a request, so no PIN screen comes after the reboot. The PIN screen is for a request that the FOS task stages on a machine with a vendor PK. Also, MOK only matters when the client boots through shim. You boot snponly.efi, which is signed with your DB key, so db trust is the trust that counts. You do not need the MOK step on these machines.

One thing to know before you roll this out. The unattended task enrolls this FOG server’s own PK and KEK, with Microsoft’s KEK and db entries kept beside them. Your machine’s platform key is now the FOG server’s key, not a vendor key or one of your own. To change db or KEK later from the OS, you need an update signed by the FOG server’s KEK or PK.

Could you tell us the make, model and firmware version of this machine? That lets us confirm the firmware behavior and test the fix against it.

On #2064: the fix (#2065) is on dev-branch. With it, a FOG-managed DHCP config hands out snponly.efi when the installer rebuilds iPXE with your CA. You already did this by hand, so nothing changes for you.