CodeSign collisions between Developer and Enterprise Distribution

泄露秘密 提交于 2019-11-30 03:42:18
kevboh

After discussing with Apple Developer Technical Support, they've advised creating separate keychains to house the different certificates and then pass the --keychain filename argument into the codesign step to point at the appropriate file. You can pass this argument into Xcode or xcodebuild using the OTHER_CODE_SIGN_FLAGS option. eg:

xcodebuild -target "<targetname>" -configuration "<configname>" \
  PROVISIONING_PROFILE=A3A47A82-E91F-4E95-8559-601C6C857053 \
  OTHER_CODE_SIGN_FLAGS="--keychain=/Users/username/Library/Keychains/enterprise.keychain" \
  build  

Also, after creating a new keychain it seems to default to relocking after 5 minutes - you might want to change this if you have builds that take a while.

Another way which helped me is to give the signing identity as a SHA1 hash to codesign. Steps:

  1. Find the SHA1 hash in keychain access of the needed certificate
  2. Compare the SHA1 hash with the one returned by: security find-identity -v -p codesigning
  3. Use the right SHA1 from step 2 for codesign: codesign -s "SHA1_FROM_STEP2" ...

After speaking with the xcode team at WWDC, they suggested a much simpler solution - that I could request that my enterprise certificate is renamed so there isn't a clash.

To do this, contact Developer Services by clicking the "Managing Your Account" link on the developer contact page then selecting "iOS Provisioning Portal" as the subject - they did this for me within a day of me asking.

This is far, far simpler than any other way - I now have both sets of certificates in my keychain, and can happily build for appstore or enterprise distribution without doing anything more than selecting the right entity to codesign with.

I've had a lot of trouble with this. Probably the best solution is to just request Apple that your certificate is renamed, but if you don't want to deal with that I used a different solution. I have a folder where I exported both the regular and the enterprise certificates. Then you can delete the certificate you are not using and import the other one. Maybe this is more hassle, but usually I only distribute apps in enterprise, so it's not that much trouble.

By the way, what I do to delete a certificate is select the certificates filter, which then shows the associated private key, and then I delete both the certificate and the key. If I delete only the certificate Xcode keeps creating it again.

To elaborate on homer_simpson's answer: it's possible to compute SHA1 of your .p12 file directly (without using security calls), and then feed the result to codesign or xcrun. Here's an excerpt from my autobuild script:

# get SHA1 of .p12 file and pass it to PackageApplication to prevent ambiguity in cert selection
# sample output of openssl: SHA1 Fingerprint=14:B0:58:D1:F9:1D:A5:74:0A:AA:BE:B9:F2:7A:7E:AD:58:82:A2:25
# fingerprint (everything after =) is extracted with cut, and : are removed with sed

# ${IDENTITY} is a variable that contains path to your .p12 file. passphrase is empty in this case.
P12_SHA=$(openssl pkcs12 -in "${IDENTITY}" -nodes -passin pass: | openssl x509 -noout -fingerprint -sha1 | cut -d = -f 2 | sed -e 's/://g')

/usr/bin/xcrun -sdk iphoneos PackageApplication -s "${P12_SHA}" ...
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!