Could Not Code Sign a MAC App

Could not code sign a Mac App

It seems there may be code signing issues with macOS Sierra. You can follow the issue here.

I would recommend reverting back to El Cap and only installing an early beta of a new Mac OS on a machine used for testing the OS, not one you are doing active development on.

[update 7/6/2016]

Some developers are reporting this fixed with macOS Sierra Beta 2 and Xcode 8 Beta 2, but I have not yet comfirmed on my spare Mac if this fixes the problem.

Also, some developers have reported that resetting the Keychain fixes is. In the Keychain Access app , go to "Preferences..." and click "Reset My Default Keychain".

osx complains that app is from unidentified developer, although it passes all validations

First of all, you should check this technical note:

TN2206

However, I will summarize in a few lines a few checks that you need to make to ensure that everything goes OK:

a) Make sure you are using the latest Xcode version — sometimes just upgrading can solve all your problems

b) Make sure Xcode is set to manage automatically your certificate and provisioning profiles — this is probably the best advice I can give you if you have problems in code signing. In summary, if you have Xcode 8, you have to:

1. Click on your project in the navigation area (on the left) > Build Settings tab.
2. Set the Provisioning Profile build setting to Automatic for all build
   configurations.
3. Set the Code Signing Identity build setting:
   
   
   • Set to iOS Developer for all build configurations in iOS projects.
   • Set to Mac Developer or Developer ID, as appropriate, for all build configurations in macOS projects.
4. Set your target in Targets > General > Team to None
5. For Mac apps, set your target in Targets > General > Signing to None.
6. Change the Provisioning Profile build setting to Automatic for all build configurations.
7. Set the Code Signing Identity build setting:
   
   
   • Set to iOS Developer for all build configurations in iOS targets.
   • Set to Mac Developer or Developer ID, as appropriate, for all build configurations in macOS targets.
8. Go back to Targets and revert General > Team > to your team and
9. Check Automatically manage signing checkbox
10. Restart Xcode.

This is in part explained in the QA1814, but some important steps are missing in it and some information in it is outdated. So I advise that you do what I say above.

c) If you are running on El Capitan (10.11) or later, check your code by running the following commands in Terminal:

$ spctl -a -v path/to/your.app

It should yield something like:

path/to/your.app: accepted
source=Developer ID

Another command that you should check is:

$ spctl -a -v --raw path/to/your.app

or this:

$ codesign --verbose=4 --deep --strict path/to/your.app

These will check if any the frameworks or any embedded code is doing something that is not supposed to, such as pointing to code outside of the allowed directories such as:

/System
/Library
/usr

as that poses a security risk.

However, do not use the latter command to really code sign your app. This is only to mimic what Gatekeeper does to check your app.

To know more what command you should use, read the Code Signing Guide.

d) code sign your dmg disk image by using the command:

codesign -s <identity> <disk-image>

This is now highly recommended for your software to run on macOS Sierra without any problems.

Why can't I code sign this Mac app?

I got it to work. I deleted my App and created it new.

I didn't create a new Configuration, and I only changed the Code Signing Indentity of the Target to 3rd Party Mac Developer Application. After this, I archived the app and then I was able to select the installer cert.

Successfully codesigned and notarized app getting unable to verify developer when running

I found the issue. I have a framework in the .app that I codesign. Gatekeeper doesn't show anything wrong when I notarize it. However, when I didn't code sign the included framework, and then submitted to notarize, it came back with errors.

I simply codesigned what the errors were, instead of everything and that fixed the issue. Now the app runs fine on other devices!

The code signature version is no longer supported

Notice

This answer is mostly for people using older versions of Xcode. My build farm was for a time stuck at Xcode 12.4 because some Mac minis couldn't be upgraded past Catalina. If you are using a recent Xcode 13+ this is not your issue. Probably cruft of some kind in your project.

If you're still using an Xcode 12 release it is time to let go. The only reason to use 12.4 would be because you're stuck on Catalina and new problems are cropping up that will not be worked around so easily.

codesign --generate-entitlement-der

Apple has changed the codesign signature to include DER encoded entitlements in addition to the plist encoded entitlements. This additional DER encoded entitlements section is required in iOS 15 and becomes the default behavior of codesign in the latest Xcode. To use codesign on an older machines with an older version of Xcode add the --generate-entitlement-der flag to your call to codesign.

If signing through Xcode, you can add this flag to the OTHER_CODE_SIGN_FLAGS setting in the Build Settings tab.

