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"

Hello, What is the supported revocation-status source or documented validation procedure for the following exact intermediate certificate, encountered in signatures on Apple-supplied Command Line Tools Python 3.9? This concerns first-party Apple code signing, not Developer ID, public TLS, or S/MIME. Certificate details Subject: CN=Apple Code Signing Certification Authority, OU=Apple Certification Authority, O=Apple Inc., C=US Serial: 0x21 (33 decimal) DER SHA-256: 5bdab1288fc16892fef50c658db54f1e2e19cf8f71cc55f77de2b95e051e2562 Validity: 2011-10-24 17:39:41 UTC to 2026-10-24 17:39:41 UTC Issuer: Apple Root CA Issuer DER SHA-256: b0b1730ecbc7ff4505142c49f1295e6eda6bcaed7e2c68c5be91b5a11001f024 Embedded CRL distribution point: http://www.apple.com/appleca/root.crl This intermediate has no Authority Information Access extension. Retained observations from 1 October 2026 At approximately 16:59 UTC, one request to: https://www.apple.com/appleca/root.crl recorded HTTP 200 and returned a 511-byte CRL with: thisUpdate: 2025-03-10 21:28:16 UTC nextUpdate: 2025-07-23 21:28:16 UTC SHA-256: 02b300d7e2edc09a33c0e98c0291da47932320761f6060ea8d7624f6e344f1dd At approximately 20:02 UTC, a separate request to: https://crl.apple.com/root.crl recorded HTTP 404 and returned a 287-byte HTML error body. This was an alternative HTTPS candidate; it does not establish the behavior of its HTTP counterpart. Neither request followed redirects or retried. Response bodies and normalized collector records were retained, but raw HTTP headers and stderr were not retained. These are limited observations from that date, not a claim about global service availability or key compromise. Questions Which current Apple-published source provides signed revocation-status evidence covering this exact intermediate? If the distribution point has moved, what is the authoritative replacement and how is its scope established? Which CP/CPS or documented first-party validation mechanism applies to this certificate? In particular, does Apple Certificate Policy v7.0 (20 March 2026), sections 2.1 and 4.10, cover this chain? If a public revocation-status service is no longer supported for this legacy first-party CA, what documented verification approach should be used, or which Apple team handles this question? I am not treating an expired CRL or an HTTP error as evidence that the certificate is revoked. I am also not assuming that a standalone CRL lookup reproduces macOS trust evaluation. I am asking for the supported source and verification procedure, not for a way to bypass validation, change trust settings, or re-sign Apple binaries. Thank you.

Hi everyone, I’m trying to get my iOS app running on a physical iPhone for real-device testing, but I’m blocked by a persistent code-signing issue in Xcode. The project compiles successfully, but when I select my physical iPhone as the destination, the build fails during the signing stage: errSecInternalComponent Command CodeSign failed with a nonzero exit code The app therefore never gets installed on the device. What I’ve checked: Xcode recognises my Apple Development certificate. security find-identity -v -p codesigning reports the identity as valid. The certificate is present in my login keychain. Keychain Access shows the certificate with its private key underneath it. My login keychain is unlocked. The keychain search list contains my login keychain and the System keychain. I checked both keychains for the corresponding private key. There are no custom trust settings. The particularly strange part is that signing fails outside Xcode too. I tested signing /usr/bin/true directly using the same Apple Development identity, and that also fails with: errSecInternalComponent I also attempted to repair the private key’s signing access/partition list, but received: The specified item is no longer valid. It may have been deleted from the keychain. Certificate situation Xcode → Manage Certificates currently shows two Apple Development certificates: One current certificate One older certificate marked “Not in Keychain” When I try to create a new Apple Development certificate, Xcode says: You already have a current Development certificate or a pending certificate request. This is the only Mac I have used with this Apple Developer account, so there isn’t another Mac from which I can recover or export the original private key. What should I do? I’m trying to understand the safest next step without making the certificate/keychain situation worse. Should I: Revoke the older certificate and create a new development certificate/private-key pair? Try to repair the existing signing identity/private key? Take another Apple-supported approach? The immediate goal is to get the app onto a physical iPhone so I can begin real-device testing, followed by QA/beta testing and App Store launch. Any advice on what is actually causing errSecInternalComponent in this situation, and the safest way to resolve it, would be greatly appreciated. I can provide additional Terminal output, screenshots, or Xcode logs if helpful. Thanks!

