I’m unable to notarize the executable and the .app — the status has been showing “In Progress” for over an hour. Upon checking the xcrun logs, it indicates that the submission ID was not received. I also noticed there’s an Apple Developer Service outage reported since October 8, 2025. Could you please let me know when this outage is expected to be resolved? It would be very helpful.

The problem is the following: We create a keychain item called NotaryTool (There are multiple accounts that use Notary tool and we created it for all of them ) This is created in the following way: $ xcrun notarytool store-credentials This process stores your credentials securely in the Keychain. You reference these credentials later using a profile name. Profile name: NotaryTool We recommend using App Store Connect API keys for authentication. If you'd like to authenticate with an Apple ID and app-specific password instead, leave this unspecified. Path to App Store Connect API private key: //AuthKey_ABCDEFGH.p8 App Store Connect API Key ID: <ABCDEFGH> App Store Connect API Issuer ID: ABCDEF-ABCD-1234-1234-1234567 Validating your credentials... Success. Credentials validated. Credentials saved to Keychain. To use them, specify `--keychain-profile "NotaryTool"` The key is downloaded from Apple and some other IDs are provided alongside. These should remain in the keychain for as long as the user process is running (just like any other process) A few runs are successful when we run with the profile that was created. After a few runs we start seeing a failure. Now we are seeing the following issue where the keychain item just vanishes: Error: No Keychain password item found for profile: NotaryTool\n\nRun 'notarytool store-credentials' to create another credential profile.\nError during the not process\nTue Aug 26 06:02:09 2025 Notarization failed with notarytool with exit code 17664: \nTue Aug 26 06:02:09 2025 could not upload for notarization!!!

I am facing an issue while trying to staple a notarization ticket to my signed macOS installer package. Details of my setup: The .pkg file is signed using my Developer ID Installer certificate. The app inside the package is signed using my Developer ID Application certificate. Notarization via xcrun notarytool completes successfully with status: Accepted. However, the stapler command fails with the following error: xcrun stapler staple -v /Users/mac-test/Desktop/IPMPlus_Arm_Installer_signed.pkg Processing: /Users/mac-test/Desktop/IPMPlus_Arm_Installer_signed.pkg Could not validate ticket for /Users/mac-test/Desktop/IPMPlus_Arm_Installer_signed.pkg The staple and validate action failed! Error 65. I verified that all other Apple notarization-related servers (api.apple-cloudkit.com, gs.apple.com, ocsp.apple.com, ocsp2.apple.com, crl.apple.com, developer.apple.com) are reachable. However, the domain cdn-apple-cloudkit.apple.com cannot be resolved from any network, including mobile or public Wi-Fi. Both dig and nslookup return “No answer” even when using external DNS servers like 8.8.8.8 or 1.1.1.1. It appears that cdn-apple-cloudkit.apple.com might be required during the stapler validation process, but the DNS for this domain is not resolving. Could you please confirm whether this CDN endpoint is required for stapling, and if there is currently an outage or configuration issue with cdn-apple-cloudkit.apple.com?

