If you’ve ever tried compiling a Linux kernel from source—whether to add custom system calls, test new features, or optimize for specific hardware—you might have encountered the frustrating “No rule to make target ‘debian/canonical-certs.pem’” error.
This seemingly cryptic message can stop your kernel compilation in its tracks, but fortunately, there are several effective solutions.
In this article, I’ll guide you through resolving this common certificate-related error that appears when compiling Linux kernel versions 5.11.11 and later on Ubuntu systems. I’ll explain not just how to fix it, but also why these errors occur and the security implications of different solutions.
Understanding the Problem
What’s Happening?
When compiling a kernel on Ubuntu (particularly versions 20.04 LTS and later), you might encounter this error:
make[1]: *** No rule to make target 'debian/canonical-certs.pem', needed by 'certs/x509_certificate_list'. Stop.
make: *** [Makefile:1809: certs] Error 2
The Root Cause
This error occurs because the kernel’s default configuration is looking for certificate files that are only available to Canonical (Ubuntu’s parent company) for signing official kernel builds. When you’re compiling your own kernel, you don’t have access to these certificate files, which causes the build process to fail.
Specifically, the kernel configuration contains these lines:
CONFIG_SYSTEM_TRUSTED_KEYS="debian/canonical-certs.pem"
CONFIG_SYSTEM_REVOCATION_KEYS="debian/canonical-revoked-certs.pem"
These configuration options are related to kernel module signing for secure boot, which is an important security feature in modern systems.
Three Ways to Resolve the Certificate Error
Let’s explore three different approaches to fix this issue, with their pros and cons.
Solution 1: Disable the Certificate Keys Configuration (Recommended for Testing)
This is the quickest solution and works well for development and testing environments.
Step-by-Step Instructions:
- Navigate to your kernel source directory:
cd /path/to/your/kernel/source - Disable the trusted keys configuration:
scripts/config --disable SYSTEM_TRUSTED_KEYS - Disable the revocation keys configuration (required for kernel 5.13 and later):
scripts/config --disable SYSTEM_REVOCATION_KEYS - Resume your kernel compilation:
make -j$(nproc)
If you’re using make menuconfig instead, you can navigate to the relevant options and set them to empty strings manually.
Why This Works
By disabling these configuration options, you’re telling the kernel build system that you don’t need signed kernel modules. For personal use and development environments where secure boot isn’t a concern, this is often the most practical approach.
Read: Secure Your Ubuntu 24.04 System: 30 Essential Steps for Enhanced Security
Solution 2: Create Your Own Self-Signed Certificate (Better for Security)
If you’re concerned about security or plan to use your kernel in a secure boot environment, creating your own certificate is a better option.
Step-by-Step Instructions:
- Navigate to your kernel source directory:
cd /path/to/your/kernel/source - Generate a self-signed certificate:
openssl req -x509 -newkey rsa:4096 -keyout certs/mycert.pem -out certs/mycert.pem -nodes -days 3650This command will prompt you for information to create the certificate. Fill in the details or press Enter to use defaults.
- Update your kernel configuration to use your certificate:
scripts/config --set-str SYSTEM_TRUSTED_KEYS "certs/mycert.pem" scripts/config --set-str SYSTEM_REVOCATION_KEYS "" - Resume your kernel compilation:
make -j$(nproc)
Additional Configuration Options
For a more comprehensive setup, you might want to include these options in your kernel configuration:
CONFIG_MODULE_SIG_KEY="certs/mycert.pem"
CONFIG_SYSTEM_TRUSTED_KEYRING=y
CONFIG_SYSTEM_TRUSTED_KEYS="certs/mycert.pem"
CONFIG_SYSTEM_EXTRA_CERTIFICATE=y
CONFIG_SYSTEM_EXTRA_CERTIFICATE_SIZE=4096
CONFIG_SECONDARY_TRUSTED_KEYRING=y
CONFIG_SYSTEM_BLACKLIST_KEYRING=y
CONFIG_SYSTEM_BLACKLIST_HASH_LIST=""
Why This Method Is Better for Security
When you create your own certificate and use it for signing kernel modules, you maintain the security benefits of module signing. In secure boot environments, you can add your certificate to your system’s trusted keys, allowing your custom kernel to boot while still preventing unauthorized kernel modules from loading.
Solution 3: Create a Workaround Directory Structure
If you prefer not to modify the security configuration, you can create a directory structure that satisfies the build requirements.
Step-by-Step Instructions:
- Navigate to your kernel source directory:
cd /path/to/your/kernel/source - Create a debian directory:
mkdir -p debian - Copy a certificate file to the expected location:
cp certs/signing_key.pem debian/canonical-certs.pem touch debian/canonical-revoked-certs.pem - Resume your kernel compilation:
make -j$(nproc)
Note on This Approach
This approach essentially tricks the build system by providing files with the expected names. However, the certificates won’t be the official Canonical certificates, so the security benefits aren’t the same as with official signed kernels.
Testing Your Compiled Kernel
After successfully compiling your custom kernel, you should test it before installing it system-wide:
- Install the compiled kernel modules:
sudo make modules_install - Install the kernel:
sudo make install - Update your bootloader (for GRUB):
sudo update-grub - Reboot your system and select your new kernel from the bootloader menu.
Understanding the Security Implications
When compiling your own kernel, it’s important to understand the security implications of modified certificate configurations:
- Disabling certificate checks: This is convenient for development but removes the secure boot protections against unauthorized kernel modules.
- Using self-signed certificates: This maintains security if you configure your system to trust your certificates but requires additional setup.
- Creating dummy files: This satisfies the build process but doesn’t provide actual security benefits.
For desktop development or personal use, disabling the certificate checks is often sufficient. For production systems, especially those requiring secure boot, creating and properly managing your own certificates is recommended.
Common Issues and Troubleshooting
Error: Cannot Find Certificate File
If you’re trying to use your own certificate but get an error about not finding the file, check the path. Kernel paths are relative to the kernel source root directory.
Error After Resume Compilation
If you encounter new errors after applying one of these fixes, your kernel configuration might have other issues. Try running:
make oldconfig
This command will prompt you for any new configuration options.
Module Loading Issues After Installation
If your compiled kernel loads but has issues loading modules, it could be related to module signing. Check the kernel logs (dmesg) for signature verification failures.
Frequently Asked Questions
Why does Canonical require these certificate files?
Canonical uses these certificates to sign their official kernel builds, ensuring that only authorized kernel code runs on Ubuntu systems with secure boot enabled. This is an important security feature that protects systems from malicious kernel-level code.
Will disabling these certificates make my system less secure?
If you’re using secure boot, then yes, disabling the certificate verification can reduce security by allowing unsigned kernel modules to load. If you’re not using secure boot, the impact is minimal.
Do I need to repeat this process for every kernel update?
Yes, whenever you download a new kernel source or update your existing source, you’ll need to apply these changes again before compiling.
Can I use these methods on distributions other than Ubuntu?
These specific certificate issues are most common on Ubuntu and its derivatives, but similar concepts apply to other distributions that use signed kernels for secure boot. The exact file paths and configuration options might differ.
Is it possible to use the official Canonical certificates?
No, the official Canonical certificates are not publicly available, which is why you need to either disable the certificate checks or create your own certificates.
How often should I update my self-signed certificate?
The example creates a certificate valid for 10 years (3650 days). For personal use, this is typically sufficient. For production systems, you might want to renew certificates more frequently following your organization’s security policies.
Conclusion
Compiling a custom Linux kernel provides tremendous flexibility and learning opportunities, but certificate errors can be a stumbling block. By understanding the cause of these errors and knowing multiple ways to resolve them, you can choose the approach that best balances convenience and security for your specific needs.
Whether you’re adding custom system calls, testing new features, or optimizing for specific hardware, I hope this guide helps you get past the certificate hurdle and on to a successfully compiled custom kernel.
Remember that kernel development and compilation should be approached with care, especially on production systems. Always test your custom kernels thoroughly before deploying them in critical environments.
The post How to Fix “No rule to make target ‘debian/canonical-certs.pem” When Compiling Linux Kernel 5.11.11 and Later appeared first on net2.
Discover more from Ubuntu-Server.com
Subscribe to get the latest posts sent to your email.
