Цифровая подпись файлов AIR

Цифровая подпись установочных файлов AIR с помощью сертификатов, выданных сертифицирующими органами (СО), дает вашим пользователям гарантию того, что в устанавливаемый ими файл не был нечаянно или специально внедрен сторонний код, и обозначает вас в качестве автора подписи (издателя). Во время установки AIR отображает имя издателя, если приложение AIR заверено надежным сертификатом или сертификатом, указывающим на надежный сертификат на данном компьютере:

Диалоговое окно подтверждения для приложения, подписанного доверенным сертификатом

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

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

Сертификаты для подписывания кодов

Гарантии, ограничения безопасности и юридические обязательства, связанные с использованием сертификатов подписи кода, описаны в документе Certificate Practice Statements (CPS, «Положения об использовании сертификатов») и соглашениях с подписчиками, публикуемых сертифицирующими органами. Дополнительные сведения о соглашениях с сертифицирующими органами, которые выпускают сертификаты для подписания программных кодов AIR в данное время, см. по следующим адресам:

ChosenSecurity (http://www.chosensecurity.com/products/tc_publisher_id_adobe_air.htm)

ChosenSecurity CPS (http://www.chosensecurity.com/resource_center/repository.htm)

GlobalSign (http://www.globalsign.com/code-signing/index.html)

GlobalSign CPS (http://www.globalsign.com/repository/index.htm)

CPS Thawte (http://www.thawte.com/cps/index.html)

VeriSign CPS (http://www.verisign.com/repository/CPS/)

Соглашение с подписчиком VeriSign (https://www.verisign.com/repository/subscriber/SUBAGR.html)

О подписании кода AIR

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

AIR использует инфраструктуру открытых ключей (PKI), поддерживаемую хранилищем ключей операционной системы, для проверки подлинности сертификата. Для проверки информации об издателе компьютер, на который устанавливается приложение AIR, должен либо подтвердить принятие сертификата, с помощью которого подписано приложение, либо подтвердить принятие цепочки сертификатов, ведущих к сертификату надежного СО.

Если файл AIR подписан сертификатом, не ведущим к одному из основных надежных сертификатов (как правило, это относится к самозаверяющим сертификатам), то информацию об издателе нельзя проверить. Хотя AIR может проверить, не был ли пакет AIR изменен с момента подписи, узнать, кто на самом деле создал и подписал файл, невозможно.

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

Об идентификаторах издателя AIR

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

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

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

Чтобы определить исходный идентификатор издателя, найдите файл publisherid в подкаталоге META-INF/AIR, в котором установлено исходное приложение. Строка в этом файле является идентификатором издателя. Чтобы указать идентификатор издателя вручную, в дескрипторе приложения должна быть указана среда выполнения AIR 1.5.3 (или более поздней версии) в объявлении пространства имен файла дескриптора приложения.

При наличии идентификатора издателя он используется в следующих целях:

  • как часть ключа шифрования для зашифрованного локального хранилища;

  • как часть пути к каталогу хранения приложения;

  • как часть строки для локальных соединений;

  • как часть строки учетных данных, используемой для вызова приложения в API-интерфейсе обозревателя AIR;

  • как часть идентификатора OSID (используется при создании пользовательских программ установки/удаления).

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

О форматах сертификатов

Средства подписи AIR принимают любые хранилища ключей, доступные в рамках криптографической архитектуры Java (JCA). Сюда включены файлы-хранилища, например файлы формата PKCS12 (обычно имеют расширение .pfx или .p12), файлы Java .keystore, аппаратные хранилища PKCS11 и системные хранилища ключей. Форматы хранилищ ключей, к которым может иметь доступ средство ADT, зависят от версии и конфигурации среды выполнения Java, в которой запускается ADT. Доступ к некоторым типам хранилищ, например аппаратным маркерам PKCS11, возможен только при установке и конфигурации дополнительных программных драйверов и подключаемых модулей JCA.

Чтобы подписать файлы AIR, можно использовать большинство существующих сертификатов для подписания программного кода, а также можно получить новый ускоренно выпущенный сертификат для подписания приложений AIR. Например, можно использовать любой из следующих типов сертификатов, выпущенных VeriSign, Thawte, GlobalSign или ChosenSecurity:

  • ChosenSecurity

    • Идентификатор TC Publisher для Adobe AIR

  • GlobalSign

    • Сертификат для подписания кода ObjectSign

  • Thawte :

    • сертификат разработчика AIR

    • сертификат разработчика Apple

    • сертификат разработчика JavaSoft

    • сертификат Microsoft Authenticode

  • VeriSign :

    • Цифровое удостоверение Adobe AIR

    • цифровое удостоверение Microsoft Authenticode

    • цифровое удостоверение Sun Java

Примечание. Этот сертификат должен создаваться для подписания кода. Нельзя использовать SSL или сертификаты другого типа для подписания файлов AIR.

Временные отметки

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

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

По умолчанию средства упаковки AIR используют временные отметки Geotrust.

Получение сертификата

Для получения сертификата обычно нужно посетить сайт сертифицирующего органа и пройти процесс заверения. Средства, используемые для создания файла-хранилища ключей для средств AIR, зависят от типа приобретенного сертификата, способа хранения сертификата на принимающем компьютере, а в некоторых случаях и от обозревателя, через который получается сертификат. Например, чтобы получить и экспортировать сертификат разработчика Adobe от Thawte, необходимо использовать Mozilla Firefox. Затем этот сертификат можно экспортировать как файл P12 или PFX непосредственно из интерфейса пользователя Firefox.

Примечание. Java 1.5 и более поздние версии не позволяют использовать в паролях для защиты файлов сертификатов PKCS12 нестандартные символы ASCII. Язык Java используется средствами разработки AIR для создания подписанного пакета AIR. При экспорте сертификата в виде файла с расширением P12 или PFX, в пароле используются только стандартные символы ASCII.

С помощью средства ADT, которое используется для упаковки установочных файлов AIR, можно создать собственный самозаверяющий сертификат. Также можно использовать и инструменты сторонних разработчиков.

Инструкции по созданию самозаверяющих сертификатов и по подписи файлов AIR см. в разделе AIR Developer Tool (ADT) . Файлы AIR также можно экспортировать и подписывать с помощью Flash Builder, Dreamweaver и обновления AIR для Flash.

В примере ниже показано, как получить от Thawte сертификат разработчика AIR и подготовить его для использования с ADT.

Пример: получение сертификата разработчика AIR от Thawte

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

Для приобретения сертификата разработчика AIR Thawte требуется использовать обозреватель Mozilla Firefox. Закрытый ключ сертификата сохраняется в хранилище ключей обозревателя. Убедитесь, что хранилище ключей Firefox защищено основным паролем, а компьютер защищен физически. (После завершения процесса заверения можно экспортировать и удалить сертификат из хранилища ключей обозревателя.)

В ходе процесса регистрации сертификата генерируется связка закрытого и открытого ключей. Закрытый ключ автоматически заносится в хранилище ключей Firefox. Для запроса и получения сертификата с сайта Thawte необходимо использовать один и тот же компьютер и один и тот же обозреватель.

  1. Зайдите на сайт Thawte и перейдите к странице Product page for Code Signing Certificates («Сертификаты подписания кода»).

  2. Выберите из списка сертификатов подписания кода сертификат разработчика AIR (Adobe AIR Developer Certificate).

  3. Выполните все три шага процесса регистрации сертификата. Необходимо предоставить информацию об организации и контактные данные. Затем Thawte проверяет подлинность личности заявителя и запрашивает дополнительную информацию. После завершения проверки Thawte отправляет электронное письмо с инструкциями по получению сертификата.

    Примечание. Дополнительные сведения о типе требуемой документации см. здесь: https://www.thawte.com/ssl-digital-certificates/free-guides-whitepapers/pdf/enroll_codesign_eng.pdf .

  4. Получите выписанный сертификат на сайте Thawte. Сертификат автоматически заносится в хранилище ключей Firefox.

  5. Экспортируйте файл-хранилище с закрытым ключом и сертификат из хранилища ключей Firefox, как описано ниже.

    Примечание. При экспорте закрытого ключа и сертификата из хранилища Firefox файл получает формат .p12 (pfx), который распознают ADT, Flex, Flash и Dreamweaver.

    1. Откройте диалоговое окно Менеджер сертификатов в Firefox:

    2. В ОС Windows откройте Сервис -> Параметры -> Дополнительно -> Шифрование -> Просмотр сертификатов

    3. В Mac OS откройте Firefox -> Установки -> Дополнительно -> Шифрование -> Просмотр сертификатов

    4. В Linux откройте «Правка -> Установки -> Дополнительно -> Шифрование -> Просмотр сертификатов» (Edit -> Preferences -> Advanced -> Encryption -> View Certificates)

    5. Выберите сертификат подписания кода Adobe AIR из списка и нажмите кнопку Резервная копия .

    6. Введите имя файла и место его экспорта и нажмите кнопку Сохранить .

    7. Если используется основной пароль Firefox, вам потребуется ввести пароль устройства защиты ПО для экспорта файла. (Этот пароль используется только в Firefox.)

    8. В диалоговом окне Выберите пароль резервного копирования создайте пароль для файла-хранилища.

      Важная информация. Пароль нужен для защиты файла хранилища и требуется, когда файл используется для подписи приложений AIR. Необходимо выбирать надежный пароль.

    9. Нажмите кнопку «ОК». Вы должны увидеть сообщение об успешном принятии пароля резервного копирования. Файл-хранилище с закрытым ключом и сертификатом сохраняется с расширением .p12 (в формате PKCS12)

  6. Экспортированный файл можно использовать в ADT, Flash Builder, Flash Professional или Dreamweaver. Пароль, созданный для файла, потребуется при подписи приложения AIR.

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

Замена сертификатов

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

  • Возобновление исходного сертификата подписи.

  • обновление самозаверяющего сертификата до сертификата, выданного сертифицирующим органом;

  • замена истекающего самозаверяющего сертификата на новый;

  • замена одного коммерческого сертификата другим, например при изменении корпоративных данных

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

После установки файла AIR с подписью переноса новый сертификат становится основным. Для последующих обновлений подпись переноса не требуется. Однако подписи переноса следует применять как можно дольше, чтобы обеспечить работу пользователей, пропустивших обновления.

Важная информация. Чтобы обновить исходный сертификат, прежде чем закончится его срок действия, необходимо изменить сертификат и применить подпись переноса. В противном случае перед установкой новой версии пользователям потребуется удалить существующую версию приложения. Для AIR 1.5.3 и более поздней версии подпись переноса можно применить, используя устаревший сертификат в течение 365-дневного льготного периода после окончания его срока действия. Однако нельзя использовать просроченный сертификат для применения основной подписи приложения.

Для замены сертификата выполните следующие действия:

  1. Создайте обновление приложения

  2. Упакуйте и подпишите файл обновления AIR новым сертификатом

  3. Подпишите файл AIR снова, на этот раз оригинальным сертификатом (с помощью команды ADT -migrate )

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

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

Применение подписи переноса производится Команда ADT migrate , как описано в разделе « Подписание обновленной версии приложения AIR ».

Примечание. Команда ADT migrate не может использоваться в приложениях AIR для настольных платформ, включающих расширения на собственном языке платформы, поскольку такие приложения упаковываются в виде собственного файла установки платформы, а не файла air. Для смены сертификата приложения AIR для настольных платформ, включающего собственные расширения, следует упаковать такое приложение при помощи Команда ADT package с флагом -migrate.

Изменение учетных данных приложения

В версиях, предшествующих AIR 1.5.3, учетные данные приложения AIR изменялись при установке обновления с подписью переноса. Изменение учетных данных приложения имеет несколько последствий, в том числе:

  • Новая версия приложения не может получать доступ к данным в существующем зашифрованном локальном хранилище.

  • Изменяется адрес каталога хранилища приложения. Данные из старого каталога не копируются в новый каталог. (Но новое приложение может найти старый каталог с помощью ID издателя.)

  • Приложение больше не может устанавливать локальные соединения с помощью ID издателя.

  • Изменяется строка учетных данных, используемая для доступа к приложению с веб-страницы.

  • Изменяется идентификатор OSID приложения. (Идентификатор OSID используется при написании пользовательских программ установки/удаления.)

При публикации обновления с использованием AIR 1.5.3 или более поздней версии изменение учетных данных приложения невозможно. Идентификаторы исходного приложения и издателя должны быть указаны в дескрипторе приложения файла AIR обновления. В противном случае новый пакет не распознается как обновление.

Примечание. При публикации нового приложения AIR с использованием AIR 1.5.3 или более поздней версии не следует указывать идентификатор издателя.

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

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

Термин

Описание

Сертифицирующий орган (СО)

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

Certificate Practice Statement (CPS, «Положение об использовании сертификатов»)

Содержит рекомендации и правила по выдаче и проверке сертификатов для сертифицирующих органов. CPS является частью договора между СО и его подписчиками и связанными лицами. Также в нем описывается политика проверки подлинности и степени гарантий различных сертификатов.

Список отозванных сертификатов (CRL)

Список выданных сертификатов, которые были впоследствии отозваны и более недействительны. AIR проверяет список CRL во время подписи приложения AIR, а если временной отметки нет, то еще раз при установке.

Цепочка сертификатов

Цепочка сертификатов — это последовательность, в которой каждый сертификат подписывается следующим.

Цифровой сертификат

Цифровой документ, содержащий информацию об идентификационных данных владельца, открытом ключе владельца и идентификационных данных самого сертификата. Сертификат, выданный СО, сам подписан сертификатом, принадлежащим этому СО.

Цифровая подпись

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

Хранилище ключей

База данных с цифровыми сертификатами и (в некоторых случаях) связанными с ними закрытыми ключами.

Криптографическая архитектура Java (JCA)

Открытая архитектура для управления и доступа к хранилищам ключей. Дополнительные сведения см. в руководстве по криптографической архитектуре Java .

PKCS #11

Стандарт интерфейса криптографических маркеров, разработанный Лабораторией RSA. Аппаратное хранилище ключей на основе маркеров.

PKCS #12

Стандарт синтаксиса обмена личной информацией, разработанный Лабораторией RSA. Файл-хранилище ключей, содержащий закрытый ключ и связанный с ним цифровой сертификат.

Закрытый ключ

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

Открытый ключ

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

Инфраструктура открытых ключей (PKI)

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

Временная отметка

Цифровая метка, содержащая дату и время того или иного события. ADT может ставить временные отметки согласно серверу времени пакета AIR, соответствующего стандарту RFC 3161 . Если функция временных отметок включена, AIR использует ее для проверки подлинности сертификата во время подписания. Это позволяет устанавливать приложение AIR после истечения срока действия сертификата.

Орган выдачи временных отметок

Орган, выдающий временные отметки. Чтобы AIR распознавала временные отметки, они должны соответствовать стандарту RFC 3161, а подпись временной отметки должна вести к надежному основному сертификату на принимающем компьютере.

Сертификаты iOS

Сертификат подписания кода, выданный Apple, используется для подписания приложений для ОС iOS, включая приложения, разработанные с помощью Adobe AIR. Применение подписи с использованием сертификата разработки Apple требуется для установки приложения на тестовые устройства. Применение подписи с использованием сертификата распространения требуется для распространения готового приложения.

Для подписания приложения ADT требуется доступ к сертификату подписания кода и связанному с ним личному ключу. Файл сертификата не содержит личный ключ. Необходимо создать хранилище ключей в формате файла обмена личной информацией (.p12 или .pfx), который будет содержать сертификат и личный ключ. См. раздел « Преобразование сертификата разработчика в файл хранилища P12 ».

Генерация запроса на подпись сертификата

Чтобы получить сертификат разработчика, необходимо сгенерировать запрос на подписание сертификата и отправить его в Apple iOS Provisioning Portal.

При создании запроса на подписание сертификата генерируется связка закрытого и открытого ключей. Закрытый ключ сохраняется на компьютере. Отправьте в Apple запрос на подписание, содержащий открытый ключ и идентификационную информацию. Компания Apple возьмет на себя роль сертифицирующего органа. Apple подписывает ваш сертификат, используя собственный сертификат World Wide Developer Relations.

Формирование запроса на подпись сертификата в ОС Mac OS

В ОС Mac OS для формирования запроса подписи воспользуйтесь программой «Связка ключей». Программа «Связка ключей» расположена в каталоге Программы/Служебные программы. Инструкции по генерации запроса на подписание сертификата доступны на портале Apple iOS Provisioning Portal.

Формирование запроса на подпись сертификата в ОС Windows

Для тех, кто работает в ОС Windows, будет проще получить сертификат разработчика iPhone, используя компьютер с ОС Mac. Тем не менее, получить сертификат на компьютере с ОС Windows возможно. Сначала нужно создать запрос на подпись сертификата (CSR-файл) с помощью OpenSSL.

  1. Установите OpenSSL на компьютере Windows. (Перейдите на страницу http://www.openssl.org/related/binaries.html .)

    Возможно, потребуется также установить файлы Visual C++ 2008 Redistributable, указанные на странице загрузки Open SSL. (Устанавливать Visual C++ на компьютер не требуется.)

  2. Откройте сеанс командной строки Windows и компакт-диск для каталога корзины OpenSSL (например, c:\OpenSSL\bin\).

  3. Создайте личный ключ, введя следующее в командную строку: 

    openssl genrsa -out mykey.key 2048

    Сохраните файл с личным ключом. Он понадобится вам в дальнейшем.

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

  4. Создайте CSR-файл, введя следующее в командную строку: 

    openssl req -new -key mykey.key -out CertificateSigningRequest.certSigningRequest  -subj "/emailAddress=yourAddress@example.com, CN=John Doe, C=US"

    Подставьте свой адрес электронной почты, имя сертификата (CN) и страну (C).

  5. Отправьте CSR-файл на веб-сайт разработчиков iPhone . (См. раздел «Запрос сертификата разработчика iPhone и создание профиля обеспечения».)

Преобразование сертификата разработчика в файл хранилища P12

Чтобы создать хранилище ключей P12, необходимо объединить в одном файле сертификат разработчика Apple и связанный с ним закрытый ключ. Процедура создания файла хранилища определяется методом, который был использован для генерации запроса на подписание исходного сертификата, а также местом хранения закрытого ключа.

Преобразование сертификата разработчика iPhone в файл P12 в ОС Mac OS

Загрузив сертификат iPhone с сайта Apple, экспортируйте его в формате файла хранилища P12. В ОС Mac® OS выполните следующие действия.

  1. Откройте программу «Связка ключей» (каталог Программы/Служебные программы).

  2. Если сертификат еще не добавлен в связку ключей, выберите «Файл» > «Импорт». Найдите файл сертификата (CER-файл), полученный от компании Apple.

  3. В программе «Связка ключей» выберите категорию «Ключи».

  4. Выберите личный ключ, связанный с данным сертификатом на разработку iPhone.

    Личный ключ идентифицируется связанным с ним открытым сертификатом «Разработчик iPhone: <имя> <фамилия>».

  5. Нажмите на сертификат iPhone Developer и выберите Экспорт «iPhone Developer: Имя...» .

  6. Сохраните хранилище ключей в формате файла обмена личными данными (.p12).

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

Преобразование сертификата разработчика Apple в файл P12 в ОС Windows

Для разработки приложений AIR for iOS необходимо использовать файл сертификата P12. Этот сертификат создается на основе файла сертификата разработчика iPhone, полученного от компании Apple.

  1. Преобразуйте файл сертификата разработчика, полученный от компании Apple, в файл сертификата PEM. С помощью командной строки запустите следующую операцию из каталога корзины (bin) OpenSSL. 

    openssl x509 -in developer_identity.cer -inform DER -out developer_identity.pem -outform PEM

  2. Если используется личный ключ из связки ключей на компьютере с ОС Mac, преобразуйте его в ключ PEM: 

    openssl pkcs12 -nocerts -in mykey.p12 -out mykey.pem

  3. Теперь можно создать действительный файл P12 на основе ключа и версии PEM сертификата разработчика iPhone: 

    openssl pkcs12 -export -inkey mykey.key -in developer_identity.pem -out iphone_dev.p12

    Если используется ключ из связки ключей в ОС Mac OS, используйте версию PEM, созданную при выполнении предыдущего шага. В противном случае используйте ключ OpenSSL, созданный ранее (в ОС Windows).