Product: macOS, Notarization Tool: notarytool, Stapler Tool: xcrun stapler, Application: master-billing.app, DMG: master-billing.dmg I'm attempting to notarize and staple a macOS .dmg file containing a signed .app. Notarization completes successfully, but the stapling step fails with Error 65. All tools are up-to-date and I'm following the official Apple process. #!/bin/bash set -e APP="dist/mac-arm64/master-billing.app" DMG="dist/mac-arm64/master-billing.dmg" IDENTITY="Developer ID Application: NAME (TEAM ID)" PROFILE="notarysiva" VOLUME_NAME="MasterBilling" Sign binaries and frameworks find "$APP" -type f ( -name ".dylib" -or -name ".so" -or -name "*.node" -or -perm -u+x ) -exec codesign --force --options runtime --timestamp --sign "$IDENTITY" {} ; find "$APP" -type d ( -name ".app" -or -name ".framework" ) -exec codesign --force --options runtime --timestamp --sign "$IDENTITY" {} ; codesign --deep --force --options runtime --timestamp --sign "$IDENTITY" "$APP" Create DMG hdiutil create -volname "$VOLUME_NAME" -srcfolder "$APP" -ov -format UDZO "$DMG" Sign DMG codesign --sign "$IDENTITY" --timestamp "$DMG" Verify DMG signature codesign --verify --verbose=2 "$DMG" Submit for notarization xcrun notarytool submit "$DMG" --keychain-profile "$PROFILE" --wait Staple ticket xcrun stapler staple -v "$DMG" Signing all binaries, dylibs, and frameworks... . . ✅ App signing complete. 💽 Creating DMG... ...................................................................................... created: /Users/one/Documents/MASTER/bill-master/dist/mac-arm64/master-billing.dmg 🔏 Signing the DMG... ✅ Verifying DMG signature... dist/mac-arm64/master-billing.dmg: valid on disk dist/mac-arm64/master-billing.dmg: satisfies its Designated Requirement 📤 Submitting DMG for notarization... Conducting pre-submission checks for master-billing.dmg and initiating connection to the Apple notary service... Submission ID received id: 32927c3c-7459-42b4-a90c Upload progress: 100.00% (123 MB of 123 MB) Successfully uploaded file id: 32927c3c-7459-42b4-a90c path: /Users/one/Documents/MASTER/bill-master/dist/mac-arm64/master-billing.dmg Waiting for processing to complete. Current status: Accepted............ Processing complete id: 32927c3c-7459-42b4-a90c status: Accepted 📌 Stapling notarization ticket to DMG... Processing: /Users/one/Documents/MASTER/bill-master/dist/mac-arm64/master-billing.dmg . . . Downloaded ticket has been stored at file:///var/folders/1l/ht34h5y11mv3rhv8dlxy_g4c0000gp/T/5bb9e667-dfe1-4390-8354-56ced7f48fa0.ticket. Could not validate ticket for /Users/one/Documents/MASTER/bill-master/dist/mac-arm64/master-billing.dmg The staple and validate action failed! Error 65.

Dear support team, is it possible to rename a notarized ZIP package and not to loose the notarized status? One of our ZIP package contains resources and binaries which are code signed. The archive itself is accepted after submitting and uploading during the notarization process (online notarization). Unfortunately, the ZIP cannot be stapled (offline verification). So, is the filename part of the notarized ZIP package or can a ZIP package be renamed? Best regards, Stefan

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.

Our app .dmg file was successfully code signed. We then revised the app and created a new .dmg. Running codesign gave an "app is already signed" message. Then running codesign -dv said "code object is not signed at all" Older solutions said to use -f to force signing, but that is no longer an option.

Dear Apple Support, for better understanding to use the Notary Service, I would like to ask when and what have to be notarized. I am absolutely aware of using the Notary Service and which packages can be submitted and how to get the status. Scenario: We have one library which is developed by a specific team and other teams develop and deliver to customer MacOS apps which packages this library for the shipment. So, the library will be produced internally and will be shipped in different products. The library will be code signed before we make available internally. When should we notarize (and staple) this library? Directly after the code is signed or when it will be packaged in each product when it will be delivered to customer? Best regards, Stefan

I'm working on an app that needs access to device activity. When I add device activity entitlement, I'm getting Provisioning profile "..." doesn't include the com.apple.developer.deviceactivity entitlement. This is failing for both, the main app and the extension, and both have entitlements added. It is not clear how to add it to the profile, the provisioning profile is created/managed by XCode. When I remove the entitlement, I can build my app but it won't be able to use device activity data I reached out to Developer Support, and they sent me here. What is the right way to add device activity entitlement? I'm also seeing another issue with XCode Cloud builds. When I remove device activity entitlement. I can build my app w/o any issue, and I can also install it directly on my iPhone. However, XCode Cloud builds fail wit Run command: 'xcodebuild -exportArchive -archivePath /Volumes/workspace/tmp/d41fc2f1-4f39-4906-8941-112488e75f6c.xcarchive -exportPath /Volumes/workspace/adhocexport -exportOptionsPlist /Volumes/workspace/ci/ad-hoc-exportoptions.plist '-DVTPortalRequest.Endpoint=http://172.16.68.193:8089' -DVTProvisioningIsManaged=YES -IDEDistributionLogDirectory=/Volumes/workspace/tmp/ad-hoc-export-archive-logs -DVTSkipCertificateValidityCheck=YES -DVTServicesLogLevel=3' I suspect that it could be related to my app having DeviceActivityExtension but no device activity entitlement is present. Thanks, Peter.

