Can't sign kext in Mavericks / Yosemite?

Question

Purpose: Sign my own packages and my own kernel extensions. “My own” in the context means “what I wrote or what I chose elsewhere, recompiled myself from my sources and want to install it on my machine.

Problem: Mavericks does not accept my signature with Code Signing Failure: code signature is invalid (but loads kext), Yosemite won't even load it.

I have my own CA and code signing certificates. I was able to successfully sign the code and configure policies that would allow you to install and execute the code signed by the specified certificates - codesign and spctl , as you see in the output below. However, this does not seem to apply to kext (kernel extensions) - kextutil claims that the signature is not valid. Here's the output I get:

 $ codesign --verify -vvvv /opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext /opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext: valid on disk /opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext: satisfies its Designated Requirement $ spctl -a -vvv -t exec /opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext /opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext: accepted source=XXXXXCode origin=XXXXXCoder $ spctl -a -vvv -t install /opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext /opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext: accepted source=XXXXXInstall origin=XXXXXCoder $ kextutil -tn /opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext Diagnostics for /opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext: Code Signing Failure: code signature is invalid /opt/local/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext appears to be loadable (including linkage for on-disk libraries). 

In Mavericks, this kext is loaded with a warning message, on Yosemite this will not happen.

I noticed here and in the Apple CA CPS Developer ID that the certificate must have the following extension: ( 1.2.840.113635.100.6.1.18 ) to designate it as a kext signature certificate. I do not have it. I suspect this is the cause of my problem, but I don’t know how to solve it. There is no type option in spctl to create a policy that designates a given certificate as kext signing.

How to add this extension (preferably to Keychain key support, although an OpenSSL-based solution would be great too) without paying an annual "$ 100 Apple usage fee"?

Answer 1

To request an Apple Kext Signature Certificate, you need to use this form .

Answer 2

Only Apple can create certificates with this OID and consider it valid for the kernel.

For a more detailed explanation, see What's New in Kext Development at tonymacx86.com. Here are the relevant parts.

OID 1.2.840.113635 is Apple's prefix, and the rest of the OID describes which specific property must exist in a sheet certificate, (signature certificate), to allow kernel booting. This means that a valid, signed kernel extension can only be created using a certificate provided by Apple as part of their $ 99 per year developer and, in addition, interested parties must fill out a special form explaining why they require a certificate; Kext certificates are available only upon request and approval.

Although you can create a certificate with a specific OID and sign it using your own CA, OS X will only recognize Apple CA for kernel extensions. The gateway documentation briefly mentions this.

modify the code requirements built into kextutil, kextd, and kextcache to allow root certificates other than

Apple

Answer 3

Anyone can create certificates with any OID they want. In fact, OIDs are added all the time. You can go to IANA , request an OID and hack gnutls / openssl to start creating certificates for your new fangled field. The corresponding OIDs for code signing, which should be in the certificate, are documented . This should lead to the creation of personal CA certificates and intermediate certificates that kexts can sign. Check out OpenSSL patches that allow it to generate RPKI certificates

The next task is to find out how Apple recognizes your CA as a binding certificate. I assume that you will need to import the resulting CA certificate using KeyChain Access. If the apple somehow hardcodes the CA (unlikely and would be stupid), we will be doomed. Otherwise, they must load certificate bindings from some file system resource. Use dtruss to find out. My starting points for research in / System / Library / Keychains /