Notarization failing, not signed with Developer ID Cert

I'm having problems getting our application Notarized. It gets this error:

  "severity": "error",
  "code": null,
  "path": "Metrix Installer.dmg/Install/MetrixApplication.pkg",
  "message": "The binary is not signed with a valid Developer ID certificate.",

The thing is that I did do a codesign on it. (I've also tried productsign)

codesign -f --verbose=4 --timestamp --options runtime --sign F3YTHMJYQ9 Metrix/Install/MetrixApplication.pkg

codesign -dvvv Metrix/Install/MetrixApplication.pkg
 Executable=/Users/johnluss/Metrix/BuildInstaller/Metrix/Install/MetrixApplication.pkg
 Identifier=MetrixApplication
 Format=generic
 CodeDirectory v=20200 size=177 flags=0x10000(runtime) hashes=1+2 location=embedded
 Hash type=sha256 size=32
 ...
 Signature size=9053
 Authority=Developer ID Application: Eps Us, LLC (F3YTHMJYQ9)
 Authority=Developer ID Certification Authority
 Authority=Apple Root CA
 Timestamp=Sep 9, 2022 at 1:54:18 PM
 Info.plist=not bound
 TeamIdentifier=F3YTHMJYQ9
 Sealed Resources=none
 Internal requirements count=1 size=180

Any suggestions as to what I'm missing or doing wrong?

Any suggestions as to what I'm missing or doing wrong?

You are signing your installer package as code, which is not right. Installer packages must be signed by installer tools using a Developer ID Installer code signing identity. Packaging Mac Software for Distribution shows the basics.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Well, the referenced instructions are a bit vague as to exactly which tool I should use when. The particular item in the DMG that the error is about is the actual Application that will be installed, not the installer application. The error just mentions a "Developer ID" certificate - which doesn't narrow down which particular version of certificate is needed.

Note that we used to use:

productsign --timestamp --sign $SIGNID "$PACKAGE_DEST/Install/MetrixApplication.pkg" "$PACKAGE_DEST/Install/MetrixApplication-signed.pkg"

and that worked - before we had to switch to a whole new Apple developer account and certificates. It gets the exact same error as my attempt to use codesign.

I think that I am using a Developer ID Installer code signing identity.

H2WGX2D1Q6NW:BuildInstaller johnluss$ security find-identity -v
  1) 3D7E5672AF0B37ABB6B3963FE0798A6E937FB44D "3rd Party Mac Developer Installer: Eps Us, LLC (F3YTHMJYQ9)"
  2) A4BD899689B2C6ABB973D04B3D3519FC2859AAA2 "Developer ID Application: Eps Us, LLC (F3YTHMJYQ9)"
  3) 4B963D271E6BA871BFCA42C21ACD6A5A6E812A09 "Developer ID Installer: Eps Us, LLC (F3YTHMJYQ9)"
  4) 7FAFF5716D350A39D28FA64049A7E30A4FF929A4 "Apple Development: John Lussmyer (9W4G27WAV9)"
     4 valid identities found

The SIGNID I pass is F3YTHMJYQ9

Well, the referenced instructions are a bit vague as to exactly which tool I should use when.

Can you elaborate on what you found ambiguous. The Build an Installer Package says:

If you’re distributing a product independently, use a Developer ID Installer signing identity. This is named Developer ID Installer: TTT, where TTT identifies your team.

which seems pretty clear to me.


The SIGNID I pass is F3YTHMJYQ9

That matches all 4 of the signing identities printed by security find-identity. If you did this with codesign, it’d fail with an error saying that the string is ambiguous. Unfortunately it seems like productsign isn’t so smart; AFAICT it just uses the first one it finds.

The solution is to either:

  • Pass in the full name.

  • If that string happens to match more than one identity — which can happen, for example, if you’ve recently renewed your signing identity — pass in the SHA-1 hash (4B963D271E6BA871BFCA42C21ACD6A5A6E812A09 is your case).

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks, for the info, but let me clear up a couple items.

Vagueness on tools was in relation to this: "For more details on how to work with installer packages, see the man pages for productbuild, productsign, pkgbuild, and pkgutil. " As the man pages don't do a good job of telling me when/why I need to use which one of those.

Also note that codesign did NOT fail with an error saying the string was ambiguous. Both codesign and productsign ran without error. If the error you mentioned HAD been reported, it. would have definitely helped me figure out what the problem was.

I do have Notarization succeeding now.

As the man pages don't do a good job of telling me when/why I need to use which one of those.

Right. Sadly the current state of our installer documentation is quite dire )-:

Also note that codesign did NOT fail with an error saying the string was ambiguous.

I regularly see that error. For example:

% security find-identity -v
…
  5) … "Mac Developer: Quinn Quinn (7XFU7D52S4)"
  6) … "Apple Development: Quinn Quinn (7XFU7D52S4)"
…
     9 valid identities found
% cp /usr/bin/true .
% codesign -s 7XFU7D52S4 -f true
7XFU7D52S4: ambiguous (matches "Apple Development: Quinn Quinn (7XFU7D52S4)" and "Mac Developer: Quinn Quinn (7XFU7D52S4)" in /Users/quinn/Library/Keychains/login.keychain-db)

But looking at your identity list again I see why. The string F3YTHMJYQ9 matches three signing identities:

  • 3rd Party Mac Developer Installer: Eps Us, LLC (F3YTHMJYQ9)

  • Developer ID Application: Eps Us, LLC (F3YTHMJYQ9)

  • Developer ID Installer: Eps Us, LLC (F3YTHMJYQ9)

However, codesign only sees one. That’s because two of the three are installer signing identities, and codesign restricts its search to code signing identities.

The fact that the installer tools don’t detect ambiguity is annoying, and I’ve filed an enhancement request for them to do so (r. 99862021).

I do have Notarization succeeding now.

Yay!

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Notarization failing, not signed with Developer ID Cert
 
 
Q