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 Code Signing Identifiers Explained 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"

We maintain a macOS product whose installer uses custom InstallerSection plugin bundles to show configuration panes during install. Starting with macOS 27 beta 6, all of our plugins stopped loading in Installer.app — the panes never appear and the install fails because our preinstall step depends on data the panes collect. The exact same .pkg works on macOS 26.6, and per thread 842811 the same bundles were fine on 27 betas 1–4(I have tested it from beta 6 onwards). While investigating we found what looks like the underlying cause, and it's reproducible by hand. THE FINDING During a failing install, look inside the extracted plugin bundle while the Installer window is still open: ls -la /private/tmp/com.apple.installer*/.bundle/Contents/ That layout fails code-signature validation. You can reproduce the failure manually, no Installer involved: codesign -vvv "/private/tmp/com.apple.installer"*/.bundle → .bundle: Too many levels of symbolic links WHAT THE SYSTEM LOGS SHOW amfid rejects the plugin executable: /private/tmp/com.apple.installerXXXXXX/.bundle/Contents/MacOS/ not valid: Error Domain=AppleMobileFileIntegrityError Code=-420 "The signature on the file is invalid" with repeated "UNIX error exception: 62" (errno 62 = ELOOP, too many levels of symbolic links) in backtraces through BundleDiskRep::component → SecStaticCode::component → validateNonResourceComponents → staticValidateCore, and "Code failed basic validity check (error: 100062)". For a Developer ID–signed plugin the kernel then treats it as fatal: AMFI: When validating /private/tmp/com.apple.installerXXXXXX/.bundle/Contents/MacOS/: The code contains a Team ID, but validating its signature failed. mac_vnode_check_signature: ... code signature validation failed fatally check_signature[pid: N]: error = 1 The plugin is never dlopen'd and the pane never appears. QUESTIONS Is there a way to get Installer to deploy the bundle with real files — or any other workaround? Note : I have Filed via Feedback Assistant as FB24601496; this overlaps FB24415432 / thread https://developer.apple.com/forums/thread/842811, which we've cross-referenced I have experienced this issue on latest Beta 8 build also -27.0 Beta (26A5425a)

Hello, I am very new to programming for iPhone, so please excuse me if this question is ignorant and I'm missing something silly. I am trying to build an app for my phone (iPhone SE 3rd gen) using my Macbook Air (same Apple Account). I downloaded XCode and started with the default "Hello World!" template. I created a personal team and figured out all the settings on my phone (trusted the computer, turned on developer mode, trusted the account). However, after uploading, I get the following error: The weird part is that I have a stable internet and cell connection. Following the instructions given to me in the similar error on my Mac, I head to General -> VPN and Devices -> my account and click "Verify App". This gives me a pop-up: Clicking Verify, it loads for a second and absolutely nothing happens. Not sure how to proceed or what's wrong.

Hello, I am trying to use XCode to generate a 'embedded.provisionprofile' file. My Xcode macos project keeps giving me an error saying: Provisioning profile "BRandNewMebedded" doesn't include signing certificate "Apple Distribution: Martin Barker (LV6WXG529F)". When I download the Provisioning Profile file "BRandNewMebedded" from online, I make sure it has "Mac App Distribution" checked, but even if i edit it to use the first option "Distribution" and re-download it, my XCode keeps saying the same error in red.

