.NET sandboxed app on macOS does not see certificate in keychain imported by third party sandboxed app

[tsw-github]

Hello,
we have a dotnet application (.NET 10, C#14) that uses the SescureBlackbox libraries (v24.0.9470) to access the macOS (v26.2, M3) keychain. The application runs within the macOS platform in a sandbox, because we need it to communicate with the Safari web browser extension via App Groups, the application is not distributed via the App Store. We have currently noticed a problem that when a third-party application eToken (https://www.602.cz/e-token), which also runs in a sandbox and does not share an App Group or Keychain group with our application, issues a certificate and imports it into the keychain, our application does not see it. When we disable the sandbox for our application, we see the certificate fine. When we create a simple test application via XCode/Swift, it always sees the certificate in the keychain, whether it has sandbox enabled or not. Do you know what the problem could be? Thank you.

[vst121]

Hi,
What you’re seeing is expected behavior due to macOS sandboxing. When your .NET app runs in a sandbox, it can only access keychain items that belong to its own App Group or Keychain group. Certificates imported by a third-party app (like eToken) that isn’t in the same group won’t be visible.

When you disable the sandbox, your app can see all keychain items, which is why the certificate appears. The Swift/Xcode test app likely has broader entitlements or is not constrained in the same way, which is why it sees the certificate even in a sandbox.

This isn’t a bug with SecureBlackbox. It’s the expected macOS sandbox behavior. To access the certificate in a sandboxed app, it must be imported into a shared App Group or Keychain group that your app can access.

[vst121]

From what you’ve shared:

1. The Swift/Xcode app can access the eToken certificates in a sandboxed state.
2. A minimal .NET 10 app targeting net10-macos using SecKeyChain directly can also access the certificate, even sandboxed.
3. The difference appears specifically when using SecureBlackbox to query the Keychain from your production .NET app.

This strongly suggests that the issue is within the SecureBlackbox → .NET interop layer, rather than the macOS sandbox itself. The queries from SecureBlackbox look correct at a high level, but subtle differences in:

• CFDictionary / CFString / CFBoolean marshaling
• Keychain search list handling in the sandbox
• Runtime environment differences between a net10-macos app and your production .NET app

can affect whether sandbox rules allow the certificate to be returned.

At this point, the most actionable steps would be:

• Compare the raw SecItemCopyMatching query dictionary generated by SecureBlackbox vs the direct SecKeyChain call. Logging the CFDictionary contents can reveal minor differences that matter to the sandbox.
• If possible, try a minimal P/Invoke SecItemCopyMatching wrapper in your production app to see if it reproduces the issue. This would isolate whether the problem is SecureBlackbox or the .NET runtime layer.
• Share these findings with the SecureBlackbox team so they can check the marshaling and sandbox behavior in macOS 14 / .NET 10 context.

The key takeaway is that this is not a sandbox limitation, sandboxed apps can see the certificate when using direct Keychain APIs, but SecureBlackbox’s interop may need adjustments to match that behavior.

[tsw-github]

It's strange, I came up with the following. When I target the .NET test application (use SBB libs to work with certificates) to net10-macos, the problematic certificate is loaded in both the sandbox and non-sandboxed variants. However, when I target net10 and when I create the app bundle myself then the certificate is loaded only in the non-sandbox variant. When I sign the bundle (the same entitlements file is used for all variants) then the certificate is not loaded. So the problem is not in SBB libs, but is probably somewhere in the signing step in combination with net10 and the given form of the app bundle.

net10-macos, sandboxed - ok ✅
net10-macos, non-sandboxed - ok ✅
net10, sandboxed - not working correctly ❌
net10, non-sandboxed - ok ✅

net10-macos bundle structure:

• Contents
  • _CodeSignature
  • MacOS - only main app executable
  • MonoBundle - all DLLs and other files
  • Resources
  • PkgInfo
  • Info.plist

net10 bundle structure:

• Contents
  • _CodeSignature
  • MacOS - all DLLs, main app executable and other files
  • Resources
  • Info.plist

Everything in MacOS folder is signed in both variants. This is the signing script:

function sign_app_bundle() {
  echo "[INFO] Start signing app bundle $1..."

  find "$1/Contents/MacOS"|while read fname; do
    if [[ -f $fname ]]; then
      echo "[INFO] Signing $fname"
      codesign \
        --force \
        --deep \
        --timestamp \
        --options=runtime \
        ${3:+'--entitlements' "$3"} \
        --sign "$2" \
        "$fname"
    fi
  done

  codesign \
    --force \
    --timestamp \
    --options=runtime \
    ${3:+'--entitlements' "$3"} \
    --sign "$2" \
    "$1"
}

Am I doing anything wrong?

[vst121]

It strongly suggests the issue is not in SecureBlackbox or the Keychain query, but in how the net10 bundle is constructed and signed.

A few things stand out:

1. In the net10 bundle, all DLLs and the main executable are placed directly inside Contents/MacOS, and every file is signed individually using --deep.
2. --deep signing is generally discouraged because it can lead to unexpected entitlement propagation and makes it harder to reason about which binary actually carries the sandbox entitlement.
3. In a sandboxed app, only the actual executable that launches the process must carry the correct entitlements. If entitlements are applied inconsistently (or applied to nested binaries unnecessarily), macOS may enforce different security rules at runtime — including Keychain filtering.

Since net10-macos produces a proper macOS bundle layout (with a clear single app executable in Contents/MacOS), and that variant works correctly, I would focus on:

• Verifying which binary is the real process entry point in the net10 bundle.
• Checking its effective entitlements using:

codesign -d --entitlements :- YourApp.app

and also:

codesign -d --entitlements :- YourApp.app/Contents/MacOS/<actual_executable>

• Avoiding --deep and instead signing in proper order:

1. Sign nested binaries (if any) without entitlements.
2. Sign the main executable with entitlements.
3. Sign the bundle itself without --deep.

Most likely, in the failing net10 sandboxed case, the running process does not end up with the exact sandbox entitlement set that you expect, even though the same entitlements file is used.

Given the behavior matrix, the signing/layout difference is the most plausible explanation.

[tsw-github]

Hi,
I modified the signing script:

function sign_app_bundle() {
  echo "[INFO] Start signing app bundle $1..."
  
  find "$1/Contents/MacOS" -type f ! -name "$APP_EXECUTABLE" | while read -r fname; do
    echo "[INFO] Signing $fname"
    codesign \
      --force \
      --timestamp \
      --options=runtime \
      --sign "$2" \
      "$fname"
  done
  
  # Sign main executable with entitlements
  echo "[INFO] Signing $1/Contents/MacOS/$APP_EXECUTABLE"
  codesign \
    --force \
    --timestamp \
    --options=runtime \
    ${3:+'--entitlements' "$3"} \
    --sign "$2" \
    "$1/Contents/MacOS/$APP_EXECUTABLE"
  
  codesign \
    --force \
    --timestamp \
    --options=runtime \
    ${3:+'--entitlements' "$3"} \
    --sign "$2" \
    "$1"
}

The problem persists. I checked the effective entitlements for app bundle and main executable and entitlements are the same. I checked the console.app logs again and found out that there is a problem with com.apple.CoreAuthentication.agent and com.apple.ctkd.token-client. When I explicitly add these two things to entitlements, section com.apple.security.temporary-exception.mach-lookup.global-name, then the certificate correctly appeared. Thank you for your assistence and guidance.