If codesigning at the command-line:

CODESIGN_ALLOCATE=$( xcrun --find codesign_allocate ); export CODESIGN_ALLOCATE
xcrun codesign --generate-entitlement-der ...

The source of this information was the Apple Forum thread and the answer from Matt Eaton in DTS at Apple.

In the Xcode 12.5 Release Notes there is also a reference to the new signature format. However, it seems the information is not entirely correct.

General advice

If you have a non-trivial setup like CocoaPods, you should probably de-integrate and re-integrate and of course do a project clean. These sorts of 'me too' answers really just add noise to the signal and anyone doing this sort of development should have already tried this.

Failure digitally signing a Mac app outside Xcode

Sorry for answering my own question, but I see no other way as editing the original question would lead to spaghetti text.

I finally solved my problem. First the credit: (i) The answer to my other stackoverflow question was very useful and (ii) I got very good (paid) advice from an official Apple developer, by filing a so-called Technical Support Incident (TSI).

On the basis of all this I am now able to give here a very concise recipe of how getting your Mac app successfully treated by GateKeeper. After detailing the recipe I will show what my original mistake was.

Goal: After having developed a Mac app outside Xcode to have GateKeeper issuing the warning "Downloaded from the Internet ..." with three buttons, one of which is "open".

Failure: When GateKeeper issues a warning with either the text ".. unidentified developer.." or the text ".. unconfirmed developer .. " with - in both cases - a messagebox with a single OK button.

Getting your app GateKeeper-ready involves three steps:

• Make your app standalone with no unacceptable external dependencies. The only acceptable external dependences are system libraries. All other dependencies should have been copied to your MyApp.app folder. GateKeeper rejects any app that has non-system external dependencies
• Binaries should not be located at illegal positions inside the MyApp.app folder. Libraries go into MyApp/Contents/Frameworks and the executable goes into MyApp/Contents/MacOS
• All binaries inside MyApp should be digitally signed. Then the MyApp.app folder should be signed. For this signing an Apple "Developer ID Application ..." certificate is necessary

Our recipe is automatic. All the work is done by one script. In case of Qt Creator we use a qmake script where we access the system shell through the $$system command. When using either of the (Xcode) system commands codesign, spctl or check-signature we assume you have redirected stderr to stdout as outlined in answer to question . Otherwise you will not be able to catch the system response when running these utilities. In the following we will not explicitly show this redirection.

HERE IS OUR RECIPE

A. Making the app stand-alone:

1. copy (with a script) all the needed binaries to the MyApp.folder
2. run (with a script) install_name_tool -change and install_name_tool -id such that all dependences inside the app are of the relative type @executable_path/../MacOS.. or @executable_path/../Frameworks
3. run (with a script) otool -L on all binaries inside the MyApp.app folder and flag any illegal dependence, like "@rpath..." or absolute file paths not being system paths. Note that otool -L is not guaranteed to find all dependencies. Plugins are often beyond the horizon of otool. That is why you need the next check.
4. start a terminal at the location "MyApp.app/Contents/MacOS". Run export DYLD_PRINT_LIBRARIES=1. Then run inside the same terminal window ./MyApp. Your terminal will fill up with over hundred loaded libraries. Check this list again for forbidden libraries (libraries present on your computer, but not on the computer of your customers).
5. proof of the pudding is in the eating. We use the MacInCloud virtual machines and check whether or not our app runs there. Alternative solution could be the Mac of a relative who is not a developer. Or you could also create a new user ("test") on your own Mac and copy the app to its Download (or Desktop folder, or ...). In the latter case you must temporarily rename the root folder of your IDE as otherwise the user "test" will find the missing binaries there.

B Signing the app

6. Signing: With our script we run codesign --force --verify --verbose --sign \"Developer ID Application: ....\" \"/path/to/binary\" on all the binaries in the app and then on the app folder itself. In each case the system response is caught. It should contain in each case the string "signed Mach-O thin".
7. Verification: Run (with a script) command codesign --verify --verbose \"/path/to/binary\" on each binary in your app and on the app itself and catch the system response. It should in each case contain the strings "valid on disk" and "satisfies its Designated Requirement".
8. GateKeeper check: Run (with a script) spctl -a -t exec -vv /path/to/binary\" on each binary and on the app folder itself. The system response is caught. It should contain in all cases the string "accepted source".
9. check-signature: Run (with a script) check-signature \"/path/to/banary\" on each binary and on the app folder itself. The system response is caught. It should contain the string "YES" in each case.

