Resolving codesign certificate ambiguity with multiple developer certificates
I recently did some work for another company, building an iPhone app for them. As I split development time between their offices, using their computers, and my office, I generated a key and had it signed as part of their iPhone Dev Center "team."
I already had an existing Dev Center account and my own developer certificate. After importing the certificate for the client project, signing that application gives me a warning from codesign that it finds multiple certificates matching "iPhone Developer: Steve Madsen", but it chooses the correct one and signs the binary.
I am now going back to one of my older projects, using my own developer certificate. Codesign is telling me it can't resolve the ambiguity between my certificate and the one used for my client:
iPhone Developer: Steve Madsen: ambiguous (matches "iPhone Developer: Steve Madsen (9E69FVL37K)" and "iPhone Developer: Steve Madsen" in /Volumes/Users/steve/Library/Keychains/login.keychain)
The client certificate is the one with (9E69FVL37K), which I presume is how codesign is able to figure things out in my client's project.
How can I configure the Xcode project to use the correct identity? Picking a specific one (not the automatic profile selector) under the target build settings does not help.
Better yet, while Apple anticipated that a developer could be a member of multiple teams, I have found no documentation on how a developer such as myself should set up my environment. Generating a second key/certificate seemed the only way to make this work, as provisioning profiles must be associated with certificates under one team's Program Portal. Does anyone have good advice on how to make this process work smoothly?
Answer
I took the plunge this evening and decided to revoke my old certificate and generate a new one. My guess was correct: Apple is now issuing all certificates with a (hex-string) suffix.
Xcode is smart enough to do the right thing. I select "iPhone Developer" (automatic selection) in the target settings. It determines which of my keys should be used to sign the binary based on the provisioning profile, then tells codesign to use exactly that identity by including the (hex-string) suffix.
My bet is that newer iPhone developers won't ever see this problem, because they generated their first certificate after Apple started adding the suffix.
A reminder to anyone else that has to do this: you need to fix all your existing provisioning profiles, too, and reinstall those.