MenuMenu

ГлавнаяIosСертификат разработчика ios

Сертификация в Apple Developer Center простым и понятным языком. Сертификат разработчика ios


сертификат разработчика iOS iOS Dev

Я читаю документацию для получения сертификата разработчика iOS, но мне трудно понять, как это работает.

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

Другой вопрос: будет ли этот сертификат использоваться только на моем mac или на любом mac, который моя компания предоставит мне? Я полагаю, что я буду использовать свой персональный Mac для работы, но даже возможно, что моя компания назначит еще одну в будущем, так что это актуально для меня.

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

если я получу сертификат, смогу ли я развернуть на одном конкретном устройстве или с моим сертификатом, я смогу развернуть и протестировать на любом устройстве, которое мне даст моя компания?

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

будет ли этот сертификат использоваться только на моем mac или на любом mac, который моя компания предоставит мне?

Существуют инструкции о том, как экспортировать свой сертификат и общедоступные / закрытые ключи на вашем Mac и перенести их на другие компьютеры Mac, на которые вы планируете код. Я считаю, что это в руководстве пользователя PDF, которое можно загрузить с домашней страницы портала обеспечения. После того, как вы импортируете их на свои Mac, установите профили обеспечения на Xcode Organizer на этих Mac. После этого Xcode может подписать и установить ваши приложения.

Не уверенный в твоем третьем вопросе, хотя, я одинокий волк.

Вы должны получить сертификат для своей компании – это позволит вам распространять приложения для всех в компании, не помещая их в App Store. Вам нужно будет предоставить информацию о вашей компании Apple в рамках процесса регистрации.

После того, как у вас есть учетная запись, вы создаете сертификат разработчика с закрытым ключом, сгенерированным на вашем Mac. Вы можете скопировать этот закрытый ключ между разработчиками компании и поделиться сертификатом.

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

Также имейте в виду, что существует отличный механизм распространения, где вы можете поместить ссылку на веб-страницу, которую пользователь может просматривать с устройства, и установить ее прямо на устройство, не проходя через iTunes. Для этого требуется iOS 4.0+, но он избегает таких безумных головных болей в дистрибутиве, что это обязательное требование для любого бизнес-приложения, которое вы разрабатываете (а также означает, что вы можете использовать гораздо больше расширенных API и блоков).

Ans 1. Предположим, у вас есть аккаунт разработчика. Если регистрация устройства учетной записи предприятия не требуется. Шаг 1. Зарегистрируйте свое устройство. Шаг 2; Создайте идентификатор, сертификат разработчика, затем создайте профиль подготовки. Шаг 3: Затем загрузите и установите на свой компьютер Mac и выберите настройку и сертификат в своем Xcode.

Ans 2. Создайте свой Mac. Перейдите в брелок и создайте файл p12 и установите файл p12 на другой компьютер Mac.

Ans 3. Да, мы можем поделиться одним сертификатом разработчика с другой машиной Mac, но рекомендуется создать персональный сертификат разработчика.

ios.phonec.com

Тестируем iOS приложения без Apple Developer Program Membership / Хабр

Мне было интересно попробовать написать приложение для iOS, чисто в познавательных целях, но 99USD платить Apple за «любознательность» не очень то и хотелось. Не отчаивайтесь, для таких как мы есть способы и запустить приложение и отладить его на целевом устройстве. После курения доков и разного рода экспериментов у меня получилось. К счастью однажды я сохранил туториал с одной странички, но откуда, уже вряд ли найду, поэтому это можно считать переводом. Ну и плюс дополнил от себя.

Итак, версии софта, которые я использовал:

  • OS X Mavericks 10.9.2
  • Xcode 5.1.1
  • iOS 6.1.2 iPhone 4
  • iOS 7.0. iPad mini

Итак, что же потребуется для «любознательности»? Всего то:

  1. Заджейлить наше iOS устройство
  2. Подготовить iOS к установке само-подписанных приложений
  3. Подсоединить iOS к Xcode и настроить девайс для разработки
  4. Создать свой сертификат
  5. Настроить Xcode для использования само-подписанного сертификата
  6. Настроить Xcode для отладки на целевом устройстве
Джейлим iOS
Тут в общем всё просто. На данный момент прошивка, поддающаяся взлому 7.0.6. Все остальное можно почерпнуть с сайта evasi0n. Если нет взломанного устройства — то закрываем данный туториал и платим 99USD Apple.
Подготавливаем наше iOS устройство к установке само-подписанных приложений
Довольно известный факт, что того чтобы ставить само-подписанный приложения (суть взломанные) необходимо установить в Cydia так называемый AppSync. Я ставил AppSync из нашенского русского репозитория smolk — http://smolk.myrepospace.com. Насколько я наблюдал за этим репозиторием, Smolk сам пишет/тырит AppSync и выкладывает его одним из первых, поэтому и рекомендую воспользоваться его трудами.

Если же ничего не получилось, то Xcode выдаст примерно следующее:

Подключаем и настраиваем наше iOS устройство к Xcode
  1. Запускаем Xcode
  2. Цепляем iOS устройство к USB
  3. Открываем Organizer (Window\Organizer)
  4. Выбираем подключенное устройство
  5. Жмем «Use for development»
  6. Скорее всего Xcode попытается подключиться к серверу Apple и проверить наличие аккаунта разработчика, если так — жмем Cancel