Hi, My understanding from this information: " https://developer.apple.com/support/certificates/ iOS Distribution Certificate (in-house, internal-use apps) Users will no longer be able to run apps that have been signed with this certificate. You must distribute a new version of your app that is signed with a new certificate. " is that even if I re-sign the app with a new Provisioning Profile based on a new Distribution Certificate the apps will stop working. I need to re-build my apps with a new Distribution certificate+Provisioning profile, when distributing in-house, right? I can see that the apps continue to function when I re-sign them with a new Provisioning Profile, but according to the information above they will stop working the day (day after) the Distribution certificate they were built with expires. /Rikard

I have a valid Developer ID Certificate, I've used it to sign an app locally and send the app to other machines of my colleagues to make sure it works and does not get triggered by GateKeeper Now I want to automate the process of signing and notarization on github actions and so I want to export my certificate and upload it there. Initially I tried uploading both the Developer ID Certificate and the G2 CA both as .cer files encoded in base64. But apparently I need my certificate to be in .p12 format When I try to export it from keychain access the option to export as .p12 is disabled. So how can I do it ?

Hi, hoping someone can help here. I recently updated my Mac to macOS 15 (Tahoe) and am using Xcode 15+ (possibly 16). I’m working on a Flutter app and testing on a real iPhone device. Here's the situation: I’m using the free Apple Developer account. My signing certificate and provisioning profile both show as valid and active in Keychain and says "signing..." in Xcode. When I build and run the app from Xcode, it works completely fine on a simulator. But when I try to run the same project from VS Code using flutter run, whether on an simulator phone or my personal iphone, I get a code signing error, specifically: Failed to codesign Flutter.framework with identity... I believe the app is set to use the correct Team ID because it says my name and (team) (my team ID isBDKUKWVRBY), and I can see my certificate in Keychain under "My Certificates". What I’ve already tried: flutter clean pod install / pod update Manually selecting my team in Xcode Signing settings Restarting my machine and VS Code Confirming the same project builds on other machines Verified provisioning profile is assigned to the project in Xcode deleting and recreating a certificate I have even had AI inside VS code take a shot at it and that couldn't fix either My question: Why would VS Code / Flutter not be able to use the same certificate and signing setup that works in Xcode? Is this an issue with Flutter tooling on macOS 15, or do I need to reconfigure signing differently now? Any suggestions or fixes would be greatly appreciated!

My Developer ID certificate will expire in few days, so I downloaded and installed new certificate in login keychain. However my key is still linked to my old certificate. I have my .p12 but even if I delete the old certificate from login keychain and reinstall the .12 file, my old certificate reappears in the login keychain. I tried to select the new certificate in the login keychain and choose Files > Export Items (in Keychain Access) but in the Save dialog under File Format the "Personal Information Exchange (.p12)" option is grayed out. How can I generate a key/.p12 file that will be linked to my new certificate?

