This is not a bug, it is a feature.
As Anthony Wong says, when you install a DKMS package you are compiling the package yourself, thus, Canonical cannot sign the module for you.
However, you can definitely use Secure Boot, however this is exactly the use case where Secure Boot is trying to protect you from yourself because it cannot know whether you trust a module or don't.
By default, there is a Platform Key (PK) on your UEFI machine, which is the ultimately trusted Certificate Authority for loading code in your processor.
GRUB, or shim, or other boot mechanisms can be digitally signed by a KEK which is trusted by the root CA (PK), and thus your computer can, without any configuration, boot software like Ubuntu Live USB/DVDs.
On Ubuntu 16.04 the kernel is built with CONFIG_MODULE_SIG_FORCE=1, which means that the kernel will enforce modules to be signed by a trusted key in the platform.
Take into consideration that the UEFI platform by default contains a PK that you do not have any control over, and thus you cannot sign binaries with a key recognized by your own machine.
Some people bash and rant against that, but there is really no better way (from a security standpoint) than it being yourself who enrolls the new key you want.
If your boot system uses shim, you can use something called a Machine Owner's Key database, and enroll your key as a MOK (You can do that with mokutil). If you don't, you can also enroll your key in the UEFI database as a signing key.
After you enroll your key, you can sign your DKMS-built package with your MOK (there should be a perl script at /usr/src/kernels/$(uname -r)/scripts/sign-file
), and after it is signed, you can load it into the kernel.
Granted, someone should make more visual instructions on this, and probably even make a wizard or a better DKMS standard to allow keys to be taken into consideration, but this is what we have as of now.
You can refer to this explanation on how to sign your own kernel modules: https://askubuntu.com/a/768310/12049
UEFI Secure Boot protects your boot loader from being tampered with by using a combination of CA keys and signatures in boot files. Microsoft for example has signed boot loaders for which CA keys are already present in UEFI firmware of most PC's already.
This only protects the very early core of the loader and nothing afterwards. For example initrd(initramfs) is not protected, or anything after (GRUB, kernel, Modules, Drivers, anything in userspace, etc).
3rd party software that you installed MAY have included certain low-level PCI or RAID code required for the boot loader, which is why you need to create a password, which will create a key in the UEFI firmware's space. After modifications, if the system notices something different at boot time, the BIOS will stop at POST and ask for the same password you entered during installation to prove that you are the one who installed the software. This method insures that a user physically sitting at the computer is entering this password as confirmation since no software can be loaded at BIOS POST time to fake this.
For most user systems, secure boot does little to protect you. It does not prevent viruses or malware, or installation of those. All it does it prevent low-level bootloader tampering, which is usually prevented by basic antivirus or OS security anyways. In my opinion, and according to most documentation out there, it can be safely disabled.
Best Answer
sudo mokutil --enable-validation
After restart Mok managment will pop up. There will be an option where you can enable secure boot (just like you disabled after installing Ubuntu).
Manpage of mokutil: http://manpages.ubuntu.com/manpages/xenial/man1/mokutil.1.html