Problem: You have two Apple development accounts: One for the App Store and one for In-House App’s. Both are named the same in according to your company name.

Result: Code Sign error: Certificate identity ‘iPhone Distribution: <Name>.’ appears more than once in the keychain. The codesign tool requires there only be one.

So how to solve this annoying issue? There is not really an solution.

I have written an article for the magazine MacTech. And did I not only write an article, it is also published in the February issue of 2013.

The subject was Code Signing, the hell most of us developers encounter at least once. But most likely more then once. I had already made a post about the subject on this website. But now this post matured into a full fledged published article. And I even extended the article with newly found tips.

Writing this article was fun, not always easy. But in the end it is done!

Cool, I have published an article…. Really cool.

I have saved the article as a PDF scan.

But I do have found a nice work around of the issue!

First step I took was contacting Apple in requesting to change the name of our In-House account, so the names of the distribution certificates are going to be different. But no luck there, Apple responded with the advice to use multiple keychain’s for storing the certificates and keys to do the signing with. Well that is part of the solution.

Looking in an Xcode project I noticed in the Code Signing Section of the Build Settings of a Target the part: “Other Code Signing Flags”. This could be interesting, let us take a look in the man page of the unix app codesign, which is in effect being used by Xcode to do the actual signing. As with any unix app we can add options when executing the command. So there could be something interesting in there. There is the option –keychain filename
Let’s take a closer look at the explanation of this option:

--keychain filename During signing, only search for the signing identity in the keychain file specified.
This can be used to break any matching ties if you have multiple similarly-named identities in several keychain's on the user's search list.
**Note that the standard keychain search path is still consulted while constructing the certificate chain being embedded in the signature.**

So you would think that you are done, right? Just add the –keychain option to the Other Code Signing Flags for your release and be on your merry way…..
Well, not really, the note at the end is the big kicker…. The standard keychain search path is still consulted….. That means that in whatever keychain I place the certificate and keys, it will still be found… Back to square 1, the duplicate of name is still found. But this got me thinking:

What can we do to change or alter the search path for the keychain’s?

It seems that the list of keychain’s, listed in the top left of the application Keychain Access, are nothing more then references to the actual keychain’s stored on your HD. So this could be beneficial to our solution.

side note:Why in heavens name would you create an option to select an specific keychain for using with the signing process, while still consulting the other keychain’s, and thus in effect canceling out the whole purpose of the option? Any ideas?

For me the following solution is working:


Create three new keychain’s:

  • Development: Place here all of you development keys and certificates
  • App Store: Place here all of your Distribution certificates and keys for using in the App Store accounts.
  • Enterprise:Place here all of your Distribution certificates and keys for using with your In-House accounts.

If your are working for more than one client, and these clients have also App Store and Enterprise accounts, this is an easy way to differentiate between them.

Work flow:

  1. Open the Keychain Access app, and delete the reference of the keychain not needed. Make sure that you select the right button, the default button is the right one.
  2. In Xcode make sure that you have selected the right distribution mobileprovision profile, and make an archive. The error should be gone. And signing successful.
  3. In Keychain Access add the deleted reference to the keychain. And make sure the keychain is unlocked before building.

For me this works, no warranties what so ever….