General: Forums topic: Code Signing Forums subtopics: Code Signing > General, Code Signing > Certificates, Identifiers & Profiles, Code Signing > Notarization, Code Signing > Entitlements Forums tags: Code Signing, Signing Certificates, Provisioning Profiles, Entitlements Developer Account Help — This document is good in general but, in particular, the Reference section is chock-full of useful information, including the names and purposes of all certificate types issued by Apple Developer web site, tables of which capabilities are supported by which distribution models on iOS and macOS, and information on how to use managed capabilities. Developer > Support > Certificates covers some important policy issues Bundle Resources > Entitlements documentation TN3125 Inside Code Signing: Provisioning Profiles — This includes links to the other technotes in the Inside Code Signing series. WWDC 2021 Session 10204 Distribute apps in Xcode with cloud signing Certificate Signing Requests Explained forums post --deep Considered Harmful forums post Don’t Run App Store Distribution-Signed Code forums post Resolving errSecInternalComponent errors during code signing forums post Finding a Capability’s Distribution Restrictions forums post Signing code with a hardware-based code-signing identity forums post New Capabilities Request Tab in Certificates, Identifiers & Profiles forums post Isolating Code Signing Problems from Build Problems forums post Investigating Third-Party IDE Code-Signing Problems forums post Determining if an entitlement is real forums post Mac code signing: Forums tag: Developer ID Creating distribution-signed code for macOS documentation Packaging Mac software for distribution documentation Placing Content in a Bundle documentation Embedding nonstandard code structures in a bundle documentation Embedding a command-line tool in a sandboxed app documentation Signing a daemon with a restricted entitlement documentation Defining launch environment and library constraints documentation WWDC 2023 Session 10266 Protect your Mac app with environment constraints TN2206 macOS Code Signing In Depth archived technote — This doc has mostly been replaced by the other resources linked to here but it still contains a few unique tidbits and it’s a great historical reference. Manual Code Signing Example forums post The Care and Feeding of Developer ID forums post TestFlight, Provisioning Profiles, and the Mac App Store forums post For problems with notarisation, see Notarisation Resources. For problems with the trusted execution system, including Gatekeeper, see Trusted Execution Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

To ship a product outside of the Mac App Store, you must notarise it. The notary service issues a notarised ticket, and the ultimate consumer of that ticket is Gatekeeper. However, Gatekeeper does not just check the ticket; it also applies a variety of other checks, and it’s possible for those checks to fail even if your notarised ticket is just fine. To avoid such problems showing up in the field, test your product’s compatibility with Gatekeeper before shipping it. To do this: Set up a fresh machine, one that’s never seen your product before. If your product supports macOS 10.15.x, x < 4, the best OS version to test with is 10.15.3 [1]. Download your product in a way that quarantines it (for example, using Safari). Disconnect the machine from the network. It might make sense to skip this step. See the discussion below. Install and use your product as your users would. If the product is signed, notarised, and stapled correctly, everything should work. If not, you’ll need to investigate what’s making Gatekeeper unhappy, fix that, and then retest. For detailed advice on that topic, see Resolving Trusted Execution Problems. Run this test on a fresh machine each time. This is necessary because Gatekeeper caches information about your product and it’s not easy to reset that cache. Your best option is to do this testing on a virtual machine (VM). Take a snapshot of the VM before the first test, and then restore to that snapshot when you want to retest. Also, by using a VM you can disable networking in step 3 without disrupting other work on your machine. The reason why you should disable networking in step 3 is to test that you’ve correctly stapled the notarised ticket on to your product. If, for some reason, you’re unable to do that stapling, it’s fine to skip step 3. However, be aware that this may cause problems for a user if they try to deploy your product to a Mac that does not have access to the wider Internet. For more background on this, see The Pros and Cons of Stapling. [1] macOS 10.15.4 fixes a bug that made Gatekeeper unnecessarily strict (r. 57278824), so by testing on 10.15.3 you’re exercising the worst case. The process described above is by far the best way to test your Gatekeeper compatibility because it accurately tests how your users run your product. However, you can also run a quick, albeit less accurate test, using various command-line tools. The exact process depends on the type of product you’re trying to check: App — Run syspolicy_check like this: % syspolicy_check distribution WaffleVarnish.app This tool was introduced in macOS 14. On older systems, use the older spctl tool. Run it like this: % spctl -a -t exec -vvv WaffleVarnish.app Be aware, however, that this check is much less accurate. Disk image — Run spctl like this: % spctl -a -t open -vvv --context context:primary-signature WaffleVarnish.dmg Installer package — Run spctl like this: % spctl -a -t install -vvv WaffleVarnish.pkg Other code — Run codesign like this: % codesign -vvvv -R="notarized" --check-notarization WaffleVarnish.bundle This command requires macOS 10.15 or later. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Revision history: 2024-12-05 Added instructions for using syspolicy_check. Made other minor editorial changes. 2023-10-20 Added links to Resolving Trusted Execution Problems and The Pros and Cons of Stapling. Made other minor editorial changes. 2021-02-26 Fixed the formatting. 2020-04-17 Added the section discussing spctl. 2020-03-25 First version.