Всё, наше устройство теперь при подключении всегда будет распознаваться как использующееся для разработки.
Создаем сертификат разработчика
  1. Запускаем приложение «Keychain Access»
  2. Меню «Certification Assistant > Create a Certificate»
  3. На первой страничке заполним данные и жмем «Continue».
    • Name: iOS Developer
    • Identify Type: Self Signed Root
    • Certification Type: Code Signing
    • Отмечаем галочку «Let me override defaults»
  4. Жмем «Continue» для создания сертификата.
  5. Изменяем «Validity Period» например на 3650 — это 10 лет срока действия, жмем «Continue».
  6. Оставляем поле «Email address» пустым и жмем «Continue».
  7. Оставляем значения по умолчанию в полях «Key Size» и «Algorithm», жмем «Continue».
  8. Жмем «Continue» на всех следующих страницах, пока не появится окошко с кнопкой «Create».
  9. Жмем «Create» и «Done» соответственно.
Настраиваем Xcode для использования само-подписанного сертификата
  1. Закрываем Xcode, если он открыт.
  2. Открываем Terminalcd /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform # create copy of Info.plist sudo cp -p Info.plist Info.plist.orig # convert to editable xml format sudo plutil -convert xml1 ./Info.plist # replace each occurrence of XCiPhoneOSCodeSignContext with XCCodeSignContext in Info.plist sudo sed -i .bkup 's/XCiPhoneOSCodeSignContext/XCCodeSignContext/g' ./Info.plist
  3. Открываем Xcode
  4. Открываем или создаем проект и идем в настройки проекта, в закладку «Build settings». Выбираем в поле «Code Signing Identity» созданный сертификат:
  5. Около кнопки «Run» выбираем наше подключенное iOS устройство.
  6. Жмем «Run» и Xcode транслирует исходники в исполняемый файл и загружает его в устройство.
  7. Далее Xcode показывает нам следующую ошибку: Так и должно быть, потому что отладчик мы еще не настроили, но само приложение можно уже запускать на устройстве.
Настраиваем Xcode для отладки приложения на целевом устройстве
Компилируем ldid
  1. Если не стоит GIT, устанавливаем отсюда
  2. Далее в терминале:cd ~/Documents git clone git://git.saurik.com/ldid.git cd ldid git clone git://git.saurik.com/minimal.git ./make.sh sudo mkdir /usr/local/bin sudo cp ldid /usr/local/bin
  3. Создаём файл /usb/local/bin/ldid3.py с содержимым:#!/usr/bin/env python from sys import argv from subprocess import check_call from os.path import basename, dirname, splitext, join from tempfile import NamedTemporaryFile app = argv[-1] ldid_path = join(dirname(__file__), 'ldid') obj_path = join(app, splitext(basename(app))[0]) if '-gta' not in argv: check_call([ldid_path, '-S', obj_path]) else: with NamedTemporaryFile('w+b', 0) as f: f.write(""" <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>get-task-allow</key> <true/> </dict> </plist> """) f.flush() check_call([ldid_path, '-S' + f.name, obj_path])
  4. Делаем ldid и ldid3.py запускаемыми:sudo chmod +x /usr/local/bin/ldid sudo chmod +x /usr/local/bin/ldid3.py
Настраиваем Xcode
  1. Закрываем Xcode, если он открыт.
  2. Обновляем файл конфигурации iPhoneCodeSign.xcspec, для этого в терминале:cd /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Specifications # create a backup copy of iPhoneCodeSign.xcspec sudo cp -p iPhoneCodeSign.xcspec iPhoneCodeSign.xcspec.orig # convert to editable xml format sudo plutil -convert xml1 iPhoneCodeSign.xcspec # replace codesign with /usr/local/bin/ldid3.py sudo sed -i .bkup 's/codesign/\/usr\/local\/bin\/ldid3.py/g' iPhoneCodeSign.xcspec
  3. Открываем Xcode
  4. Теперь, чтобы включить отладку, нам необходимо добавить ключик "-gta" в командную строку утилиты codesign, предыдущим шагом мы её заменили на наш ldid3.py
  5. Собираем приложение и запускаем н целевом iOS устройстве.

Надеюсь данное руководство поможет начинающим программистам iOS просто и незатейливо попробовать свои силы в написании программ для устройств Apple.

habr.com

Apple, боль и сертификаты / Хабр

Знакомьтесь, Боб — матёрый ios разработчик, Алиса — не менее матёрая тестировщица. Дело было вечером дело было в пятницу. Боб дофиксил багу, вроде бы протестил на своих девайсах. Затем Боб запускает уже отточенные до автоматизма команды:git checkout develop git merge bug_fix_#999 git checkout master && git merge develop --no-ff .... git push ....

На пуш на сервере срабатывает jenkins/teamcity/travis, который запускает билд. В это же самое время наш Боб пишет Алисе, что скоро пойдет домой, и хочет, чтобы аппа ушла сегодня в app store на апрув, дабы выиграть лишние пару дней, так как на носу выходные, если, конечно, приложение пройдет ручное тестирование Алисы.

Приложение Боба довольно обычное: пару сотен компилируемых класс файлов, еще с десяток cocoapods зависимостей ну и кучка сторибордов — Боб ценит своё время и время коллег поэтому не пишет UI в коде. Боб знает, что его приложение с чистого старта на сервере собирается за 4 минуты для develop версии, которое идет на тест Алисе, и столько же или чуть больше для production версии. Боб также знает, что ему нужно около 10 минут, чтобы дождаться окончания полной сборки и затем сообщить Алисе, что она может приступать к тестированию. Боб человек ответственный, поэтому по истечении 10 минут после пуша проверяет статус билда, так как знает, что сервер — это отдельный параллельный мир со своими правилами, законами и странностями.

Пятница, вечер, Боба отделяет от долгожданных выходных только 10 минут, после которых передаст эстафету Алисе. Боб вбивает в сафари bobcompany.ci/dashboard, где видит красную лампочку напротив своего приложения, глаза Боба потускнели, разочарованию не было предела. Боб жмет на show more, где его встречает ошибка:

Code Sign error: No codesigning identities found: No codesigning identities (i.e. certificate and private key pairs) that match the provisioning profile specified in your build settings (“com.company.bob”) were found.

Тут нервы Боба совсем сдают:

*Кратко об ошибке, она проявляется, когда мы пытаемся подписать приложение несуществующим сертификатом, под несуществующим понимается или он не установлен на машине, или он устарел и mobileprovision заведен на более свежую версию сертификата того же аккаунта для того же бандла.

И самое обидное, что эта ошибка только для production версии билда, который запускается вторым после develop версии, причем, сначала xcode компилирует зависимости (cocoapods) и уже только после проверяет валидность подписи, то есть только когда собирает основное приложение. Поэтому ошибка проявляется примерно во второй половине процесса сборки, из-за чего первые 6-7 минут потрачены в пустую, от чего Боб расстроен еще больше.

Наш разработчик Боб не первый раз сталкивается с этой проблемой, ведь он работает в большой компании, где несколько команд ios разработчиков, где нормальная практика для разработки использовать один Apple аккаунт на несколько человек. Да, Боб знает про Xcode плагин https://github.com/neonichu/FixCode, но ведь не заставлять же его насильно всем ставить, разработчики нежные создания, не все любят, когда их заставляют что-то делать против их воли, Боб сам такой.

Бобу всё это настолько надоело, что он уже забыл, что собирался домой 10 минут назад, вместо этого Боб заказывает пиццу, расчехляет макбук, который уже успел упаковать, наливает кофе, просит админов дать доступ до сервера, коннектится туда по ssh и начинает выяснять, в чем же, именно, проблема и как её можно решить.

Ну окей. Первым делом Боб проверяет какие сертификаты, вообще, есть на машине:

security find-identity -v login.keychain

Что выдает

1) 40948A3CA3527F580B9ECB2131DE6B1938FB3D7C "iPhone Developer: Mike ... (KSDA3C3QF2)" 2) 0279CB81AEAD8CE015282DD1FA76CE520A815C4D "iPhone Developer: Bob .. (4WT74HLM2M)" 3) 79A2544B1A63C3F9D3DA3FFAB199FEAADB7EC306 "iPhone Developer: Alica ... (VJ53F2J4EK)" .... 24 valid identities found

Так, как минимум, в keychain, который используется по дэфолту на сервере, есть 24 сертификата. Боб знает, что каждый mobileprovision файл создается на какой-то один конкретный сертификат. Нужно выяснить на какой сертификат создан mobileprovision файл для которого упал билд и понять, что же произошло с сертификатом. Нужно, вообще, понять как mobileprovision файл связан с сертификатом. Боб знает, что develop версия приложения собралась, поэтому на сервере точно есть этот сертификат и сейчас нужно понять как он соотносится с mobileprovision файлом. Для этого Бобу нужно найти mobileprovision файл и данные о сертификате, чтобы начать искать какие-то соответствия между ними.

Ищем mobileprovision файл по его бандлу (если ваш бандл wildcard, то можно искать по любым другим признакам):

cd ~/Library/MobileDevice/Provisioning Profiles find . -name "*.mobileprovision" -type f -exec grep -H -n -a {} -e "com\.company\.bob" \;

Отлично, мы нашли наш файл:

./f98a06f3-21c2-4de0-975f-5df74197c731.mobileprovision:30: <string>4HUHB9J47M.com.company.bob</string>

В файле есть префикс 4HUHB9J47M у бандла. Из ранее полученного списка сертификатов ничто с этим значением не совпадает. Поэтому Бобу приходится идти в developer.apple.com и искать на какой же аккаунт создан этот mobileprovision файл. Методом тыка он выясняет, что это сертификат Майка:

2) 40948A3CA3527F580B9ECB2131DE6B1938FB3D7C "iPhone Developer: Mike .. (KSDA3C3QF2)"

Отлично, теперь у нас есть с чем работать. Боб у нас не криптоаналитик или секурити ресерчер, но он хороший гуглер, поэтому он с легкостью нашел способ как получить необходимую информацию из сертификата.

Вытаскиваем данные в .pem файл:

security find-certificate -p -c "iPhone Developer: Mike .. (KSDA3C3QF2)" > cert.pem

В файле получаем следующее:

-----BEGIN CERTIFICATE----- MIIFnjCCBIagAwIBAgIIN8GwnYhLQ/kwDQYJKoZIhvcNAQELBQAwgZYxCzAJBgNV BAYTAlVTMRMwEQYDVQQKDApBcHBsZSBJbmMuMSwwKgYDVQQLDCNBcHBsZSBXb3Js ZHdpZGUgRGV2ZWxvcGVyIFJlbGF0aW9uczFEMEIGA1UEAww7QXBwbGUgV29ybGR3 aWRlIERldmVsb3BlciBSZWxhdGlvbnMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw ... .... ..... lD+ocFo6+mab/Ph6mTJOZkZu+hnqhzbTD9Q9dXKWkeXAwTqaESNfnhnuOdfCX3vu YAz0Hb46G9fkLa5lHjVydbtms685C+uz9Ss4GNRfji1cz5KyblAQAAsqQBUiCwnb z34= -----END CERTIFICATE-----

Как оказалось, с этого файла можно считать информацию о сертификате, попробуем получить наиболее интересную для нас:

openssl x509 -noout -fingerprint -in cert.pem

Выдает нам:

SHA1 Fingerprint=40:94:8A:3C:A3:52:7F:58:0B:9E:CB:21:31:DE:6B:19:38:FB:3D:7C

