NSOSStatusErrorDomain/-26276 during Code Signing trust evaluation and strict verification

Code Signing General
kimdev OP
Created
Replies 5
Boosts 0
Views 1k
Participants 2

I am diagnosing a trust failure for an archived iOS arm64 app, without changing trust settings or rebuilding speculatively.

Environment: macOS 26.6.2 (25G83), Xcode 27.0 (27A266a), as reported by installed public metadata. The diagnostic is a non-interactive Python helper calling the installed Security/CoreFoundation APIs through a bounded child-process runner in a desktop coding-agent session. This is not an Xcode GUI operation; an effect of the session, keychain/cache, or service access has not been established.

Observed results:

  • The app's embedded code CMS supplies three certificates. One explicitly identified signer matches the stored signer receipt in memory. The helper places the signer first, followed by the other supplied certificates.
  • It uses SecPolicyCreateWithProperties(kSecPolicyAppleCodeSigning), SecTrustCreateWithCertificates, and SecTrustSetNetworkFetchAllowed(false). The status-returning setup calls succeed. Disabling intermediate fetching does not prove that all OS revocation/cache/network activity is absent.
  • One SecTrustEvaluateWithError call returns false. The top-level CFError and its single kCFErrorUnderlyingErrorKey child both report NSOSStatusErrorDomain / -26276. The child has no further underlying-error key. This designated key chain was collected completely; other userInfo and localized descriptions were not collected.
  • A prior recorded evaluation returned a chain containing only the signer. The latest diagnostic did not request another evaluated chain. Supplied certificates and the evaluated/trusted chain are distinct observations.
  • Separate metadata collection found three distinct supplied certificates within their validity intervals at the observation time. Issuer/subject names matched signer → supplied issuer → third certificate, and the third had equal issuer/subject names. This does not verify issuer signatures, CA purpose, or root trust.
  • Existing independent codesign --verify --deep --strict verification exits 1 with CSSMERR_TP_NOT_TRUSTED for arm64; it does not identify the failing certificate. The extraction/trust helper does not validate the CMS/CodeDirectory signature.

The public SecTrust header allows false both for denied trust and for an evaluation that cannot complete. The inspected installed SecBase header defines errSecInternalComponent as -2070 and errSecDecode as -26275; it provided no name for -26276. I am not treating -26276 as either code or as proof of certificate/profile damage, sandbox denial, or trust-service failure.

Questions:

  1. What supported interpretation or specific conditions explain -26276 on this public Code Signing API path, including the underlying error repeating the same domain/code?
  2. What smallest independent public field or observation distinguishes policy rejection from evaluation failure while keeping the policy, intermediate-fetch=false, and trust settings unchanged? The underlying key chain supplies no more specific code.
  3. How should this be interpreted alongside CSSMERR_TP_NOT_TRUSTED from strict verification of an archived iOS app? What specific evidence separates an embedded-signature/signing-input defect from a local trust or evaluation-context failure and justifies a targeted correction?

No certificate names, fingerprints, DER, profile identifiers, account details, private paths, raw payloads, or attachments are included.

Answered by DTS Engineer in 908558022

Hmmmm, that wasn’t the answer I was expecting.

It seems like you have two goals here:

  • Check the app before you submit it to App Store Connect.
  • If App Store Complains about an app you submitted, quickly diagnose the issue.

Is that right?

If so, the best tool for the pre-submission check is indeed the Xcode organiser’s Validate App option. You can also automate this using the --validate-app subcommand in altool.

The nice thing about Validate App is that it runs a mini version of the same validation that’s done internally by App Store Connect [1], and thus it’s a solid predictor of success or failure.

The best path forward for your second point is much less clear cut. I probably wouldn’t drop down to the SecCode API for this. You can achieve much the same results using the codesign tool, and that’s an easier and more flexible option for this sort of work.

As a basic check I’d do this:

% codesign -v --deep -strict -vvv /path/to/your.app

You can also do this:

% codesign -d --extract-certificates /path/to/your.app

