“codesign”

Thanks for the updated posts. [quote='873386022, Leo_Nagano, /thread/812857?answerId=873386022#873386022, /profile/Leo_Nagano'] legacy dns-proxy entitlement [value] [/quote] To be clear, this isn’t a legacy value. This value is used for App Store distribution, both on iOS and macOS. It’s also used for development. The -systemextension suffix is used for direct distribution using Developer ID signing. Neither value is more legacy than the other. As to what’s going wrong, you’ve tried a lot of different things and it’s hard to be sure what’s what at this state. However, this is problematic: NSExtensionPointIdentifier com.apple.system_extension.network_extension And it suggests that you could do with some high-level guidance. The best place to get that is Xcode. Consider this sequence: In Xcode 26.2, create a new project from macOS > App template. In my case I named it “Test812857”. Then create a new target within that project, using the macOS > System Extension > Network Extension template. In my case

[quote='873484022, oddeyed, /thread/799110?answerId=873484022#873484022, /profile/oddeyed'] My application currently requires elevated privileges or “sudo” to verify the codesign … [/quote] Lemme see if I understand this correctly: You take a Mac that’s never seen your app before. You install your app in the standard way that a user would install it. This command fails: % codesign --verify --deep --strict /path/to/your.app Instead you have to do this: % sudo codesign --verify --deep --strict /path/to/your.app Is that right? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hello Quinn, a couple of follow up questions on this issue. My application currently requires elevated privileges or “sudo” to verify the codesign using the codesign —verify --strict command. Will this cause the Apple Gatekeeper to throw this prompt? If that is the case, why is this prompt not shown on all of the macOS machines if Gatekeeper is unable to read our application due to restricted permissions?

Then Xcode shouldn't just add dupes of these certs. What happens is signing fails, Xcode gives no guidance. And so the Xcode UI has the option to add a new one. Then end up with dupe certs that cannot be cleaned out. Then the profiles fail if not the correct out of the 3 dupes, and signing still fails if the cert private key isn't in the keychain. Again no guidance from Xcode on any of these signing failures. Here's one error. Xcode shows Ineligible for the profile: Provisioning profile KramViewerProvision doesn't include signing certificate Developer ID Application: ... (hash...) Here's an error when the private key isn't in the Keychain. C6BA06....: no identity found Command CodeSign failed with a nonzero exit code

[quote='872696022, joel2001k, /thread/812624?answerId=872696022#872696022, /profile/joel2001k'] As reading about Certificate types, I think this certificate is missing: [/quote] No. As I mentioned above, that platform specific distribution certificate type is no longer relevant. It’s been subsumed by Apple Distribution, which works for all platforms. [quote='872712022, joel2001k, /thread/812624?answerId=872712022#872712022, /profile/joel2001k'] What is with these 2 files? [/quote] You’re asking me?!? Seriously though, Apple’s standard processes don’t use openssl. If you go down that path, you won’t find any help from Apple sources. And I think that speaks to the main issue you’re having here: Apple’s code-signing infrastructure relies on digital identities in the keychain. A digital identity is the combination of a certificate and the private key that matches the public key in that certificate. Both of these have to be in the keychain. The openssl sequence you posted above doesn’t add the private key to the k