C External check

10. zip your app into a single zip file. Upload to one of your cloud servers

11. GateKeepers keeps a long list (typically hundreds of items) of exceptions on its general gate-keeper role. Your app must not be in that list if you want to test GateKeeper. Rather than editing this list a much simpler trick is creating a new user on your Mac. Log in to that user and download the zip file from the Internet cloud server. Finder will automatically uncompress it. Click on it. If GateKeeper tells you that it can open the application but it warns you at the same time that it is downloaded from the Internet, it is time to grab a (white) beer.

Here the desired GateKeeper warning:

My mistake

I did much of the installing and signing without explicitly checking the result for each binary. After that I would use otool -L on a number of binaries but not on all. I missed the fact that upgrading to Qt 5.5 from an earlier Qt version the binary libqminimal.dylib has acquired an extra dependency, viz.: QtDBus. I had not noticed it, but GateKeeper did.

Qt developers might wonder why we not just use macdeployqt for deploying Qt application on a Mac. In the first place we do not like not to use ill-documented black-box utilities. On Internet fora there are quite a number of people reporting issues with macdeployqt. In addition the Qt libraries can have different install locations (as reported by otool-L) when comparing different Qt versions. When we have a new Qt version our script will immediately start to yell about forbidden dependencies. In this way we get information about what has changed in this new version.

How to codesign an existing Mac OS X .app file for gatekeeper?

To summarize the comments to my questions, here are the commands I run to sign my .app file for Gatekeeper:

export CODESIGN_ALLOCATE="/Applications/Xcode.app/Contents/Developer/usr/bin/codesign_allocate"
codesign --force --sign "Developer ID Application: <my name>" /path/to/my.app

Thanks, Gordon Davisson and JWWalker!

(edit) If this fails, I realize that installing the "Command Line Tools" from within XCode was needed.

EDIT:
To verify

$ codesign -dv --verbose=4 my.app

In Apple ID account make sure you have few types of certificate?

How to properly sign a Mac application for self-distribution?

I kept digging at it and I found my answer:
https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution?language=objc

The type if certificate I needed was Developer ID and the type of provision Developer ID Application, which is what is intended for self-distribution of a signed Mac application.
After that it needs to be submitted to Apple for notarization to satisfy the requirement for 10.14.5+. After notarization had completed I was able to send the exported app to myself and it offered me an "Open" option for the app downloaded from Internet. This is the desired behavior.

It required me to request the account holder to issue me the Developer ID certificate by sending them a CSR, as Developer ID certificate option is greyed out for delegated users that are not the original developer account holder (admin role may satisfy, but I am not one so can't say).

Yay.

Questions about code signing Mac App with Developer ID

Re: Provisioning profiles and DeveloperID— they are unnecessary. You should be able to accept your DeveloperID in the automatic section of the Code Signing Identity portion of the Build Settings. If you cannot, your key may be missing or there may be something else wrong with the database that contains the information.

First, go into Keychain Access and verify that your DeveloperID certificate has an accompanying private key associated with it (this will be visible under a disclosure triangle). If it does not, then you should go check around to see if you saved off the key related to that certificate anywhere, because if you can't find and reimport it (from, for example, a Developer Profile exported from Xcode), you will need to revoke and reissue the certificate, since there's no way to sign it.

Second, there is a known bug in 4.6.1 that can corrupt a cached database containing information from the developer portal. There's no specific indication that this behavior can be caused by this problem, but before following the next step, you might want to give it a try. Basically, you will need to quit Xcode, move aside (or delete) ~/Library/Developer/Xcode/connect1.apple.com 4.6.1.db (yes, there's a space in that file name), restart Xcode, go to the Organizer and Refresh your profiles and certificates.

If this doesn't work, you may want to consider revoking your Developer ID.

WARNING If you have successfully distributed code with the certificate, do not revoke it until you have visited Apple's web site (https://developer.apple.com/support/technical/certificates/) and thoroughly understand the implications to shipped code for revoking a developer id. Specifically that installed software will continue to work, but users will not be able to install/reinstall binaries signed with the original certificate.

If you have never successfully distributed code with the certificate (or if your key is irrecoverably lost), you may want to go to the portal and revoke and then reissue your Developer ID certificate. Once you have revoked it, you can create a new certificate by requesting a new certificate.

---

Related Topics