IMPORTANT The underlying issue here (FB8830007) was fixed in macOS 11.3, so the advice in this post is irrelevant if you’re building on that release or later. Note This content is a repost of info from another thread because that thread is not world readable (it’s tied to the DTK programme). A number of folks have reported problems where: They have a product that supports older versions of macOS (anything prior to 10.11). If they build their product on Intel, everything works. If they build their product on Apple Silicon, it fails on those older versions of macOS. A developer filed a bug about this (FB8830007) and, based on the diagnosis of that bug, I have some info to share as to what’s going wrong and how you can prevent it. Let’s start with some background. macOS’s code signing architecture supports two different hash formats: sha1, the original hash format, which is now deprecated sha256, the new format, support for which was added in macOS 10.11 codesign should choose the signing format based on the deployment target: If your deployment target is 10.11 or later, you get sha256. If your deployment target is earlier, you get both sha1 and sha256. This problem crops up because, when building for both Intel and Apple Silicon, your deployment targets are different. You might set the deployment target to 10.9 but, on Apple Silicon, that’s raised to the minimum Apple Silicon system, 11.0. So, which deployment target does it choose? Well, the full answer to that is complex but the executive summary is that it chooses the deployment target of the current architecture, that is, Intel if you’re building on Intel and Apple Silicon if you’re building on Apple Silicon. For example: intel% codesign -d --arch x86_64 -vvv Test664892.app … Hash choices=sha1,sha256 … intel% codesign -d --arch arm64 -vvv Test664892.app … Hash choices=sha1,sha256 … arm% codesign -d --arch x86_64 -vvv Test664892.app … Hash choices=sha256 … arm% codesign -d --arch arm64 -vvv Test664892.app … Hash choices=sha256 … The upshot is that you have problems if your deployment target is less than 10.11 and you sign on Apple Silicon. When you run on, say, macOS 10.10, the system looks for a sha1 hash, doesn’t find it, and complains. The workaround is to supply the --digest-algorithm=sha1,sha256, which overrides the hash choice logic in codesign and causes it to include both hashes: arm% codesign -s - --digest-algorithm=sha1,sha256 Test664892.app arm% codesign -d --arch x86_64 -vvv Test664892.app … Hash choices=sha1,sha256 … % codesign -d --arch arm64 -vvv Test664892.app … Hash choices=sha1,sha256 … Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