and then check that the leaf certificate is the one you’re expecting. You could hardwire that check — distribution certificates don’t change very often — or look inside the certificates for the key characteristics that represent an Apple Distribution certificate from your team. Those are documented, albeit cryptically, in the various docs accessible via Apple PKI page.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] To be clear, it’s not the full set of checks done by App Store Connect. Some of those checks can only be done server side.

Replies  5
Boosts 0
Views  1k
Participants  2
DTS Engineer OP
Apple

Error -26276 is errSecInternal [1]. There are two ways to learn more about this:

  • You can rummage through the Darwin source to look for all the places it’s raised.
  • You can monitor the system log to see what gets logged immediately before you get that error. See Your Friend the System Log for lots of hints and tips on that front.

However, I’d like to take a step back here. Your post suggests you’re working with trust objects (SecTrust), and that’s somewhat unusal when dealing with code signing. Is there a reason you’re not working with SecCode?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Per the Darwin source.
kimdev OP

Thank you for identifying errSecInternal.

SecTrust was used as a supplementary diagnostic of the certificates supplied by the embedded CMS, not as a replacement for code-signature validation.

On an earlier archive, SecStaticCodeCheckValidityWithErrors returned CSSMERR_TP_NOT_TRUSTED. On the later archive, codesign --verify --deep --strict also failed with CSSMERR_TP_NOT_TRUSTED for arm64. These are different artifacts, so I am keeping those observations separate.

Our preserved system logs concern an earlier export operation and cannot be correlated with the -26276 evaluation.

Which SecStaticCode CFError fields or system-log subsystem would be most useful to distinguish a signing-input defect from a local trust-evaluation failure? We have kept trust settings unchanged.

DTS Engineer OP
Apple
Which [things] would be most useful to distinguish a signing-input defect from a local trust-evaluation failure?

What are you actually trying to achieve here?

Because, for example, the approach you’d use to verify the code signature of a product before shipping it would be very different than, say, the approach you’d use in an endpoint security product.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
kimdev OP

The goal is to verify and ship our own iOS app through App Store Connect. We are not building an endpoint security product. An earlier archive failed SecStaticCodeCheckValidityWithErrors with CSSMERR_TP_NOT_TRUSTED, and a later archive failed codesign --verify --deep --strict with the same trust error. The SecTrust experiment was supplementary and did not verify either product signature.

We need to determine whether the current distribution archive can pass Apple's supported signing, export, and validation path, and if not, identify the specific signing input to correct. Is Xcode Organizer's Validate App, including its distribution certificate, provisioning profile, and entitlements review, the right next product-level check? If it fails, which exact Xcode or SecStaticCode error output would be useful to report back?

DTS Engineer OP
Apple
Recommended

Hmmmm, that wasn’t the answer I was expecting.

It seems like you have two goals here:

  • Check the app before you submit it to App Store Connect.
  • If App Store Complains about an app you submitted, quickly diagnose the issue.

Is that right?

If so, the best tool for the pre-submission check is indeed the Xcode organiser’s Validate App option. You can also automate this using the --validate-app subcommand in altool.

The nice thing about Validate App is that it runs a mini version of the same validation that’s done internally by App Store Connect [1], and thus it’s a solid predictor of success or failure.

The best path forward for your second point is much less clear cut. I probably wouldn’t drop down to the SecCode API for this. You can achieve much the same results using the codesign tool, and that’s an easier and more flexible option for this sort of work.

As a basic check I’d do this:

% codesign -v --deep -strict -vvv /path/to/your.app

You can also do this:

% codesign -d --extract-certificates /path/to/your.app

and then check that the leaf certificate is the one you’re expecting. You could hardwire that check — distribution certificates don’t change very often — or look inside the certificates for the key characteristics that represent an Apple Distribution certificate from your team. Those are documented, albeit cryptically, in the various docs accessible via Apple PKI page.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] To be clear, it’s not the full set of checks done by App Store Connect. Some of those checks can only be done server side.