Если убрать двоеточия, то получим 40948A3CA3527F580B9ECB2131DE6B1938FB3D7C, это как раз sha1 сертификата Майка, который мы можем увидеть в UI в Keychain:

Мы также можем получить срок действия сертификата, если нужно написать валидатор истёкших сертификатов:

openssl x509 -noout -startdate -in cert.pem // Feb 27 07:13:41 2016 GMT openssl x509 -noout -enddate -in cert.pem // Feb 26 07:13:41 2017 GMT

Это же мы видим и в keychain:

В общем с сертификатом всё ясно. «Как же его привязать к нашему mobileprovision файлу?» — думает любопытный Боб. Давайте сначала посмотрим на mobileprovision файл поближе:

security cms -D -i f98a06f3-21c2-4de0-975f-5df74197c731.mobileprovision

Вывод нам дает интересную информацию для поля data, а именно:

<data> MIIFnjCCBIagAwIBAgIIN8GwnYhLQ/kwDQYJKoZIhvcNAQELBQAwgZYxCzAJBgNV BAYTAlVTMRMwEQYDVQQKDApBcHBsZSBJbmMuMSwwKgYDVQQLDCNBcHBsZSBXb3Js ZHdpZGUgRGV2ZWxvcGVyIFJlbGF0aW9uczFEMEIGA1 ... ... YAz0Hb46G9fkLa5lHjVydbtms685C+uz9Ss4GNRfji1cz5KyblAQAAsqQBUiCwnb z34= </data>

Где-то это Боб уже видел, похоже на содержание ранее полученного .pem файла:

-----BEGIN CERTIFICATE----- MIIFnjCCBIagAwIBAgIIN8GwnYhLQ/kwDQYJKoZIhvcNAQELBQAwgZYxCzAJBgNV BAYTAlVTMRMwEQYDVQQKDApBcHBsZSBJbmMuMSwwKgYDVQQLDCNBcHBsZSBXb3Js ZHdpZGUgRGV2ZWxvcGVyIFJlbGF0aW9uczFEMEIGA1UEAww7QXBwbGUgV29ybGR3 aWRlIERldmVsb3BlciBSZWxhdGlvbnMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw ... .... ..... lD+ocFo6+mab/Ph6mTJOZkZu+hnqhzbTD9Q9dXKWkeXAwTqaESNfnhnuOdfCX3vu YAz0Hb46G9fkLa5lHjVydbtms685C+uz9Ss4GNRfji1cz5KyblAQAAsqQBUiCwnb z34= -----END CERTIFICATE-----

Тут Боб понял, вот она зацепка mobileprovision файла на сертификат.

Итого, нам нужно взять наш mobileprovision файл, вытащить из него значение для поля data, затем пробежать по всем валидным сертификатам и сравнить с данными из их .pem представления. Боб тут же накидал небольшой скрипт, который передал коллегам из бэкенда, чтобы они его запускали перед каждой сборкой ios проектов. Скрипт запускается достаточно просто:

ruby cert_checker.rb f98a06f3-21c2-4de0-975f-5df74197c731.mobileprovision ruby скриптrequire 'active_support/core_ext/hash' return if ARGV.empty? xmlString = `security cms -D -i #{ARGV.first}` data = Hash.from_xml(xmlString) # получили значение data из mobileprovision provision_cert_data = data['plist']['dict']['array'].map { |e| e['data'] }.compact.first # пробегаем по всем сертификатам и собираем их данные в .pem формате certs = `security find-identity -v login.keychain | grep -o "\\".*\\""`.split("\n").map { |e| e[1..-2] } pems = certs.map { |e| `security find-certificate -p -c "#{e}"`.split("\n")[1..-2].join('') } dict = Hash[pems.zip(certs)] # сравниваем mobileprovision data с .pem данными сертификатов, если совпадет, значит нашли сертификат для mobileprovision, # если не нашли, значит на машине не установлен сертификат if dict.keys.keep_if { |e| e == provision_cert_data }.empty? puts "Have no certificate for file #{ARGV.first}" else puts "Your mobileprovision issued for #{dict[provision_cert_data]}" end

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

habr.com

ios - Управление сертификатом Apple Developer/iOS

Мы боремся с обработкой сертификата распространения от Apple. У нас есть несколько разработчиков на портале Apple Developer Portal, для примера: Алиса: Администратор команды Боб: Admin Чарльз: Админ Дэн: Разработчик

Алиса, Боб и Чарльз должны иметь возможность создавать приложения для распространения (Adhoc для внутреннего тестирования, Testflight для внешнего тестирования и Appstore для распространения). Дэн только производит код и отлаживает свою локальную машину. Все пользователи используют отдельные учетные записи для разработки.

Из того, что мы поняли из документации Apple, Алисе, Бобу, Чарльзу нужен действительный сертификат распространения. Если xCode генерирует это для них, они начнут играть "пинг-понг" и будут отзывать друг друга сертификатом - по крайней мере, это то, что, как представляется, происходит на данный момент. Мы не знаем, почему это произойдет. Можно было бы подумать, что если вы создадите другого нового пользователя, эта учетная запись может также поддерживать свои собственные (дистрибутивные) сертификаты.

В любом случае, им нужно будет предоставить общий доступ к сертификату распространения, поделившись с ним секретным ключом (p12 файл), как вы можете найти в ответе здесь.

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

В документации упоминалось, что у вас может быть до 2 действительных сертификатов распространения. Мы также вручную попытались создать сертификаты распространения и могли подтвердить, что он ограничен двумя.