I help a lot of developers with macOS trusted execution problems. For example, they might have an app being blocked by Gatekeeper, or an app that crashes on launch with a code signing error. If you encounter a problem that’s not explained here, start a new thread with the details. Put it in the Code Signing > General subtopic and tag it with relevant tags like Gatekeeper, Code Signing, and Notarization — so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Resolving Trusted Execution Problems macOS supports three software distribution channels: The user downloads an app from the App Store. The user gets a Developer ID-signed program directly from its developer. The user builds programs locally using Apple or third-party developer tools. The trusted execution system aims to protect users from malicious code. It’s comprised of a number of different subsystems. For example, Gatekeeper strives to ensure that only trusted software runs on a user’s Mac, while XProtect is the platform’s built-in anti-malware technology. Note To learn more about these technologies, see Apple Platform Security. If you’re developing software for macOS your goal is to avoid trusted execution entanglements. You want users to install and use your product without taking any special steps. If, for example, you ship an app that’s blocked by Gatekeeper, you’re likely to lose a lot of customers, and your users’ hard-won trust. Trusted execution problems are rare with Mac App Store apps because the Mac App Store validation process tends to catch things early. This post is primarily focused on Developer ID-signed programs. Developers who use Xcode encounter fewer trusted execution problems because Xcode takes care of many code signing and packaging chores. If you’re not using Xcode, consider making the switch. If you can’t, consult the following for information on how to structure, sign, and package your code: Placing content in a bundle Embedding nonstandard code structures in a bundle Embedding a command-line tool in a sandboxed app Creating distribution-signed code for macOS Packaging Mac software for distribution Gatekeeper Basics User-level apps on macOS implement a quarantine system for new downloads. For example, if Safari downloads a zip archive, it quarantines that archive. This involves setting the com.apple.quarantine extended attribute on the file. Note The com.apple.quarantine extended attribute is not documented as API. If you need to add, check, or remove quarantine from a file programmatically, use the quarantinePropertiesKey property. User-level unarchiving tools preserve quarantine. To continue the above example, if you double click the quarantined zip archive in the Finder, Archive Utility will unpack the archive and quarantine the resulting files. If you launch a quarantined app, the system invokes Gatekeeper. Gatekeeper checks the app for problems. If it finds no problems, it asks the user to confirm the launch, just to be sure. If it finds a problem, it displays an alert to the user and prevents them from launching it. The exact wording of this alert varies depending on the specific problem, and from release to release of macOS, but it generally looks like the ones shown in Apple > Support > Safely open apps on your Mac. The system may run Gatekeeper at other times as well. The exact circumstances under which it runs Gatekeeper is not documented and changes over time. However, running a quarantined app always invokes Gatekeeper. Unix-y networking tools, like curl and scp, don’t quarantine the files they download. Unix-y unarchiving tools, like tar and unzip, don’t propagate quarantine to the unarchived files. Confirm the Problem Trusted execution problems can be tricky to reproduce: You may encounter false negatives, that is, you have a trusted execution problem but you don’t see it during development. You may also encounter false positives, that is, things fail on one specific Mac but otherwise work. To avoid chasing your own tail, test your product on a fresh Mac, one that’s never seen your product before. The best way to do this is using a VM, restoring to a snapshot between runs. For a concrete example of this, see Testing a Notarised Product. The most common cause of problems is a Gatekeeper alert saying that it’s blocked your product from running. However, that’s not the only possibility. Before going further, confirm that Gatekeeper is the problem by running your product without quarantine. That is, repeat the steps in Testing a Notarised Product except, in step 2, download your product in a way that doesn’t set quarantine. Then try launching your app. If that launch fails then Gatekeeper is not the problem, or it’s not the only problem! Note The easiest way to download your app to your test environment without setting quarantine is curl or scp. Alternatively, use xattr to remove the com.apple.quarantine extended attribute from the download before you unpack it. For more information about the xattr tool, see the xattr man page. Trusted execution problems come in all shapes and sizes. Later sections of this post address the most common ones. But first, let’s see if there’s an easy answer. Run a System Policy Check macOS has a syspolicy_check tool that can diagnose many common trusted execution issues. To check an app, run the distribution subcommand against it: % syspolicy_check distribution MyApp.app App passed all pre-distribution checks and is ready for distribution. If there’s a problem, the tool prints information about that problem. For example, here’s what you’ll see if you run it against an app that’s notarised but not stapled: % syspolicy_check distribution MyApp.app App has failed one or more pre-distribution checks. --------------------------------------------------------------- Notary Ticket Missing File: MyApp.app Severity: Fatal Full Error: A Notarization ticket is not stapled to this application. Type: Distribution Error … Note In reality, stapling isn’t always required, so this error isn’t really Fatal (r. 151446728 ). For more about that, see The Pros and Cons of Stapling forums. And here’s what you’ll see if there’s a problem with the app’s code signature: % syspolicy_check distribution MyApp.app App has failed one or more pre-distribution checks. --------------------------------------------------------------- Codesign Error File: MyApp.app/Contents/Resources/added.txt Severity: Fatal Full Error: File added after outer app bundle was codesigned. Type: Notary Error … The syspolicy_check isn’t perfect. There are a few issues it can’t diagnose (r. 136954554, 151446550). However, it should always be your first step because, if it does work, it’ll save you a lot of time. Note syspolicy_check was introduced in macOS 14. If you’re seeing a problem on an older system, first check your app with syspolicy_check on macOS 14 or later. If you can’t run the syspolicy_check tool, or it doesn’t report anything actionable, continue your investigation using the instructions in the following sections. App Blocked by Gatekeeper If your product is an app and it works correctly when not quarantined but is blocked by Gatekeeper when it is, you have a Gatekeeper problem. For advice on how to investigate such issues, see Resolving Gatekeeper Problems. App Can’t Be Opened Not all failures to launch are Gatekeeper errors. In some cases the app is just broken. For example: The app’s executable might be missing the x bit set in its file permissions. The app’s executable might be subtly incompatible with the current system. A classic example of this is trying to run a third-party app that contains arm64e code on systems prior to macOS 26 beta. macOS 26 beta supports arm64e apps directly. Prior to that, third-party products (except kernel extensions) were limited to arm64, except for the purposes of testing. The app’s executable might claim restricted entitlements that aren’t authorised by a provisioning profile. Or the app might have some other code signing problem. Note For more information about provisioning profiles, see TN3125 Inside Code Signing: Provisioning Profiles. In such cases the system displays an alert saying: The application “NoExec” can’t be opened. [[OK]] Note In macOS 11 this alert was: You do not have permission to open the application “NoExec”. Contact your computer or network administrator for assistance. [[OK]] which was much more confusing. A good diagnostic here is to run the app’s executable from Terminal. For example, an app with a missing x bit will fail to run like so: % NoExec.app/Contents/MacOS/NoExec zsh: permission denied: NoExec.app/Contents/MacOS/NoExec And an app with unauthorised entitlements will be killed by the trusted execution system: % OverClaim.app/Contents/MacOS/OverClaim zsh: killed OverClaim.app/Contents/MacOS/OverClaim In some cases running the executable from Terminal will reveal useful diagnostics. For example, if the app references a library that’s not available, the dynamic linker will print a helpful diagnostic: % MissingLibrary.app/Contents/MacOS/MissingLibrary dyld[88394]: Library not loaded: @rpath/CoreWaffleVarnishing.framework/Versions/A/CoreWaffleVarnishing … zsh: abort MissingLibrary.app/Contents/MacOS/MissingLibrary Code Signing Crashes on Launch A code signing crash has the following exception information: Exception Type: EXC_CRASH (SIGKILL (Code Signature Invalid)) The most common such crash is a crash on launch. To confirm that, look at the thread backtraces: Backtrace not available For steps to debug this, see Resolving Code Signing Crashes on Launch. One common cause of this problem is running App Store distribution-signed code. Don’t do that! For details on why that’s a bad idea, see Don’t Run App Store Distribution-Signed Code. Code Signing Crashes After Launch If your program crashes due to a code signing problem after launch, you might have encountered the issue discussed in Updating Mac Software. Non-Code Signing Failures After Launch The hardened runtime enables a number of security checks within a process. Some coding techniques are incompatible with the hardened runtime. If you suspect that your code is incompatible with the hardened runtime, see Resolving Hardened Runtime Incompatibilities. App Sandbox Inheritance If you’re creating a product with the App Sandbox enabled and it crashes with a trap within _libsecinit_appsandbox, it’s likely that you’re having App Sandbox inheritance problems. For the details, see Resolving App Sandbox Inheritance Problems. Library Loading Problem Most library loading problems have an obvious cause. For example, the library might not be where you expect it, or it might be built with the wrong platform or architecture. However, some library loading problems are caused by the trusted execution system. For the details, see Resolving Library Loading Problems. Explore the System Log If none of the above resolves your issue, look in the system log for clues as to what’s gone wrong. Some good keywords to search for include: gk, for Gatekeeper xprotect syspolicy, per the syspolicyd man page cmd, for Mach-O load command oddities amfi, for Apple mobile file integrity, per the amfid man page taskgated, see its taskgated man page yara, discussed in Apple Platform Security ProvisioningProfiles You may be able to get more useful logging with this command: % sudo sysctl -w security.mac.amfi.verbose_logging=1 Here’s a log command that I often use when I’m investigating a trusted execution problem and I don’t know here to start: % log stream --predicate "sender == 'AppleMobileFileIntegrity' or sender == 'AppleSystemPolicy' or process == 'amfid' or process == 'taskgated-helper' or process == 'syspolicyd'" For general information the system log, see Your Friend the System Log. Revision History 2025-08-06 Added the Run a System Policy Check section, which talks about the syspolicy_check tool (finally!). Clarified the discussion of arm64e. Made other editorial changes. 2024-10-11 Added info about the security.mac.amfi.verbose_logging option. Updated some links to point to official documentation that replaces some older DevForums posts. 2024-01-12 Added a specific command to the Explore the System Log section. Change the syspolicy_check callout to reflect that macOS 14 is no longer in beta. Made minor editorial changes. 2023-06-14 Added a quick call-out to the new syspolicy_check tool. 2022-06-09 Added the Non-Code Signing Failures After Launch section. 2022-06-03 Added a link to Don’t Run App Store Distribution-Signed Code. Fixed the link to TN3125. 2022-05-20 First posted.