I just purchased the Apple Developer Paid Account on the 3rd of October to start development on an App and hasn't been able to use it even once I’m having an iOS code-signing/provisioning issue where development/Ad Hoc builds complete successfully, but the app cannot be installed on my registered iPhone. The same issue occurs with builds produced through both Xcode and Expo EAS Build, so at this point I don’t think this is specific to EAS. When installing the app on the device, iOS shows: Unable to Install “Sencard” This app cannot be installed because its integrity could not be verified. The device logs give a much more specific error. Environment Apple Developer account type: Individual Team ID: 26K9NDX728 Main bundle identifier: com.sencard.mobile Widget extension bundle identifier: com.sencard.mobile.widgets App Group: group.com.sencard.mobile Physical iPhone registered in the Apple Developer portal Expo SDK: 57 EAS distribution: Internal / Ad Hoc The same device is included in both provisioning profiles The issue also occurs when building/installing through Xcode The application contains a WidgetKit extension, so there are two targets: Sencard com.sencard.mobile ExpoWidgetsTarget com.sencard.mobile.widgets Both targets use the same Apple Distribution certificate, with separate provisioning profiles as expected. Current signing configuration I completely reset the signing credentials and let EAS regenerate them. Both targets now use the same distribution certificate: Distribution Certificate Serial: 64FE74F9A8F0091A81671D9CDE9F7CDB The main application has its own active Ad Hoc provisioning profile: Bundle ID: com.sencard.mobile Provisioning Profile: 7D9CS7B97R Status: active Registered device: included The widget extension has a separate active Ad Hoc provisioning profile: Bundle ID: com.sencard.mobile.widgets Provisioning Profile: DY3D63UHPX Status: active Registered device: UDID: 00008130-************001C EAS reports: All credentials are ready to build @sencard/sencard (com.sencard.mobile, com.sencard.mobile.widgets) The build itself completes successfully. Device-side failure I captured the device system log while reproducing the installation failure. The important part appears to be Apple’s online provisioning authorization service rejecting the profile: online-auth-agent: The server returned: {"actions":["REJECT_PROFILE"],"authorized":false,...} online-auth-agent: Permanently rejected profile This is immediately followed by: installd(libmis.dylib): No online authorization (0x2) installd(libmis.dylib): validation failed because of failing online authorization (-402620392) Then MobileInstallation reports: The identity used to sign the executable is no longer valid. and: Failed to verify code signature of .../Payload/Sencard.app 0xe8008018 (The identity used to sign the executable is no longer valid.) Finally: Verification stage failed and the installation fails. What seems particularly significant is that the device contacts the online authorization service successfully, but the response is explicitly: "actions":["REJECT_PROFILE"] "authorized":false Things I have already tried I have done a fairly extensive clean reset of the signing configuration: Deleted the existing Ad Hoc provisioning profiles. Removed the existing distribution certificates from EAS. Revoked the corresponding distribution certificates in the Apple Developer portal. Created a completely new Apple Distribution certificate. Generated completely new Ad Hoc provisioning profiles. Verified that the provisioning profiles show as active in EAS. Verified that both profiles contain the physical iPhone being used for testing. Verified that both targets belong to Apple Team 26K9NDX728. Configured both the main app and widget extension to use the same distribution certificate. Created separate provisioning profiles for: com.sencard.mobile com.sencard.mobile.widgets Confirmed the App IDs still exist in the Developer portal. Confirmed the App Group exists and is assigned correctly. Confirmed the registered iPhone is present in the Developer portal. Rebuilt the app from scratch after regenerating all credentials. Confirmed that the EAS build succeeds. Reproduced the installation failure again on the physical device. Captured the iPhone system logs using idevicesyslog. Reproduced the problem with Xcode as well as EAS. Initially, before resetting the credentials, I also encountered a build-time error similar to: Provisioning profile ... doesn't include signing certificate "iPhone Distribution: ... (26K9NDX728)" I then deleted and regenerated the certificates/profiles and ensured both targets shared the same distribution certificate. That resolved the build failure — the application now builds successfully — but the resulting application is still rejected by iOS during installation with the REJECT_PROFILE / 0xe8008018 error above. What I’m trying to determine Is there some server-side state associated with my Apple Developer team/account that can cause a newly generated, apparently valid Ad Hoc provisioning profile to be returned as: REJECT_PROFILE by Apple’s online authorization service? Specifically: What causes online-auth-agent to return REJECT_PROFILE for a newly created provisioning profile? Can an Apple Developer team/account get into a state where newly generated Development/Ad Hoc profiles are rejected by device-side online authorization? Is there any additional server-side reset or validation Apple Developer Support can perform for Team ID 26K9NDX728? Is error -402620392 associated with a specific provisioning/profile authorization condition? Is there anything else I should inspect in the .mobileprovision file or code signature to determine exactly why Apple is rejecting it? Since I can reproduce this with both Xcode and EAS, is there any known issue affecting Ad Hoc/Development profile authorization rather than the build tooling itself? At this point I’m reluctant to keep generating new certificates and provisioning profiles because I’ve already done a complete signing reset and the newly generated profiles are still being rejected. Any guidance on what REJECT_PROFILE means internally, or what Apple Support should check on the Developer account/team, would be greatly appreciated.

