Verifying App Signatures and Notarization with codesign and spctl
Checking whether an application's code signature and notarization are actually valid from the command line, instead of relying only on Gatekeeper's pass/fail dialog with no further detail.
When Gatekeeper blocks or warns about an application, the GUI dialog tells you very little beyond “this app can’t be opened” or a generic damage warning — codesign and spctl, both built into macOS, give you the actual underlying signature and notarization details directly, which is usually necessary for understanding whether a warning reflects a genuine problem or something more benign like an expired developer certificate.
Checking an application’s code signature directly
codesign -dv --verbose=4 /Applications/SomeApp.appThis dumps detailed information about the app’s code signature: the signing identity (developer name/team), the specific certificate chain, the designated requirement, and the signature’s validity. --verbose=4 gives the most detailed output level, including information that’s genuinely useful for diagnosis but omitted at lower verbosity levels.
Verifying the signature is actually valid, not just present
An application having a code signature at all doesn’t mean that signature is currently valid — checking validity specifically:
codesign -v --verbose=4 /Applications/SomeApp.appA clean result (no output, or explicit confirmation of validity) confirms the binary hasn’t been modified since signing and the signature’s certificate chain is currently trusted. A failure here — distinct from the app simply lacking a signature — indicates either actual tampering or a genuinely broken/expired signing certificate, which is meaningfully different information than Gatekeeper’s generic blocking dialog communicates on its own.
Checking Gatekeeper’s specific assessment
spctl -a -vv /Applications/SomeApp.appThis runs the same assessment Gatekeeper itself performs when you attempt to open an application, but with detailed output explaining exactly why it passed or failed — source=Notarized Developer ID confirms proper notarization, while a rejection reason like source=no usable signature or a specific notarization failure gives you the actual, specific reason Gatekeeper is blocking the app, rather than only the generic dialog text.
Checking notarization status specifically
Notarization is a distinct check from the code signature itself — an app can be validly signed but not notarized, or notarized but with a since-revoked ticket. spctl’s verbose output above already surfaces this, but confirming the notarization ticket itself is stapled to the app bundle (rather than requiring an online check against Apple’s servers every time) is worth checking separately:
stapler validate /Applications/SomeApp.appA stapled ticket means the notarization proof travels with the app bundle itself, letting Gatekeeper verify it offline — an app that validates via spctl only when online, but fails stapler validate, has valid notarization that simply wasn’t stapled to the bundle, a distinct and generally less convenient (though not necessarily insecure) situation from a fully stapled app.
Diagnosing “app is damaged and can’t be opened” specifically
This particular error frequently isn’t about actual file damage at all — it’s commonly triggered by the quarantine extended attribute macOS attaches to downloaded files, combined with a signature that fails verification (often because the file was modified after download, even trivially, by certain archive/decompression tools that don’t preserve it correctly). Checking the quarantine attribute directly:
xattr -p com.apple.quarantine /Applications/SomeApp.appconfirms whether quarantine is present, and re-running the codesign -v check above against the specific app confirms whether the signature itself is actually intact — distinguishing a genuinely corrupted download (signature verification genuinely fails) from an overly cautious quarantine flag on an otherwise perfectly valid app.
Why checking this directly beats guessing from the Gatekeeper dialog alone
The generic system dialog is deliberately simplified for a non-technical audience, which means it collapses several genuinely different underlying situations (invalid signature, missing notarization, revoked certificate, genuine file corruption, an overly cautious quarantine flag on an otherwise fine file) into the same vague warning. codesign and spctl’s verbose output distinguish between these directly, which matters because the correct response is different for each — re-downloading a genuinely corrupted file is a different fix than clearing an overly cautious quarantine flag on a file that was never actually damaged, and guessing between them from the generic dialog alone isn’t reliable.