This post is a ‘child’ of Resolving errSecInternalComponent errors during code signing. If you found your way here directly, I recommend that you start at the top. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Fixing an untrusted code-signing certificate If your code-signing identity is set up correctly, selecting its certificate in Keychain Access should display a green checkmark with the text “This certificate is valid”. If it does not, you need to fix that before trying to sign code. There are three common causes of an untrusted certificate: Expired Missing issuer Trust settings overrides Check for an expired certificate If your code-signing identity’s certificate has expired, Keychain Access shows a red cross with the text “… certificate is expired”. If you try to sign with it, codesign will fail like so: % codesign -s "Apple Development" -f "MyTrue" error: The specified item could not be found in the keychain. If you use security to list your code-signing identities, it will show the CSSMERR_TP_CERT_EXPIRED status: % security find-identity -p codesigning Policy: Code Signing Matching identities 1) 4E587951B705280CBB8086325CD134D4CDA04977 "Apple Development: …" (CSSMERR_TP_CERT_EXPIRED) 1 identities found Valid identities only 0 valid identities found The most likely cause of this problem is that… yep… your certificate has expired. To confirm that, select the certificate in Keychain Access and look at the Expires field. Or double click the certificate, expand the Details section, and look at the Not Valid Before and Not Valid After fields. If your code-signing identity’s certificate has expired, you’ll need to renew it. For information on how to do that, see Developer Account Help. If your certificate hasn’t expired, check that your Mac’s clock is set correctly. Check for a missing issuer In the X.509 public key infrastructure (PKI), every certificate has an issuer, who signed the certificate with their private key. These issuers form a chain of trust from the certificate to a trusted anchor. In most cases the trusted anchor is a root certificate, a certificate that’s self signed. Certificates between the leaf and the root are known as intermediate certificates, or intermediates for short. Your code-signing identity’s certificate is issued by Apple. The exact chain of trust depends on the type of certificate and the date that it was issued. For example, in 2022 Apple Development certificates are issued by the Apple Worldwide Developer Relations Certification Authority — G3 intermediate, which in turn was issued by the Apple Root CA certificate authority. If there’s a missing issuer in the chain of trust between your code-signing identity’s certificate and a trusted anchor, Keychain Access shows a red cross with the text “… certificate is not trusted”. If you try to sign with it, codesign will fail like so: % codesign -s "Apple Development" -f "MyTrue" MyTrue: replacing existing signature Warning: unable to build chain to self-signed root for signer "Apple Development: …" MyTrue: errSecInternalComponent The message unable to build chain to self-signed root for signer is key. If you use security to list your identities, it will not show up in the Valid identities only list but there’s no explanation as to why: % security find-identity -p codesigning Policy: Code Signing Matching identities 1) 4E587951B705280CBB8086325CD134D4CDA04977 "Apple Development: …" 1 identities found Valid identities only 0 valid identities found IMPORTANT These symptoms can have multiple potential causes. The most common cause is a missing issuer, as discussed in this section. Another potential cause is a trust settings override, as discussed in the next section. There are steps you can take to investigate this further but, because this problem is most commonly caused by a missing intermediate, try taking a shortcut by assuming that’s the problem. If that fixes things, you’re all set. If not, you have at least ruled out this problem. Apple publishes its intermediates on the Apple PKI page. The simplest way to resolve this problem is to download all of the certificates in the Apple Intermediate Certificates list and use Keychain Access to add them to your keychain. Having extra intermediates installed is generally not a problem. If you want to apply a more targeted fix: In Keychain Access, find your code-signing identity’s certificate and double click it. If the Details section is collapsed, expand it. Look at the Issuer Name section. Note the value in the Common Name field and, if present, the Organizational Unit field. For example, for an Apple Development certificate that’s likely to be Apple Worldwide Developer Relations Certification Authority and G3, respectively. Go to the Apple PKI and download the corresponding intermediate. To continue the above example, the right intermediate is labelled Worldwide Developer Relations - G3. Use Keychain Access to add the intermediate to your keychain. Sometimes it’s not obvious which intermediate to choose in step 4. If you’re uncertain, download all the intermediates and preview each one using Quick Look in the Finder. Look in the Subject Name section for a certificate whose Common Name and Organizational Unit field matches the values from step 3. Finally, double check the chain of trust: In Keychain Access, select your code-signing identity’s certificate and choose Keychain Access > Certificate Assistant > Evaluate. In the resulting Certificate Assistant window, make sure that Generic (certificate chain validation only) is selected and click Continue. It might seem like selecting Code Signing here would make more sense. If you do that, however, things don’t work as you might expect. Specifically, in this case Certificate Assistant is smart enough to temporarily download a missing intermediate certificate in order to resolve the chain of trust, and that’ll prevent you from seeing any problems with your chain of trust. The resulting UI shows a list of certificates that form the chain of trust. The first item is your code-signing identity’s certificate and the last is an Apple root certificate. Double click the first item. Keychain Access presents the standard the certificate trust sheet, showing the chain of trust from the root to the leaf. You should expect to see three items in that list: An Apple root certificate An Apple intermediate Your code-signing identity’s certificate If so, that’s your chain of trust built correctly. Select each certificate in that list. The UI should show a green checkmark with the text “This certificate is valid”. If you see anything else, check your trust settings as described in the next section. Check for a trust settings override macOS allows you to customise trust settings. For example, you might tell the system to trust a particular certificate when verifying a signed email but not when connecting to a TLS server. The code-signing certificates issued by Apple are trusted by default. They don’t require you to customise any trust settings. Moreover, customising trust settings might cause problems. If code signing fails with the message unable to build chain to self-signed root for signer, first determine the chain of trust per the previous section then make sure that none of these certificates have customised trust settings. Specifically, for each certificate in the chain: Find the certificate in Keychain Access. Note that there may be multiple instances of the certificate in different keychains. If that’s the case, follow these steps for each copy of the certificate. Double click the certificate to open it in a window. If the Trust section is collapsed, expand it. Ensure that all the popups are set to their default values (Use System Defaults for the first, “no value specified” for the rest). If they are, move on to the next certificate. If not, set the popups to the default values and close the window. Closing the window may require authentication to save the trust settings. Another way to explore trust settings is with the dump-trust-settings subcommand of the security tool. On a stock macOS system you should see this: % security dump-trust-settings SecTrustSettingsCopyCertificates: No Trust Settings were found. % security dump-trust-settings -d SecTrustSettingsCopyCertificates: No Trust Settings were found. That is, there are no user or admin trust settings overrides. If you run these commands and see custom trust settings, investigate their origins. IMPORTANT If you’re working in a managed environment, you might see custom trust settings associated with that environment. For example, on my personal Mac I see this: % security dump-trust-settings -d Number of trusted certs = 1 Cert 2: QuinnNetCA Number of trust settings : 10 … because my home network infrastructure uses a custom certificate authority and I’ve configured my Mac to trust its root certificate (QuinnNetCA). Critically, this custom trust settings are nothing to do with code signing. If you dump trust settings and see an override you can’t explain, and specifically one related to code-signing certificate, use Keychain Access to remove it. Revision History 2025-09-29 Added information about the dump-trust-settings command to Check for a trust settings override. Made other minor editorial changes. 2022-08-10 First posted.

