Original Problem We use codesign and notarytool in a scripted environment to build and distribute binaries daily. We also do manual builds by logging into the build server using SSH. This has been working for many years, but after updating to a new "Developer ID Application" certificate, codesign was failing with errSecInternalComponent and the console logs showed errSecInteractionNotAllowed. Summary of Resolution Attempting to fix the problem resulted in multiple copies of the same Certificate which were NOT shown by Keychain Access. I had to run security delete-identity multiple times to clear out the redundant Identities and then imported the certificate using the security CLI tool. Details I originally followed these instructions for requesting and installing a new certificate: https://developer.apple.com/help/account/certificates/create-developer-id-certificates/ Tip: Use the security tool intead These instructions fail to mention two critical points: 1) they assume the machine you generate the request on is the same machine you will be using to perform signatures, and 2) KeyChain Access does not allow you to set permissions for applications like codesign. I made the mistake of following the instructions on my workstation, and then tried to import the certificate to the build machine by double clicking on the .cer file. When that did not work, I followed various forum suggestions and eventually realized I need to export the private key as a .p12 file from the workstation, and import it into the build machine. Tip: The term "Certificate" often refers to a public certificate by itself, while "Identity" to refers to the combination of a public certificate and private key. At this point, I could use codesign, but only within Terminal.app while logged into the build machine's console. I tried various security commands to reimport the Identity, set a key partition list, and unlock the keychain, but none of them allowed codesign to work from within SSH or cron scripts. Eventually I stumbled upon this: sudo security find-identity -v Password: 1) 3C255…1560 "Developer ID Application: Data Expedition, Inc. (VK…8X)" 2) 3C255…1560 "Developer ID Application: Data Expedition, Inc. (VK…8X)" 3) 3C255…1560 "Developer ID Application: Data Expedition, Inc. (VK…8X)" 4) EA377…96DD "Developer ID Application: Data Expedition, Inc. (VK…8X)" 5) 3C255…1560 "Developer ID Application: Data Expedition, Inc. (VK…8X)" 6) 3C255…1560 "Developer ID Application: Data Expedition, Inc. (VK…8X)" 7) 3C255…1560 "Developer ID Application: Data Expedition, Inc. (VK…8X)" 8) 3C255…1560 "Developer ID Application: Data Expedition, Inc. (VK…8X)" 9) 3C255…1560 "Developer ID Application: Data Expedition, Inc. (VK…8X)" 10) 3C255…1560 "Developer ID Application: Data Expedition, Inc. (VK…8X)" 10 valid identities found Keychain Access only showed one copy of the Identity in each keychain, but with security I could see there were actually 9. Tip: Keychain Access does not accurately display keychain contents. If it shows no contents at all, type a letter in the search box. Identities are distinguished from lone Certificates by a drop-down caret to the left of the certificate name. Clicking that shows the key. To fix the redundant Identities, I had to run this command four times to delete the nine copies: security delete-identity -Z 3C255…1560 I repeated this until the identity (I used the SHA1 hash of the certificate) no longer showed up in security find-identity -v. I then re-imported the certificate and key using security import, which is what I should have done from the begininng. The Correct Way Here are the commands I used to get things going after I deleted all the problem certificates: security import mycertificate.cer -k /Library/Keychains/System.keychain -T /usr/bin/codesign This next command I ran in Terminal.app on the console so it could display a password prompt: security import ImportThisKey.p12 -k /Library/Keychains/System.keychain -T /usr/bin/codesign After this, I used security find-identity -v to verify that there was only one copy of the Identity. I then verified that codesign could be used from SSH and cron-scripts even while logged out of the console. I suspect that a lot of mysterious certificate problems might be caused by duplicate certificates, each with different permissions. As far as I can tell, there is no way to uniquely identify a certificate/identity or the permissions attached to them. The system just searches based on hash, or team-id, or other non-unique property and seems to just arbitrarily pick one. I hope this helps someone else stuck with errSecInternalComponent errors!

I am on a mission to secure our key material for our iOS app's code signing certificate. My first endeavor with storing the code signing certificate on a YubiKey is a marginal success - it seems that with a pin policy that requires entering the PIN at least once we must enter the PIN umpteen times per build. Creating a certificate with a policy of never would be ill-advised. On the other hand, we could chose to store the code signing certificate in the Secure Enclave. However, it seems that I am only allowed to create eliptic curve private keys and not RSA keys in the secure enclave. When I attempt to upload a certificate signing request to AppStoreConnect, I am told that only an RSA2048 key will do. What I am after is a way to authenticate access to the certificate once per boot so that we can make multiple builds per day without manual intervention whilst also ensuring that the key material is not stored on disk. A yubikey would be preferable, but I am fine with the secure enclave if need be. Is there a way to achieve this? Best regards, Emīls