M4 Mac Mini: Xcode generates private keys with wrong label - codesigning impossible Background This is a follow up to my November 2024 thread "Keychain issues after installing backup on new Mac" which was closed because I had a temporary workaround. That workaround using my wife's MacBook Air for signing is not sustainable. I used AI assistance to determine the root cause. My DTS case 102877839447 is open but has not yet been forwarded to a DTS engineer. Environment Mac Mini M4, macOS 15.4.1 (Build 25E253) Xcode 26.4.1 (17E202) Team ID: Q23726668V (Computerade Products) Working comparison machine: MacBook Air, macOS 15.3 Precise Bug — Reproducible Every Time Every time Xcode generates a new certificate and key pair on my Mac Mini: Certificate: Apple Development: Michael Birch (9KD5TCGGHG) ✅ Private key: Apple Development: Michael Birch (Computerade Products) ❌ The key uses the organization name instead of the certificate identifier. They never pair as a valid codesigning identity. security find-identity -v -p codesigning always returns 0 valid identities. Cryptographic Evidence The internal application labels confirm the keys are cryptographically unrelated to their certificates: Key internal application label: 53C26EB056997276B5E938258D00665ACABD1F0F Certificate public key hash: 57cd1af4a9162f26b1a6d750e05a63a2166b75ff These do not match ❌ Confirmed Eliminated As Causes Keychain search list corruption — found and fixed Partition list — set correctly Access control — set to allow all applications Full Disk Access — granted to Xcode Xcode caches and preferences — completely cleared Login keychain — completely reset Orphaned certificates and keys — all removed SIP enabled, system fully up to date Valid P12 Import Also Fails A p12 exported from the working MacBook Air and cryptographically verified as a matched pair also fails on the Mac Mini: security import returns MAC verification failed Keychain Access import returns OSStatus -2 Importing certificate and key separately as PEM files succeeds but they are not recognized as a valid identity pair despite matching application labels A3F3F193B7896DA9055353F59AB450778CB09AE7 Question Is there a known issue with M4 Mac Mini keychain infrastructure where private keys are generated with incorrect internal application labels? Is there a lower level diagnostic or fix beyond what the security command provides? The problem is specific to my Mac Mini M4 and persisted thru more than a year of Mac OS and xCode updates.

Installing a development build on a physical iPhone fails with: 0xE8008018 - The identity used to sign the executable is no longer valid. On the same Mac, same iPhone, same codebase and same Xcode, switching to a free personal Apple ID team installs and runs with no error. Only builds signed with our paid organisation team fail. Nothing else changes between the two runs. We have already regenerated certificates and provisioning profiles, deleted the profiles folder, cleared DerivedData, removed old identities from the keychain, trusted the profile on device, and tried both automatic and manual signing. None of it changes the result. We have also gone through the existing threads on this error and none of the suggested fixes apply. The build validates locally but the device rejects the identity. Since the signing team is the only variable between success and failure, what should we be looking at? A support case is open with Developer Support but we have not had a technical response yet.

Hi Apple DTS and community, My developer account's app has been granted the Default Mail App managed capability (com.apple.developer.mail-client). The capability works for Development and App Store Connect distribution, but it is not enabled for Ad Hoc distribution. This prevents us from using our Xcode Cloud “Archive & TestFlight” workflow: The archive succeeds. Development and App Store Connect exports succeed. Xcode Cloud then automatically attempts an Ad Hoc export. The Ad Hoc export fails, causing the entire archive action to fail and the TestFlight post-action to be skipped. The export log reports: Entitlement com.apple.developer.mail-client not found and could not be included in profile. This likely is not a valid entitlement and should be removed from your entitlements file. We have reproduced this in two consecutive Xcode Cloud runs. We also confirmed that: The App ID has the Default Mail App capability enabled. The entitlement is present and correctly spelled in the app’s entitlements file. The App ID’s provisioning support lists Development and App Store Connect, but not Ad Hoc. Our Xcode Cloud workflow does not expose an option to disable the automatically attempted Ad Hoc export. This appears to match these previous reports: https://developer.apple.com/forums/thread/774506 — a DTS engineer enabled Ad Hoc support for the entitlement, after which the developer confirmed the issue was resolved. https://developer.apple.com/forums/thread/800072 — DTS confirmed that the Ad Hoc distribution option must be enabled for the Default Mail App managed capability. We also opened an Apple Developer Support case (102945477410). Developer Support directed us to the forums and indicated that this issue would need to be handled by DTS engineers. I can provide our Team ID, Developer Support case number, Xcode Cloud run identifiers, and any other account details privately if needed. Thank you!