I regularly see folks run into problems with their Developer ID signing identities. Historically I pointed them to my posts on this thread, but I’ve decided to collect these ideas together in one place. If you have questions or comments, start a new thread here on DevForums and tag it with Developer ID so that I see it. IMPORTANT Nothing I write here on DevForums is considered official documentation. It’s just my personal ramblings based on hard-won experience. There is a bunch of official documentation that covers the topics I touch on here, including: Xcode documentation Xcode Help Developer Account Help Developer > Support > Certificates For a lot more information about code signing, see the Code Signing Resources pinned post. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" The Care and Feeding of Developer ID Most Apple signing assets are replaceable. For example, if you accidentally lose access to your Apple Development signing identity, it’s a minor inconvenience. Just use the Developer website to revoke your previous certificate and create a replacement. Or have Xcode do that for you. IMPORTANT If you don’t understand the difference between a certificate and a digital identity, and hence signing identity, read Certificate Signing Requests Explained before reading this post. Some signing assets are precious. Losing access to such assets has significant consequences. Foremost amongst those are Developer ID signing identities. These allow you to sign Mac products that ship independently. Anyone with access to your Developer ID signing identity can sign code as you. This has a number of consequences, both for you and for your relationship with Apple. Identify a Developer ID Signing Identity A Developer ID signing identity consists of two parts: the certificate and the private key. There are two different flavours, identifiable by the subject name in the certificate: Developer ID Application — This is named Developer ID Application: TTT, where TTT identifies your team. Use this to sign code and disk images. Developer ID Installer — This is named Developer ID Installer: TTT, where TTT identifies your team. Use this to sign installer packages. Note If you do KEXT development, there’s a third flavour, namely a KEXT-enabled Developer ID Application signing identity. For more details, see KEXT Code Signing Problems. This post focuses on traditional signing identities, where you manage the private key. Xcode Cloud introduced cloud signing, where signing identities are “stored securely in the cloud”. These identities have the Managed suffix in Certificates, Identifiers, and Profiles. For example, Developer ID Application Managed is the cloud signing equivalent of Developer ID Application. To learn more about cloud signing, watch WWDC 2021 Session 10204 Distribute apps in Xcode with cloud signing. To identify these certificates ‘in the wild’, see Identifying a Cloud Managed Signing Certificate. Limit Access to Developer ID Anyone with your Developer ID signing identity can sign code as you. Given that, be careful to limit access to these signing identities. This is true both for large organisations and small developers. In a large organisation, ensure that only folks authorised to ship code on behalf of your organisation have access to your Developer ID signing identities. Most organisations have some sort of release process that they use to build, test, and authorise a release. This often involves a continuous integration (CI) system. Restrict CI access to only those folks involved in the release process. Even if you’re a small developer with no formal release process, you can still take steps to restrict access to Developer ID signing identities. See Don’t Leak Your Private Key, below. In all cases, don’t use your Developer ID signing identities for day-to-day development. That’s what Apple Development signing identities are for. Create Developer ID Signing Identities as the Account Holder Because Developer ID signing identities are precious, the Developer website will only let the Account Holder create them. For instructions on how to do this, see Developer Account Help > Create certificates > Create Developer ID certificates. For more information about programme roles, see Developer > Support > Program Roles. IMPORTANT In an Organization team it’s common for the Account Holder to be non-technical. They may need help getting this done. For hints and tips on how to avoid problems while doing this, see Don’t Lose Your Private Key and Don’t Leak Your Private Key, both below. Limit the Number of Developer ID Signing Identities You Create Don’t create Developer ID signing identities unnecessarily. Most folks only need to create one. Well, one Developer ID Application and maybe one Developer ID Installer. A large organisation might need more, perhaps one for each sub-unit, but that’s it. There are two reasons why this is important: The more you have, the more likely it is for one to get into the wrong hands. Remember that anyone with your Developer ID signing identity can sign code as you. The Developer website limits you to 5 Developer ID certificates. Note I can never remember where this limit is actually documented, so here’s the exact quote from this page: You can create up to five Developer ID Application certificates and up to five Developer ID Installer certificates using either your developer account or Xcode. Don’t Lose Your Private Key There are two standard processes for creating a Developer ID signing identity: Developer website — See Developer Account Help > Create certificates > Create Developer ID certificates. Xcode — See Xcode Help > Maintaining signing assets > Manage signing certificates. Both processes implicitly create a private key in your login keychain. This makes it easy to lose your private key. For example: If you do this on one Mac and then get a new Mac, you might forget to move the private key to the new Mac. If you’re helping your Organization team’s Account Holder to create a Developer ID signing identity, you might forget to export the private key from their login keychain. It also makes it easy to accidentally leave a copy of the private key on a machine that doesn’t need it; see Don’t Leak Your Private Key, below, for specific advice on that front. Every time you create a Developer ID signing identity, it’s a good idea to make an independent backup of it. For advice on how to do that, see Back Up Your Signing Identities, below. That technique is also useful if you need to copy the signing identity to a continuous integration system. If you think you’ve lost the private key for a Developer ID signing identity, do a proper search for it. Finding it will save you a bunch of grief. You might be able to find it on your old Mac, in a backup, in a backup for your old Mac, and so on. For instructions on how to extract your private key from a general backup, see Recover a Signing Identity from a Mac Backup. If you’re absolutely sure that you previous private key is lost, use the Developer website to create a replacement signing identity. If the Developer website won’t let you create any more because you’ve hit the limit discussed above, talk to Developer Programs Support. Go to Apple > Developer > Contact Us and follow the path Development and Technical > Certificates, Identifiers, and Provisioning Profiles. Don’t Leak Your Private Key Anyone with your Developer ID signing identity can sign code as you. Thus, it’s important to take steps to prevent its private key from leaking. A critical first step is to limit access to your Developer ID signing identities. For advice on that front, see Limit Access to Developer ID, above. In an Organization team, only the Account Holder can create Developer ID signing identities. When they do this, a copy of the identity’s private key will most likely end up in their login keychain. Once you’ve exported the signing identity, and confirmed that everything is working, make sure to delete that copy of the private key. Some organisations have specific rules for managing Developer ID signing identities. For example, an organisation might require that the private key be stored in a hardware token, which prevents it from being exported. Setting that up is a bit tricky, but it offers important security benefits. Even without a hardware token, there are steps you can take to protect your Developer ID signing identity. For example, you might put it in a separate keychain, one with a different password and locking policy than your login keychain. That way signing code for distribution will prompt you to unlock the keychain, which reminds you that this is a significant event and ensures that you don’t do it accidentally. If you believe that your private key has been compromised, follow the instructions in the Compromised Certificates section of Developer > Support > Certificates. IMPORTANT Don’t go down this path if you’ve simply lost your private key. Back Up Your Signing Identities Given that Developer ID signing identities are precious, consider making an independent backup of them. To back up a signing identity to a PKCS#12 (.p12) file: Launch Keychain Access. At the top, select My Certificates. On the left, select the keychain you use for signing identities. For most folks this is the login keychain. Select the identity. Choose File > Export Items. In the file dialog, select Personal Information Exchange (.p12) in the File Format popup. Enter a name, navigate to your preferred location, and click Save. You might be prompted to enter the keychain password. If so, do that and click OK. You will be prompted to enter a password to protect the identity. Use a strong password and save this securely in a password manager, corporate password store, on a piece of paper in a safe, or whatever. You might be prompted to enter the keychain password again. If so, do that and click Allow. The end result is a .p12 file holding your signing identity. Save that file in a secure location, and make sure that you have a way to connect it to the password you saved in step 9. Remember to backup all your Developer ID signing identities, including the Developer ID Installer one if you created it. To restore a signing identity from a backup: Launch Keychain Access. Choose File > Import Items. In the open sheet, click Show Options. Use the Destination Keychain popup to select the target keychain. Navigate to and select the .p12 file, and then click Open. Enter the .p12 file’s password and click OK. If prompted, enter the destination keychain password and click OK. Recover a Signing Identity from a Mac Backup If you didn’t independently backup your Developer ID signing identity, you may still be able to recover it from a general backup of your Mac. To start, work out roughly when you created your Developer ID signing identity: Download your Developer ID certificate from the Developer website. In the Finder, Quick Look it. The Not Valid Before field is the date you’re looking for. Now it’s time to look in your backups. The exact details depend on the backup software you’re using, but the basic process runs something like this: Look for a backup taken shortly after the date you determined above. In that backup, look for the file ~/Library/Keychains/login.keychain. Recover that to a convenient location, like your desktop. Don’t put it in ~/Library/Keychains because that’ll just confuse things. Rename it to something unique, like login-YYYY-MM-DD.keychain, where YYYY-MM-DD is the date of the backup. In Keychain Access, choose File > Add Keychain and, in the resulting standard file panel, choose that .keychain file. On the left, select login-YYYY-MM-DD. Chose File > Unlock Keychain “login-YYYY-MM-DD“. In the resulting password dialog, enter your login password at the date of the backup. At the top, select My Certificates. Look through the list of digital identities to find the Developer ID identity you want. If you don’t see the one you’re looking for, see Further Recovery Tips below. Export it using the process described at the start of Back Up Your Signing Identities. Once you’re done, remove the keychain from Keychain Access: On the left, select the login-YYYY-MM-DD keychain. Choose File > Delete Keychain “login-YYYY-MM-DD”. In the confirmation alert, click Remove Reference. The login-YYYY-MM-DD.keychain is now just a file. You can trash it, keep it, whatever, at your discretion. This process creates a .p12 file. To work with that, import it into your keychain using the process described at the end of Back Up Your Signing Identities. IMPORTANT Keep that .p12 file as your own independent backup of your signing identity. Further Recovery Tips If, in the previous section, you can’t find the Developer ID identity you want, there are a few things you might do: Look in a different backup. If your account has more than one keychain, look in your other keychains. If you have more than one login account, look at the keychains for your other accounts. If you have more than one Mac, look at the backups for your other Macs. The login-YYYY-MM-DD keychain might have the private key but not the certificate. Add your Developer ID certificate to that keychain to see if it pairs with a private key. Revision History 2025-03-28 Excised the discussion of Xcode’s import and export feature because that was removed in Xcode 16. 2025-02-20 Added some clarification to the end of Don’t Leak Your Private Key. 2023-10-05 Added the Recover a Signing Identity from a Mac Backup and Further Recovery Tips sections. 2023-06-23 Added a link to Identifying a Cloud Managed Signing Certificate. 2023-06-21 First posted.