Every recent attempt to create a Installer certificate has failed, and now we've hit the maximum. We can't revoke them either — the portal only shows "Download," not "Revoke." Xcode also fails with: "Signing Certificates Error: There is a problem with the request entity. You already have a current Developer certificate or pending certificate request." This is completely blocking notarization and distribution of our macOS app. Has anyone resolved this, or does it require Apple to intervene on the backend? (This is a relatively new issue, we have successfully done this in the past hundreds of times over the years.)

I've seen a few posts about this online and it seems that Xcode generates random team ID's with it's automatic signing system. But I haven't seen any way to make this work properly. If I log into the dev portal and look at my account, in the upper right I can see my team ID. If I manually generate a cert, I get a totally different one. Question: How can I generate a cert with my proper team ID (my paid account) where the ID's on my certs, identifiers and profiles all match? I've never had this issue before and am unsure how to solve it.

Context: I am building an iOS productivity app using EAS Build. The project has 4 targets: the main app and 3 extensions (ShieldAction, ShieldConfiguration, ActivityMonitorExtension). The Issue: I have officially received approval from Apple for the Family Controls (Distribution) entitlement for my main Bundle ID. However, the build still fails during the Xcode phase. The Errors: Xcode reports that the generated provisioning profiles do not include the com.apple.developer.family-controls entitlement. For example: Provisioning profile "*[expo] com.*.** AdHoc 177247892...." doesn't support the Family Controls capability. All 3 extensions are failing with the exact same error. What I've done: Confirmed approval from Apple for com.*.**. Enabled Family Controls and App Groups on the Apple Developer Portal for all 4 Identifiers. Cleared EAS local and remote cache using eas build --clear-cache. Deleted existing profiles on both Expo.dev and Apple Portal to force regeneration. The Question: Even with official approval, why does EAS continue to generate "empty" profiles for my Ad-Hoc development build? Do I need separate approval for each extension's Bundle ID, or is there a way to force EAS to sync these "Managed Capabilities" correctly?

Apple has introduced the Wireless Insights Service Predictions capability in iOS 26. After prior alignment with Apple engineers, we are working to integrate this capability into the Douyin App, and intend to provide a TestFlight build for Apple engineers to validate and debug the integration. We have encountered a blocking issue with entitlement configuration: We use our Apple Developer Enterprise Program account to build and submit TestFlight builds. When we manually create and configure provisioning profiles via the Apple Developer Portal, the required entitlement key com.apple.developer.wireless-insights.service-predictions is not available for selection or inclusion in the profile's Entitlements. This completely blocks us from enabling, using, and validating the Wireless Insights Service Predictions capability. For comparison, when we use our Apple Developer Program individual account, the entitlement com.apple.developer.wireless-insights.service-predictions is fully available. It is automatically included in provisioning profiles generated for local debugging, and can also be manually added to custom provisioning profiles via the Apple Developer Portal without issues. We request assistance to resolve this entitlement access discrepancy for our Enterprise Program account, so that we can complete the integration and provide the TestFlight build for validation as planned.

I accidentally mis-copy-pasted when creating a new app identifier, and I can't create the correct one. I missed the leading "c" and I created An App ID with om.automaticduck.MyApp I deleted it, but now I can't create the correct one. The error says An attribute in the provided entity has invalid value An App ID with Identifier 'com.automaticduck.MyApp' is not available. Please enter a different string. Thank you for helping with what I need to do.

Unable to Verify App An internet connection is required to verify trust of the developer "Apple Development: John Doe (ABCXYZ123)". This app will not be available until verified. I've been getting this constantly over the last few weeks. It has been a real struggle to get anything done. Sometimes it goes away on its own after I try to launch the app a few times, but currently it's just staying down and I can't do any work. Apparently there were issues with some Apple server ppq.apple.com before. They seem to be back, because trying again right now: ping ppq.apple.com PING use1-ppq-ext-prod.apple.com (17.33.200.235): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 ^C --- use1-ppq-ext-prod.apple.com ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss ping apple.com PING apple.com (17.253.144.10): 56 data bytes 64 bytes from 17.253.144.10: icmp_seq=0 ttl=60 time=9.776 ms 64 bytes from 17.253.144.10: icmp_seq=1 ttl=60 time=8.726 ms ^C --- apple.com ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 8.726/9.251/9.776/0.525 ms This is incredibly disruptive. Surely there must be a way to disable this online verification? This is a development device that never leaves my desk and never installs any software except the things I build locally from my Mac (which I have trusted on the device).

