I have secure boot enabled on my Fedora install, and I also compile my own kernel modules. Therefore, I use a Machine Owner Key (MOK) to sign my own kernel modules. This has been working fine for me since Fedora 34, and throughout the Fedora 35 upgrade as well.
However, since the dnf upgrade from dkms-3.0.3-1.fc35.noarch to dkms-3.0.4-1.fc35.noarch, my custom kernel module (GitHub - dwagelaar/it87) is no longer signed properly: the kernel won’t load the module because of an untrusted signature. Downgrading dkms to the original dkms-2.8.6-1.fc35.noarch that came on release fixes the problem: the module is properly signed and loaded (when rebuilt).
Have not seen the problem, but you should be able to solve it by generating a new key with the latest mokutil package and saving it into the bios for future use. I suspect something was updated to not allow use of the older key generation encryption schema so the old key is no longer valid.
Going to dkms-3.0.4, the kernel module signing logic is implemented in some other script than /etc/dkms/sign_helper.sh. Looking at the code, it appears the MOK keypair must be located in /var/lib/dkms. There was already a default (generated on RPM install) keypair there, which obviously wasn’t enrolled in my UEFI. I moved the default keypair out of the way, and put my own keypair in place. After rebuilding the kernel module everything worked again!