Given Rocky Linux shall be 100% bug-for-bug compatible with Red Hat Enterprise Linux, signing the “UEFI shim loader” for UEFI Secure Boot will also become a topic.
Microsoft provides a long list of UEFI Signing Requirements, which likely require some additional work and have external dependencies, thus they should be started early:
EV certificate (as per CA/B forum, this requires a registered verifiable legal entity, e.g. company, foundation, natural person if they’re a registered business) and an Azure Active Directory (AAD) account.
Shims must be reviewed first by the “shim review board” before they can be signed.
Code signing keys must be backed up, stored, and recovered only by personnel in trusted roles, using at least dual-factor authorization in a physically secured environment.
Private part of the code signing key must be protected with a hardware cryptography module, e.g. HSMs, smart cards, smart-card-like USB tokens and TPMs.
Operating environment must achieve a level of security at least equal to FIPS 140-2 Level 2.
Really the only thing there that’s a pain point for infrastucture is the FIPS requirement, and that would need some firming up around what part of the environment is in scope for that requirement.
We have already received a generous offer for certificates which may be possible to use for signing… which is great. Thanks for bringing this up. Not sure of the implications just yet, but good to be aware of.
I think we’re gonna have to do this anyway, at the very least because debranding will require us to remove the RHEL signing key. And yep @neil, CentOS definitely has their own key.
I’m not sure if CentOS meets all of those requirements, esp FIPS, but I know for a fact that CentOS is signed and will boot under UEFI Secure Boot on Azure.
I had to confirm this earlier this year… my notes indicate I tested this on July 8, 2020.