Тем не менее, мы недавно получили приглашение в программу разработчиков клиентов, чтобы подписывать приложения от его имени. Я предполагаю, что клиент не знал, что нам нужен секретный ключ из его сертификата распространения. Поэтому мы попытались вручную создать сертификат распространения и увидели, что это невозможно. К нашему удивлению, однако, заказчику удалось создать 3 действительных сертификата распространения. Любая идея, как это сработало?

Наши вопросы в двух словах:

1. Что лучше всего, когда вы управляете командой разработчиков?

Вы обычно используете закрытый ключ первого разработчика, который сгенерировал сертификат со всеми другими членами команды, которые должны иметь возможность подписывать приложение?

2. Какова наилучшая практика при работе с клиентами? Вы просите их создать еще один закрытый ключ или есть скрытые функции для создания как можно большего количества сертификатов распространения, учитывая, что каждый разработчик использует свою собственную учетную запись?

3. Что происходит, когда мы отменяем сертификат. Это не влияет на приложения в магазине приложений, но только, кажется, ограничивает других разработчиков для создания своего приложения. Однако что происходит с сертификатами APNS/Push Server? Когда мы отменим сертификат распространения через xCode, это также внезапно перестанет работать для отправителя?

Благодарим вас за помощь.

qaru.site

iphone - Как продлить сертификат разработки iPhone?

Когда мои профили распределения были в течение двух дней после истечения срока действия, я попытался их расширить. Я обнаружил, что на самом деле заканчиваются сертификаты удостоверений в моей цепочке ключей, к которым привязаны все профили. И я не мог найти никакого способа обновить удостоверения личности; Мне пришлось удалить мои сертификаты из брелка и создать их с нуля, как описано здесь:

https://developer.apple.com/library/ios/#qa/qa1618/_index.html

... Удалите сертификат из вашей брелка, затем следуйте инструкциям "Получение сертификата развития iPhone" или "Получение сертификата распространения iPhone" в руководстве пользователя портала разработчиков программного обеспечения iPhone для создания нового сертификата

Однако мои проблемы на этом не закончились. Теперь у меня появился новый сертификат, и мне удалось создать профиль распространения, как описано здесь:

https://developer.apple.com/library/ios/#recipes/ProvisioningPortal_Recipes/CreatingaDistributionProvisioningProfile/CreatingaDistributionProvisioningProfile.html

Однако я все еще не мог создать сборку рассылки (ad hoc или для App Store), потому что Xcode жаловался, что в моей цепочке ключей есть два сертификата распространения, и (он сказал) там должно быть только одно. Но как это могло быть? Я удалил истекающие сертификаты. Но, конечно же, это правда: истекающие сертификаты, которые я удалил, вернулись к моей цепочке ключей!

В конце концов я понял, что именно сам Xcode каким-то образом воссоздал истекающие сертификаты - предположительно на основе информации внутри истекающих профилей разработки и распространения, которые Xcode все еще содержал. Правильно, Xcode создавал второй сертификат в моей цепочке ключей, а затем жаловался, что в моей цепочке ключей было слишком много сертификатов!!!!

Итак, я удалил все профили разработки и распространения из Xcode, а затем снова удалил истекшие сертификаты из моей брелка.

Но это еще не решило проблему, потому что Xcode снова загрузил все профили из портала! И когда он это сделал, он снова создал истекающие сертификаты в моей цепочке ключей.

Итак, в конце концов мне пришлось удалить все:

  • Я удалил все профили распределения и подготовки из Portal, чтобы Xcode не смог загрузить их снова.

  • I удалил все профили распределения и подготовки из Xcode.

  • Я также удалил все профили распределения и подготовки с моих устройств, чтобы быть в безопасности.

  • I удалил устаревшие сертификаты удостоверений из моей привязки, в последний раз.

Наконец-то я остался с чистым списком. Итак, теперь я повторно загрузил профиль распространения, который я создал на портале, и мне удалось создать сборку дистрибутива моего приложения и загрузить его в iTunes Connect.

Моя последняя проблема заключалась в том, что теперь я не мог создавать и запускать на своих устройствах, потому что я удалил истекающий "профиль развития команды". Я не мог найти способ сделать новый на портале, и я не мог найти способ запросить его в Xcode, но в итоге я ударил по счастливой случайности: я подключил один из моих устройства к компьютеру и попросил Xcode добавить его на Portal, хотя он уже был добавлен в Portal ранее. Это сработало - это привело к тому, что Xcode попросил Портал создать новый профиль развития команды, и, наконец, я полностью вернулся в бизнес. Я смог разработать на своих устройствах профиль разработки команды, и мне удалось создать профили распространения, загрузить их и построить с ними для сборки Ad Hoc или App Store.

Итак, что я узнал из этого приключения: когда ваши сертификаты истекают, удалите все (все сертификаты и профили) и начните с нуля.

qaru.site

ios - Наличие нескольких учетных записей разработчика IOS и не может создать сертификат распространения IOS

У меня есть 2 действительных одиночных аккаунта разработчика IOS и 1 mac book air. Чтобы лучше объяснить мою проблему, я называю свои аккаунты учетной записью A и учетной записью B. Моя проблема заключается в том, что я могу создавать сертификаты разработчика и распространения для учетной записи A. Однако я не могу создать сертификат распространения для учетной записи B с именем учетной записи B. Аккаунт B сертификата распространения принимает имя имени учетной записи A. Чтобы создавать сертификаты, я выполняю следующие действия: Откройте доступ к keychain → помощник сертификата → запрос сертификата из центра сертификации → введите имя учетной записи B и почтовый адрес → откройте страницу разработчика Apple с учетной записью B для входа в систему и загрузите "файл запроса сертификата" в раздел "создать сертификат разработчика" и раздел "создать сертификат распространения". " Сертификат разработчика" успешно принимает имя из учетной записи B, но " сертификат распространения" принимает имя учетной записи A. Я отозвал сертификаты из учетной записи A и учетной записи B. Я удалил сертификаты из профилей доступа и профилей ключей для ключей из организатора xcode и страницы разработчика, но все же я не могу создать сертификат распространения с именем учетной записи B. Я должен отправить свое приложение из учетной записи B, потому что я создал приложение на " itunesconnect", и я хочу показать имя разработчика как учетную запись B. Как сертификат распределения учетной записи B взять имя имя учетной записи B вместо имени учетной записи A? В чем проблема?