I am seeing a reproducible Developer ID code-signing issue on an Apple Silicon Mac running macOS 26.6.2. A Universal macOS app and its Quick Look extension (arm64 + x86_64) are signed with a newly issued Developer ID Application certificate using Hardened Runtime and a secure timestamp. Immediately after signing, all verification succeeds, including: codesign --verify --strict --verbose=4 and architecture-specific verification for both arm64 and x86_64. At this point, codesign reports: valid on disk satisfies its Designated Requirement The expected Developer ID authority chain and TeamIdentifier are present. However, after some time, without modifying the bundle or executable, the exact same Quick Look extension starts failing verification for both architectures: invalid signature (code or signature have been modified) codesign -d then reports: Authority=(unavailable) Info.plist=not bound The executable SHA-256, size, and mtime remain unchanged. I also copied the now-invalid extension to a different directory, creating completely new inodes. The copy remains invalid. I verified that: all regular files in the original and copy are byte-for-byte identical executable SHA-256 is identical _CodeSignature/CodeResources is identical there are no hard links (link count is 1) there are no extended attributes anywhere in the extension com.apple.provenance, com.apple.quarantine, and com.apple.FinderInfo are absent copying the bundle to a new inode does not restore signature validity The affected extension executable currently has: SHA-256: 3b36d1aca258a371311a9c94e93d10606edc184ea120dd252cf230a251c67243 CDHash arm64: 178ff5b7b2cedbed00ec6bc07536d168e22d9ba5 CDHash x86_64: ada914101f5b107704b78958520c904c4f022894 Signing environment Developer ID Team ID: XY2B8MLPV8 The Developer ID Application certificate is newly issued with a new RSA 2048-bit private key. I have also observed the following message in the Security log during signing: CSSMERR_CSP_INVALID_KEYATTR_MASK No new occurrence of that error is logged when subsequently verifying the already-invalid extension. Troubleshooting already performed I have: issued a completely new Developer ID Application certificate with a new RSA 2048-bit private key verified the certificate chain and code-signing policy successfully reproduced related Keychain/identity problems in a fresh macOS user account tested with a newly created independent Keychain tested in Safe Mode reinstalled macOS without erasing user data Before reinstalling macOS, even security find-identity -v -p codesigning eventually failed to recognize otherwise valid Developer ID identities. After reinstalling macOS, security find-identity -v -p codesigning correctly reports all identities again. I then performed a durability test using the new Developer ID identity on a minimal Universal Mach-O binary. Verification succeeded: immediately after signing after approximately 2 minutes after approximately 5 minutes after copying the binary to a different directory The minimal binary remained valid throughout. However, the problem subsequently reproduced with the actual Quick Look extension. Notarization The application was packaged in a Developer ID Installer-signed PKG and submitted to Apple Notary Service. The submission was Accepted, stapling and validation succeeded, and Gatekeeper accepted the notarized PKG. Notarization submission ID: 54dc0de7-5089-4b8c-9c10-b5a74df8df97 I initially suspected the packaging process, but I subsequently found that the original pre-PKG Quick Look extension itself had become invalid. Therefore, this does not appear to be caused by PKG creation or extraction. Questions What could cause a Developer ID signature that initially verifies successfully to become invalid later when the signed files themselves have not changed? Is there a Security.framework / codesign diagnostic that can show exactly which part of the CMS signature or CodeDirectory validation is failing? Are there any known macOS 26.x issues involving code-signing validation or CSSMERR_CSP_INVALID_KEYATTR_MASK that could explain this behavior? I would be happy to collect additional Security logs, codesign diagnostics, or a sysdiagnose if that would help identify the cause.