Hi After I added iCloud container and iCloud documents my UITests can't run anymore what is this problem and how can I solve it? Thanks!

Hi, If an Apple developer subscription account is stopped, how does it affect already signed and and notarized apps? Will all apps and dmg's already signed and notarized in the past still be valid in the future?

Hello, I am on maxOS 14.6 and I developed a C++ application for macOS with graphical-user interface by using wxWidgets. The .app application bundle is built correctly and the application runs. Now I would like to sign it to get it notarized. I get the following error sudo codesign -vvv --deep --strict MyApp.app/Contents/MacOS/MyApp MyApps.app/Contents/MacOS/MyApp: code has no resources but signature indicates they must be present If I check the signature I get % pkgutil --check-signature MyApp.app Package "MyApp": Status: package is invalid (checksum did not verify) How may I fix this? Thank you!

App is built using jdk21, jpackage to create dmg, pulls in the needed jre. Been working fine until about a week ago when notarize start failing bad signing, which when examined it's complaining modified files - a handful of jre license and copyright text files. DMGs built, signed and notarised successfully are now failing codesign verification. Has a macOS 15.1.1 release or Xcode 16.1 patched something, is there new behaviour to be aware of plse?

For some reason Xcode said my certificate was revoked. Developer support says it’s active. Could someone point me towards the steps to reactivate it?

