I have a ancient kext (last supported with 10.7.5). It works when disabling SIP and such.
The question I'm having, is if you could sign that ancient text? I already tried]codesign -s "Developer ID Application:" --verbose Downloads/private/tmp/InstallerTemp/M-AudioFireWireBeBoB.kext/
You haven't given much detail. Does signing fail? If it succeeds, what does kextutil path/to/M-AudioFireWireBeBoB.kext say?
A few things I can think of that could be causing problems:
I don't think codesigning works for kexts with a 32-bit slice. So if it's a universal 32/64-bit kext (or if it still has a PPC slice 😱), extract the x86-64 binary using lipo and use only that instead.
The signing certificate must have the special kext signing feature associated with it. Apple only grants that upon special request, a regular Developer ID Application certificate is not sufficient for kexts.
On macOS 10.14.5+ and 10.15, the kext must additionally be notarised. Create a zipfile of the kext, and upload it to Apple using xcrun altool --notarize-app. Once approved, you can staple the notarisation to the kext using xcrun stapler staple path/to/your.kext. See Apple's documentation on notarisation and the output of xcrun altool --help for details.
Related
This is the first time I have ever tried to sign a kernel extension, so I am open to the possibility that I'm doing it wrong.
I requested a kernel signing certificate from Apple. I was required to fill out a form that demonstrated that I really needed to create an in-kernel driver, rather than a user space driver that talked to an IOUserClient.
$ sudo kextutil FL2000.kext/
Password:
Notice: /Library/Extensions/FL2000.kext has debug properties set.
Diagnostics for /Library/Extensions/FL2000.kext:
Code Signing Failure: code signature is invalid
Untrusted kexts are not allowed
ERROR: invalid signature for com.frescologic.FL2000, will not load
It doesn't load at boot - it needs to because it is a graphics driver.
$ codesign --verify -vvvv FL2000.kext/
FL2000.kext/: valid on disk
FL2000.kext/: satisfies its Designated Requirement
$ codesign --display -vvvv FL2000.kext/
Executable=/Library/Extensions/FL2000.kext/Contents/MacOS/FL2000
Identifier=com.frescologic.FL2000
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=1590 flags=0x0(none) hashes=44+3 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=83a0328f9af971484b7e30c8d04e68a96dee72c1
CandidateCDHash sha256=cd6c72d17f00d2eed36078eece6a5b536c482772
Hash choices=sha1,sha256
Page size=4096
CDHash=cd6c72d17f00d2eed36078eece6a5b536c482772
Signature size=4693
Authority=Mac Developer: Michael Crawford (YU8CSARZFD)
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Signed Time=Nov 10, 2017, 1:10:07 PM
Info.plist entries=20
TeamIdentifier=444JK52Q93
Sealed Resources version=2 rules=13 files=2
Internal requirements count=1 size=184
Help me O Stackoverflow-Wan. You're my only hope!
I should have spotted this in your codesign output, but your comments make it clear: the problem is with the certificate you are using. Apple issues 4 kinds of Mac codesigning certificates:
"Mac Developer" certificates are for signing apps destined for the Mac App Store during the development phase. This is the type of certificate you appeared to be trying to use for signing a kext. This won't work. It will sign it OK, but kextd etc. won't accept the signature.
"Developer ID Application" certificates are for signing apps which will be distributed outside the App Store. A special variant of this type of certificate includes the certificate extension "( 1.2.840.113635.100.6.1.18 )" - only with this extension, it becomes possible to sign kexts such that they are accepted by macOS.
"Developer ID Installer" certificates are for signing Installer .pkg files/bundles. If you are distributing an app via a DMG or ZIP file, you shouldn't need this, but if you need an installer, possibly because what you're distributing isn't an app, but a kext or system service, then you should create an installer package and sign that with such a certificate.
"Mac Distribution" certificates are what you use to sign the build of an app before submitting it to the Mac App Store. These are also irrelevant to kext signing.
Presumably for security reasons, certificate types 2-4 are only issued to Team Agents in an Apple Developer account. Lowly developers are only given "Mac Developer" certificates, which are intended to be purely temporary, so they're not very security-relevant.
So to summarise, your problem is that you're using a "Mac Developer" certificate to sign a kext. You need to use a "Developer ID Application" certificate instead, specifically one that was issued after the development team was granted kext signing privileges by Apple. If you haven't applied for kext signing privileges, you can do so using this form. (It sounds like you have done so previously, but I'm pointing it out for the benefit of people in the same situation who might stumble across this in the future.)
We have a audio kernel extension, which installs in /Library/Extensions.
According apple new guidelines(WWDC video 707) we should code sign kext which installs /Library/Extensions.
We requested apple to enable kext code signing attribute to our developer id and now it is enabled. As per the mail reply that we got from apple says like this
If you have previously obtained a Developer ID for application signing, you need to re-download your Developer ID to have the updated certificate.
Hence we redownloded certificate and codesigned the kext. Code compiles fine However when we try to verify the code sign using below command
sudo kextutil -tn KEXTPATH
it gives following error-
Code Signing Failure: code signature is invalid
KEXT_PATH appears to be loadable (including linkage for on-disk libraries).
Can any one help me to resolve this error.
Apart from the developer ID certificate for the code signing of kexts to work you need to code sign kernel extensions on 10.9 and above.
You cannot sign it on 10.8, install it on 10.9 -> /Library/Extensions
I am not sure if this helps solve your problem.
Due to the inclusion of Gatekeeper, you have to codesign your OS X apps (so your users won’t get a warning). It seems, though, that the only way to get it signed will involve paying the $99/year for a developer program. Is there a way to codesign an app for free?
The only way to get an app signed is to obtain a certificate from Apple for $99/year.
I have an application (installer, actually) that was built outside of Xcode which I have codesigned using the codesign utility, but when I try to install it after downloading the signed app, Gatekeeper complains that it comes from an unidentified developer. I have tried using the "3rd Party Mac Developer:..." identity, as well as my own "Mac Developer:..." identity; same result in either case. codesign (as far as I can tell) says all is well, so I'm thinking I'm either using the wrong identity (in which case my question is what I should use/make-to-use instead) or the signature is fine, but there is something that needs to be done w/ my developer account (in which case my question is what might that be).
According to Apple, and verified by me :), there is another set of identities specifically for signing apps to satisfy the intermediate security setting in Gatekeeper, but only a Team's Agent can get, which is why I wasn't getting them. My agent got them, I used them, and Gatekeeper is happy.
I build an OSX app which is distributed as a DMG outside of the Mac App Store, and I'd like to continue to have it be that way once Gatekeeper enforcement begins.
From studying code signing documentation, it looks like the recommended approach is to get a "Developer ID" certificate and use that to codesign. However, you must be a registered OSX developer and pay Apple $99 each year. I already have a certificate from a recognized CA, and I would like to use it with codesign. I found documentation on how to do this, but I cannot tell whether Gatekeeper will allow applications signed using certs issued by other CAs, not Apple.
Does anyone know?
Gatekeeper only recognizes apps signed with Developer ID, not just any signature. See this which also explains how to test Gatekeeper functionality under Lion.
The point is that if Apple owns the certificate authority, they can revoke the certificate if your app turns out to be a trojan or something.