I am diagnosing a trust failure for an archived iOS arm64 app, without changing trust settings or rebuilding speculatively. Environment: macOS 26.6.2 (25G83), Xcode 27.0 (27A266a), as reported by installed public metadata. The diagnostic is a non-interactive Python helper calling the installed Security/CoreFoundation APIs through a bounded child-process runner in a desktop coding-agent session. This is not an Xcode GUI operation; an effect of the session, keychain/cache, or service access has not been established. Observed results: The app's embedded code CMS supplies three certificates. One explicitly identified signer matches the stored signer receipt in memory. The helper places the signer first, followed by the other supplied certificates. It uses SecPolicyCreateWithProperties(kSecPolicyAppleCodeSigning), SecTrustCreateWithCertificates, and SecTrustSetNetworkFetchAllowed(false). The status-returning setup calls succeed. Disabling intermediate fetching does not prove that all OS revocation/cache/network activity is absent. One SecTrustEvaluateWithError call returns false. The top-level CFError and its single kCFErrorUnderlyingErrorKey child both report NSOSStatusErrorDomain / -26276. The child has no further underlying-error key. This designated key chain was collected completely; other userInfo and localized descriptions were not collected. A prior recorded evaluation returned a chain containing only the signer. The latest diagnostic did not request another evaluated chain. Supplied certificates and the evaluated/trusted chain are distinct observations. Separate metadata collection found three distinct supplied certificates within their validity intervals at the observation time. Issuer/subject names matched signer → supplied issuer → third certificate, and the third had equal issuer/subject names. This does not verify issuer signatures, CA purpose, or root trust. Existing independent codesign --verify --deep --strict verification exits 1 with CSSMERR_TP_NOT_TRUSTED for arm64; it does not identify the failing certificate. The extraction/trust helper does not validate the CMS/CodeDirectory signature. The public SecTrust header allows false both for denied trust and for an evaluation that cannot complete. The inspected installed SecBase header defines errSecInternalComponent as -2070 and errSecDecode as -26275; it provided no name for -26276. I am not treating -26276 as either code or as proof of certificate/profile damage, sandbox denial, or trust-service failure. Questions: What supported interpretation or specific conditions explain -26276 on this public Code Signing API path, including the underlying error repeating the same domain/code? What smallest independent public field or observation distinguishes policy rejection from evaluation failure while keeping the policy, intermediate-fetch=false, and trust settings unchanged? The underlying key chain supplies no more specific code. How should this be interpreted alongside CSSMERR_TP_NOT_TRUSTED from strict verification of an archived iOS app? What specific evidence separates an embedded-signature/signing-input defect from a local trust or evaluation-context failure and justifies a targeted correction? No certificate names, fingerprints, DER, profile identifiers, account details, private paths, raw payloads, or attachments are included.

My two apps, com.qrafter.Qrafter and com.qrafter.QrafterPro, have been on the iOS App Store since 2011, and their App IDs still use my team's unique App ID prefix 99T3FA87E9 instead of the Team ID GH4CGS3B5H. I'm adding native Mac versions to the same App Store records (universal purchase), so the bundle IDs can't change. Every profile Apple generates for these App IDs pairs com.apple.application-identifier = 99T3FA87E9.com.qrafter.Qrafter with com.apple.developer.team-identifier = GH4CGS3B5H. iOS uploads are accepted, but Mac App Store validation (xcrun altool --validate-app -t macos) rejects even a minimal one-window app with exactly two errors: Invalid code signing entitlements. … the "99T3FA87E9.com.qrafter.Qrafter" value for the com.apple.application-identifier key … isn't supported. This value should be a string that starts with your Team ID, followed by a dot ("."), followed by the bundle ID. (90286) Invalid Provisioning Profile. … Invalid 'com.apple.application-identifier' entitlement value. (91130) Following "Code Signing Identifiers Explained" (thread 811970), I requested the prefix migration through Contact Us on 4 September (case 102953576372). On 20 September Developer Support asked me to confirm the one-time keychain data loss described in "App ID Prefix Change and Keychain Access" (thread 706128), and I confirmed. Since then the case has had no reply despite follow-ups on 24 and 29 September, and as of 6 October both App IDs still show 99T3FA87E9. Two questions: Is there anything else I need to do to get case 102953576372 completed, or a better route to escalate it? Is there any way to ship a Mac App Store build for these App IDs before the migration, or is the migration the only path? I have a minimal sample project and the full validation log if that helps.