I have an app for iOS already on the AppStore and I'm trying to add a macOS version of it. The AppID prefix for this app is different than my Team ID. This mismatch was always fine for submitting my iOS app. However for some reason, the macOS version gets rejected when I upload it. It tells me the AppID prefix must match my Team ID. I do not control my TeamID and I do not control my AppID prefix, they are both given to me by Apple. Yet the error message tells me they must match. How do I get past this? Here is the error message: Validation failed Invalid code signing entitlements. Your application bundle's signature contains code signing entitlements that aren't supported on macOS. Specifically, the "APPID_PREFIX.MY_BUNDLE_ID" value for the com.apple.application-identifier key in "MY_PACKAGE" isn't supported. This value should be a string that starts with your Team ID, followed by a dot ('"), followed by the bundle ID. (ID: 930b77ae-099f-4798-a14a-2803f2a9be9e) Thanks in advance for any pointer.

Hello, We are experiencing an issue where our recent notarization submissions are stuck indefinitely in the "In Progress" status, and no notarization logs are available to inspect. Here are the details for our impacted submissions: Team ID: 34AC638RKM Submission ID 1: 18020127-4742-4d5f-8f56-9742e1aab766 (Submitted: 2026-07-31 13:22 UTC) Submission ID 2: f00b0f39-8b6e-4b80-aaad-dd1690cc7d85 (Submitted: 2026-07-31 21:23 UTC) Prior submissions in June were accepted without issue using the same build pipeline and signing configuration. Is there a known backend delay with the notary service, or can an Apple engineer assist in checking the status of these submission tickets? Thank you!

Hi everyone, We're migrating our iOS app from Auth0 custom scheme callbacks to HTTPS Universal URLs using ASWebAuthenticationSession. We've configured everything correctly, but webcredentials only works when using ?mode=developer suffix in our entitlements, which is not allowed for App Store submissions. The Issue Without ?mode=developer: Error Domain=com.apple.AuthenticationServices.WebAuthenticationSession Code=1 "Application with identifier com.example.myapp is not associated with domain auth.example.com. Using HTTPS callbacks requires Associated Domains using the webcredentials service type for auth.example.com." With ?mode=developer: webcredentials:auth.example.com?mode=developer Works perfectly! Questions Why does it work with ?mode=developer but not without it, even though Apple's CDN has the correct AASA? Is there a way to force iOS to re-verify associated domains without requiring users to delete and reinstall? How will this affect existing users who update the app? Will they need to reinstall? Is there a known propagation delay beyond the CDN showing correct data? Any guidance would be greatly appreciated. We cannot ship to the App Store with ?mode=developer, but without it, the authentication fails. Thank you!

I came across your contact on the Apple Developer Forums. I'm encountering an unusual issue during the notarization process. The error message states: "Team is not yet configured for notarization. Please contact Developer Programs Support at developer.apple.com under the topic Development and Technical / Other Development or Technical Questions." Any guidance you could provide would be greatly appreciated. Here are the error details for reference: json { "logFormatVersion": 1, "jobId": "b6023a7c-dc85-4fa5-91dd-fba92c9ed831", "status": "Rejected", "statusSummary": "Team is not yet configured for notarization. Please contact Developer Programs Support at developer.apple.com under the topic Development and Technical / Other Development or Technical Questions.", "statusCode": 7000, "archiveFilename": "Bytemonk.dmg", "uploadDate": "2025-07-02T07:07:07.945Z", "sha256": "b9494170cc040a76045ed263de22e6b89a5455142af16ce502530e1c1ee72ddf", "ticketContents": null, "issues": null }

All our workflows started to fail today due to timeouts - the notarization process is unable to finish in under 1 hour. The latest submission ID that failed after 45mins: 7449abcb-0d24-441b-a992-d5c7e7d279e3 It has never been a problem for us for the past years - is there something off on Apple side?

I’m seeing several Developer ID notarization submissions stuck in “In Progress” after an app transfer. This is for a macOS app distributed outside the Mac App Store. The app was recently transferred to a new Apple Developer team. After the transfer, notarization uploads succeed, but the submissions never complete. The app appears to be Developer ID signed correctly with the new team. I submitted the app through both Xcode Direct Distribution and command-line notarytool. The upload succeeds, but the submissions remain in “In Progress”, and no notarization log is available. Example submission IDs: 5e411dc6-0610-4f9c-8eef-e2a3d0b6a2fb 01bdeeda-3c7e-421a-ae72-6dc081b75e79 986b0c5e-e32f-489f-bc86-3b3c7d7ec91d 193f29b7-b23a-40e7-8324-c076859ca843 notarytool log returns: Submission log is not yet available or submissionId does not exist I also see older submissions from the previous day still stuck in “In Progress”, so this does not look like a normal notarization delay. I’m trying to determine whether this is caused by the recent app transfer / Team ID change, or whether there is anything else I can check locally. Questions: Is it expected for Developer ID notarization jobs to remain “In Progress” for more than a day with no log available? Is there any known issue with Developer ID notarization after an app transfer? If the upload succeeds but no log is ever generated, is there a recommended escalation path for stuck notarization backend jobs?

I work for a company which develops as part of our product suite a System Extension implementing an Endpoint Security client. Our local developer workflow for testing and validating changes is to build locally with Developer certificates (not a legitimate/production Developer ID certificate) and deploy local builds in to a VM, where to get the System Extension to load and be accepted we need to disable SIP & AMFI. macOS 27 VM is refusing to allow me to disable SIP. Is there an alternate approach we can use for this workflow to allow macOS VMs to accept our software when signing with a (same teamID, but different certificate to the provisioningprofile) developer certificate for local validation?

I have run into an interesting topic today. So far, I have been under the impression that when I am using the setCodeSigningRequirement() function on an NSXPCConnection, I am completely removing any chance of receiving AND sending messages to untrusted XPC Peers. However, I created a malicious replacement for my daemon, and I wanted to check if my application can still send and receive messages to it. I checked with codesign --verify that the replacement does NOT fulfil the code signing requirement. I put a system log instruction in the malicious tool's XPC function. When calling the XPC Peer, I expected to see: XPC connection to <redacted> failed! [Error Domain=NSCocoaErrorDomain Code=4102 "The code signature requirement failed." UserInfo={NSDebugDescription=The code signature requirement failed.}] and I did. However, I also saw the system log from the malicious tool's XPC function. Then, I checked all XPC documentation, and I found for the original C implementation - xpc_connection_set_peer_code_signing_requirement() - the following in the discussion section: All messages received on this connection will be checked to ensure they come from a peer who satisfies the code signing requirement. For a listener connection, requests that do not satisfy the requirement are dropped. When a reply is expected on the connection and the peer does not satisfy the requirement XPC_ERROR_PEER_CODE_SIGNING_REQUIREMENT will be delivered instead of the reply. (this is in xpc/connection.h) which seems to align with the observed results. However, this is (embarassingly?) new for me, I would have never expected this, given how in my head pre-checking before any connection is made seems straightforward, even with public Apple SDK APIs: Grab a SecCode (not SecStaticCode) object of the daemon (malicious or not). This is running code, so it cannot be substituted between the check and the outgoing message. Perform validations on the SecCode object in some form - on macOS 15.0+ it's pretty easy with LightweightCodeRequirement's SecCodeCheckValidityWithProcessRequirement(). Immediately drop the connection if the peer is untrusted, before any message is sent. Am I overlooking something or making wrong assumptions here? or Am I right and this is something that I have to accept that's implemented less than ideally and I can perform above steps 1-3 myself and make a difference? Thanks in advance!

Two months ago we got approval for using the Notification Filtering entitlement. We rushed out to implement it in our app, only to find out that the permission was set for the wrong bundle identifier. We expected to get the permission for the notification extension's bundle identifier, yet it is added for the main app's bundle identifier. Per the official docs, the entitlement permission should be in the notification service extension target: After you receive permission to use the entitlement, add com.apple.developer.usernotifications.filtering to the entitlements file in the Notification Service Extension target. However, this fails to get signed when compiling for non-simulator targets because of the bundle mismatch issue. Simulator perfectly filters notifications. Adding the entitlement to the main app does compile, but filtering does not work (as expected). We reached out to Apple twice (Case-ID: 14330583) but we have yet to receive any response. Could there be something else wrong instead of the identifier mismatch?

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 IMPORTANT When investigating code signing problems, don’t use sudo to run commands as root. This is a common source of confusion. I explain why in Resolving errSecInternalComponent errors during code signing. 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 2026-07-02 Added a warning not to run tests using sudo. 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.

One code signing issue I commonly see, both here on DevForums and in my Day Job™ with DTS, is that the codesign command fails with errSecInternalComponent. This issue crops up in a wide variety of circumstances and the correct fix depends on the specific problem. This post is my attempt to clarify the potential causes of this error and help folks resolve it. If you have any questions or comments about this, please start a new thread, tagging it with Code Signing so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Resolving errSecInternalComponent errors during code signing In some circumstances the codesign command might fail with the error errSecInternalComponent. For example: % codesign -s "Apple Development" "MyTrue" MyTrue: errSecInternalComponent This typically affects folks who are signing code in a nonstandard environment, for example, when logged into a Mac via SSH or when signing code on a continuous integration (CI) server. This post explains how to resolve such issues, starting in the simplest case, signing from Terminal app, and then going on to discuss SSH and other contexts. IMPORTANT Before going further, make sure you understand the difference between a digital identity and a certificate. See TN3161 Inside Code Signing: Certificates for the details. Test from Terminal Code signing makes extensive use of the keychain, and that’s sensitive to the execution context in which it’s running. So, the first step in resolving this problem is to test your code signing from Terminal. To start, log in to the Mac using the GUI. Note If you don’t have access to the GUI, see Working without the GUI, below. Check that Keychain Access shows that your code signing identity’s certificate is trusted. Select the certificate and look for a green checkmark with the text “This certificate is valid”. If you see a red cross with an explanatory text like “… certificate is not trusted”, follow the instructions in Fixing an untrusted code signing certificate. Note macOS 15 moved Keychain Access out of the Utilities folder. The easiest way to find and launch Keychain Access is to use Spotlight. In Terminal, run the security tool to check that your code signing identity is available: % security find-identity -p codesigning Policy: Code Signing Matching identities 1) 4E587951B705280CBB8086325CD134D4CDA04977 "Apple Development: …" 1 identities found Valid identities only 1) 4E587951B705280CBB8086325CD134D4CDA04977 "Apple Development: …" 1 valid identities found If the identity is missing from the Matching identities list, you don’t have a code signing identity to sign with. If you see your code signing identity’s certificate in the keychain, it’s possible that you’re missing its private key. See Certificate Signing Requests Explained for more about that issue. If the identity is shown in the Matching identities list but not in the Valid identities only list, see Fixing an untrusted code signing certificate. This example assumes that you’re testing with an Apple Development signing identity. If you’re using something else, you’ll see a different identity name in this list. Use that identity name in the codesign command below. Still in Terminal, make a copy of the true tool to use for this test: % cp "/usr/bin/true" "MyTrue" Try to sign it: % codesign -s "Apple Development" -f "MyTrue" MyTrue: replacing existing signature The -f flag tells codesign to replace the existing signature. This command may display one or more keychain dialogs but, once you respond to those, it should correctly sign MyTrue. If it doesn’t, skip down to the Terminal failure section at the end of this post. Eliminate keychain alerts When you signed your code in the previous section, you may have seen one of two different types of keychain alerts: Keychain unlock dialog Access control list (ACL) dialog The keychain unlock dialog looks like this: codesign wants to use the … keychain. Please enter the keychain password. Password: [ ] [Cancel] [[OK]] The keychain containing your code signing identity is locked, and you must enter the keychain password to unlock it. You rarely see this dialog when logged in via the GUI because the system automatically unlocks the login keychain when you log in. However, the underlying cause of this alert will become relevant in the next section, when you log in via SSH. The ACL dialog looks like this: codesign wants to sign using key … in your keychain. To allow this, enter the … keychain password. Password: [ ] [Always Allow] [Deny] [[Allow]] The ACL for the your code signing identity’s private key prevents codesign from using the private key without your explicit approval. If you enter your password and click Allow, codesign can use the private key once. If you click Always Allow, the system adds codesign to the private key’s ACL so that it doesn’t have to ask again. To avoid this alert in the future, enter your keychain password and click Always Allow. Now repeat the codesign command from the previous section. It will sign the code without presenting any dialogs. Test over SSH Once you can sign your code in Terminal without seeing any dialogs, it’s time to repeat that process over SSH. To start, log out of the GUI and then log in via SSH. If you’re testing on a CI system, log in to that system by running ssh from Terminal on your Mac. If you want to test on your local Mac, choose one of these options If you have a second Mac, log in to that second Mac using the GUI, launch Terminal, and then run ssh to log in to your main Mac from there. If you have an iPad, use a third-party iPad SSH app to log in to your main Mac over SSH. Use a virtualisation app to run a macOS guest that you can treat like your CI system. Once you’re logged in over SSH, repeat the signing command from the earlier section: % codesign -s "Apple Development" -f "MyTrue" MyTrue: replacing existing signature MyTrue: errSecInternalComponent This fails because: The system locked the keychain when you logged out of the GUI. Logging in via SSH does not unlock the keychain. When codesign tries to use your code signing identity, the system attempts to present the keychain unlock dialog. That fails because you’re logged in via SSH and thus don’t have access to the GUI. The system returns the errSecInternalComponent error to codesign, which reports it to you. To fix this, unlock your keychain using the security tool: % security unlock-keychain password to unlock default: KEYCHAIN_PASSWORD % codesign -s "Apple Development" -f "MyTrue" MyTrue: replacing existing signature IMPORTANT This assumes that your code signing identity is in your login keychain. If it’s in some other keychain, read the security man page to learn how to unlock a specific keychain. Best practice is to store both parts of your code signing identity (the certificate and the private key) in the same keychain. If you split the identity across two keychains, unlock the keychain that contains the private key. Test your CI job Once you have everything working on your CI system over SSH, try running exactly the same commands in your CI job. If your CI system manages user contexts correctly, those commands should just work. If they don’t, discuss this with your CI vendor. Note macOS has a complex execution context model. For background on this, see the Execution Contexts section of Technote 2083 Daemons and Agents. Some CI systems don’t correctly establish a user context when running jobs. For example, they might switch the traditional Unix execution context — the EUID, RUID, and so on — but not the security context. This mixed execution context causes problems for the keychain, which relies on the security context. Avoid doing code signing work as root. Some folks run everything as root because they think it’ll avoid problems. When working with the keychain the opposite is true: Running as root often causes more problems than it solves. These problems are most likely to show up when you use sudo, which creates a mixed execution context. Working without the GUI The instructions above assume you have access to the GUI so that you can test and resolve issues using GUI tools like Keychain Access. However, many CI systems don’t give you access to the GUI; at best you might have interactive access using SSH. Note If you CI system allows remote access using a screen sharing protocol, use that rather than messing around with the instructions here. If you don’t have access to the GUI of the machine on which you’re signing code, there are three issues to deal with: Avoiding the keychain unlock dialog Avoiding the ACL dialog Investigating an untrusted code signing certificate issue To unlock the keychain, use the unlock-keychain subcommand of the security tool, discussed in the Test over SSH section earlier. When logged in with the GUI, you can respond to ACL dialog by clicking Always Allow. This prevents that dialog showing up again. However, if you don’t have GUI access there’s no way to click that button. To get around this, import your signing identity and set its ACL to allow codesign to use it without extra authorisation. To do this, first unlock the keychain: % security unlock-keychain password to unlock default: KEYCHAIN_PASSWORD Then use the security tool to import the PKCS#12 file: % security import IDENTITY.p12 -T /usr/bin/codesign -P P12_PASSWORD 1 identity imported. Note the -T option, which adds codesign to the private key’s ACL. Finally, modify the partition list to allow access by Apple code: % security set-key-partition-list -S "apple:" -l "Apple Development: …" This example assumes you’re using an Apple Development signing identity to test with. If you’re using something else, replace Apple Development: … with that identity name. Finally, investigating an untrusted code signing certificate issue remotely is quite challenging. Your best option here is to set up a local test environment, run your investigation in that environment, and then apply the results to your CI environment. There are two good choices for your local test environment: Use a virtualisation app to create a ‘clean’ macOS guest, one that’s never seen your code signing setup before. Use System Settings > Users & Groups to create a new local user account and do your testing there. The first option is best because you can easily restore your VM to a clean state between tests. When running through the process described in Fixing an untrusted code signing certificate, you might end up performing two different remedial actions: Importing an intermediate Reseting trust settings. Once you understand these remediations, you need to apply them to your CI system. The first one is easy: To import an intermediate, run security with the import subcommand: % security import INTERMEDIATE.cer 1 certificate imported. Resetting trust settings is more of a challenge. It’s probably possible to do this with the security tool but, honestly, if you think that your CI system has messed up trust settings it’s easiest to throw it away and start again from scratch. Terminal failure The bulk of this post assumes that the process described in the Test from Terminal section works. If it doesn’t, something weird is happening and you should apply the following diagnostic suggestions. The first is to create a new local user account on your Mac — using System Settings > Users & Groups — and then retry there. The goal of this test is to isolate: A problem that affects your Mac as a whole From a problem that’s tied to your user account If the problem is with your user account, switch back to your original account and run: % security dump-trust-settings SecTrustSettingsCopyCertificates: No Trust Settings were found. In most cases this should report that no trust settings were found. If it report trust setting overrides, remove them. See Check for a trust settings override in Fixing an untrusted code signing certificate. If that doesn’t resolve the issue, something else is afoot and I recommend that you seek dedicated help per the start of this post. Revision History 2026-07-06 Fixed the breakage from last week’s update. 2026-07-02 Broke the post completely O-: 2024-10-05 Added the Terminal failure section. Made other minor editorial changes. 2022-08-12 Extended the unlock-keychain explanation to cover the split identity issue. 2022-08-11 First posted.

Xcode 27 creates a placeholder for the bundle identifier of a new project. devplaceholder.$(PROJECT_UNIQUE_VALUE:identifier).$(PRODUCT_NAME:identifier) I have two questions. Is it enough to change the bundle id from the Signing & Capabilities panel or do we need to change it somewhere else? What are Apple recommendations? Should we only replace the devplaceholder value and keep the unique value and product name, provide our won id but keep the product name, or replace everything with our own bundle ID? Thanks

We are facing following message "A timestamp was expected but was not found" during codesign for following .dylib and .pkg and it cause notarization process failed. We are facing this issue for last 3 days and we have access for timestamp.apple.com and 17.0.0.0/8 and we didn't change firewall settings. We are facing this issue randomly and not for all time(scenario is 3:1). We tried the below command to sign the package, codesign --verbose --deep --force --timestamp --options=runtime --sign "&lt;CODE SIGN IDENTITY&gt;" &lt;TO BE SIGNED PACAKGE&gt; Kindly let us know how to fix this probelm.