I've successfully signed Unix apps manually in the past. Today (after signing the new agreement) I can get it to replace the existing signature but it says "rejected" when I check it. Here are the commands I'm using: michaelleahy@Michaels-Mini ~ % sudo codesign --force --deep --options runtime --sign "Developer ID Application: Bookup Corp. (6J8PUT****)” /Users/michaelleahy/Documents/theapp /Users/michaelleahy/Documents/theapp: replacing existing signature michaelleahy@Michaels-Mini ~ % spctl -a -vvvv -t install /Users/michaelleahy/Documents/theapp /Users/michaelleahy/Documents/theapp: rejected source=Unnotarized Developer ID origin=Developer ID Application: Bookup Corp. (6J8PUT****) Here is a command (issued right after the one above) showing an older signed app is accepted: michaelleahy@Michaels-Mini ~ % spctl -a -vvvv -t install /Users/michaelleahy/Documents/olderapp /Users/michaelleahy/Documents/olderapp: accepted source=Notarized Developer ID origin=Developer ID Application: Bookup Corp. (6J8PUT****) What might I be missing? Something changed since the last time I signed an app.

Hello! We built a macOS .pkg using pkgbuild (contains a DMG + postinstall bash script). The pkg works locally on the build machine but fails on other devices manually / via MDM unless signed. We tried signing with a Developer ID Installer certificate, but: security find-identity -p codesigning -v → 0 valid identities security find-identity -v → shows the cert Private key is present in Keychain OpenSSL check shows: X509v3 Extended Key Usage: Critical (Expected one might be: Code Signing) We recreated CSR + cert multiple times (G2 Sub-CA), ensured Login keychain, unlocked keychain, etc., but same result. Question: Why is the Developer ID Installer cert missing Code Signing usage and not recognized for signing? Is there any account restriction or step we might be missing? Any recommendations on resolving this issue. Thanks!

Hi everyone, I'm developing a macOS app using Tauri 2. I need to test In-App Purchases (IAP), which requires running the actual built .app (it doesn't work properly in the development environment).I tried two approaches: Apple Development Certificate (free account): After cargo tauri build, the app "Mind Elixir.app" shows this error when I try to open it: “Mind Elixir.app” was not opened because it contains malware. This action did not harm your Mac. Apple Distribution Certificate: The app builds successfully, but because it is not notarized, Gatekeeper completely blocks it and I cannot open it at all. I just want to test IAP locally on my own Mac during development. Is there any other way to get a properly signed and runnable .app for testing IAP? Any help or workaround would be greatly appreciated. Thanks!

I am experiencing an issue with Apple Development certificate creation in Xcode for my organization account. Account details: Organization: Jtecx LLC Team ID: 8V397ULNY4 Issue: When I attempt to create a new Apple Development certificate in Xcode under the Jtecx LLC (8V397ULNY4) team, the certificate is consistently generated under a different team: Apple Development: Joseph Salmond (67P4AAZ5TA) This appears to be my personal team, not the organization team. Impact: Because of this mismatch: Provisioning profiles created under 8V397ULNY4 cannot find a matching signing certificate Xcode shows “Signing Certificate: None” Xcode reports that the provisioning profile does not include the signing certificate I am unable to run or test the app on physical devices due to signing failures Troubleshooting performed: Deleted all Apple Development certificates from Keychain Access Revoked existing Apple Development certificates in the Apple Developer Portal Created a new Certificate Signing Request (CSR) using Keychain Access Generated a new Apple Development certificate through the Apple Developer portal Downloaded and installed the certificate into Keychain Attempted certificate creation via Xcode (Settings → Accounts → Manage Certificates → + → Apple Development) Verified installed identities using Terminal (security find-identity) Confirmed that only the following development identity is being created: Apple Development: Joseph Salmond (67P4AAZ5TA) Deleted this identity and repeated the process multiple times Recreated provisioning profiles after generating new certificates Downloaded and installed new provisioning profiles Attempted both manual signing and “Automatically manage signing” in Xcode Revoked certificates directly from Xcode and allowed Xcode to regenerate them Confirmed that Apple Distribution certificates are correctly issued under 8V397ULNY4 Despite all of the above steps, every new Apple Development certificate continues to be created under Team ID 67P4AAZ5TA instead of 8V397ULNY4. Expected behavior: When creating an Apple Development certificate while the Jtecx LLC (8V397ULNY4) team is selected, the certificate should be issued under that same team: Apple Development: Joseph Salmond (8V397ULNY4) Requested fix: Please investigate and correct the team association so that: Apple Development certificates are generated under the correct team (8V397ULNY4) is properly associated with the Jtecx LLC developer team for certificate issuance Xcode correctly creates and uses development certificates for the organization team Additional notes: Apple Distribution certificates are working correctly under 8V397ULNY4 Only Apple Development certificates are affected This issue is blocking local development and testing on physical devices Thank you.