источник поделиться

qaru.site

Сертификация в Apple Developer Center простым и понятным языком

Кратко о главном

В Apple Developer Center с незапамятных времен применяется довольно мудреная система подписи ваших приложений на каждом из основных этапов — разработка, тестирование и публикация.

Зачастую при первом погружении в эту систему у начинающих (и не только) разработчиков возникают серьезные проблемы с пониманием того, как функционирует Apple Developer Center (будем называть его «девцентр» для простоты). В результате, мне в процессе профессиональной деятельности не раз приходилось наблюдать на новых местах работы огромные свалки из профилей и сертификатов в девцентре, в результате чего приходилось приступать к «разбору завалов».

При этом, в сети довольно не такой большой выбор материалов на эту тему. Конечно, в официальной документации Apple все хорошо структурировано и очень подробно описано, но зачастую просто не хватает времени на изучение такого количества материала. Как правило, хочется быстро понять, что именно и в каком порядке нужно сделать для корректной работы приложения на этапах разработки, тестирования и при публикации его в магазин App Store. В русском же сообществе подобных материалов, собранных в одном месте и в удобном доступе, я не видел вовсе, поэтому и решил написать эту статью. Для всех интересующихся — добро пожаловать под кат.

Что мы будем разбирать?

Мы разберем процесс управления вашим приложением в Apple Developer Center от его создания до публикации в магазине App Store. Мы будем говорить только о базовых вещах, таких, как разработка, тестирование и публикация, а также обсудим APNs (Push Notifications).

Отмечу тот факт, что далее я буду описывать принцип работы девцентра по состоянию на 31 марта 2016 года, поэтому если вы читаете эту статью позднее — все уже могло измениться.

Что нам понадобится?

Собственно, для работы нам нужно следующее:

  • Рабочий Mac, либо PC с виртуальной машиной и установленной на ней Mac OS.
  • Действующий Apple ID. Его всегда можно бесплатно зарегистрировать на официальном сайте компании Apple.
  • На вашем Apple ID (либо у одной из компаний, которая добавила ваш Apple ID в свою команду) должна быть активирована так называемая Apple Developer Program — оплачиваемая раз в год «подписка», дающая вам доступ к Apple Developer Center и возможность публиковать ваши приложения в App Store. На текущий момент стоимость в пересчете на год невелика и составляет в районе $99 за год пользования.
  • И, конечно же, навыки разработки под iOS.

Ориентировка по разделам

В девцентре для полноценной работы с вашими приложениями нам понадобятся только два пункта:

  • Certificates, Identities & Profiles.

    Раздел обеспечивает управление всей системой сертификации ваших приложений. Работу именно с этим разделом мы и будем разбирать в данной статье.

  • iTunes Connect.

    Дает доступ к внутреннему и внешнему тестированию через TestFlight, а также к управлению публикацией ваших приложений в App Store.

Терминология

Давайте подробно разберем понятия, лежащие в основе функционирования девцентра Apple.

Сертификаты (Certificates)

Этот раздел дает доступ к управлению сертификатами, которыми обладает ваша учетная запись Apple ID. Каждый из этапов, которые вы будете проходить, будь то разработка, тестирование или публикация, включая все значимые составляющие экосистемы Apple вроде Push Notifications, требует обязательного наличия актуального (действующего, Active) сертификата. Говоря проще, ваше приложение не сможет даже чихнуть, не имея на то разрешения из Apple Developer Center. Чуть подробнее о подразделах:

  • Pending.

    Запрошенные вами сертификаты, находящиеся в процессе обработки от Apple. Для дев (Development) и прод (Production) сертификатов конкретно в моем случае этот подраздел чаще всего пустует.

  • Development.

    Дев-сертификаты, обеспечивающие возможность отладки вашего приложения на конкретных девайсах (одном либо нескольких) через Xcode. Более подробно поговорим о них чуть ниже.

  • Production.

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

Теперь разберем типы сертификатов.

Сертификаты типа «Development»

В первую очередь, нужно знать, что девелоперский сертификат всегда привязывается к одной конкретной машине. То есть, нельзя иметь дев-сертификат, привязанный к разным компьютерам. Если, к примеру, вы устроились на работу iOS-программистом, и в ваши задачи входит отладка на устройствах (как правило, так и есть), то вам понадобится создать отдельный дев-сертификат конкретно для вашего Mac.

Инструкция по этому процессу будет показана вам в девцентре Apple при начале создания сертификата, там все расписано очень подробно и понятно, по шагам, сложностей возникать не должно. Если вкратце, то после выбора типа сертификата (iOS App Development, для отладки приложения, либо APNs Sandbox, для отладки пушей) вам придется создать файл запроса к бюро сертификации (Certificate Signing Identity Request), на основе которого и будет сгенерирован девелоперский сертификат. Если вы хотите и отлаживать приложение, и отлаживать пуш-нотификации в «песочнице», то вам потребуются оба этих сертификата. Забегая вперед, упомяну, что аналогичный процесс применяется и при создании прод-сертификатов.

