Hi all
I'm stuck on a notarization failure that doesn't match any cause I can find or fix locally — looking for either a known explanation or a pointer to the right support channel.
Setup:
- macOS 15.7.2 (24G325)
- Certificate: "Developer ID Installer"
- Issued: 16 Aug 2026, expires 17 Aug 2031
- Confirmed on developer.apple.com as Active (not revoked) — matches the certificate installed locally by serial/expiry
- Signing a component .pkg containing a notarized-requirements-compliant plugin bundle (hardened runtime, secure timestamp, universal x86_64/arm64, signed with a valid "Developer ID Application" cert from the same team)
What I've verified locally, all pass cleanly:
- pkgutil --check-signature on the .pkg: full valid chain, Developer ID Installer -> Developer ID Certification Authority -> Apple Root CA, with a trusted timestamp
- spctl -a -vvv -t install on the .pkg: recognizes it as "Developer ID" origin, correctly reports "Unnotarized Developer ID" (i.e. Gatekeeper trusts the signature itself, just knows it isn't notarized yet)
- codesign -dv --verbose=4 on the inner plugin bundle (both architecture slices checked individually): valid Developer ID Application signature, hardened runtime flag set, trusted timestamp present
What I've tried, no change in any case:
- Originally built/signed via the third-party "Packages" app — failed notarization
- Re-signed the same .pkg independently with Apple's own
productsigndirectly (bypassing Packages entirely, to rule out a third-party tool bug) — productsign's own console output explicitly confirmed it added both the "Developer ID Certification Authority" and "Apple Root CA" certificates to the signature — still failed notarization, identical error - Found and accepted a pending Program License Agreement banner on developer.apple.com that I hadn't noticed before — resubmitted after accepting — still failed, identical error
- Rebuilt the plugin bundle from source fresh, repackaged, resubmitted — still failed, identical error
Every attempt gets the same result from xcrun notarytool log <id>:
"status": "Invalid", "statusSummary": "Archive contains critical validation errors", "statusCode": 4000, "issues" "severity": "error", "path": "<the .pkg filename itself>", "message": "The binary is not signed with a valid Developer ID certificate.", "architecture": null
Note "path" is the top-level .pkg itself and "architecture" is null — so this is flagging the Installer signature on the package, not the inner bundle's Application signature.
Some submission IDs for reference, in case anyone from Apple can look at the notary service's own logs directly:
- 9a5364bf-7b0e-4cf8-a68c-0508bc081855
- caa2a263-d4af-443b-89dd-1c26d93a7bee
- f15fcf6d-99c3-4810-8c42-926e4328a042
Has anyone seen this combination before — a certificate that verifies as fully valid by every local tool (pkgutil, spctl, codesign) and shows as Active on the portal, but is rejected by the live notary service specifically? Is there some other account-level state (beyond agreements, which I've now accepted) that can cause this? Trying to figure out whether this needs a Technical Support Incident or if it's a known/documented gotcha I'm missing.
Thanks for any pointers.
After posting the above I did some extra digging and found this thread: https://developer.apple.com/forums/thread/811481
Thanks again to @DTS Engineer (Quinn) — the pointer to "Fixing an untrusted code signing certificate" was exactly what was needed. Posting the resolution here in case anyone else hits this.
Root cause: the "Developer ID Installer" certificate on my machine had a custom Keychain trust override set to kSecTrustSettingsResultTrustAsRoot, applied across almost every policy (SSL, Code Signing, S/MIME, etc.), each with "Allowed Error: CSSMERR_TP_CERT_EXPIRED" attached. Best guess is that someone, at some point in the past, used Keychain Access's "Always Trust" on this certificate to make an unrelated warning go away, without realising what that setting actually does.
The effect: every local tool (codesign, pkgutil --check-signature, spctl -a -t install) reported the certificate and the resulting .pkg as completely valid, because the override makes the local machine blindly trust the certificate rather than actually validating the chain. Apple's notary service, however, performs its own independent validation that isn't affected by local Keychain overrides at all — so it correctly saw through this and rejected every submission with "The binary is not signed with a valid Developer ID certificate," no matter how the package was built or re-signed.
This is why re-signing with productsign directly (bypassing our third-party packaging tool), accepting a separately-pending Program License Agreement, and rebuilding the whole project from scratch all made no difference — none of those touched the actual cause. The minimal repro test suggested earlier in this thread (Application cert + zip = Accepted, Installer cert + pkg = Invalid, even with a completely trivial throwaway package) was what pointed at the certificate itself rather than anything in our build pipeline.
Fix: found via security dump-trust-settings, which showed the override explicitly. Removed it with:
security remove-trusted-cert /path/to/exported/installer-cert.pem
(exported from Keychain Access first, or the same can be done directly in Keychain Access: double-click the certificate, expand Trust, set the first dropdown to "Use System Defaults" and everything else to "No value specified.")
After that, a freshly re-signed .pkg notarized cleanly on the first attempt.
Thanks again for pointing at the right doc rather than us continuing to chase the chain-building warning literally.