Конфликты CodeSign между разработчиком и корпоративным распространителем

Question

Моя компания использует одну сборочную машину (Mac Mini) в качестве узла CI для сборки нашего приложения для iOS. В настоящее время мы создаем конфигурацию Ad-Hoc и App Store на мини. Мы недавно зарегистрировались в программе Enterprise и хотим начать создавать конфигурацию Enterprise. Однако наш процесс сборки теперь терпит неудачу, потому что теперь у нас есть два сертификата, называемых «iPhone Distribution: Widget Corporation». Одним из них является сертификат распространения для AdHoc / AppStore, а другим - Enterprise (Apple называет это In-House).

Я пытался изменить цепочки для ключей mini таким образом, чтобы один сертификат находился в цепочке для ключей входа в систему, а другой - в новой цепочке для ключей под названием "enterprise", но это просто сместило ошибку с начала сборки:

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

до конца сборки:

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)

Мой вопрос заключается в том, существует ли способ надлежащей песочницы для двух сертификатов, чтобы я мог создавать версии приложения Ad-Hoc, App Store и In-House на одном компьютере. Единственное возможное решение, которое мне еще предстоит попробовать, - это на самом деле связать сертификаты с источником и использовать security для добавления и удаления сертификатов по мере необходимости; очевидно, что это решение не очень красиво и создает угрозу безопасности.

Есть идеи?

Answer 1

После обсуждения со службой технической поддержки Apple Developer, они посоветовали создать отдельные цепочки для ключей для размещения различных сертификатов, а затем передать аргумент --keychain filename в шаг codesign, чтобы указать на соответствующий файл. Вы можете передать этот аргумент в Xcode или xcodebuild, используя опцию OTHER_CODE_SIGN_FLAGS. например:

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

Кроме того, после создания новой цепочки для ключей она по умолчанию перезапускается через 5 минут - вы можете изменить это, если у вас есть сборки, которые требуют времени.

Answer 2

Еще один способ, который помог мне, - присвоить подписи идентификационные данные как хэш SHA1 для кодового знака.Шаги:

1. Найти хеш SHA1 в доступе к цепочке для ключей необходимого сертификата
2. Сравните хеш SHA1 с полученным хешем: security find-identity -v -p codesigning
3. Используйте правоSHA1 с шага 2 для кодового знака: codesign -s "SHA1_FROM_STEP2" ...

Answer 3

Поговорив с командой xcode на WWDC, они предложили гораздо более простое решение - чтобы я мог запросить переименование моего корпоративного сертификата, чтобы не было конфликта.

Для этого обратитесь в службу поддержки разработчиков.щелкнув ссылку «Управление учетной записью» на странице контактов разработчика , а затем выбрав «Портал обеспечения iOS» в качестве темы - они сделали это для меня в течение одного дня после моего запроса.

Этоэто намного, намного проще, чем любой другой способ - теперь у меня есть оба набора сертификатов в моей цепочке для ключей, и я могу с радостью создать приложение для магазина приложений или корпоративного дистрибутива, не делая ничего, кроме выбора правильной сущности для кодового знака.

Answer 4

Чтобы уточнить ответ homer_simpson: можно вычислить SHA1 вашего файла .p12 напрямую (без использования вызовов security), а затем передать результат в codesign или xcrun. Вот выдержка из моего скрипта автобилда:

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

Answer 5

У меня было много проблем с этим. Возможно, лучшее решение - просто запросить у Apple переименование вашего сертификата, но если вы не хотите с этим бороться, я использовал другое решение. У меня есть папка, куда я экспортировал как обычные, так и корпоративные сертификаты. Затем вы можете удалить сертификат, который вы не используете, и импортировать другой. Может быть, это более хлопотно, но обычно я распространяю приложения только на предприятии, так что это не такая большая проблема.

Кстати, для удаления сертификата я выбираю фильтр сертификатов, который затем показывает связанный закрытый ключ, а затем я удаляю и сертификат, и ключ. Если я удаляю только сертификат, Xcode продолжает создавать его снова.