note technically code-signing but related...... Why has there been no update to the documentation at: https://developer.apple.com/documentation/appstorereceipts/validating_receipts_on_the_device To demonstrate how to validate an SHA256 app store hash ??? The January deadline is looming and I can find no working example code which sucessfully validates an SHA256 hash HELP !!!!

Xcode 16.2 無法在IOS 18.2 Debug Xcode 16.2 iOS 18.2 直接建立新專案 Xcode -> Create New Project -> Multiplatform -> Application -> App 選擇 實體手機 -> 執行 error: attach by pid '1050' failed -- attach failed (Not allowed to attach to process. Look in the console messages (Console.app), near the debugserver entries, when the attach failed. The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.) Logging Error: Failed to initialize logging system due to time out. Log messages may be missing. If this issue persists, try setting IDEPreferLogStreaming=YES in the active scheme actions environment variables.

Chrome has started crashing almost immediately after startup. I've reported the issue to the Chrome team here: https://issues.chromium.org/issues/385433270 I'm hoping to debug the issue a bit more myself. This page from the Chrome team https://chromium.googlesource.com/chromium/src/+/master/docs/mac/debugging.md#chrome-builds suggests using the follow to strip off the protections: codesign --force --sign - path/to/Google\ Chrome.app However, applying that seems to have no effect: % codesign --force --sign - /Applications/Google\ Chrome\ copy.app /Applications/Google Chrome copy.app: replacing existing signature /Applications/Google Chrome copy.app: resource fork, Finder information, or similar detritus not allowed % lldb /Applications/Google\ Chrome\ copy.app (lldb) target create "/Applications/Google Chrome copy.app" Current executable set to '/Applications/Google Chrome copy.app' (arm64). (lldb) run error: process exited with status -1 (attach failed (Not allowed to attach to process. Look in the console messages (Console.app), near the debugserver entries, when the attach failed. The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.)) I have tried other variations like the following based on Stack Overflow, this forum, etc., but with the same result. (I'm still a little vague on the meaning for some flags, sorry.) Though codesign says that it's "replacing existing signature", as far as I can tell, nothing is changing: % cat <<EOF > debuggee-entitlement.xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.security.get-task-allow</key> <true/> </dict> </plist> EOF % codesign --verbose=4 -fs - --options library-validation --entitlements debuggee-entitlement.xml /Applications/Google\ Chrome\ copy.app /Applications/Google Chrome copy.app: replacing existing signature /Applications/Google Chrome copy.app: resource fork, Finder information, or similar detritus not allowed file with invalid attached data: Disallowed xattr com.apple.FinderInfo found on /Applications/Google Chrome copy.app lldb still fails the same way. Here's what I see after the above: % codesign -d -vvv /Applications/Google\ Chrome\ copy.app Executable=/Applications/Google Chrome copy.app/Contents/MacOS/Google Chrome Identifier=com.google.Chrome Format=app bundle with Mach-O universal (x86_64 arm64) CodeDirectory v=20500 size=1821 flags=0x12a00(kill,restrict,library-validation,runtime) hashes=46+7 location=embedded Hash type=sha256 size=32 CandidateCDHash sha256=5d7beab2b03d9892426076b24acc19815d7a3ff8 CandidateCDHashFull sha256=5d7beab2b03d9892426076b24acc19815d7a3ff8c1446966e422c3c10672626b Hash choices=sha256 CMSDigest=5d7beab2b03d9892426076b24acc19815d7a3ff8c1446966e422c3c10672626b CMSDigestType=2 CDHash=5d7beab2b03d9892426076b24acc19815d7a3ff8 Signature size=8989 Authority=Developer ID Application: Google LLC (EQHXZ8M8AV) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=Dec 17, 2024 at 2:47:58 PM Notarization Ticket=stapled Info.plist entries=44 TeamIdentifier=EQHXZ8M8AV Runtime Version=15.0.0 Sealed Resources version=2 rules=13 files=63 Internal requirements count=1 size=288 From what I can tell, my codesign runs have changed nothing... I see no diff as compared with what I see running codesign -d on a fresh copy. Is it possible to strip off the protections on my local instance to allow debugging with lldb? If so, could someone share a command for accomplishing that? Although I'm asking about this because of Chrome specifically, I'm hoping to learn more about codesigning in general and to be more empowered as a user to be able to debug when an app I depend on is crashing. Thanks much! Happy Holidays!