Summary A third-party PKG installer that ships a custom Installer Plugin no longer displays one of its selection panes. The plugin bundle appears not to be loaded, so the pane that it provides is silently skipped and the user cannot choose the intended installation option. This behavior started with recent macOS releases and did not occur on the immediately preceding versions, so it looks like a regression. Environment Machine: MacBook Pro 14-inch (M3) Affected builds: macOS 27.0 (26A428) macOS 26.7 (25G229) macOS 15.8 (24H23) Not affected: macOS 26.6 and earlier macOS 15.7 and earlier Reproducibility: every time Plugin binary: Mach-O 64-bit bundle, x86_64 only (no arm64 slice) Steps to Reproduce Download the Epson iProjection Ver.4.04 installer from the vendor support site: https://support.epson.net/setupnavi/?LG2=EN&OSC=MI&PINF=vpapp&MKN=EB-770Fi Mount the downloaded disk image and run the PKG installer. Step through the installer GUI and observe the pane transitions. Expected Result The installer GUI shows the "Application type" selection pane provided by the bundled Installer Plugin. Actual Result The "Application type" pane is never shown. The installer proceeds as if the plugin did not exist, and the user cannot select the installation type. What I Checked 1. The plugin is present inside the PKG pkgutil --expand-full PKG_PATH DEST_DIR The expanded payload contains the plugin bundle and its Mach-O executable under Contents/MacOS. 2. Architecture of the plugin binary file DEST_DIR/PluginName.bundle/Contents/MacOS/PluginName Result: Mach-O 64-bit bundle x86_64. It is a single-architecture binary with no arm64 slice. 3. The plugin is actually touched at install time sudo fs_usage -w -f filesys InstallerRemotePluginService-x86 opens the plugin executable inside the installer's temporary directory (a path under /private/tmp/com.apple.installer* ). So the plugin is reached as a load target, but the pane still does not appear. 4. Code signature validation When the installer is launched directly from the mounted disk image, code signature validation fails with: Too many levels of symbolic links My working theory is that the bundle contents are turned into symbolic links when the plugin is expanded, and that this causes codesign validation to fail, so the plugin is rejected before it can register its pane. 5. Code evaluation by syspolicyd log stream --info --debug --predicate 'process == "syspolicyd"' GK package assessment, GK process assessment and GK performScan entries are present, so Gatekeeper evaluation itself is running. The following also appears: Error Domain=NSOSStatusErrorDomain Code=-67062 Unsigned code in: PST: (path: REDACTED), (team: (null)), (id: (null)), (bundle_id: (null)) The PST path is anonymized in the log, so I could not confirm that this particular assessment refers to the plugin bundle. 6. XProtect evaluation results differ between versions log stream --info --debug --predicate 'process == "syspolicyd"' On the versions where the installer works correctly, the GK Xprotect results lines explicitly include a file URL pointing at the plugin bundle inside the installer temporary directory. On the affected builds, searching the same log for the plugin bundle name returns zero matches. That suggests the bundle is not being processed as an XProtect evaluation target at all on the newer builds. Question Was there a change in how Installer Plugins are expanded or validated in these releases, in particular around symlinked bundle contents or single-architecture x86_64 plugins? Any guidance on the supported way to ship an Installer Plugin so that it is still loaded on current macOS would be appreciated.