Наличие дев-сертификата означает, что, скачав его и установив двойным кликом в Связку Ключей (Apple Keychain), вы сможете запускать ваше приложение напрямую через Xcode в режиме отладки на устройстве, подключив это устройство проводом к вашему Mac. Перечень разрешенных конкретных устройств Apple нужно будет обязательно указать при генерации девелоперского профиля, но об этом позже.

Сертификаты типа «Production»

Для начала на всякий случай поясню, что сборкой iOS-приложения называют *.ipa-файл, архив, выпускаемый с соблюдением правил сертификации Apple через команду Project — Archive в Xcode.

Теперь о сертификации. Прод-сертификаты обеспечивают функционирование различных подсистем приложения в «боевых» условиях, то есть в магазине App Store, а также на устройствах, где выполняется внутреннее и внешнее тестирование приложения через TestFlight. Здесь, по аналогии с Development-сертификацией, есть тип App Store & Ad Hoc Production, а также тип APNs Production, использующийся веб-сервером для рассылки push-уведомлений. Если вы планируете выпустить приложение, поддерживающее работу с пушами, то вам понадобятся оба сертификата, как App Store & Ad Hoc (на основе которого вы сделаете сборку и отправите приложение в iTunes Connect), так и APNs Production (его вы отдадите серверу, а тот воспользуется им для получения прав на рассылку пушей). В довесок к уже упомянутым подсистемам есть еще несколько других, обеспечивающих доступ к Wallet, Apple Watch и так далее, но их обзор выходит за рамки данной статьи.

Очень часто возникает вопрос о том, в чем же разница между App Store и тем самым Ad Hoc. Ранее они были представлены разными сертификатами, с некоторого времени Apple объединила их в единое целое, за что им большое спасибо. Чуть подробнее об этих разновидностях:

  • Выпуск сборок типа App Store.

    Обеспечивает возможность тестировать приложение в TestFlight, как в режиме внутреннего, так и в режиме внешнего тестирования. Также дает возможность опубликовать приложение в App Store.

  • Выпуск сборок типа Ad Hoc.

    Термин «Ad Hoc» можно перевести как «специальный», «для конкретной цели». Такой тип сертификации обеспечивает возможность запускать ваше приложение (включая все нужные подсистемы типа APNs) в боевых условиях, но только на конкретных девайсах, и без участия Xcode в процессе запуска. Другими словами, Ad Hoc необходим, если вы захотите поставить ваше приложение на стороннее устройство, не имея к нему прямого доступа (то есть не подсоединяя его проводом к вашему Mac, так как в этом случае вам бы хватило Development-сертификата), но при этом и не выкладывая приложение в iTunes Connect. Такой сертификат используется при создании специального Ad Hoc-профиля, о котором пойдет речь чуть позже.

Intermediate Certificates

Некоторое время назад Apple внесла изменения в логику работы девцентра и своей системы сертификации, после чего на большинстве компьютеров пропала возможность делать сборки приложений, несмотря на наличие активных дев- и прод-сертификатов и актуальных профилей. Причина этого была в том, что Apple добавила дополнительное требование, чтобы на вашем Mac в связке ключей был установлен специальный сертификат под названием «Worldwide Developer Relations Certificate Authority». Он устанавливается автоматически с новыми версиями Xcode, но те, у кого Xcode уже был установлен ранее, просто должны были установить этот сертификат вручную, скачав его по прямой ссылке из секции Intermediate Certificates в девцентре Apple, после чего проблемы со сборками исчезали. Больше никакой смысловой нагрузки этот сертификат не несет.

Идентификаторы (Identities)

Данный раздел обеспечивает управление идентификаторами. Для вашего приложения в минимальном исполнении понадобится App ID, управление которыми доступно в одноименном подразделе.

В буквальном переводе «App ID» означает «идентификатор приложения», что полностью отражает его суть. Любое ваше приложение, которое вы хотите отлаживать на устройстве Apple, тестировать через TestFlight и/или публиковать в магазин App Store, должно обладать собственным уникальным именем, по которому его можно однозначно идентифицировать среди тысяч других приложений. При добавлении нового App ID вам будет предложено ввести несколько элементов:

  • App ID Description.

    Имя вашего приложения. К примеру, если ваше приложение называется Mail Printer, то прямо так его и записываем в это текстовое поле.

  • App ID Prefix.

    Префикс вашего приложения, он выдается вам автоматически и будет общим для конкретной команды Apple Team, где подключена и активна Apple Developer Program.

  • App ID Suffix.

    Здесь нам понадобится выбрать Explicit App ID, чтобы указать бандл (bundle) приложения. Это идентификатор, обычно имеющий вид com.mycompany.myappname, где mycompany — имя вашей компании или вашего домена. Например, com.homecompany.MailPrinter. Обращаю ваше внимание, что точно такой же бандл должен быть выставлен в настройках таргета (Target) вашего приложения в Xcode (секция настроек General, поле Bundle Identifier).

  • App Services.

    Здесь вам нужно отметить те сервисы, которые вы планируете использовать в вашем приложении. По умолчанию там отмечены только Game Center и In-App Purchase, их использование обязательно, удалить их нельзя. Остальные сервисы подключайте по мере необходимости.

После создания App ID вы можете использовать его для генерации любых типов профилей, об этом чуть позже.

Устройства (Devices)

В этом разделе размещено управление всеми устройствами Apple, которые вы можете использовать в рамках вашей Apple Developer Program. Есть ограничение, максимум 100 зарегистрированных девайсов на одну учетную запись в год, обычно этого более чем достаточно. При необходимости отладки на устройстве или выпуска Ad Hoc-сборки просто добавляйте сюда UDID нужных вам девайсов и используйте их при генерации профилей.

