Posts

Post marked as solved
9 Replies
4.7k Views
We have a DMG for our Mac desktop app that has notarized OK, but on stapling we get the error below. The DMG and its contained app are signed (prior to Catalina this was sufficient.) The .app folder is directly constructed in our build process (not using XCode or similar); the .dmg is by DMGCanvas. The app only contains the UI; the libs and command-line tools are in a sibling folder, laid out much as they are on our other *nix builds. (When installed, everything is placed in a dedicated folder inside /Applications to keep it all in one place.)Searching for the error "Certificate authority pinning mismatch" almost entirely links to cssmapple.h, which implies not many other people have run into this?OS: 10.15.1Xcode: 11.1xcrun: 48Notarization:Request Identifier: 71c0468a-2a58-46ae-b699-22462e8593b0Stapling:Properties are { NSURLIsDirectoryKey = 0; NSURLIsPackageKey = 0; NSURLIsSymbolicLinkKey = 0; NSURLLocalizedTypeDescriptionKey = "Disk Image"; NSURLTypeIdentifierKey = "com.apple.disk-image-udif"; "_NSURLIsApplicationKey" = 0; } Codesign offset 0xcee4caf length: 9556 Stored Codesign length: 9556 number of blobs: 3 Total Length: 9556 Found blobs: 3 Props are { cdhash = {length = 20, bytes = 0xfb512617c5c078595f7a2ab6f74c73d7fa00a73c}; digestAlgorithm = 2; flags = 0; secureTimestamp = "2019-09-12 15:10:53 +0000"; signingId = "FICO Xpress 8.7.0 for Mac Installer"; teamId = KL84GEX7ZW; } JSON Data is { records = ( { recordName = "2/2/fb512617c5c078595f7a2ab6f74c73d7fa00a73c"; } ); } Headers: { "Content-Type" = "application/json"; } Domain is api.apple-cloudkit.com Certificate trust evaluation did not return expected result. (5) [leaf AnchorApple ChainLength IntermediateMarkerOid] Certificate trust evaluation for api.apple-cloudkit.com did not return expected result. Certificate authority pinning mismatch. Certificate trust evaluation did not return expected result. (5) [leaf AnchorApple ChainLength IntermediateMarkerOid] Certificate trust evaluation for api.apple-cloudkit.com did not return expected result. Certificate authority pinning mismatch. Could not establish secure connection to api.apple-cloudkit.com Response is (null) error is Error Domain=NSURLErrorDomain Code=-999 "cancelled" UserInfo={NSErrorFailingURLStringKey=https://api.apple-cloudkit.com/database/1/com.apple.gk.ticket-delivery/production/public/records/lookup, NSLocalizedDescription=cancelled, NSErrorFailingURLKey=https://api.apple-cloudkit.com/database/1/com.apple.gk.ticket-delivery/production/public/records/lookup} Size of data is 0 CloudKit's response is inconsistent with expections: (null) The staple and validate action failed! Error 68.
Posted
by jperks.
Last updated
.
Post not yet marked as solved
6 Replies
4.9k Views
We have a multi-platform suite of command-line executables and libraries that we ported to Mac; I'm new to Mac development. The file layout was/Applications/ (company folder)/ (our UI).app(product name)/ bin/ ...executalbes...lib/ ...dylibs...(other stuff)/...This was shipped in a DMG that was codesigned, as was the app. This worked OK until Catalina.Now on Catalina, we have codesigned all the executables, dylibs, apps (including ones nested in the top-level app's framework), frameworks, and the DMG itself. When we notarize it the resulting JSON log lists no issues. However, when I run any of our executables that depends on one of our dylibs I get a pop-up telling me the "developer cannot be identified". Even though it has been signed and notarized OK. Running codesign with -dvvv option includes the following:SHA-256 hash choicelist of Authority entries terminating in Apple Root CATeamIdentifier entryTimestampRuntime: 10.13.0Question How can I fix this, or at least get Gatekeeper to tell me why it's not accepting this file? Maybe a log, or an equivalent of spctl --assess for files rather than apps?ObservationsThis only happens when the OS is Catalinait's under the /Applications folderoutside of /Applications (e.g. in a folder on desktop) it only happens sometimes (and sometimes it claims a dylib can't be loaded on first attempt, then succeeds if tried a moment later)the executable depends on one or more of our dylibs (standalone ones run OK)the executable has the com.apple.quarantine xattr set I've tried to mix'n'match between clean and downloaded (i.e. quarantine-xattr'd files) and the problem only arises if the executable is quarantined; it doesn't care if a non-quarantined executable loads a quaratined dylibThe signing operation was done via codesign with args "--deep --strict --timestamp --options runtime", and then verified I've since updated this to include some of the Hardened Runtime entitlements to fix another build issue, but it hasn't helped with this oneThe executables depend on the dylibs via @rpath (as reported by otool -L)Result of "spctl --assess -t open --context context:primary-signature -v" on the DMG acceptedsource=Notarized Developer IDResult of "spctl --assess --context context:primary-signature -v" on the app acceptedsource=Notarized Developer IDResult of running it on the various nested apps in the app's Contents/Framework/nwjs Framework.framework/Helpers/ folder rejected (the code is valid but does not seem to be an app)(I'm not sure this is relevant to the problem at hand, but I just ran into it.)
Posted
by jperks.
Last updated
.