OK, so definitely not your project. If you temporarily remove the iCloud key-value storage capability capability, the app builds, right? If so, look in the build log for an entry like this: CodeSign …/Test811382.app (in target 'Test811382' from project 'Test811382') cd …/Test811382 Signing Identity: Apple Development: Quinn Quinn (7XFU7D52S4) Provisioning Profile: iOS Team Provisioning Profile: com.example.apple-samplecode.Test811382 (5db3ba83-07fb-4780-8ca4-f87de64fd20d) Note For info on how to get the build log, see Command [something] failed with a nonzero exit code. The UUID in that entry is the UUID of the provisioning profile that Xcode is using to sign your app. You should find that in ~/Library/Developer/Xcode/UserData/Provisioning Profiles. Now dump the contents of that profile like so: % security cms -D -i 5db3ba83-07fb-4780-8ca4-f87de64fd20d.mobileprovision | plutil -p - { … Entitlements => { application-identifier => SKMME9E2Y8.com.example.apple-samplecode.Test811382 com.apple.devel

[quote='812770021, davertay-j, /thread/812770, /profile/davertay-j'] it appears to contain 19 certificates [/quote] I agree that that’s strange. A distribution profile should only contain distribution certificates, and most teams only have one or two of those active at any one time. I recommend that you check the type of the profile and also look at the certificates embedded in the profile. [quote='812770021, davertay-j, /thread/812770, /profile/davertay-j'] Is there a way to find out which certificate is missing exactly? [/quote] Yes. TN3125 Inside Code Signing: Provisioning Profiles explains how you can pull apart the profile to work out what it authorises. You combine that with the --extract-certificates option to codesign, which allows you to determine the certificate of the code-signing identity that was used to sign the code. I’ve got some info on how to do that somewhere… Oh, right, here it is… Have a look at the Check the Signing Certificate section of Resolving Code Signing Crashes on Launch

Notarisation is a read-only process, so notarising an app can’t cause it to stop working. Usually problems like this are caused by the hardened runtime. Notarisation requires that you enable the hardened runtime, so folks re-sign their app with that enabled and then it fails. There are two ways you can approach that: Run the Developer ID-signed build before you notarise it. This should hang in the same way. Enable the hardened runtime on your day-to-day development builds. This lets you debug this issue like you would any other hang. Resolving Trusted Execution Problems has a section on debugging hardened runtime issues, namely Resolving Hardened Runtime Incompatibilities. Oh, one more thing. This is problematic: codesign --force --deep --verify --verbose --option runtime --sign Developer ID Application: ORG NAME (ZZZZZZZZZ) path/to/app.app To start, you’re supplying both --verify and --sign, which is never a good idea. For any given invocation of codesign, you should do one or the other. Ne

Thanks for the extra info. First up, an SFAuthorizationPluginView can’t support smart card authentication in the same way as the built-in login UI can (FB11978008). That’s because the built-in UI populates various authorization context values but SFAuthorizationPluginView does not. The name and format of these values is not documented, so the authorization plug-in can’t work around this issue itself. However, that’s not what you’re trying to do. Rather, you’re trying to simply use smart-card-back credentials, and that’s more feasible. There’s one thing to check here, and then a roadblock to get around. The thing to check is that your smart card is available in pre-login context. To do that, disable your authorisation plug-in, reverting to the built-in login UI. Then check that you can use the built-in PIV smart card support to pair your user with your smart card, and thus log in with your YubiKey. I don’t have docs for how to do that handy — that’s more of an Apple Support thing than a DTS thing — but I do it

Thanks for the replies. You are both quite right that I should have provided more information. When I say that notarization succeeds, I mean that I submit the dmg file produced by the build to the Apple notarization service and receive a status of 'Accepted'. I take this to mean all is well. When I say that notarization fails, I mean that the notarization step produces a status of 'Invalid'. Retrieving the notarization log indicates that the binaries were not signed. I've just gone through this again with my two machines. The build here is performed by scripts that are maintained in source code control and forced to be identical in both setups. The build infrastructure is also the same for both. Before beginning, both machines were powered off for a period of time. Power up one machine. Ensure the source tree is up-to-date. Run the build to produce a signed dmg. Submit it for notarization. The submission produces a status of Accepted. Power down the first machine. Power up the second machine. Again ensure the

Hi all, I’m seeing the same behavior and it’s currently blocking me from shipping my product. Starting Jan 6–7, every notarization submission stays “In Progress” indefinitely (I’ve waited 8+ hours with no transition to Accepted/Invalid). This includes a minimal control submission: I created a tiny AppleScript .app, signed with Developer ID + hardened runtime, zipped with ditto, and submitted via xcrun notarytool submit. That submission also remains In Progress. I’ve verified signatures with codesign --verify --deep --strict, confirmed my Developer ID cert is valid, and checked for account/agreement issues. The only time I’ve seen a terminal state recently is when a submission fails validation quickly (Invalid), but anything that enters processing appears to stall. I currently have multiple submission IDs stuck in notarytool history. Has anyone found a workaround or received guidance from Apple Support? Happy to share submission IDs/timestamps if that helps with escalation. Thanks.