Hello, We are currently in the process of creating our Developer ID Application certificate which is due to expire. While creating the certificate, we were posed with the option of choosing a Developer ID Certificate Intermediary G2 Sub CA which is supported by Xcode 11.4.1 and later Previous Sub CA We currently build our application out of Xcode using Make or CMake files and perform the codesign and productsign using the codesign commands. We also use 2 different build machines, Ventura with Xcode 14.3 for our latest releases High Sierra (10.13) with Xcode 10.1 for legacy releases to support some customers. Can you please let us know which Developer ID Certificate Intermediary we should choose for generating the new Developer ID Application certificate?

The device UDID was registered to the developer account 40 hours ago, the STATUS column was "processing" in the first 24 hours, then turned to empty. But I still can't run my app (with distribution method "development"), when I try to run it after download it through my OTA URL, it prompts “the app cannot be installed because its integrity could not be verified” but everything runs good on a iPhone which was registered a month ago. What should I do now? keep waiting?

Hi, after 2 years of not updating my app on appstore i wanted to submit an update for my iOS app which also containts a watch app target. When i try to submit it to upload it i get the following errors: Failed registering bundle identifier The app identifier "(myappBundleID).watchkitapp" cannot be registered to your development team because it is nit available. Change your bundle identifier to a unique string to try again. No Profiles for "(myappBundleID).watchkitapp" were found. Xcode culdn't find any iOS App Store provisining profiles matching "(myappBundleID).watchkitapp" Since i have my app already in store with that bundle identifier i don't know why it can not be registered to my team. Also i don't want to change the bundle identifier because then i can not publish it as update to store.

Is it possible to directly distribute a macOS app with a Developer ID Certificate that belongs to a different team? I am trying to resolve issues that arise when distributing a macOS app with a Network Extension (Packet Tunnel) outside the App Store using a Developer ID Certificate from a different team than the app’s provisioning profiles and entitlements. I started by attempting Direct Distribution in Xcode with automatic signing. However, it fails with the following message: Provisioning profile "Mac Team Direct Provisioning Profile: ” failed qualification checks: Profile doesn't match the entitlements file's value for the com.apple.developer.networking.networkextension entitlement. I suspect the issue is that the provisioning profile allows "packet-tunnel-provider-systemextension", whereas the entitlements generated by Xcode contain "packet-tunnel-provider". When I manually modify the .entitlements file to include the -systemextension suffix, the project fails to build because Xcode does not recognize the modified entitlement. If there is a workaround for this issue, please let me know. Due to these issues, I resorted to manually creating a signed and notarized app. My process is as follows: Export the .app from the Xcode archive. Since the exported .app does not contain the necessary entitlements or provisioning profile for direct distribution, I replace Contents/embedded.provisioningprofile in both the .app and the .appex network extension. Sign the app and its components in the following order: codesign --force --options runtime --timestamp --sign "Developer ID Application: <name>" <app>.app/Contents/Frameworks/<fw>.framework/ codesign --force --options runtime --timestamp --sign "Developer ID Application: <name>"<app>.app/Contents/PlugIns/<netext>.appex/Contents/Frameworks/<fw>.framework/Versions/A/<fw> codesign --force --options runtime --entitlements dist-vpn.entitlements --timestamp --sign "Developer ID Application: <name>" <app>.app/Contents/PlugIns/<netext>.appex/ codesign --force --options runtime --entitlements dist.entitlements --timestamp --sign "Developer ID Application: <name>" <app>.app Verify the code signature: codesign --verify --deep --strict --verbose=4 <app>.app - <app>.app: valid on disk - <app>.app: satisfies its Designated Requirement Create a ZIP archive using: ditto -c -k --sequesterRsrc --keepParent <app>.app <app>.zip Notarize the app with notarytool and staple it. The notarization completes successfully with errors: nil. Package the notarized app into a DMG, notarize, and staple the DMG. The app runs successfully on the development machine. However, when moved to another machine and placed in /Applications, it fails to open. Inspecting Console.app reveals Gatekeeper is blocking the launch:
 taskgated-helper <bundleid>: Unsatisfied entitlements: com.apple.developer.networking.networkextension, com.apple.developer.team-identifier taskgated-helper entitlements: { "com.apple.developer.networking.networkextension" = ("packet-tunnel-provider-systemextension"); "com.apple.developer.team-identifier" = <teamid>; } As mentioned earlier, the Developer ID Certificate used for signing belongs to a different team. We are a third-party developer and do not have access to the Developer ID Certificate of the team assigned as the team-identifier. When I changed the bundle identifier (app ID), team, entitlements, and provisioning profiles to match the team associated with the Developer ID Certificate, the app worked. My question is:
 Is this failure caused by using a Developer ID Certificate from a different team, or should it still work if the provisioning profiles and entitlements are correctly set? Could there be an issue elsewhere in the provisioning profiles or entitlements for the original app ID?

