How to sign DMG and installer for OSX - macos

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.

Related

macOS kext with invalid signature

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>

impossible gpg signature verification

wget https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/cryptsetup-1.7.3.tar.xz
wget https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/cryptsetup-1.7.3.tar.sign
wget https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/sha256sums.asc
shasum verified: ok
gpg --verify cryptsetup-1.7.3.tar.sign cryptsetup-1.7.3.tar.xz
the output is bad :
gpg: Signature made Sun 30 Oct 2016 01:56:01 PM UTC using RSA key ID D93E98FC
gpg: BAD signature from "Milan Broz <gmazyland#gmail.com>"
then
wget https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/v1.7.3-ReleaseNotes
wget https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/v1.7.3-ReleaseNotes.sign
gpg --verify v1.7.3-ReleaseNotes.sign v1.7.3-ReleaseNotes
this is good (although the warning):
gpg: Signature made Sun 30 Oct 2016 01:56:09 PM UTC using RSA key ID D93E98FC
gpg: Good signature from "Milan Broz <gmazyland#gmail.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 2A29 1824 3FDE 4664 8D06 86F9 D9B0 577B D93E 98FC
I make another test on another website:
wget https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.0.30.tar.bz2
wget https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.0.30.tar.bz2.sig
and everything is good as well.
Then I go to the author's blog (Milan Broz's blog), but the download link leads to the same website.
I tried some previous packages and had the same issue:
cryptsetup-1.7.1.tar.sign with cryptsetup-1.7.1.tar.gz & cryptsetup-1.7.1.tar.xz
cryptsetup-1.7.2.tar.sign with cryptsetup-1.7.2.tar.gz & cryptsetup-1.7.2.tar.xz
If I miss something here, plz tell me what.
otherwise, is there a place where I can have a correctly signed version of this software?
thanx folks.
is there a place where I can have a correctly signed version of this software?
Try from the official website: https://gitlab.com/cryptsetup/cryptsetup (now -- Nov. 2017, 9 months later, in 1.7.5 or 2.0-rc1)
this is good (although the warning):
The warning is expected. See "Check PGP Signature and Install Veracrypt 1.17":
The "WARNING: This key is not certified with a trusted signature! There is no indication that the signature belongs to the owner." means that the Veracrypt public key is not signed by you or by anybody whose key you have signed, so there is no direct line of trust between you and the Veracrypt developers.
This is as expected.

Decoding Mac App Store designated requirements

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.

Firefox ignores signature on successfully signed XPI - how to diagnose?