Hi everyone, I am developing an iOS companion app with an integrated watchOS component (a golf swing tracking tool using CoreMotion). I have run into an issue where the watchOS app gets stuck indefinitely in the "Installing..." state and never finishes installing on the physical Apple Watch. Environment (All on latest public releases): Xcode Version: Latest release (Xcode 18.x) macOS Version: Latest release (macOS Sequoia / latest version) iOS Version: Latest release (iOS 20.x) watchOS Version: Latest release (watchOS 13.x on Apple Watch Ultra 2) Deployment Target: Matched to latest minimum deployments Signing: "Automatically manage signing" enabled with an active Apple Developer Program account Steps to Reproduce: Connect the iPhone to the Mac via a physical cable. Select the iOS target in Xcode and successfully run/install the companion app onto the iPhone. Launch the stock Watch app on the paired iPhone. Scroll down to the "Available Apps" section, locate the development app, and tap "Install". The circular progress indicator starts spinning with the status "Installing...", but it remains in this state indefinitely (waited over 2 hours) without ever completing, timing out, or surfacing an error alert on either the iPhone or the Apple Watch. Troubleshooting Already Verified: Bundle ID Hierarchy: iOS App: com.company.appname Watch App: com.company.appname.watchkitapp Both targets share the exact same Development Team, signing certificate, and provisioning profiles. Developer Mode: Explicitly enabled and rebooted on the Apple Watch (Settings -> Privacy & Security -> Developer Mode). Also verified as enabled on the host iPhone. Connectivity & Cache: Cleared Xcode DerivedData (rm -rf ~/Library/Developer/Xcode/DerivedData). Performed hard reboots on both the iPhone and the Apple Watch to terminate any hung background sync daemons (installd / CoreDevice). Ensured both devices and the Mac are on the same Wi-Fi network with Bluetooth turned on. Questions: Under the current CoreDevice architecture, is installing local debug builds via the iPhone's stock Watch app still supported, or does it silently fail because the physical Apple Watch's UDID is not directly provisioned during an iOS-only build? Which subsystem in macOS Console.app (e.g., com.apple.dt.CoreDevice, com.apple.StreamingExtractor, or installd) is best for tracking the exact error/timeout code when the watch installation hangs? What is the currently recommended workflow to deploy and debug a paired watchOS target directly onto physical hardware? Any insights from the team or community would be greatly appreciated!

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.

I prepare a private project in Xcode, use Archive, Distribute/Copy, save the application somewhere. Copy it to my other computer, run. Works perfectly with normal MacOS applications. With Catalyst ones though it does not; whatever I try, all I get is “The application XXX cannot be opened”. What do I do wrong and how to fix the problem? Thanks!

I'm asking about how to ask for an addition to a managed entitlement, where we already have a grant of that entitlement (with a different value) and we already have other managed entitlements granted. This post https://developer.apple.com/forums/thread/789176 tells me I can request entitlements at the Requests tab here: https://developer.apple.com/account/resources/, which leads me to this form: https://developer.apple.com/contact/request/system-extension/ The form URL doesn't specify a particular App Identifier, but is the Identifier implied with this form submission? Or, put another way, is the entitlement we're asking for attached only to the Team ID, or also to the bundle ID of the app which is going to use the entitlement? So if I made another app which talks to my dext, I'd have to ask again for userclient-access to the same dext, but from a different bundle ID? The form says "Which DriverKit entitlements do you need" and "select all that apply", but I'm unclear about whether I need to request ALL the DriverKit entitlements we need for all our apps, or only for the specific App Identifier I reached this form from. It also isn't clear if I need to check both the USB Transport and the UserClient Access boxes in my case. We already have UserClient Access granted for at least one bundle ID, and I want to add another. We already have USB. Transport granted for two different vendor IDs. Do I need to mention that in my request here, and also check the USB Transport box, although I'm not requesting any new vendor ID values? I don't want to end up with new profiles which break new builds of existing apps which were relying on previously-granted entitlements that are now missing from the newly-generated profiles. Here: https://developer.apple.com/forums/thread/822652 user JackLongbow submitted a request for UserClient Access for two bundle IDs, presumably in the form of a simple two-line string like this: com.turing.TuringTouch com.turing.TuringTouch.TouchDriver but the resulting provisioning profile was malformed, it contained this value under com.apple.developer.driverkit.userclient-access <string>com.turing.TuringTouch com.turing.TuringTouch.TouchDriver</string> the Forum post said that the approved entitlement looks like this: <array> <string>com.turing.TuringTouch</string> <string>com.turing.TuringTouch.TouchDriver</string> <string>com.turing.TuringTouchDriver</string> <string>com.turing.virtualpad</string> <string>com.turingdraw.DigidrawTouch.DigidrawDriver</string> </array> Should I be formatting my request as above, as a chunk of xml, or is a plain text list of bundle IDs, one per line, acceptable? Is there a way for us to get a summary of all the managed entitlements already granted to our team? At present, it seems like I have to pick a particular profile, download it, and QuickLook at it - but not all profiles contain all entitlements, just as apps don't have to claim all the entitlements the profile offers .