Hi there, We've discovered a problem with our iOS app. We've been attempting to add a Driverkit driver to it, but any time we run the app through Testflight, the driver installs fine, but when we go to enable the driver toggle in the app's settings, the toggle stays on, but in the device logs I can see: could not insert bundle at <private> into manager: <private> As you would expect - this means the driver is not actually enabled and does not respond to a device being connected to the iPad. This does not happen when building & running the app locally, nor does it happen when installing an Ad Hoc build. We also have a different app, not yet shipped. We are able to add the driver to that app without issue. It works after going through Testflight. What we have discovered now is that everything works fine even if we just create an entirely new app with it's own bundle IDs. I should point out that in all cases, we're keeping the capabilities the same for each of these apps/IDs - including the managed capabilities. The bundle IDs that have this problem are older (5 years old or more). It seems like any newer ID will work, but trying to add the driver (and the associated managed capabilities) to an older app/ID results in this vague error message, with no further details. If we inspect the resulting dexts, we can also see that the "Internal requirements code size" is different on the ones that fail. The failing ones have a size of 204 bytes, whereas the working ones all have a size of 220 bytes. Not sure if that's related but it's strikingly consistent. Does this mean there is an issue with older app IDs, and we need Apple to manually refresh them in some way before the driverkit capabilities will work after going through Testflight? We have two apps in this state, both are of the same vintage (~5 years+). We've been battling this issue for months on and off, so would appreciate some help.

We have NFC capabilties enabled for our app ID - com.uob.mightyvn but our minimum deployment target is 15.0. We do not have an option deselect PACE from provisioning profile. Hence, the validation is failed for IPA. Invalid entitlement for core nfc framework. The sdk version '18.2' and min OS version '15.0' are not compatible for the entitlement 'com.apple.developer.nfc.readersession.formats' because 'NDEF is disallowed'

1.Provisioning profile "xxx" doesn't include signing certificate "Developer ID Application: xxxxx". 2.Provisioning profile "xxx" doesn't match the entitlements file's value for the com.apple.developer.networking.networkextension entitlement. I decoded the profile, <dict> <key>com.apple.developer.system-extension.install</key> <true/> <key>com.apple.developer.networking.networkextension</key> <array> <string>packet-tunnel-provider-systemextension</string> <string>app-proxy-provider-systemextension</string> <string>content-filter-provider-systemextension</string> <string>dns-proxy-systemextension</string> <string>dns-settings</string> <string>relay</string> <string>url-filter-provider</string> <string>hotspot-provider</string> </array> <key>com.apple.security.application-groups</key> <array> <string>xxxxx</string> <string>xxxxx</string> </array> <key>com.apple.developer.networking.vpn.api</key> <array> <string>allow-vpn</string> </array> <key>com.apple.application-identifier</key> <string>xxxxx</string> <key>keychain-access-groups</key> <array> <string>xxxxx</string> </array> <key>com.apple.developer.team-identifier</key> <string>xxxxx</string> </dict> Kindly help me to resolve this.

The attached file bellow contains the full error error I clone this repo to my mac, change team id and group, and run it in Xcode: https://github.com/protonpass/ios-pass There's no issue when I ran it with the Debug configuration, but when I go to Product > Scheme > Edit Scheme and change the iOS target build configuration to Release then I got that error above. I have tried Archive and export the ipa, verify that the provisioning profile contains my Mac UDID, but when double clicking the ipa to install, I also got the error This app cannot be installed because its integrity could not be verified.