I want to code radeem for testflight

I have an executable file named infogodesk, located in the directory /usr/local/SmpAgent/rustdesk/infogodesk. When I execute it using the terminal with ./infogodesk, the process gets terminated by the kernel. However, if I move the executable to another directory, it works fine. This issue is very frustrating, and I hope to get some help. Below is the console log output: 默认 11:26:28.162205+0800 kernel ASP: Validation category (6) does not match top-level policy match (3) for process: /usr/local/SmpAgent/rustdesk/infogodesk 默认 11:26:28.162211+0800 kernel Validation category policy: Notifying syspolicyd about /usr/local/SmpAgent/rustdesk/infogodesk with PID 88264 默认 11:26:28.166695+0800 kernel CODE SIGNING: cs_invalid_page(0x104e04000): p=88264[infogodesk] final status 0x23000200, denying page sending SIGKILL 默认 11:26:28.166698+0800 kernel CODE SIGNING: process 88264[infogodesk]: rejecting invalid page at address 0x104e04000 from offset 0x0 in file "/usr/local/SmpAgent/rustdesk/infogodesk" (cs_mtime:1734509326.0 == mtime:1734509326.0) (depth:0) 默认 11:26:28.166738+0800 kernel infogodesk[88264] Corpse allowed 1 of 5 默认 11:26:28.255182+0800 ReportCrash ASI found [ReportCrash] (sensitive) 'Pid 88264 'infogodesk' CORPSE: Extracting Completed 1, Recent: Pid 86766 'ReportCrash' CORPSE' 默认 11:26:28.261619+0800 ReportCrash ASI found [ReportCrash] (sensitive) 'Pid 88264 'infogodesk' CORPSE: Extracting Completed 1, Recent: Pid 86767 'ReportCrash' CORPSE'

Hi, I am a newbie to this, I am trying to build my own ios phone app. I am using my own phone as the developers phone so its set to debug. Using Flutter I do flutter run. it get so far and always stops on : Could not build the precompiled application for the device. Error (Xcode): Unknown platform: "ios". /Users/admin/group2/ios/Runner/Assets.xcassets Error launching application on iPhone XS Max. I have tried everything, so I thought someone on here might have the answer. I am happy to share any files or anything that you might need to recreate the issue.

ad hoc和enterprise都不行 Team "tao yang (Personal Team)" is not enrolled in the Apple Developer Program.

Short description of the issue/suggestion: After upgrading to MacOS Sequoia and being required to code sign and notarize my app, cannot launch app even though code sign and notarization pass Please tell us about your environment: MacBookPro Chip Apple M2 Max 32 GB JavaPackager version: 1.7.6 OS version: macOS Sequoia 15.0.1 JDK version: jdk-1.8 Build tool: Maven Steps to reproduce the issue: -DMG Maven Build of Spring Boot /Java (version 8) application with "fvarrui" JavaPackager plugin using default universalJavaApplicationStub. Code signing and Notarization / Stapling PASS and App installs in Application folder, however cannot launch App. Although code sign and notarization pass, it is interesting that in the build output, prior to it submitting to Apple, there is an error stating that the App code sign could not be replaced. What is the expected behavior? -App launches when double clicking the application icon What have you tried to resolve / workaround the issue? -Install via package rather than DMG - same result -Can launch App by opening up the app Content/MacOS folder and clicking directly on the universalJavaApplicationStub. Note requires that you allow it to run within the Security and Privacy settings. codesign --verify --deep --verbose force1.app force1.app: valid on disk force1.app: satisfies its Designated Requirement spctl -a -vvv force1.app Info.plist.txt pom.xml.txt f Build Output abridged.txt o SysConsoleOutput.txt r ce1.app: accepted source=Notarized Developer ID origin=Developer ID Application: Neal Hartmann (JPFYU53MK9)

We are using SHC to compile on macOS to convert the .sh script to a binary file. This binary file is then digitally signed by the Apple developer account and then notarised. After that, it will work on the same system where we follow this process. But if we share this file to another system, then it gets quarantined (com.apple.quarantine) while downloading. Is there any way to prevent it by getting quarantine on another system or something I'm missing, any clues?

iPad(第10世代、iOS v18.1)でMDMを使用してWi-Fiを設定すると、「ネットワーク「SSID名」に接続できない」という問題が発生しています。 この件についてアドバイスをいただければ幸いです。 私が取った手順は次のとおりです。 1.iPadをWi-Fiに接続し、Wi-Fi情報(SSID、ユーザー名、パスワード)をカスタム属性値としてMDMに登録します。 2. MDMから、Wi-Fiプロファイルをデバイスに配布します。 3.Wi-Fiプロファイルがデバイスにインストールされ、その後、ネットワークは自動的に切断されます。 ネットワークに再接続 4.To、OS設定の「Wi-Fi > My Network」に表示されているSSIDをタップしてください。 5.次の証明書画面で、「信頼」ボタンをタップします。 ここで、「ネットワーク「SSID名」に接続できません」というエラーが発生しました。 Appleサポートの提案に基づいて、以下を確認しました。しかし、問題はありません。 1.ルーターの電源がオンになっており、デバイスが通信範囲内にあります。 他のデバイスはWi-Fiに接続できるので問題ありません。 2.Wi-Fiがオンになり、ネットワークが認識されていることを確認します。 Wi-Fiが「オン」で、ネットワークが認識されます。 3.入力画面が表示された場合は、Wi-Fiパスワードを入力します。 入力画面が表示されません。 4.Wi-Fiネットワークに問題がないことを確認します。 接続されているWi-Fiネットワークの名前の下にWi-Fi警告/エラーは表示されません。 5.ケーブルと接続状態を確認します。 他のデバイスはWi-Fiに接続できるので問題ありません。 6.iPadを再起動します。 iPadを再起動しました。しかし、問題は解決しませんでした。 OS:iPadOS18.1 デバイス:iPad第10世代