Hi, I recently got a consistent delay from notary tool. I have viewed all your suggestions and understand that it "occasionally" will have further review and take longer time, but then it will be faster. However, in my case, my app although is accepted many times. It is still significantly delay. It is a native macOS app called ConniePad. Whenever I submit, it took me 2 days or more to finish notarise, which significantly affect my business. Could you please have a look on it. For log detail about the time, and the ids: -------------------------------------------------- createdDate: 2025-04-05T22:54:45.815Z id: 998b5aa8-fc9c-4469-98fe-950d815e734e name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-05T21:32:22.679Z id: c7b1ab49-6f46-4998-8d06-2ffe8a180c8f name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-03T08:39:52.594Z id: aa33d9d0-9d2f-4296-8fc3-d7e0b404596b name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-03T01:23:31.077Z id: b0333d78-497d-491c-b36c-bdfb64520296 name: ConniePad.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-03T01:17:20.925Z id: 83aa12f2-f1bb-457f-940a-4c2281cf8a5f name: ConniePad.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-03T01:12:52.932Z id: 0a921069-fb37-469a-bfb0-6be82e9320ba name: ConniePad.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-03T01:03:30.584Z id: a607fe3c-d10f-43d6-a184-e97df7b632fd name: ConniePad.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-03T00:52:47.322Z id: c42d0ca0-db8a-4431-b5b4-646ccfcad003 name: ConniePad.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-03T00:28:18.626Z id: 7ef8777f-7add-4440-abb5-3c0b19cf92d4 name: ConniePad.app.zip status: Invalid -------------------------------------------------- createdDate: 2025-04-03T00:24:37.320Z id: 36bb1285-0aeb-4c48-b23c-fac737a3d93f name: ConniePad.app.zip status: Invalid -------------------------------------------------- createdDate: 2025-04-02T23:59:27.940Z id: bb4578a5-a67b-49e8-afd0-a9d707c10091 name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-02T08:51:38.295Z id: 93ff89f4-98d3-45ac-9ee8-9483726a9666 name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-02T08:19:13.762Z id: 9e4a62df-3d8a-4cfa-ae9e-56ff35ffe137 name: ConniePad-ConverterTool.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-02T04:15:34.508Z id: 7ee43b74-f73f-462a-bb3d-f6bc53b1cb80 name: ConniePad-ConverterTool.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-02T02:11:53.312Z id: d675e8f6-dc30-48e9-9269-9bc376f1b29e name: ConniePad-ConverterTool.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-02T01:30:32.768Z id: 9901f125-4355-4812-936b-97578ac2de2f name: ConniePad-ConverterTool.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-01T20:47:26.035Z id: a79265bc-8ad3-4a4b-ae39-150801aa9da9 name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-18T22:39:54.189Z id: b808b676-a41c-4536-b4fd-4b567701adcb name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-18T05:21:23.607Z id: 797f5d4f-cd94-4511-9217-11e57c2c7ac3 name: ConniePad.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-18T05:18:30.707Z id: c5b5c260-fb7f-4bda-9548-f5b7e57cb2f3 name: ConniePad.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-17T06:45:37.831Z id: f24c1017-9171-4796-bf97-ea47ef83f7ce name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-17T06:38:17.981Z id: 8dd0ea7e-e810-48f9-a48f-62dcc1406284 name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-17T06:33:27.649Z id: 704e339a-4d99-4e5e-8414-deb8b26c57ac name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-17T06:32:06.925Z id: 8e9b09b6-e061-4361-abc1-0bbd8f33b599 name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-17T06:26:52.444Z id: 2b564641-eb87-4de9-a59c-ff5362b8bf4a name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-17T06:22:04.790Z id: 1aa158bd-0afd-4c60-8e2f-3029388710ab name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-17T06:17:17.141Z id: 3bffcf1d-2fd7-41ba-b70c-f85837499736 name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-17T02:38:47.102Z id: 2dd2fb47-7dff-4f30-b2e0-d8c2bfcf10f5 name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-14T03:23:54.671Z id: 5cafb2a9-03e3-468e-b918-ff24b17fceee name: ConniePad.app.zip status: Accepted