I've created a Firefox plugin, a Win32-native code DLL - using Firebreath. I'm working on Windows 7/x64, and targeting Windows only. The plugin itself is working well, but I'm really stuck getting a correctly signed XPI. If I don't sign my XPI, it's accepted and installed by FF 3.6 thru 10 (beta). Of course, during the install it lists the publisher as (Author not verified). So, I spent a week debugging the signing process... but FF 9 and 10 still say (Author not verified)! FF 3.6 rejects the signed XPI as invalid.
How do I troubleshoot this??
Just to repeat: I sign the xpi without error, and the resulting XPI installs successfully on FF 9 and 10, but FF still says (Author not verified).
Here's the batch code I use to sign the XPI:
echo * clean out old signing folder and xpi
if exist package rmdir /S /Q package
if exist %package%.xpi del %package%.xpi
echo * copy in files for package
md package
xcopy ..\*.rdf package
md package\plugins
xcopy ..\build\bin\Plugin\Debug\*.dll package\plugins
echo * clean out certificate database
del *.db
echo * import our signing certificate
pk12util -d . -i %keyfile% -K %pwd% -w keypass.txt
echo * adjust trust on base, intermediate and root cert
certutil -M -d . -n "VeriSign" -t "c,c,C"
certutil -M -d . -n "VeriSign Class 3 Code Signing 2010 CA - VeriSign, Inc." -t "TC,TC,TC"
certutil -M -d . -n "%certname%" -t "u,u,Cu"
certutil -L -d .
echo * create signed package
signtool -d . -X -Z %package%.xpi -k "%certname%" -p %pwd% package
I work for Mozilla, but this isn't an authoritative answer, just what I've gathered asking around:
So, essentially, each certificate authority has three trust bits Mozilla might grant it: they might trust it to sign websites, and/or mail, and/or code. Your certificate is from a certificate authority that Mozilla doesn't trust to sign code. (This is why going and manually setting the bit in your preferences makes it work—for you.)
I'm told so few people try to use binary code in xpi's that Mozilla doesn't really have an organized way to find out which authorities can be used for what. However, you can check out this list: look at the "Code Trust Bit":
https://spreadsheets.google.com/pub?key=ttwCVzDVuWzZYaDosdU6e3w&single=true&gid=0&output=html
For example (picked completely at random), ComSign Secured CA has the "Websites" and "Code" trust bits set.
I gather that Mozilla publicly discusses what rights to grant to each CA, and re-evaluates each CA periodically:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
Basically your signature needs to include full certificate chain up to the trusted VeriSign root certificate, bypassing the "VeriSign Class 3 Public Primary Certification Authority - G5" with unknown trust in mozilla (bug 602107), as by default the chain ends too soon.
Your XPI is currently signed with your certificate, with no further certificate chain included, relying that the user's browser will trust the issuer of your certificate immediately. You can examine this with Mozilla's jarsigner tool (see Mozilla NSS tools):
Tools\nss-3.11>jarsigner -verify -verbose -certs my-old.xpi
2057 Thu Sep 15 15:17:44 CEST 2011 META-INF/zigbert.rsa
sm 87 Thu Sep 15 15:17:44 CEST 2011 chrome.manifest
X.509, CN=Company Name inc., OU=General, OU=Digital ID Class 3 - Microsoft Software Validation v2, O=Company Name inc., L=City, ST=State, C=XX
[certificate will expire on 26.4.13 0:59]
(showing just the output for the 1st file)
You need to include a few more certificates to complete the chain to a certificate that is by default explicitly trusted in the end user's browser. In the end it should look like this:
jarsigner -verify -verbose -certs my-newly-signed.xpi
2057 Thu Sep 15 15:17:44 CEST 2011 META-INF/zigbert.rsa
sm 87 Thu Sep 15 15:17:44 CEST 2011 chrome.manifest
X.509, CN=Company Name inc., OU=General, OU=Digital ID Class 3 - Microsoft Software Validation v2, O=Company Name inc., L=City, ST=State, C=XX
[certificate will expire on 26.4.13 0:59]
X.509, CN=VeriSign Class 3 Code Signing 2010 CA, OU=Terms of use at https://www.verisign.com/rpa (c)10, OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
[certificate is valid from 8.2.10 1:00 to 8.2.20 0:59]
[KeyUsage extension does not support code signing]
X.509, CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
[certificate is valid from 8.11.06 1:00 to 8.11.21 0:59]
[KeyUsage extension does not support code signing]
X.509, OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
[certificate is valid from 23.5.06 19:01 to 23.5.16 19:11]
To achieve this you need to:
remove the not-explicitly-trusted VeriSing's built-in certificates from the certificate database with Mozilla's certutil tool
Build the certificate trust chain of your certificate all the way up to Microsoft's "Class 3 Public Primary Certification Authority".
sign the xpi (this time full certificates chain will be included in the signature)
verify the xpi with jarsigner as described above
test the xpi in Firefox - you should not see "Author not verified" anymore.
Caveats:
Trust bits in the built-in Firefox certificate store are actually 3-state (trusted, untrusted and unknown), despite only being shown as 2-state checkbox in the FF GUI (checked=trusted, unchecked=untrusted OR unknown). By default trust is unknown, which enables you to bypass the VeriSign's certificate as described. If you ever enabled trust via FF's checkboxes it will still work, but if you uncheck the trust checkbox the trust will be set to untrusted, which will prevent bypassing that certificate in the chain. The easiest (only?) way to reset this back to initial unknown is to delete your firefox profile.
After Mozilla eventually enables the code-signing trust bit (see the bug above) you will still need to sign like this if you want to support older versions of Firefox.
Hope it helps!

How to solve "Application failed codesign verification" when uploading to iTunes Connect?

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

Resources