Every App Store Connect upload I sign with my Cloud Managed Apple Distribution certificate is rejected with ITMS-90035 ("Code failed to satisfy specified code requirement(s)") for the app binary and its widget extension. It happens from Xcode Cloud and from a manual Organizer upload alike. I think I have found the cause, and it looks like a Unicode normalization bug in cloud-managed signing. The certificate holder's name contains an umlaut: "Apple Distribution: Jonathan Thorsten Müller (…)". In the certificate the "ü" is precomposed (NFC, UTF-8 c3 bc). In the designated requirement that the export writes into the signature it is decomposed (NFD, "u" + U+0308, UTF-8 75 cc 88): certificate subject CN ... 4d c3 bc 6c 6c 65 72 ... ("Müller", NFC) designated requirement leaf CN ... 4d 75 cc 88 6c 6c 65 72 ... ("Müller", NFD) The bytes differ, so the signature can never satisfy its own designated requirement. It reproduces with Xcode 27.0's App template, unmodified, and without uploading anything: Archive for a generic iOS device. With no distribution identity in the local keychain, export for App Store Connect to a folder (export options: method app-store-connect, destination export, signingStyle automatic). DistributionSummary.plist shows "Cloud Managed Apple Distribution". xcodebuild -exportArchive -archivePath MyApp.xcarchive -exportPath out -exportOptionsPlist ExportOptions.plist -allowProvisioningUpdates Verify the exported app: codesign --verify --strict -vv Payload/MyApp.app Result: "valid on disk", then "does not satisfy its designated Requirement". Compare the requirement with the certificate's subject: codesign -d -r- Payload/MyApp.app codesign -d --extract-certificates Payload/MyApp.app openssl x509 -inform DER -in codesign0 -noout -subject -nameopt RFC2253,-esc_msb | xxd The same archive exported with a regular Apple Distribution certificate (same name, private key in my keychain) writes the NFC form, verifies, and App Store Connect accepts that upload. That works for manual uploads only. Xcode Cloud always signs with the cloud-managed certificate, so I cannot distribute from Xcode Cloud at all. Setup: Xcode 27.0 (27A266a) locally and in Xcode Cloud, automatic signing, one team, no custom code-signing flags. Product name, bundle IDs and file names are plain ASCII. Questions: Is this a known issue with cloud-managed signing and non-ASCII certificate names? Is there a supported way to have Xcode Cloud sign without hitting it in the meantime? If you see ITMS-90035 on Xcode Cloud and your name (or your team's) has an accent or umlaut in it, you may be hitting the same thing: run step 3 on an exported IPA and check.

Is there a way to run codesign (macOS) tool on Docker container ?

I have been trying for 24 hours to upload app, and first time this has happened in 8 years and 100+ uploads. Please help. Validate App and Upload both hang indefinitely at "Preparing" in Xcode Organizer. No error is ever returned — the progress bar freezes and the operation never completes or times out. Transporter 1.4.5 fails identically. Key detail: archive 2.4.3 (build 123), which Apple accepted and processed on Sept 10, 2026, now hangs the same way when validated. Same machine, same Xcode, same Apple ID. This rules out the archive, its signature, and its provisioning profile. Already ruled out: two independent networks (home Wi-Fi and iPhone cellular hotspot); the archive itself (known-good build 123 fails identically); Xcode install (27.0 / 27A266a, xcode-select verified correct); Apple ID session (signed out and back in three times); full reboot. macOS 27.0 (26A428) on MacBookPro18,4. Last successful upload Sept 10, 2026. 100+ prior archives uploaded without incident over several years. macOS has updated twice since Sept 10. Separately: Transporter 1.4.5 crashes on macOS 27.0 with an unhandled exception in TransporterKit while drawing its activity queue (EXC_BREAKPOINT via +[NSApplication _crashOnException:]).

My developer account identity has a red 'x' next to it like other users have stated. It looked as though a tech helped them correct it. I have been requesting support via email for over 10 days on this and am still waiting for assistance. When I sign into App Store Connect, I can see both of my apps I have registered. My apple developer account at the top tells me I need to enroll in a program and can click to enroll but then will tell me I cannot enroll. I can see myself as the account holder and admin in the user identities. I also have the developer certificate in my keychain.