Dear Apple Developer Technical Support, I am encountering an issue with notarizing and stapling both PKG and DMG installers for our Electron-based macOS application COSGrid. Despite receiving successful notarization submission responses via notarytool, the stapling process fails with Error 65. Environment: App Name: COSGrid Bundle Identifier: com.cosgrid.pkg.COSGrid Developer ID Team ID: YB8S2XZ98K macOS Version: macOS [15.1] Xcode Version: [16.0 (16A242d)] Workflow Summary: For PKG: Build via yarn build (Vite + Electron Builder) Package with pkgbuild Sign using productsign Submit for notarization: xcrun notarytool submit COSGridMZA-2.1.10-arm64.pkg --apple-id "..." --team-id YB8S2XZ98K --password "..." --wait Conducting pre-submission checks for COSGridMZA-2.1.10-arm64.pkg and initiating connection to the Apple notary service... Submission ID received id: a8ff8e09-1ab4-49ed-9f6b-4afb9f09e53a Upload progress: 100.00% (235 MB of 235 MB) Successfully uploaded file id: a8ff8e09-1ab4-49ed-9f6b-4afb9f09e53a path: /Users/murugavel/Documents/MZA/mza/release/2.1.10/COSGridMZA-2.1.10-arm64.pkg Waiting for processing to complete. Current status: Accepted..................... Processing complete id: a8ff8e09-1ab4-49ed-9f6b-4afb9f09e53a status: Accepted Receive notarization success Stapling fails: xcrun stapler staple COSGridMZA-2.1.10-arm64.pkg Could not validate ticket... The staple and validate action failed! Error 65. For DMG: Sign via codesign Submit to notarization — success Attempt to staple: xcrun stapler staple -v COSGrid-2.1.10-arm64.dmg Could not validate ticket... The staple and validate action failed! Error 65. Additional Verification: I verified the DMG’s code signature integrity: Command: codesign --verify --verbose=4 COSGrid-2.1.10-arm64.dmg Output: COSGrid-2.1.10-arm64.dmg: valid on disk COSGrid-2.1.10-arm64.dmg: satisfies its Designated Requirement Command: codesign -dvv COSGrid-2.1.10-arm64.dmg Output: Executable=/Users/murugavel/Documents/MZA/mza/release/2.1.10/COSGrid-2.1.10-arm64.dmg Identifier=COSGrid-2.1.10-arm64 Format=disk image CodeDirectory v=20200 size=308 flags=0x0(none) hashes=1+6 location=embedded Signature size=9013 Authority=Developer ID Application: COSGrid Systems Private Limited (YB8S2XZ98K) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=1 Jul 2025 at 11:34:05 AM Info.plist=not bound TeamIdentifier=YB8S2XZ98K Sealed Resources=none Internal requirements count=1 size=180 **Verified Signature for .pkg ** pkgutil --check-signature COSGridMZA-2.1.10-arm64.pkg Package "COSGridMZA-2.1.10-arm64.pkg": Status: signed by a developer certificate issued by Apple for distribution Signed with a trusted timestamp on: 2025-06-30 13:57:19 +0000 Certificate Chain: 1. Developer ID Installer: COSGrid Systems Private Limited (teamID) Expires: 2027-02-01 22:12:15 +0000 2. Developer ID Certification Authority Expires: 2027-02-01 22:12:15 +0000 3. Apple Root CA Expires: 2035-02-09 21:40:36 +0000 Diagnostic Logs Attached: Stapler verbose logs for both PKG and DMG codesign verification output for both PKG and DMG Notarytool submission logs Ticket JSON response from Apple API API request/response headers Effective electron-builder.yaml config Key Observations: codesign verification passes successfully for both artifacts Notarization submission reports success via notarytool Stapler fails with Error 65 for both PKG and DMG Ticket JSON fetched from CloudKit API appears valid No provisioning profile used (Developer ID distribution only) Request: Could you please help investigate: Why is the stapler unable to validate or attach the ticket even though notarization completes successfully? Are there any known issues, entitlements, or workflow adjustments recommended in this case? Is any special handling required for Electron apps’ PKG/DMG packages or Hardened Runtime configurations during stapling? I can provide the signed DMG/PKG and full notarization logs upon request. Thank you very much for your assistance — looking forward to your guidance. Best regards, Murugavel COSGrid Systems Private Limited

Error 7000 "Team is not yet configured for notarization" - Cannot notarize any apps I'm trying to notarize macOS apps for Developer ID distribution and consistently getting error 7000 on every submission. Error Details: { "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 } What I've tried: Completed enrollment verification Created new App Store Connect API key with Admin access Created fresh App-Specific Password Submitted via both API key and App-Specific Password authentication All submissions are accepted and uploaded successfully, but after processing they're rejected with error 7000 Technical Details: Active Developer ID Application certificate Hardened runtime enabled Apps are properly code-signed (codesign -vvv passes) Behavior: Over 15 submissions since December 2nd - ALL rejected with the same error 7000. The submissions upload successfully and show "In Progress" for extended periods (sometimes hours) before eventually being rejected. Questions: Has anyone encountered error 7000 and resolved it? What was the fix? Are there any account settings or agreements required specifically for notarization that aren't obvious in the developer portal? Should I contact Apple Developer Support directly, or is there a self-service solution? Any guidance would be greatly appreciated.

