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.