CodeSign collisions between Developer and Enterprise Distribution

My company uses one build machine (a Mac Mini) as a CI node to build our iOS app. We currently build an Ad-Hoc and an App Store config on the mini. We've recently enrolled in the Enterprise Program and want to start building an Enterprise config as well. However, our build process now fails, because we now have two certificates called "iPhone Distribution: Widget Corporation". One is the distribution cert for AdHoc/AppStore, and one is for Enterprise (Apple calls it In-House).

I've tried modifying the mini's keychains such that one cert is in the login keychain and one is in a new keychain called "enterprise", but this just shifted the error from the start of the build:

CodeSign error: Certificate identity 'iPhone Distribution: Widget Corporation' appears more than once in the keychain.

to the end of the build:

iPhone Distribution: Widget Corporation: ambiguous (matches "iPhone Distribution: Widget Corporation" in /Users/hudson.admin/Library/Keychains/login.keychain and "iPhone Distribution: Widget Corporation" in /Users/hudson.admin/Library/Keychains/enterprise.keychain)

My question is whether or not there's a way to properly sandbox the two certificates so I can build Ad-Hoc, App Store, and In-House versions of the app on the same machine. The only开发者_开发技巧 possible solution I've yet to try is to actually bundle the certs along with the source and use security to add and delete the certificates as I need them; clearly that solution isn't very pretty and poses security risks.

Any ideas?

---

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}" ...