Hi everyone,
My app notarization has been stuck in the “In Progress” state for the past 4 days. Here are the details:
createdDate: 2025-10-12T07:56:46.228Z
id: 8f8c9a33-1c72-489e-a189-74c797a12fbc
name: DevScribe.zip
status: In Progress
I checked the Apple System Status
page and noticed that the Developer Notarization service has been showing an outage since October 8th.
Could this ongoing outage be the reason my notarization is stuck? Is anyone else experiencing the same issue?
Any guidance or workaround would be greatly appreciated.
Demystify code signing and its importance in app development. Get help troubleshooting code signing issues and ensure your app is properly signed for distribution.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Hello,
I am new to the apple developer program. I, and my team, are working on porting some medical software that we have written from Windows to MacOS. We obviously want to notarize our app to make it easy for professionals and colleagues to use. The software is entirely written in python and includes ffmpeg for one of the features to export the medical data to video and compiled to a single file with pyinstaller, like so:
pyinstaller app_name.py --noconfirm --onefile --add-data "ffmpeg:ffmpeg"
chmod +x dist/app_name*
We are currently adding the signing and notarization of the app to our github workflow. The workflow build a successful app with the correct structure and is able to be run if we allow it past the MacOS firewall. We are signing the app like so:
run: |
BINARY_PATH="dist/app_name"
IDENTITY=$(security find-identity -p codesigning -v | grep -E 'Developer ID Application|Mac Developer' | head -n1 | awk -F\" '{print $2}')
echo "Using identity: $IDENTITY"
security unlock-keychain -p "" build.keychain
codesign --verbose=4 --force --options runtime --timestamp --entitlements .github/mac_build_tools/entitlements.plist --sign "$IDENTITY" "$BINARY_PATH"
codesign --verify --verbose=4 "$BINARY_PATH"
We then also move the binary around into an app structure and sign that as well like so
echo "Moving contents to SedPlot.app"
mkdir -p dist/app_name.app/Contents/MacOS
mv "$BINARY_PATH" dist/app_name.app/Contents/MacOS
cp .github/mac_build_tools/Info.plist dist/app_name.app/Contents
echo -n "APPL????" > dist/app_name.app/Contents/PkgInfo
echo "Signing App"
codesign --verbose=4 --force --options runtime --timestamp --entitlements .github/mac_build_tools/entitlements.plist --sign "$IDENTITY" dist/app_name.app
codesign --verify --verbose=4 dist/app_name.app
codesign --display --entitlements :- dist/app_name.app
If I upload the artifact and check its properties, everything looks good. It has the correct ID associated with it and shows as valid when I use codesign --verify on it. I start having issues when I move onto notarization, like so:
cd dist
echo "Zipping and checking the zip"
ditto -c -k --keepParent app_name.app app_name.zip
zipinfo -1 app_name.zip | head
echo "$AC_API_KEY" > AuthKey.p8
SUBMISSION_ID=$(xcrun notarytool submit app_name.zip \
--key AuthKey.p8 \
--key-id "$AC_KEY_ID" \
--issuer "$AC_ISSUER_ID" \
--team-id "TEAM_ID" \
--output-format json | jq -r '.id')
echo "Submitted notarization with ID: $SUBMISSION_ID"
All of the print statements for errors look good at this point, and the submission ID shows up in my history when I query it. However, all 7 attempts that I have made to notarize this app hang for indefinite amounts of time. We are hoping to submit our tool for publication soon, and it would be helpful to know if there is an issue causing the hang on our end or if this is an issue with new developers.
I have been reading around the forums and see some notes about this taking about a week until the system start to "learn" about our development team and our attempts to notarize. I also know that there is limited amounts that can be said about the backend of the notarizations step. What would be helpful is a few things:
I would like feedback about if there is a fundamental flaw in our approach for signing and notarizing our application, so that we can identify it.
I would appreciate some guidelines about how long to expect this notarization step to take until we can get notarization to finish within 10s of minutes, as we have a hard-coded 30 min wait time for the completion of the notarization in our workflow right now.
It would be helpful to know how to check our logs, as requesting the logs for any of our attempts results in being told that the logs are not available yet.
In case someone from apple is interested in this and wants to check, the most-recent submission ID (the one that I believe should be most-likely correct and valid) is 9ef24966-42a5-47db-a7e0-c6baf0310ac4
Thank you in advance!
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?
Anyone know how long it takes to get Apple to respond to a request for provisioning for endpoint security?
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Tags:
Provisioning Profiles
Endpoint Security
The Developer App Certificate is not trusted.
Topic:
Code Signing
SubTopic:
General
Hello,
We have a working application with several entitlements - com.apple.developer.endpoint-security.client and com.apple.developer.team-identifier.
Recently, the Developer ID signing certificate expired and we created a new one according to the instructions on the website. Also the provisioning profile for those entitlements expired so we edited it to use the new certificate.
We built using xcodebuild in a script and signed with codesign, We supply the certificate id and the entitlement in a plist file like this :
codesign --timestamp --force --sign "${application_signature}" --options=runtime "${obj}" --entitlements "${SR_ENTITLEMENT_PATH}"
(those env vars hold the correct values for the cert id and plist path as far as we checked).
The signing works and looks ok with "codesign -dvvv":
(XXXX replaces the real file name for privacy)
Signature size=9050
Authority=Developer ID Application: XXXXXX. (XXXXX)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=16 Oct 2025 at 11:09:53 AM
Info.plist=not bound
TeamIdentifier=XXXXX
Runtime Version=14.5.0
Sealed Resources=none
Internal requirements count=1 size=184
[Dict]
[Key] com.apple.application-identifier
[Value]
[String] XXXXX.com.XXXX.XXXX
[Key] com.apple.developer.endpoint-security.client
[Value]
[Bool] true
[Key] com.apple.developer.team-identifier
[Value]
[String] XXXXXX`
But when the app need to run it is killed and the console shows the following:
amfid: /private/tmp/XXXXX not valid: Error Domain=AppleMobileFileIntegrityError Code=-420 "The signature on the file is invalid" UserInfo={NSURL=file:///private/tmp/XXXXX, NSLocalizedDescription=The signature on the file is invalid} kernel: mac_vnode_check_signature: /private/tmp/CybereasonSensor: code signature validation failed fatally: When validating /private/tmp/XXXXX: Code has restricted entitlements, but the validation of its code signature failed.
We didn't change any code or build differently (it's done by a CI jenkins job.
So if the file is signed and the and has the entitlements why does it fail? what should be done?
Thanks,
Boaz
Topic:
Code Signing
SubTopic:
Entitlements
I added a new device and it's not recognizing the device model. This causes a message saying "Unable to verify" when signing an app. Has anyone else encountered this issue? This only happens with this one device, not others.
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
I have added an in-app purchase function into my app, and have enabled in-app purchase profile in developer portal(it's on by default and is marked gray in developer portal, I don't know if that's how it supposed to look like). I have issued the agreements and tried signing the app both manually and automatically, but neither of that worked. App can be built successfully in simulator but does not show the simulation window, but cannot build on real device or archive.
Errors: Missing com.apple.developer.in-app-purchase,
com.apple.developer.in-app-purchase.non-consumable, and com.apple.developer.in-app-purchase.subscription entitlements.
Automatic signing failed
Xcode failed to provision this target.
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Tags:
StoreKit
Entitlements
Provisioning Profiles
Signing Certificates
I suddenly started to receive the following email with the error in it stating that my uploaded app is not available to be used in TestFlight:
ITMS-90886: 'Cannot be used with TestFlight because the signature for the bundle at “MyApp.app/Contents/PlugIns/MyAppWidgetExtension.appex” is missing an application identifier but has an application identifier in the provisioning profile for the bundle. Bundles with application identifiers in the provisioning profile are expected to have the same identifier signed into the bundle in order to be eligible for TestFlight.'
It was all working fine and now I am not sure even where to start looking. Signing, provisioning and everything else is managed automatically.
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?
Hello everyone,
I'm facing a critical, blocking issue where my developer account (Team ID: K655PX7A46) is unable to generate a valid provisioning profile with the App Attest entitlement. I have confirmed this is a server-side issue and am hoping to get visibility from an Apple engineer who can investigate.
The Problem:
When I generate a provisioning profile for an App ID with the "App Attest" capability enabled, the resulting profile is defective. It is missing the required com.apple.developer.app-attest.environment key in its entitlements dictionary, causing Xcode to fail the build.
What I Have Proven:
The issue is not a misconfiguration. The App Attest capability is correctly enabled and saved on the App ID configuration page.
The issue is not isolated to one App ID. I created a brand new App ID from scratch, enabled the capability during creation, and the server still generates a defective profile with the same missing entitlement.
I have definitive proof by inspecting the downloaded .mobileprovision file. The contents confirm the required key is missing.
Steps to Reproduce on My Account:
Create a new App ID on the Developer Portal.
Enable the "App Attest" capability and save.
Generate a new "iOS App Development" provisioning profile for this App ID.
Download the profile and inspect its contents via security cms -D -i [profile].
Observe that the com.apple.developer.app-attest.environment key is missing.
The Evidence (Contents of the Defective Profile):
Here is the output from inspecting the profile for a brand new App ID (com.technology519.linksi.app2). As you can see, the correct entitlement is missing, and an incorrect devicecheck entitlement is present instead.
This is a critical bug in the provisioning profile generation service for my account that is blocking all development. I have already filed a support ticket (Case #102721408444) but have so far only received generic, unhelpful responses.
Can an Apple engineer please investigate this server-side issue with my account?
Thank you.
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Tags:
Entitlements
Signing Certificates
App Attest
Code Signing
I have tried everything and still I am getting this. Just for a test I created a new app (Master-Detail template Xcode 11.5) I have created an entry in the iTunes Connect to receive the app upon archiving and uploading. I regenerated all new certificates for iOS Development and Distribution. I created all new Provisioning profiles.
The Dev profile builds deploys and runs on my device
The Dist profile builds but when I select the distribution profile I get the "Profile doesn't include the com.apple.application-identifier entitlement." error.
When I download the profile within Xcode all looks good for the distribution profile:
App ID: matches correctly
Certificated: 1 Included includes the new signing certificate "iPhone Distribution...."
Capabilities: 3 Included Includes Game Center, In-App Purchase, and Keychain Sharing
Entitlements: 5 Included Includes application-identifier, keychain-access-groups, beta-reports-active, get-task-allow, and com.apple.developer.team-identifier.
Im not sure what is going on. This is a standard process I have performed for quite a while. As a matter of fact I just submitted 3 applications last Sunday.
Thank you for any suggestions.
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Tags:
iOS
App Store
Entitlements
App Store Connect
I've tried to notarize my app recently and got the error:{
"logFormatVersion": 1,
"jobId": "...",
"status": "Rejected",
"statusSummary": "Team is not yet configured for notarization",
"statusCode": 7000,
"archiveFilename": "myapp.dmg",
"uploadDate": "2019-06-20T06:24:53Z",
"sha256": "...",
"ticketContents": null,
"issues": null
}I've never heard about "team configuration for notarization" previously. What are the steps to resolve that issue?Thanks in advance.
I'm trying to help out one of our vendors by building a skeleton PCI dext which they can flesh out.
However, I can't seem to get the signing right.
I can't sign it at all using no team or my personal team. "Signing for requires a development team", and "Personal development teams ... do not support the System Extension capability".
I can't sign the driver because "DriverKit Team Provisioning Profile: doesn't match the entitlements file's value for the com.apple.developer.driverkit.transport.pci entitlement.
I think this problem occurs because our company has already been assigned a transport.pci entitlement, but for our own PCI vendor ID. But I want to build and test software that works with our vendor's PCI device.
I tried generating a profile for the driver manually, it contained only our own company's PCI driver match:
IOPCIPrimaryMatch = "0x0000MMMM&0x0000FFFF";
where MMMM is our own PCI vendor ID.
Is there a better way to inspect the profile Xcode is using than the postage-stamped sized info popup which truncates the information? I would download the generated profile but it doesn't appear on the profile, but Xcode is accessing it from somewhere.
When I look at the available capabilities I can add to an app identifier on the Developer portal, I see com.apple.developer.driverkit.transport.usb, which is "development only". There's no "development only" capability for PCI. Does this mean it isn't possible to develop even a proof-of-concept PCI driver without being first granted the DriverKit PCI (Primary Match) entitlement?
When adding capabilities to a driver, the list of available capabilities shown in Xcode has one "DriverKit PCI (Primary Match) entry", but if I double click it, two such entries appear in the Signing and Capabilities tab for my driver target. On the Developer portal, when I look at my driver's Identifier, there are two Capabilities labelled DriverKit PCI (Primary Match). Why?
I believe that this is related to the post https://developer.apple.com/forums/thread/790880.
I essentially have the same problem that they did. I submit my Distribution PKG for notarization but the notarization fails and when I attempt to install the PKG user the UI I get a "External component packages (3) trustLevel=0 (trust evaluation failed; treating as invalid due to higher trust level for parent product archive)"
However if I install using "sudo installer -verboseR -pkg ConcealDistribution.pkg -target /" everything works as expected.
The difference between me and the other post is that when I expand my PKG using pkgutil --expand I do not have a Resources folder within my top level distribution. Instead my structure looks like
ConcealDistribution
├── Distribution
├── ConcealConnect.pkg
├── ConcealBrowse.pkg
└── ConcealUpdate.pkg
The specific notary service errors I receive are as follows
{
"logFormatVersion": 1,
"jobId": "7e30e3fd-1739-497c-a02e-64fbe357221d",
"status": "Invalid",
"statusSummary": "Archive contains critical validation errors",
"statusCode": 4000,
"archiveFilename": "ConcealDistribution.pkg",
"uploadDate": "2025-10-08T19:41:33.491Z",
"sha256": "40aacfacf25c6da0be8fe31ae9c145a25ddf9ed1f38be714687c74d95b26619d",
"ticketContents": null,
"issues": [
{
"severity": "error",
"code": null,
"path": "ConcealDistribution.pkg",
"message": "Package ConcealDistribution.pkg has no signed executables or bundles. No tickets can be generated.",
"docUrl": null,
"architecture": null
},
{
"severity": "warning",
"code": null,
"path": "ConcealDistribution.pkg",
"message": "The contents of the package at ConcealDistribution.pkg could not be extracted.",
"docUrl": null,
"architecture": null
}
]
}
For what its worth all the inner PKGs have their executables signed, the PKGs are signed themselves and they are all notarized and stapled without issue. Then I am attempting to sign and notarize the outer PKG and that is where the problems pop up.
Additionally I'm not sure when this stopped working as I expected but just a few months ago I was able to do this exact same process and install with the UI and have it work.
Topic:
Code Signing
SubTopic:
Notarization
I am receiving an entitlement error from stripe terminal SDK when integrating Tap to Pay from apple in the info.plist.
Im hoping that someone can give me their input on my error output rather than diving into the stripe sdk to point me in the right direction of something I may have missed with entitlements.
I have been approved for tap to pay entitlement and am following the instructions here from apple: https://developer.apple.com/documentation/proximityreader/setting-up-the-entitlement-for-tap-to-pay-on-iphone
com.apple.developer.proximity-reader.tap-to-pay
We have an application which keeps throwing the error "application is damaged and cannot be opened. You should move it to Trash"
I have already referred to the documentation: https://developer.apple.com/forums/thread/706379 and https://developer.apple.com/forums/thread/706442
I have checked the following possible root causes:
Codesign of the application using the codesign command
Notarization of the application using the spctl command
Executable permissions
Checked for the presence of "com.apple.quarantine" flag for the application using xattr -l <path to executables"
Checked the bundle structure
None of the above listed items seemed to be a problem and are as expected.
Can you please help us understand what could cause this issue and how to resolve this without recommending an uninstall/reinstall of the application?
Hey devs,
I have a really weird issue and at this point I cannot determine is it a Big Sur 11.1 or M1 issue or just some macOS settings issue.
Short description
programatically (from node, electron) I'd like to store x509 cert to keychain. I got the following error message:
SecTrustSettingsSetTrustSettings: The authorization was denied since no user interaction was possible. (1) I could reproduce this issue on: a brand new mac mini with M1 chip and Big Sur 11.1
another brand new mac mini with M1 chip and Big Sur 11.1
a 2018 MacBook pro with Intel chip and Big Sur 11.1
I couldn't reproduce this issue on: 2020 MacBook pro with intel i9 chip and Big Sur 11.1
2020 MacBook pro with intel i9 chip and Big Sur 11.0
How am I trying to store the cert
node test.js
test.js
const { exec } = require('child_process')
exec(
	`osascript -e 'do shell script "security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /Users/kotapeter/ssl/testsite.local.crt" with prompt "Test APP wants to store SSL certification to keychain." with administrator privileges'`,
	(error, stdout, stderr) => {
		if (error) {
			console.log(error.stack)
			console.log(`Error code: ${error.code}`)
			console.log(`Signal received: ${error.signal}`)
		}
		console.log(`STDOUT: ${stdout}`)
		console.log(`STDERR: ${stderr}`)
		process.exit(1)
	}
)
testsite.local.crt:
----BEGIN CERTIFICATE
MIIDUzCCAjugAwIBAgIUD9xMnL73y7fuida5TXgmklLswsowDQYJKoZIhvcNAQEL
BQAwGTEXMBUGA1UEAwwOdGVzdHNpdGUubG9jYWwwHhcNMjEwMTE3MTExODU1WhcN
NDEwMTEyMTExODU1WjAZMRcwFQYDVQQDDA50ZXN0c2l0ZS5sb2NhbDCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANM08SDi06dvnyU1A6//BeEFd8mXsOpD
QCbYEHX/Pz4jqaBYwVjD5pG7FkvDeUKZnEVyrsofjZ4Y1WAT8jxPMUi+jDlgNTiF
jPVc4rA6hcGX6b70HjsCACmc8bZd+EU7gm4b5eL6exTsVzHc+lFz4eQFXgutYTL7
guDQE/gFHwqPkLvnfg3rgY31p3Hm/snL8NuD154iE9O1WuSxEjik65uOQaewZmJ9
ejJEuuEhMA8O9dXveJ71TMV5lqA//svDxBu3zXIxMqRy2LdzfROd+guLP6ZD3jUy
cWi7GpF4yN0+rD/0aXFJVHzV6TpS9oqb14jynvn1AyVfBB9+VQVNwTsCAwEAAaOB
kjCBjzAJBgNVHRMEAjAAMAsGA1UdDwQEAwIC9DA7BgNVHSUENDAyBggrBgEFBQcD
AQYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBAYIKwYBBQUHAwgwHQYDVR0O
BBYEFDjAC2ObSbB59XyLW1YaD7bgY8ddMBkGA1UdEQQSMBCCDnRlc3RzaXRlLmxv
Y2FsMA0GCSqGSIb3DQEBCwUAA4IBAQBsU6OA4LrXQIZDXSIZPsDhtA7YZWzbrpqP
ceXPwBd1k9Yd9T83EdA00N6eoOWFzwnQqwqKxtYdl3x9JQ7ewhY2huH9DRtCGjiT
m/GVU/WnNm4tUTuGU4FyjSTRi8bNUxTSF5PZ0U2/vFZ0d7T43NbLQAiFSxyfC1r6
qjKQCYDL92XeU61zJxesxy5hxVNrbDpbPnCUZpx4hhL0RHgG+tZBOlBuW4eq249O
0Ql+3ShcPom4hzfh975385bfwfUT2s/ovng67IuM9bLSWWe7U+6HbOEvzMIiqK94
YYPmOC62cdhOaZIJmro6lL7eFLqlYfLU4H52ICuntBxvOx0UBExn----END CERTIFICATE
testsite.local.key:
----BEGIN RSA PRIVATE KEY
MIIEpQIBAAKCAQEA0zTxIOLTp2+fJTUDr/8F4QV3yZew6kNAJtgQdf8/PiOpoFjB
WMPmkbsWS8N5QpmcRXKuyh+NnhjVYBPyPE8xSL6MOWA1OIWM9VzisDqFwZfpvvQe
OwIAKZzxtl34RTuCbhvl4vp7FOxXMdz6UXPh5AVeC61hMvuC4NAT+AUfCo+Qu+d+
DeuBjfWnceb+ycvw24PXniIT07Va5LESOKTrm45Bp7BmYn16MkS64SEwDw711e94
nvVMxXmWoD/+y8PEG7fNcjEypHLYt3N9E536C4s/pkPeNTJxaLsakXjI3T6sP/Rp
cUlUfNXpOlL2ipvXiPKe+fUDJV8EH35VBU3BOwIDAQABAoIBAQDDGLJsiFqu3gMK
IZCIcHCDzcM7Kq43l2uY9hkuhltrERJNle70CfHgSAtubOCETtT1qdwfxUnR8mqX
15T5dMW3xpxNG7vNvD/bHrQfyc9oZuV6iJGsPEreJaV5qg/+E9yFzatrIam0SCS7
YL6xovPU58hZzQxuRbo95LetcT2dSBY33+ttY7ayV/Lx7k6nh0xU6RmTPHyyr8m7
yHpoJoSxdT/xv5iBSZ8mM9/2Vzhr14SWipVuwVVhDSfbn8ngHpIoQDkaJLMpWr+m
4z3PqfftAwR6s6i96HnhYLnRir618TQh4B9IEngeEwCMn4XAzE3L+VTaKU1hg9el
aMfXzPERAoGBAPa+sJ2p9eQsv0vCUUL8KeRWvwjDZRTd+YAIfpLMWrb0tMmrBM4V
V0L2joF76kdDxt1SAlHoYCT/3Rn8EPmK0TN3MEskiXQ7v57iv+LZOZcpe0ppG/4A
ZihF9+wUjFCDw4ymnRQD463535O6BgZV+rcZksFRD2AwvEjt1nYm93VXAoGBANsh
AYM+FPmMnzebUMB0oGIkNkE9nVb9MPbQYZjEeOeHJqmt1Nl6xLuYBWTmWwCy7J4e
QPtnuMCdO6C1kuOGjQPBFIpeyFMzll+E3hKzicumgCpt5U8nTZoKc/jZckRD7n3p
lbYYgHOR3A/3GCDK5L3rwziWpSRAGMSCQylvkOC9AoGBAKLfZL3t/r3LO8rKTdGl
mhF7oUYrlIGdtJ/q+4HzGr5B8URdeyJ9u8gb8B1Qqmi4OIDHLXjbpvtFWbFZTesq
0sTiHCK9z23GMsqyam9XbEh3vUZ082FK6iQTa3+OYMCU+XPSV0Vq+9NPaWGeHXP5
NTG/07t/wmKASQjq1fHP7vCpAoGBAK4254T4bqSYcF09Vk4savab46aq3dSzJ6KS
uYVDbvxkLxDn6zmcqZybmG5H1kIP/p8XXoKCTBiW6Tk0IrxR1PsPHs2D3bCIax01
/XjQ1NTcYzlYdd8gWEoH1XwbJQWxHINummBTyowXguYOhVhM9t8n+eWbn1/atdZF
2i+vS3fhAoGAYKw6rkJfTSEswgBKlQFJImxVA+bgKsEwUti1aBaIA2vyIYWDeV10
G8hlUDlxvVkfwCJoy5zz6joGGO/REhqOkMbFRPseA50u2NQVuK5C+avUXdcILJHN
zp0nC5eZpP1TC++uCboJxo5TIdbLL7GRwQfffgALRBpK12Vijs195cc=----END RSA PRIVATE KEY
What I've already found
If I run the following command from terminal It asks my password first in terminal and after that It asks my password again in OS password prompt.
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /Users/kotapeter/ssl/testsite.local.crt
It looks like I'm getting the above error message because osascript hides the second password asking dialog.
The cert always gets stored in keychain but when I get the error message the cert "Trust" value is not "Always Trust".
References
StackOverflow question: https://stackoverflow.com/questions/65699160/electron-import-x509-cert-to-local-keychain-macos-the-authorization-was-deni
opened issue on sudo-prompt electron package: https://github.com/jorangreef/sudo-prompt/issues/137
Dear Apple Developer Support,
I am experiencing a critical issue with Developer ID certificates issued for Turkish (C=TR) developer accounts that prevents code signing on macOS.
Issue Summary
All Turkish Developer ID certificates issued on October 4, 2025, contain an Apple proprietary extension (OID 1.2.840.113635.100.6.1.13) marked as "critical" that both OpenSSL and codesign cannot handle.
Technical Details
Team ID: 4B529G53AG
Certificate Country: TR (Turkey)
Issue Date: October 4, 2025
macOS Version: 15.6.1 (24G90)
Problematic Extension OID: 1.2.840.113635.100.6.1.13 (marked as critical)
Evidence
I have verified this issue across THREE different Turkish Developer ID certificates:
Serial: 21F90A51423BA96F74F23629AD48C4B1
Serial: 461CBAF05C9EDE6E
Serial: 184B6C2222DB76A376C248EC1E5A9575
All three certificates contain the same critical extension.
Error Messages
OpenSSL: error 34 at 0 depth lookup: unhandled critical extension
Codesign: unable to build chain to self-signed root for signer
errSecInternalComponent
Comparison with Working Certificate
My previous Developer ID certificate from Singapore (before revocation) worked perfectly and did NOT contain this critical extension. This confirms the issue is specific to Turkish certificates.
Impact
Cannot sign applications for distribution, which blocks:
DMG signing for distribution
Notarization process
App distribution to users
Questions
What is the purpose of OID 1.2.840.113635.100.6.1.13?
Why is it marked as critical only for Turkish certificates?
Is this related to Turkish regulatory requirements?
Can you issue a certificate without this critical extension?
Is there a macOS update planned to support this extension?
Request
Please either:
Issue a Developer ID certificate without the critical extension OID 1.2.840.113635.100.6.1.13
Provide a workaround for signing with current Turkish certificates
Update the codesign tool to handle this extension
This appears to be a systematic issue affecting all Turkish developers as of October 2025.
Thank you for your urgent attention to this matter.
Best regards,
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Hi Apple team,
I have a recently created dev account and submitted two different 20-30 mb .apps for notary through the notary tool. I have read that this should only take minutes at this size of an app but both have been stuck in progress for almost 24+ hours.
Below are the UUIDs of the notary submissions. Also I tried re-submitting but these are also stuck in progress.
Successfully received submission history.
history
--------------------------------------------------
createdDate: 2025-09-26T11:46:32.643Z
id: 9714758e-e216-496d-80f8-422f77011ebe
name: <>.zip
status: In Progress
--------------------------------------------------
createdDate: 2025-09-25T21:48:46.161Z
id: c2a81300-c903-4277-8ef3-70205a690c76
name: <>.zip
status: In Progress
--------------------------------------------------
createdDate: 2025-09-25T18:24:36.205Z
id: 42742be1-c7e5-4483-a2c5-95e89086d070
name: <>.zip
status: In Progress
--------------------------------------------------
createdDate: 2025-09-25T16:35:09.059Z
id: a404256e-40c2-4dca-97fc-983e70ea4b7b
name: <>.zip
status: In Progress