My app records the screen to use the audio for audio analysis for a music visualization. The app works perfectly in production but when uploaded to Transporter is rejected as below. What is the correct entitlement to use as the entitlement I am using seems deprecated. Validation failed (409) Invalid Code Signing Entitlements. Your application bundle's signature contains code signing entitlements that are not supported on macOS. Specifically, key 'com.apple.security.screen-capture' in 'com.boxedpandora.pulse.pkg/Payload/PuLsE.app/Contents/MacOS/PuLsE' is not supported. (ID: a1a436f5-925d-43bc-908d-0761064d589b) Many thanks for any input provided!

Hi All, I am building my own MDM server. It seems that in order for the MDM commands to function an MDM Push Certificate for the APNS framework. And in order to get the MDM Push Certificate from the Apple Push Certificates Portal (https://identity.apple.com/pushcert/) you need to upload your CSR usually provided and sign by the MDM Vendor of your choosing. I am familiar with this process. But now that I am the MDM Vendor, I am not sure where to get this MDM Vendor CSR Signing Certificate. I've already submitted a formal request via the "contact us" form. Apple's response pointed me to the documentation on Setting Up Push Notifications and the MDM Vendor CSR Signing Certificate help page (which I had already reviewed): https://developer.apple.com/documentation/devicemanagement/setting-up-push-notifications-for-your-mdm-customers https://developer.apple.com/help/account/certificates/mdm-vendor-csr-signing-certificate/ The issue is that these documents describe using the signing certificate, but not the process for obtaining it as a new, independent vendor. So does anyone know of a portal or method of generating this “MDM Vendor Certificate”? or maybe I'm going about this all wrong and there is a simpler way… the again, its apple, so I’m probably on the right path just beed a little direction please. (I am not sure where to get this MDM Vendor CSR Signing Certificate.)

Hello Apple Developer Support Community, I am encountering a persistent issue while trying to code sign my macOS application (PromptVault.app) using a valid Developer ID Application certificate. The signing process fails with the following warning and error for every native .so file inside the app bundle: `Warning: unable to build chain to self-signed root for signer "(null)" <file-path>: errSecInternalComponent` What I have tried so far: Verified that my Developer ID Application certificate and the associated private key exist correctly in the login keychain. Confirmed that the intermediate certificate "Apple Worldwide Developer Relations - G6" is installed and valid in the System keychain. Added Terminal to Full Disk Access in Security & Privacy to ensure signing tools have required permissions. Executed security set-key-partition-list to explicitly allow code signing tools to access the private key. Reinstalled both developer and Apple intermediate certificates. Used codesign to individually sign .so files and then sign the entire bundle. Ensured macOS and Xcode Command Line Tools are up to date. Created a clean Python virtual environment and rebuilt all dependencies. Tested code signing in multiple ways and with verbose logging. Current status: Despite all these efforts, the same warning and error persist during the signing process of every .so file. This prevents successful code signing and notarization, blocking distribution. Request for assistance: Could anyone confirm if my certificate and keychain setup sounds correct? Are there known issues or extra steps necessary to properly build the trust chain for Developer ID certificates on macOS 15.6.1 (Sequoia)? Any suggestions for resolving the errSecInternalComponent during signing native libraries? Guidance on ensuring the entire certificates chain is trusted and usable by codesign tools? I can provide debug logs, screenshots of my keychain and security settings, or any other diagnostic information if needed. Thanks in advance for your help!

Hi, I was sent here by Apple developer account, it seems here is the only option for me, so your help is very much appreciated! Basically we are building a chromium based browser on iOS, we applied the "com.apple.developer.web-browser" entitlement, and it shows up in our identifier, profile etc. The app is signed with the new entitlement and published to the app store. However it is not listed as an option for default browser, doesn't matter which device I tried. I did verified that the Info.plist contains http/https urlschemes as required. In fact a few of us checked all available documents multiple times and still couldn't see why.