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.)
Related
Question:
Please note before reading this that: "Tell them to go to System preferences > Security & privacy and allow 3rd party applications to run. Is not an acceptable solve for this issue.
I have created an .app That has been signed with a valid Mac Developer certificate. Yet downloading it from the internet & running still throws the security prompt:
App can't be opened because it is from an unidentified developer
This is the codesign -vvv terminal dump for the .app:
Executable=/Users/me/Desktop/ADRA.app/Contents/MacOS/ADRA
Identifier=unity.Company.ADRA NSW 2016
Format=app bundle with Mach-O thin (i386)
CodeDirectory v=20200 size=178145 flags=0x0(none) hashes=5561+3 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=79ecf88721d6387749c1f6b10355c3683ef20eb2
CandidateCDHash sha256=0799e968a18a663a0c08d26d3fb7826017ce5a3a
Hash choices=sha1,sha256
CDHash=0799e968a18a663a0c08d26d3fb7826017ce5a3a
Signature size=4739
Authority=3rd Party Mac Developer Application: Company Pty Ltd (NH73TNDB28)
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Signed Time=20 Apr 2017, 2:46:12 PM
Info.plist entries=14
TeamIdentifier=NH73TNDB28
Sealed Resources version=2 rules=12 files=138
Internal requirements count=1 size=224
I don't understand why this does not pass Gatekeeper? Is there something missing? Does Apple require further payments / bribes or something?
Update 1:
#TheDarkKnight has suggested that I am using the incorrect certificate to sign the .app. Looks as though they are correct, so I went to create a new Developer ID Application certificate but apparently because I am not an 'Agent' in the group account, so I now have to wait until the 'Agent' creates one for me - seems backwards, is there no other way around waiting for the 'Agent' to make this for me?
(in Xcode) If the "Developer ID" radio button is greyed out you probably have a group account. These types of accounts only allow for the "Agent" role to create Developer IDs. Contact the person who created your group Apple Developer Account if you get stuck here.
https://developer.mozilla.org/en-US/docs/Mozilla/Signing_Mozilla_apps_for_Mac_OS_X
Update 2:
So I finally got my new cert today, re-signed the .app, downloaded it from the server ran and STILL GOT THE ERROR MESSAGE. The authority seems to be correct now:
Executable=/Users/me/Downloads/ADRA.app/Contents/MacOS/ADRA
Identifier=com.company.adra
Format=app bundle with Mach-O thin (i386)
CodeDirectory v=20200 size=178133 flags=0x0(none) hashes=5561+3 location=embedded
Library validation warning=OS X SDK version before 10.9 does not support Library Validation
OSPlatform=36
OSSDKVersion=657408
OSVersionMin=656896
Hash type=sha256 size=32
CandidateCDHash sha1=90d2a54162d6d018bf4f7602d7707c8e8e522fc6
CandidateCDHash sha256=dadfe5203d1367ea776f9501025dbd4ce751ee30
Hash choices=sha1,sha256
Page size=4096
CDHash=dadfe5203d1367ea776f9501025dbd4ce751ee30
Signature size=8930
Authority=Developer ID Application: Company Pty Ltd (NH73TNDB28)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=10 May 2017, 3:36:51 pm
Info.plist entries=14
TeamIdentifier=NH73TNDB28
Sealed Resources version=2 rules=12 files=138
Internal requirements count=1 size=184
I am only signing the .app is there anything else that I have to do to make this work? Is there a time period I have to wait before this will work?
Apple supply different certificates for different purposes.
If you look at a signature for an app downloaded from the App Store, you'll see that they usually contain the Common Name: Apple Mac OS Application Signing, as Apple re-sign applications that they distribute through the store.
For 3rd party developers that distribute via alternative streams, their Application certificates usually have a Common Name that begins with: "Developer ID Application...".
Note that other 3rd party certificates are available, such as an Installer certificate for signing installer packages, whose Common Name begins with "Developer ID Installer...".
The privilege of being able to sign a product with a certificate must be limited and tightly controlled.
Should a copy of your certificate be leaked, it can be used for nefarious purposes, such as distribution of malware, as was the case with KeRanger, which infected the Transmission BitTorrent application.
If you suspect a leaked certificate that you own, you need to revoke it, which can be initiated from your Apple Developer account.
So, Apple limits the creation of certificates to the Agent, as there can be only one registered with an Apple Developer account and is the person who has legally agreed to take responsibility for it.
I'm trying to sign a Mac app but i'm having problems on 10.9.5+. I've generated a new v2 certificate (Developer ID), and signed the app with Xcode, and verified that the cert is indeed v2, but i still get the Gatekeeper warning. I created a brand new test app, thinking maybe some old project setting might have been causing an issue, but same problem.
Here is what codesign tells me about the app (removing some identifying values):
codesign -dvvv NewApp.app/
Executable=/Users/XXXXXXXXXXX/Projects/Tests/NewApp/Releases/NewApp.app/Contents/MacOS/NewApp
Identifier=com.XXXXXXXXXXX.NewApp
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=228 flags=0x0(none) hashes=4+3 location=embedded
Hash type=sha1 size=20
CDHash=732ec1e6c4f2ae7b2a0e2da5f92693c27a8cbf0e
Signature size=8523
Authority=Developer ID Application: XXXXXXXXXXX (XXXXXXXXXXX)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Sep 30, 2014, 11:04:31 AM
Info.plist entries=21
TeamIdentifier=SFM7SSUSXP
Sealed Resources version=2 rules=12 files=1
Internal requirements count=1 size=216
But this is what spectl tells me:
spctl -a -t exec -vv --verbose NewApp.app/
NewApp.app/: rejected
source=Developer ID
origin=Developer ID Application: XXXXXXXXXXX (XXXXXXXXXXX)
What gives? Is there any other feedback i can dig for that will tell me why its rejected?
[UPDATE}
Not building any frameworks in my app, so these posts suggested below didn't much much. I did come across that RB App Checker app, and ran it against my very simple app (brand new app created with XCode6). I get this result:
Evaluating the application “NewApp”.
The application was signed by “Apple Root CA”, “Developer ID Application: XXXXXXXXXX (XXXXXXXXXX)”.
Both the verified timestamp and the signing-time are: Oct 2, 2014, 10:50:08 AM.
The object code format is “bundle with Mach-O thin (x86_64)”.
Both bundle and signing identifiers are “ XXXXXXXXXX.NewApp”.
The signature specifies explicit requirements. 
The signature specifies resource rules (v1). 
The signature specifies resource rules (v2). 
Requirements and resources validate correctly.
The code signature contains 3 certificates. 
Certificate “Apple Root CA”: 
Your keychain contains this trusted root certificate.
Will expire on Feb 9, 2035.
Certificate “Developer ID Certification Authority”: 
Will expire on Feb 1, 2027.
Certificate “Developer ID Application: XXXXXXXXXX (XXXXXXXXXX)”: 
Will expire on Oct 1, 2019.
SHA1 fingerprint: “XXXXXXXXXX”.
The application is probably from an authorized Apple Developer.
The code signature contains entitlements. 
The application is not sandboxed.
Is the fact that there is a v1 and v2 resource rule in there causing the issue?
I was having the same problem and the reason was that my Gatekeeper setting was changed to allow "Mac App store" only.
I think I did this change from command line, while trying various hints from internet and I was not really aware of doing it.
Changing Gatekeeper setting to "Mac App store and identified developers" fixed the problem.
I actually resolved the issue after getting very sparse help from Apple tech support. I happened to catch an off-hand comment in a WWDC video regarding "flat" installers. Looking that up, it seems that you can only sign a flat installer package with the actual Installer Developer ID. If you try to sign a non-flat installer package, you can only sign it with the Application Developer ID, which succeeds, but doesn't actually work with Gatekeeper.
So.... I figured out that my installer was non-flat, cause it was targeting an pretty old OS (10.4). I'm using PackageMaker, and once i set the target OS to be 10.5 or newer, it started building a flat installer package, which i was then able to sign correctly (with the Installer Developer ID).
Apple seems to restrict some OS X APIs (e.g. sandboxing) to applications that are codesigned by a trusted certificate, e.g. one issued to members of the paid Mac Developer program.
How does OS X treat applications that are codesigned with a self-signed (or a development) certificate?
Will those features/APIs be available, and the only difference be that users with the default Gatekeeper settings cannot (easily) launch such an application?
Will they be treated just like unsigned apps in every way (entitlements and sandboxing disabled, warning for Gatekeeper users)?
Or will a self-signed certificate be considered an error, and the app will not launch at all regardless of the user's Gatekeeper settings?
AFAIK, apps that aren't code-signed with a certificate that Gatekeeper accepts, would be treated as unsigned. I don't know about access to specific features and API.
But you can make your self-signed cert acceptable to the Gatekeeper. If you sign your code using certificates that weren't issued by Apple, every machine you want to run that code as signed, would have to (a) have your certificate installed, and (b) have policies set via spctl command that tell the Gatekeeper to allow executing and/or installing code signed by that cert. This part has been tested and verified on Mavericks.
It is more difficult with kernel extensions. I'm still working on that. :-)
I have my executable binary signed using codesign command and verify successfully on my development machine where my private key and signing certificate are in the keychain. However when I copy my executable to my testing machine and try to do "codesign -dvvv", it returns code object is not signed. My signing certificate is issued by VeriSign root ca. The CA is installed on my testing machine but I am not able to verify executable. Am I missing something?
Yes, you are missing something.
The "Gatekeeper" code signing in Mac OS X only honors signatures which chain back to Apple's CA through developer certificates issued by Apple as part of the Mac OS X developer program. A Verisign code signing certificate is not an acceptable substitute.
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.