I have the following designated requirement in my app:
(
anchor apple generic
and certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */
or
anchor apple generic
and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */
and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */
and certificate leaf[subject.OU] = <redacted_team_id>
)
and identifier "com.company.app"
Now I’m trying to validate a development build of my app against this DR. The “apple generic” root certificate check works fine, the bundle identifier check works fine. The certificate check in the first branch (6.1.9) looks for a “Apple Mac App Signing (Release)” certificate, so it fails. That’s expected with a development build.
As I understand the DR, the second branch (checking for certificate fields 6.2.6 and 6.1.13) should apply to development builds, but both certificate field checks fail:
$ codesign --verify -R="certificate 1[field.1.2.840.113635.100.6.2.6]" MyApp.app
test-requirement: code failed to satisfy specified code requirement(s)
$ codesign --verify -R="certificate leaf[field.1.2.840.113635.100.6.1.13]" MyApp.app
test-requirement: code failed to satisfy specified code requirement(s)
My question is: what exactly are the 6.2.6 and 6.1.13 certificate fields and why doesn’t my (properly signed) development build match them?
The 6.2.6 and 6.1.13 certificate fields are related to apps signed with the Developer ID certificate. The development build doesn’t match them because it was signed with the plain Mac development certificate.
Related
I don't know why electron-builder cannot find a valid identity.
Using the environment variable to debug, I always end up with the same problem where it says there is no valid identity despite listing there to be 1 valid identity underneath.
I have tried specifying the cert name as the "identity" property of the top level key "mac" in package json and leaving it out.
I have tried specifying the keychain (CSC_KEYCHAIN) to login.
I have tried adding the "Developer ID Application: ****" cert to login, System, and custom keychains (I don't know why electron builder keeps making extra keychains called "1").
I have tried adding an "Apple Root CA" to all those keychains from the previous line.
I have tried specifying and omitting CSC_NAME, CSC_LINK + CSC_KEY_PASSWORD.
I have tried CSC_IDENTITY_AUTO_DISCOVERY as false.
Running the command line from this page appears to work (as running spctl -a -t exec -vv 'Appname.dmg' gives back "source=Unnotarized Developer ID" ), but I would like to follow the automatic notarization process suggested here which is based off of electron-builder #3870
When I specify the identity in package json, the closest I get to is saying
Identity name is specified, but no valid identity with this name in the keychain identity=***** allIdentities=
1) BBBBBBBBB "Developer ID Application: ***** (XXXXX)"
1 identities found
Valid identities only
1) BBBBBBBBBB "Developer ID Application: ***** (XXXXX)" <---lists the exact one above
1 valid identities found
at/........
When I run security find-identity -v, or security find-identity -v -p codesigning, the exact same cert appears again.
Have I missed anything?
We have a kext-enabled Developer ID which we are using for code signing and I have verified that the certificate contains the 1.2.840.113635.100.6.1.18 extension required. However, kextutil -tn still shows:
Untrusted kexts are not allowed
Kext with invalid signature (-67050) denied: /Library/StagedExtensions/Library/Extensions/A0587A5A-52FC-46DC-832E-81919195902C.kext
After signing, I re-extracted the signature using 'codesign -d --extract-certificates' to verify that the correct kext-enabled Developer ID certificate was indeed used during the signing process.
I have "Apple Worldwide Developer Relations Certification Authority" and "Developer ID Certification Authority" certs in both the login and System keychains.
Any suggestions on where to go from here? Thanks!
I've figured it out. Turns out macOS 10.13+ denies kexts by default -- even those signed with a valid kex-enabled Dev. ID certificate (which we have). The solution is described in this tech note (and alluded to in the comments above):
https://developer.apple.com/library/archive/technotes/tn2459/_index.html
The first time an attempt is made to load the kext, macOS should present the user with a popup informing them that it was blocked. The user then needs to go to System Preferences > Security & Privacy in order to approve the kext. Note that the approval needs to happen within 30 minutes of the load attempt or it will disappear. Subsequent load attempts will be rejected silently but will reactivate the prompt within "Security & Privacy" -- giving the user another chance to approve the kext.
$ csrutil status
System Integrity Protection status: enabled.
$ sudo kextutil -v /Users/xxx.yyy/Library/Developer/Xcode/DerivedData/zzzz-dvqiwdodghcxydamtmpmffakjyrt/Build/Products/Release/zzzz.kext
Defaulting to kernel file '/System/Library/Kernels/kernel'
/Users/xxx.yyy/Library/Developer/Xcode/DerivedData/zzzz-dvqiwdodghcxydamtmpmffakjyrt/Build/Products/Release/zzzz.kext appears to be loadable (not including linkage for on-disk libraries).
Loading /Users/xxx.yyy/Library/Developer/Xcode/DerivedData/zzzz-dvqiwdodghcxydamtmpmffakjyrt/Build/Products/Release/zzzz.kext.
/Users/xxx.yyy/Library/Developer/Xcode/DerivedData/zzzz-dvqiwdodghcxydamtmpmffakjyrt/Build/Products/Release/zzzz.kext successfully loaded (or already loaded).
$ kextstat | grep xxxxxx
161 0 0xffffff7f83af6000 0x3c9000 0x3c9000 com.xxxxxx.driver.zzzz (1) 230E04D6-5C15-373F-8F73-E23566AE3C22 <22 15 5 4 3 1>
In order to get Microsoft PlayReady Server Agreement I need to sign WMLA.ocx file with Extended Validation Code Signing Certificate and send it back to Microsoft.
I've obtained Extended Validation Code Signing Certificate pack from Thawte, it contains:
1. Code Signing certificate itself
2. CA
3. PKCS7 certificate
Put Code Signing certificate itself to separate file with .cer extension.
I've downloaded Microsoft Code Signing pack from http://go.microsoft.com/fwlink/?LinkID=148072 contains:
a. Signcode.exe
b. WMLA.ocx
c. WMLA Instructions for EV Cert OCX v10 17 16.pdf
Following instructions (option 3) from http://msdn2.microsoft.com/en-us/library/ms537364.aspx we've tried to sign .ocx file using Signcode.exe and Code Signing certificate itself in .cer file.
Enter following command in command line:
C:\Users\User123\WMLA>signcode.exe -c ev.cer WMLA.ocx
And got error:
Error: There is no valid certificate in the my cert store
Error: Signing Failed. Result = 8009200c, (-2146885620)
Certificate is valid, but I'm not sure about signcode.exe options and putting certificate in separate .cer file?
I've been fighting with this for quite some time and would be extremely grateful if anyone could help me understand what's happening here.
I have an install4j project that creates installer packages for Windows and OSX. I have a regular signing cert for Windows and this works without issue. I have an Apple developer certificate as well. I've exported the private key from my keychain to a p12 file. I've tested the resulting p12 file to make sure it works with the keystore password. The certificate is definitely valid, since I just created it (again) today. And, when I run the installer build via Maven, it even looks as though everything is going fine:
[INFO] Compressed media file 'Mac OS X Single Bundle':
[INFO] Compressing files
[INFO] Generating VM options file vmoptions.txt.
[INFO] Signing installer
[INFO] Signing DMG
[INFO] Moving media files to media directory /Users/....
[INFO] The name of the media file is my-app_macos_1_1_1.dmg.
[INFO] The size of the media file is 4.8 MB
Which seems good, except that the installer and dmg AREN'T signed, or at least not in a way that's useful:
$ spctl -a -v target/media/my-app_macos_1_1_1.dmg
target/media/my-app_macos_1_1_1.dmg: CSSMERR_TP_CERT_EXPIRED
$ spctl -a -v /Volumes/my-app/My\ Application\ Installer.app
/Volumes/my-app/My Application Installer.app: CSSMERR_TP_CERT_EXPIRED
The cert is NOT expired:
Alias name: mac developer: me myself (my company, inc.)
Creation date: Mar 6, 2017
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: C=US, O="Radiologics, Inc.", OU=K865L34KBQ, CN=Mac Developer: Me Myself (XXXX), UID=YYYY
Issuer: CN=Apple Worldwide Developer Relations Certification Authority, OU=Apple Worldwide Developer Relations, O=Apple Inc., C=US
Serial number: 30544da25ea67233
Valid from: Mon Mar 06 14:46:17 CST 2017 until: Tue Mar 06 14:46:17 CST 2018
But whether I build the dmg/installer directly from install4j or through the Maven plugin, the result is not valid. I always get something similar to this:
$ codesign -dvvv target/media/my-app_macos_1_1_0.dmg
Executable=.../target/media/my-app_macos_1_1_0.dmg
Identifier=my-app_macos_1_1_0
Format=disk image
CodeDirectory v=20100 size=173 flags=0x0(none) hashes=1+2 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha256=XXXXXX
Hash choices=sha256
CDHash=XXXXX
Signature size=8641
Authority=(unavailable)
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements count=1 size=36
In order for us to be able to distribute this app, we really need to get this to work, but I've spent literally days on this without making any progress at all. If anyone could shed any light on what's going on here, I'd greatly appreciate it.
There are two different kinds of certificates for distributing apps outside of the Mac App Store.
An application certificate and an installer cetificate.
Check your certs (which you can do via the "My Certificates" in the Keychain Access app hiding in /Application/Utilities) to make sure you're using an installer certificate (on my machine the name of it is "Developer ID Installer: Michael Dautermann". This is separate from the "Developer ID Application" certificate you use to codesign apps.
More information can be seen here.
As for DMG's, my original answer would have been "can't do that", but actually as of MacOS 10.11.5 you CAN sign dmg files. More information can be seen in the "Signing Disk Images" section of the "macOS code signing in depth" reference guide. You'd use your Developer ID Application certificate.
I've got a problem that I couldn't solve with a deep search in different resources as most of the "similar" points out to be an error with Icon.png size, etc...
I've tried to upload my application after verifying that:
Correctly builds and run on my device
That my certificates are installed properly
That my certs / profiles are not expired.
That the Icon.png has the proper size and format of 57x57 PNG.
And several other things.
Ran codesign --verify -vvvv MyApp.app which worked fine.
My ZIP File was properly done
When I've tried to upload through the iTunes connect interface I got the simple error above, and that's why I tried with ApplicationLoader, to try and find out what's causing the error looking at the console.
The console showed the following:
16/02/10 13:25:52 ApplicationLoader[549] *** Codesign error (please ignore invalid option comments): got requirements(0x800000, 534)
Executable=/var/folders/WZ/WZu24JnOGNe9L79GWq0IlU+++TI/-Tmp-/MyApp.zip/MyApp.app/MyApp
Identifier=com.realtimed.MyApp
Format=bundle with Mach-O thin (armv6)
CodeDirectory v=20100 size=829 flags=0x0(none) hashes=33+5 location=embedded
Signature size=4333
Authority=iPhone Developer: My Name (XXXXXXXXX)
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Signed Time=16/02/2010 13:22:24
Info.plist entries=17
Sealed Resources rules=3 files=28
Internal requirements count=1 size=144
Executable=/var/folders/WZ/WZu24JnOGNe9L79GWq0IlU+++TI/-Tmp-/MyApp.zip/MyApp.app/MyApp
got entitlements(0x800400, 317)
codesign_wrapper-0.7.3: using Apple CA for profile evaluation
codesign_wrapper-0.7.3: Caling codesign with the following args:
codesign_wrapper-0.7.3: /usr/bin/codesign
codesign_wrapper-0.7.3: --verify
codesign_wrapper-0.7.3: -vvvv
codesign_wrapper-0.7.3: -R=anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.1] exists and certificate leaf[field.1.2.840.113635.100.6.1.4] exists
codesign_wrapper-0.7.3: --entitlements
codesign_wrapper-0.7.3: /var/tmp/signingbox/codesign_wrapper_entitlements.plist
codesign_wrapper-0.7.3: /var/folders/WZ/WZu24JnOGNe9L79GWq0IlU+++TI/-Tmp-/MyApp.zip/MyApp.app
**/var/folders/WZ/WZu24JnOGNe9L79GWq0IlU+++TI/-Tmp-/MyApp.zip/MyApp.app: valid on disk
/var/folders/WZ/WZu24JnOGNe9L79GWq0IlU+++TI/-Tmp-/MyApp.zip/MyApp.app: satisfies its Designated Requirement
test-requirement: failed to satisfy code requirement(s)
codesign_wrapper-0.7.3: failed to execute codesign(1)**
Any help / feedback or ideas on how to solve the situation would be highly appreciated.
I found the solution to this problem after deeply looking at the log file.
Although I created my own Distribution Profile and assigned to the CODE SIGNING IDENTITY the correct value for the developer certificate, it didn't work giving me an error: "Application failed codesign verification".
The problem is at the following line:
Authority=iPhone Developer: My Name
(XXXXXXXXX)
Despite the correct selection in the project settings for the Distribution profile, XCode was compiling it with the developer certificate.
I finally solved it: Right click on the "Targets" -> Get info -> and there it was selected (don't ask me why) the wrong distribution certificate instead of the right one.
I corrected that and it finally was accepted.
Related links (you need a developer account): https://devforums.apple.com/message/147964
Excellent post. I too was having this trouble and after much headache realized that both the Project AND the Target should be checked for using the correct Code Signing Identity. Somehow Xcode was reverting back to the Developer Provisioning Profile instead of the Distribution Provisioning Profile. It even did so on a build right after I had deliberately selected the correct one!
I. To be safe, first do the following:
Clean all builds.
Delete contents of build folder in finder.
Delete existing code signing identities from the project and target settings.
Restart Xcode.
II. Then check the Project for the correct Provisioning Profile:
Go to Project Settings > Build Tab > Code Signing Identity
Select the appropriate Distribution Provisioning Profile
III. Now check the Target:
Target > Get Info > Build Tab > Code Signing Identity
Select the appropriate Distribution Provisioning Profile
IV. Cross fingers and hope you never see that blasted little yellow triangle again.
Cy took the right approach for solving this problem - When "Application failed codesign verification" is a build warning, expand that item in the build log and scan for the root cause of the failed signature verification.
In the case of Cy.'s original post you'll see that the root issue was "test-requirement: failed to satisfy code requirement(s)", and in my experience this is almost always caused by signing with the wrong certificate i.e. an iPhone Developer profile instead of iPhone Distribution.
The root cause is not always an obvious explanation, but should guide you at least with additional search terms or troubleshooting ideas.
For others experiencing the "Application failed codesign verification" during Xcode Archive Validation or Submission, look to the build log at Product > Archive time for a build warning by the same title and expand that for the root cause. Then take a look at Apple's complete list of potential causes of this error at the following URL "How do I resolve the error: Application failed codesign verification?"
Check that the TARGET (and not only the Project) is setup with the correct Code Signing Identity for Release