Профили (Provisioning Profiles)

Дословно название этого раздела переводится как «Профили обеспечения». Чуть более развернуто я бы описал понятие «профиль» как «Специальный файл, обеспечивающий доступ к некоторой функциональности в конкретной сборке вашего приложения». В данном разделе девцентра вы можете управлять вашими профилями, обеспечивая себе возможность выпускать сборки приложения для различных целей, то есть «профилировать» его. По сути, профиль является результатом объединения двух (иногда трех) компонентов:

  • Активного сертификата определенного типа (раздел Certificates). С помощью сертификата профиль подтверждает, что ваше приложение имеет право на выполнение определенной группы действий.
  • App ID (раздел Identities). Определяет конкретное приложение, для которого выпускается профиль.
  • В некоторых случаях, еще нужен список зарегистрированных устройств (раздел Devices). Определяет перечень устройств, на которые разрешено устанавливать вашу сборку. Используется только с некоторыми типами профилей.

На выходе как раз и получаем профиль для выпуска сборок с определенными целями. Давайте рассмотрим разновидности профилей.

Профили типа «Development»

Это профиль для разработки, то есть для отладки вашего приложения на конкретных устройствах через Xcode с прямым подключением устройства проводом к вашему Mac. Дев-профили представлены двумя видами:

  • iOS App Development.

    Требует указания перечня разрешенных устройств из раздела Devices.Используется для отладки iOS-приложений.

  • tvOS App Development.

    Аналогично, только используется для tvOS-приложений.

Профили типа «Distribution»

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

  • App Store.

    Используется для тестирования (как внутреннего, так и внешнего) в TestFlight, а также для выпуска приложения в App Store.

  • tvOS App Store.

    Аналогично предыдущему, только для tvOS.

  • Ad Hoc.

    Требует указания перечня разрешенных устройств из раздела Devices.Используется, если вы хотите выпустить сборку, которую можно будет поставить в режиме «Production», но только на некоторых устройствах. Реальная ситуация, когда это может понадобится, например, следующая. Вы разрабатываете приложение, а в процессе работы заказчик попросил у вас «дать ему пощупать приложение» на своем Apple-устройстве. В iTunes Connect для активации внешнего тестирования вы еще выходить не готовы, но просьбу заказчика нужно выполнять — вот тут как раз и пригодится Ad Hoc-профиль, сгенерированный на базе прод-сертификата App Store & Ad Hoc Production Certificate.

  • tvOS Ad Hoc.

    Аналогично предыдущему, только для tvOS.

Вкратце об iTunes Connect

Этот сервис предоставляет вам возможность управлять внутренним и внешним тестированием в TestFlight, а также выкладывать приложение в App Store. Рассмотрение этого процесса выходит за рамки данной статьи, упомяну лишь тот факт, что для корректной работы этому сервису необходимы сборки, созданные на базе профиля типа Distribution — App Store (для iOS либо tvOS). Другие типы профилей здесь не поддерживаются.

Резюмируем

По сути, ваш алгоритм действий должен сводиться к следующему:

  1. Определиться, с каких конкретно машин будет производиться прямая отладка на устройствах через Xcode. Сгенерировать для каждого из этих Mac сертификаты группы Development (генерировать их нужно на базе Certificate Signing Identity Request, который вы должны получить с каждого нужного вам Mac).
  2. Узнать, с какой машины планируется собирать сборки для тестирования и/или публикации в App Store. Сгенерировать для нее (или них, если их несколько) сертификат группы Distribution.
  3. Проконтролировать наличие нужного идентификатора приложения в App ID и соответствие указанного там бандла соответствующему Bundle Identifier в проекте в Xcode, при наличии несоответствия — устранить его либо в девцентре, либо в Xcode (где именно это править — зависит от вашей конкретной ситуации).
  4. Убрать (Revoke/Delete) все сертификаты, а затем и профили, которые обладают пометкой Expired (истекший сертификат) или Invalid (некорректный профиль). Также отмечу, что, в отличие от сертификатов, профили можно редактировать. То есть, сгенерировав новые сертификаты, вместо удаления старых профилей вы можете просто отредактировать их, указав им новые сертификаты в качестве подписи.
  5. Если профилей нет, либо не хватает нужных, то сгенерировать необходимые профили.
  6. Скачать и установить нужные для вашей машины сертификаты и профили на свой компьютер. Установка производится двойным кликом на файле. Сертификаты будут установлены в Связку Ключей (Apple Keychain), профили — в Xcode.
  7. Установить в настройках проекта Xcode нужные вам сертификаты в секции Build Settings — Code Signing Identity — Development/Distribution, а также указать необходимый Provisioning Profile.

На этом подготовка и чистка девцентра завершается. Далее вы можете выполнять любой из нижеследующих пунктов по необходимости:

  • Произвести запуск в режиме отладки (Project — Run) через Xcode на разрешенном устройстве, используя дев-профиль.
  • Создать сборку (Project — Archive с выбранным целевым устройством Generic iOS Device) на базе продакшн-профиля Ad Hoc для установки на конкретные устройства (такую сборку можно будет выслать, например, по электронной почте заказчику, чтобы он установил ее на свое разрешенное устройство).
  • Создать сборку аналогично предыдущему пункту, но на базе продакшн-профиля App Store. Это будет сборка для внутреннего и/или внешнего тестирования, а также для выкладки в App Store, которую можно использовать в iTunes Connect.

Надеюсь, это подробное описание поможет вам разобраться в специфике функционирования системы сертификации приложений Apple, а также поможет навести порядок в Apple Developer Center.

Автор: GDXRepo

Источник

www.pvsm.ru

scroll to top