Secure Boot et PXE: l'oeuf, la poule et quatre façons d'en sortir

Provisionner un parc de machines Windows vierges par le réseau, en PXE, avec Secure Boot actif et sans jamais le désactiver, se heurte à un paradoxe qu’on ne voit qu’une fois le nez dessus. Pour booter en PXE, le binaire d’amorçage doit être signé ou approuvé par le firmware. Pour signer ou enroller une clé, il faut booter sur un OS. Sans OS préexistant sur la machine, on ne peut donc ni booter ni enroller et c’est exactement la situation d’un poste neuf qu’on veut justement installer par le réseau. Voici la chaîne de confiance telle qu’elle doit tenir, puis les quatre sorties réelles.

La chaîne de confiance et pourquoi snponly

Firmware UEFI (CA Microsoft enrôlée nativement par l'OEM)
  └─ snponly.efi            ← doit être trusted
       └─ wimboot           ← signé Microsoft UEFI CA
            └─ boot.wim (WinPE)
                 └─ Windows Setup

Le choix de snponly.efi plutôt qu’ipxe.efi n’est pas un détail. ipxe.efi embarque ses propres drivers réseau, des blobs binaires qui ne sont pas dans la chaîne de confiance Secure Boot, donc un firmware strict les rejette ou se comporte de façon indéfinie. snponly.efi délègue entièrement le réseau au firmware via le Simple Network Protocol, ne charge aucun code supplémentaire et garde la chaîne intacte. wimboot et les WIM, eux, ne sont pas des binaires EFI et ne passent pas par la validation Secure Boot, ce qui simplifie d’autant.

Option A, enroller une clé par le BMC

Les serveurs avec BMC, iDRAC, iLO ou Redfish standard, permettent d’enroller une clé dans la base Secure Boot sans OS, depuis le réseau. On génère un certificat, on signe son binaire iPXE custom et on pousse le certificat dans la base UEFI par l’API Redfish, piloté par Ansible.

# RSA-2048 obligatoire, shim gèle avec du 4096
openssl req -newkey rsa:2048 -nodes -keyout MOK.key \
  -new -x509 -sha256 -days 3650 -subj "/CN=Foreman PXE MOK/" -out MOK.crt
sbsign --key MOK.key --cert MOK.crt --output snponly.efi.signed snponly.efi

L’enrollment Redfish lui-même varie d’un constructeur à l’autre, donc à tester sur un exemplaire avant de généraliser, mais le principe est propre et sans intervention humaine et il passe bien à l’échelle sur un parc serveur homogène.

Option B, faire signer son binaire par Microsoft

Microsoft accepte les soumissions de binaires EFI tiers et iPXE a été accepté par cette voie après revue de sécurité. On peut soumettre sa propre build. C’est propre, sans intervention, mais le processus prend des semaines, exige une revue externe et fige le script embarqué dans le binaire signé, donc toute modification demande une nouvelle soumission. Adapté à une infrastructure long terme avec un binaire stable, pas à qui veut itérer.

Option C, réutiliser des binaires déjà signés Microsoft

C’est l’approche la plus directe si l’on dispose d’une suite d’imaging commerciale qui livre des ipxe.efi et snponly.efi déjà signés Microsoft UEFI CA. Ces binaires sont des iPXE standards et leur customisation passe par le serveur DHCP, pas par un script figé dans le binaire. La technique est le “breaking the loop” classique d’iPXE: le DHCP détecte si le client est déjà un iPXE, via la user-class et lui renvoie alors l’URL de son script au lieu du binaire.

# dhcpd.conf
if exists user-class and option user-class = "iPXE" {
    filename "http://foreman.example/unattended/iPXE?bootstrap=1";
} elsif option client-arch = 00:07 {        # UEFI x86_64
    filename "boot/snponly.efi";             # binaire signé Microsoft
} elsif option client-arch = 00:00 {         # legacy BIOS
    filename "boot/undionly.kpxe";
}

Le flux complet enchaîne alors sans aucun MOK: la machine demande le binaire signé, qui est accepté sans enrollment, iPXE refait un DHCP avec la user-class, récupère le script, charge wimboot signé et boot.wim en HTTP et WinPE démarre, Secure Boot actif de bout en bout. Servir wimboot et les WIM en HTTP et non en TFTP, parce que le TFTP est trop lent pour des fichiers de plusieurs centaines de méga-octets. C’est l’option que je recommande quand elle est disponible: zéro enrollment, zéro modification des machines, zéro dépendance à un OS préexistant.

Un point de vigilance sur les WinPE: les machines avec la CA Windows UEFI 2023 enrôlée, matériel récent ou Windows Update tardif, peuvent rejeter l’ancien bootmgfw.efi d’un WinPE généré avec un ADK trop ancien. wimboot récent gère la sélection automatiquement; avec un ADK ancien, il faut patcher le WIM à la main.

Option D, l’enrollment MOK par un technicien

Pour les parcs sans BMC Redfish et sans binaire signé disponible ou pour les workstations hors des autres options, un technicien intervient une fois par machine, deux à trois minutes et la clé est ensuite persistante dans le firmware. La voie la plus simple n’est même pas Linux: la plupart des firmwares UEFI modernes intègrent une gestion des clés Secure Boot dans le setup, donc un MOK.cer sur une clé FAT32 et une navigation dans le menu “Key Management” suffisent, Secure Boot n’étant jamais désactivé, même temporairement. Les intitulés varient d’un constructeur à l’autre et quand l’option n’apparaît pas c’est que le firmware est en mode standard qu’il faut d’abord basculer en custom, sans que cela n’efface les clés Microsoft déjà présentes. Pour le suivi, un playbook qui liste les MOK enrôlées permet de repérer les machines encore manquantes.

Choisissez votre poison

Le paradoxe oeuf-poule de Secure Boot et PXE a l’air d’un mur et il invite à la pire réponse, désactiver Secure Boot “le temps de l’install”, qui est précisément ce qu’on ne doit pas faire sur un parc. Les quatre sorties diffèrent surtout par ce qu’on possède déjà: un parc serveur à BMC va vers le Redfish, un parc équipé d’une suite d’imaging signée va vers le détournement DHCP, un besoin long terme et stable vers la soumission Microsoft et le reste vers l’enrollment manuel. Le fil commun, c’est que Secure Boot reste actif de bout en bout dans les trois premières et qu’on n’enrôle que ce qu’on a signé soi-même quand on ne peut pas faire autrement. Désactiver Secure Boot pour installer une machine qu’on veut sécurisée est une contradiction dans les termes et chacune de ces options existe précisément pour ne pas avoir à la commettre.