I am new to macOS development and presently tearing my hair out trying to get a driverkit extension to build. I have tried following the instructions here: https://developer.apple.com/documentation/driverkit/communicating_between_a_driverkit_extension_and_a_client_app namely, disabling SIP, but I am still unable to get my extension to build. The instructions say to set the code signing identity to "Sign to Run Locally" for all three targets, but this is not listed as an option for the driver extension.

xcrun notarytool submit crashes with a SIGBUS during upload, every time, for one specific build of our app. Filing this as its own post since it is a distinct, reproducible crash with a clear crash report, separate from general In Progress slowness. The exact exception, from the macOS crash reporter, is EXC_BAD_ACCESS (SIGBUS), subtype KERN_PROTECTION_FAILURE, with the message "Could not determine thread index for stack guard region." It happens on a background thread named nio.nioTransportServices.connectionchannel, which is the SwiftNIO Network.framework transport thread handling the upload connection. The faulting stack is inside notarytool's own code, going through String.init(format:), then Foundation's NSString formatting, then CoreFoundation's CFString formatting functions, almost certainly while it is trying to format a log or progress line during the upload. The same small set of return addresses repeats many times in a row right before the crash, which looks like unbounded or very deep recursion in that logging path. Reproduction: run xcrun notarytool submit yourbuild.zip --apple-id ... --password ... --team-id ... --wait against a roughly 180 MB zip of a signed .app. The tool prints Submission ID received, starts the S3 multipart upload, and crashes within about a second, before any upload progress is shown, with no error message. The submission is left behind on Apple's side, stuck at status In Progress, and disappears entirely about 11 to 12 hours later, at which point notarytool info for that id returns Submission does not exist or does not belong to your team. This is completely reproducible for us: it has now happened on five separate submissions of our x64 (Intel) build, and zero times submitting our arm64 (Apple Silicon) build of the exact same app, same machine, same credentials, same day. We also tried setting the upload timeout higher with defaults write com.apple.gke.notary.tool nt-upload-connection-timeout 300, which did not help, same crash. We have full macOS crash reports (.ips files) for two separate occurrences of this and are happy to attach or send them, along with the zip that triggers it.

I have a narrow follow-up question about file-based Keychain partition lists, this time specifically for Developer ID Installer signing with productbuild. I’ve reviewed the existing guidance around Keychain ACLs and partition lists. For codesign, the security documentation explicitly calls out the apple: partition requirement. I haven’t been able to find an equivalent supported statement for productbuild. My setup uses separate private keys for the two roles: Developer ID Application → /usr/bin/codesign Developer ID Installer → /usr/bin/productbuild The trusted-application ACL is also role-specific. I’m trying to determine the corresponding partition constraint for the Installer key without inferring it from a configuration that merely happens to work. So my question is: When /usr/bin/productbuild uses a Developer ID Installer private key from a file-based Keychain, what partition-list requirement should that key use according to the supported macOS contract? In particular, should the Installer key use apple:, apple-tool:, some combination of partitions, or something else? I’m not looking for a broad CI workaround or an “Allow all applications” configuration. I’m trying to keep the Application and Installer roles separate and use only the partition constraint actually required by the Apple signing tool. If there is no documented/supported partition value for productbuild, knowing that limitation would also answer the question. Thanks.

I’m evaluating whether Apple cloud signing can replace locally managed Developer ID private keys in a macOS distribution pipeline. I’ve read the documentation on cloud-managed certificates and the Xcode cloud-signing workflow. I understand the supported Developer ID Application flow through Xcode’s archive/export distribution process, but I haven’t been able to find an equivalent documented workflow for Developer ID Installer. I’m also checking this against the current Xcode 27 / macOS 27 toolchain, in case the supported cloud-signing scope has recently expanded. My distribution pipeline produces custom flat installer packages using productbuild. It uses separate Developer ID Application and Developer ID Installer identities, as expected. So my main question is: Can a custom macOS .pkg be signed with a cloud-managed Developer ID Installer identity using a currently supported Apple workflow? More specifically, is there a supported cloud-signing equivalent of using a local Developer ID Installer identity with productbuild / productsign, or are Developer ID Installer package signatures still expected to use a locally or externally available signing identity? I’m specifically asking about custom Developer ID packages distributed outside the Mac App Store, rather than an App Store or Xcode-managed installer workflow. If cloud-managed Developer ID Installer signing isn’t currently supported, knowing that limitation would answer my question as well. Thanks.