Firma digital de archivos de AIR

La firma digital de sus archivos de instalación de AIR con un certificado proporcionado por una entidad emisora de certificados (AC) reconocida ofrece seguridad a los usuarios de que la aplicación que están instalando no ha sido alterada ni de modo accidental ni malintencionado e identifica a usted como el firmante (editor). Si la aplicación de AIR está firmada con un certificado de confianza, o está encadenada con un certificado de confianza en el ordenador de instalación, AIR presenta el nombre del editor durante la instalación.

Cuadro de diálogo de confirmación de instalación firmado por un certificado de confianza

Si una aplicación se firma con un certificado con firma automática (o un certificado que no se vincula a un certificado de confianza), el usuario debe asumir un mayor riesgo de seguridad al instalar la aplicación. El cuadro de diálogo de instalación refleja este riesgo adicional:

Cuadro de diálogo de confirmación de instalación firmado por un certificado con firma automática
Importante: una entidad malintencionada podría falsificar un archivo de AIR con su identidad si lograra obtener su archivo de almacén de claves para la firma descubre si clave privada.

Certificados con firma de código

Las garantías de seguridad, limitaciones y obligaciones legales respecto del uso de certificados de firma de código se reseñan en la declaración de prácticas de certificación (DPC) y los acuerdos de suscriptor publicados por la autoridad de certificación emisora. Para obtener más información sobre los acuerdos para las entidades emisoras de certificados que actualmente proporcionan certificados de firma de código de AIR, consulte:

ChosenSecurity (http://www.chosensecurity.com/products/tc_publisher_id_adobe_air.htm) (en inglés)

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) (en inglés)

Thawte CPS (http://www.thawte.com/cps/index.html) (en inglés)

VeriSign CPS (http://www.verisign.com/repository/CPS/) (en inglés)

Acuerdo de suscripción de Verisign (https://www.verisign.es/repository/subscriber/SUBAGR.html)

Firma de códigos de AIR

Cuando se firma un archivo de AIR se incluye una firma digital en el archivo de instalación. La firma incluye un resumen del paquete, el cual se utiliza para verificar que el archivo de AIR no se haya alterado desde que se firmó, e incluye información acerca del certificado de firma, que sirve para verificar la identidad del editor.

AIR utiliza la infraestructura de claves públicas (PKI), compatible a través del almacén de certificados del sistema operativo, para establecer si un certificado es de confianza. El ordenador en el que se instala una aplicación de AIR debe o bien confiar directamente en el certificado que se utiliza para firmar la aplicación de AIR, o bien confiar en una serie de certificados que vinculan el certificado con una entidad emisora de certificados de confianza para que se pueda verificar la información del editor.

Si se firma un archivo de AIR con un certificado que no está encadenado con uno de los certificados raíz de confianza (que normalmente incluye a todos los certificados con firma automática), no se puede verificar la información del editor. Si bien AIR puede determinar que un paquete de AIR no ha sido alterado desde que se firmó, no hay manera de saber quién creó y firmó el archivo.

Nota: un usuario puede optar por confiar en un certificado con firma automática y en adelante las aplicaciones de AIR firmadas con el certificado presentarán el valor del campo de nombre común en el certificado como nombre del editor. AIR no proporciona ningún mecanismo para que un usuario designe un certificado como “de confianza”. El certificado (sin incluir la clave privada) debe proporcionarse por separado al usuario, quien deberá emplear uno de los mecanismos suministrados con el sistema operativo o una herramienta adecuada para importar el certificado en el lugar correcto en el almacén de certificados del sistema.

Identificador del editor de AIR

Importante: a partir de AIR 1.5.3, el ID de editor queda desfasado y no se vuelve a calcular en función del certificado de firma de código. Las nuevas aplicaciones no necesitan ni deben utilizar un ID de editor. Al actualizar las aplicaciones existentes, debe especificar el ID de editor original en el archivo descriptor de la aplicación.

Antes de AIR 1.5.3, el instalador de aplicaciones de AIR generó un ID de editor durante la instalación de un archivo de AIR. Se trata de un identificador exclusivo del certificado que se utiliza para firmar el archivo de AIR. Si se vuelve a utilizar el mismo certificado para varias aplicaciones de AIR, todas tendrán el mismo ID de editor. La firma de una actualización de la aplicación con un certificado diferente y en ocasiones incluso con una instancia renovada del certificado original cambió el ID de editor.

En AIR 1.5.3 y versiones posteriores, un ID de editor no se asigna mediante AIR. Una aplicación publicada con AIR 1.5.3 puede especificar una cadena de ID de editor en el descriptor de la aplicación. Únicamente es necesario especificar un ID de editor cuando se publiquen actualizaciones para aplicaciones publicadas en un principio para versiones de AIR antes de 1.5.3. Si no se especifica el ID original en el descriptor de la aplicación, el nuevo paquete de AIR no se tratará como una actualización de la aplicación existente.

Para determinar el ID de editor original, localice el archivo publisherid en el subdirectorio META-INF/AIR donde se instaló la aplicación original. La cadena de este archivo es el ID de editor. El descriptor de la aplicación debe especificar el motor de ejecución de AIR 1.5.3 (o posterior) en la declaración del espacio de nombres del archivo descriptor de la aplicación con el fin de especificar el ID de editor manualmente.

El ID de editor, cuando se encuentra presente, se emplea para lo siguiente:

  • Como parte de la clave de cifrado para el almacén local cifrado.

  • Como parte de la ruta para el directorio de almacenamiento de la aplicación.

  • Como parte de la cadena de conexión para conexiones locales.

  • Como parte de la cadena de identidad utilizada para invocar una aplicación la API en navegador de AIR.

  • Como parte de OSID (utilizado al crear programas personalizados de instalación y desinstalación).

Cuando cambia un ID de editor, el comportamiento de cualquier función de AIR basada en el ID también cambia. Por ejemplo, ya no se puede acceder a los datos del almacén local cifrado existente y cualquier instancia de Flash o AIR que cree una conexión local con la aplicación debe utilizar el nuevo ID en la cadena de conexión. El ID de editor para una aplicación instalada no puede cambiar en AIR 1.5.3 ni en versiones posteriores. Si se utiliza un ID de editor diferente al publicar un paquete de AIR, el instalador trata el nuevo paquete como una aplicación distinta en lugar de como una actualización.

Formatos de certificados

Las herramientas de firma de AIR aceptan cualquier almacén de claves accesibles a través de la arquitectura de criptografía de Java (Java Cryptography Architecture o JCA). En esto se incluyen los almacenes de claves basados en archivos, como archivos de formato PKCS12 (que suelen tener la extensión de archivo .pfx o .p12), archivos .keystore de Java, almacenes de claves de hardware PKCS11 y los almacenes de claves del sistema. Los formatos de almacenes de claves a los que tiene acceso ADT depende de la versión y configuración del motor de ejecución de Java que se utilice para ejecutar ADT. El acceso a algunos tipos de almacén de claves, como los token de hardware PKCS11, pueden necesitar que se instalen y configuren plugins de JCA y controladores de software adicionales.

Para firmar archivos de AIR, puede utilizar la mayoría de los certificados de firma de código existentes, o bien, puede obtener un certificado nuevo emitido expresamente para firmar aplicaciones de AIR. Se pueden utilizar, por ejemplo, cualquiera de los siguientes tipos de certificados de Verisign, Thawte, GlobalSign o ChosenSecurity:

  • ChosenSecurity (en inglés)

    • TC Publisher ID para Adobe AIR

  • GlobalSign

    • Certificado de firma de código ObjectSign

  • Thawte :

    • Certificado de AIR Developer

    • Certificado de Apple Developer

    • Certificado de JavaSoft Developer

    • Certificado de Microsoft Authenticode

  • VeriSign (en inglés):

    • ID digital de Adobe AIR

    • Microsoft Authenticode Digital ID

    • Sun Java Signing Digital ID

Nota: el certificado se debe crear para realizar la firma de código. No se puede utilizar un certificado SSL ni otro tipo de certificado para firmar archivos de AIR.

Marcas de hora

Cuando se firma un archivo de AIR, la herramienta de empaquetado consulta al servidor de una autoridad de marcas de hora para obtener una fecha y hora de la firma que sean verificables independientemente. La marca de hora que se obtiene se incorpora en el archivo de AIR. Siempre y cuando el certificado de firma sea válido en el momento de firmarlo, se podrá instalar el archivo de AIR, incluso después de caducado el certificado. Por otro lado, si no se obtiene la marca de hora, el archivo de AIR dejará de poder instalarse cuando caduque o se revoque el certificado.

La opción predeterminada es que las herramientas de empaquetado de AIR obtienen una marca de hora. No obstante, para que las aplicaciones puedan empaquetarse cuando no se dispone del servicio de marcas de hora, el marcado de hora se puede desactivar. Adobe recomienda que todo archivo de AIR que se distribuya al público incluya una marca de hora.

La autoridad de marcas de hora predeterminada que utilizan las herramientas de empaquetado de AIR es Geotrust.

Obtención de un certificado

Para obtener un certificado, normalmente visitaría el sitio web de la entidad emisora de certificados y llevaría a cabo el proceso de adquisición de la empresa en cuestión. Las herramientas que se utilizan para producir el archivo del almacén de claves que necesitan las herramientas de AIR dependen del tipo de certificado que se compre, cómo se guarda el certificado en el ordenador receptor y, en algunos casos, el navegador que se utilizó para obtener el certificado. Por ejemplo, para obtener y exportar un certificado de Adobe Developer desde Thawte, debe utilizar Mozilla Firefox. El certificado podrá entonces exportarse como archivo con prefijo .pfx o .p12 directamente desde la interfaz de usuario de Firefox.

Nota: las versiones de Java 1.5 y posteriores no aceptan caracteres ASCII superior en contraseñas utilizadas para proteger archivos de certificado PKCS12. Las herramientas de desarrollo de AIR utilizan Java para crear paquetes firmados de AIR. Si el certificado se exporta como archivo .p12 o .pfx, utilice únicamente caracteres ASCII normales en la contraseña.

Se puede generar un certificado con firma automática con Air Development Tool (ADT) que se utiliza para empaquetar los archivos de instalación de AIR. También pueden utilizarse algunas herramientas de terceros.

Para ver las instrucciones sobre cómo generar un certificado autofirmado, así como instrucciones para firmar un archivo de AIR, consulte AIR Developer Tool (ADT) . También se pueden exportar y firmar archivos de AIR con Flash Builder, Dreamweaver y la actualización de AIR para Flash.

El siguiente ejemplo describe cómo obtener un certificado de desarrollador de AIR de la autoridad de certificación Thawte y prepararlo para el uso con ADT.

Ejemplo: Cómo obtener un certificado de desarrollador de AIR con Thawte

Nota: este ejemplo muestra una sola de las diversas formas de obtener y preparar un certificado de firma de código para su uso. Cada entidad emisora de certificados cuenta con sus propias directivas y procedimientos.

Para adquirir un certificado de desarrollador de AIR, el sitio web de Thawte exige el uso del navegador Mozilla Firefox. La clave privada para el certificado se guarda en el almacén de claves del navegador. Asegúrese de que el almacén de claves de Firefox esté protegido con una contraseña maestra y que el ordenador mismo sea seguro desde el punto de vista físico. (Podrá exportar y eliminar el certificado y la clave privada del almacén de claves del navegador una vez finalizado el proceso de adquisición).

Como parte del proceso de inscripción para el certificado se genera un par de claves: pública y privada. La clave privada se guarda automáticamente en el almacén de claves de Firefox. Deberá utilizar el mismo ordenador y navegador para solicitar y recuperar el certificado del sitio web de Thawte.

  1. Visite el sitio web de Thawte y vaya a la página de productos para Certificados para firma de códigos .

  2. En la lista de certificados para firma de códigos, seleccione el certificado de Adobe AIR Developer.

  3. Complete el proceso de inscripción de tres pasos. Necesitará facilitar información sobre su organización, así como datos de contacto. A continuación, Thawte lleva a cabo su proceso de verificación de identidad y es posible que solicite información suplementaria. Una vez finalizada la verificación, Thawte le enviará un correo electrónico con instrucciones sobre cómo recuperar el certificado.

    Nota: para obtener más información (en inglés) sobre el tipo de documentación que se requiere, haga clic en: https://www.thawte.com/ssl-digital-certificates/free-guides-whitepapers/pdf/enroll_codesign_eng.pdf .

  4. Recupere el certificado emitido del sitio de Thawte. El certificado se guarda automáticamente en el almacén de claves de Firefox.

  5. Exporte del almacén de claves un archivo que contenga la clave privada y el certificado siguiendo los pasos que se indican a continuación:

    Nota: la clave privada y el certificado de Firefox se exportan en un formato .p12 (pfx) compatible con ADT, Flex, Flash y Dreamweaver.

    1. Abra el cuadro de diálogo Administrador de certificados de Firefox:

    2. En Windows: abra Herramientas -> Opciones -> Opciones avanzadas -> Cifrado -> Ver certificados.

    3. En Mac OS: abra Firefox -> Preferencias -> Avanzado -> Cifrado -> Ver certificados.

    4. En Linux: abra Editar -> Preferencias -> Avanzado -> Cifrado -> Ver certificados

    5. Seleccione el certificado para firma de códigos de Adobe AIR en la lista de certificados y haga clic en el botón Hacer copia .

    6. Escriba un nombre de archivo y el lugar al que se debe exportar el archivo del almacén de claves, y haga clic en Guardar .

    7. Si utilizó la contraseña maestra de Firefox, se le solicitará escribir la contraseña para el dispositivo de seguridad del software a fin de poder exportar el archivo. (Esta contraseña es de uso exclusivo en Firefox).

    8. En el cuadro de diálogo para la contraseña para la copia de seguridad del certificado , cree una contraseña para el archivo del almacén de claves.

      Importante: esta contraseña protege el archivo del almacén de claves y se necesita cuando se utiliza el archivo para firmar aplicaciones de AIR. Conviene elegir una contraseña segura.

    9. Haga clic en OK (Aceptar). Debería recibir un mensaje confirmando la creación de la contraseña para copias de seguridad. El archivo del almacén contiene la clave privada y el certificado se guarda con una extensión .p12 (en formato PKCS12).

  6. Utilice el archivo de almacén de claves exportado con ADT, Flash Builder, Flash Professional o Dreamweaver. Hay que utilizar la contraseña creada para el archivo cada vez que se firme una aplicación de AIR.

Importante: la clave privada y el certificado se siguen guardando en el almacén de claves de Firefox. Mientras que esto permite exportar otra copia del archivo del certificado, también facilita otro punto de acceso que debe protegerse para mantener la seguridad de su certificado y su clave privada.

Cambio de certificado

En algunos casos, es necesario cambiar el certificado utilizado para firmar actualizaciones de la aplicación de AIR. Entre estos casos se encuentran:

  • Renovación del certificado de firma original.

  • La actualización de un certificado con firma automática a un certificado emitido por una entidad emisora de certificados.

  • El cambio de un certificado con firma automática que va a caducar por otro.

  • El cambio de un certificado comercial a otro (por ejemplo, cuando cambia la identidad de la empresa).

Para que AIR reconozca un archivo de AIR como actualización, es necesario firmar tanto los archivos de AIR originales como de actualización con el mismo certificado, o bien, aplicar una firma de migración de certificados a la actualización. Una firma de migración es una segunda firma aplicada al paquete de AIR de actualización utilizando el certificado original. La firma de migración utiliza el certificado original, que establece que el firmante es el editor original de la aplicación.

Una vez instalado un archivo de AIR con una firma de migración, el nuevo certificado pasa a ser el certificado principal. Las actualizaciones posteriores no requieren una firma de migración. No obstante, las firmas de migración se deben aplicar tanto tiempo como sea posible a los usuarios que suelan omitir las actualizaciones.

Importante: se debe cambiar el certificado y aplicar una firma de migración a la actualización con el certificado original antes de que caduque. De lo contrario, los usuarios deben desinstalar su versión existente de la aplicación antes de instalar una nueva versión. Para AIR 1.5.3 o posterior, se puede aplicar una firma de migración utilizando un certificado caducado en un periodo de gracia de 365 días posteriores a la fecha de caducidad. Sin embargo, el certificado caducado no se puede utilizar para aplicar la firma de la aplicación principal.

Para cambiar el certificado:

  1. Cree una actualización de la aplicación.

  2. Empaquete y firme el archivo de AIR de actualización con el certificado nuevo .

  3. Vuelva a firmar el archivo de AIR con el certificado original (con el comando -migrate de ADT).

Un archivo de AIR con firma de migración es, en otros aspectos, un archivo de AIR normal. Si se instala la aplicación en un sistema que no tiene la versión original, AIR la instala de la forma habitual.

Nota: antes de AIR 1.5.3, la firma de una aplicación de AIR con un certificado renovado no siempre requería una firma de migración. Con el inicio de AIR 1.5.3, una firma de migración siempre es necesaria para los certificados renovados.

Para aplicar una firma de migración, use el Comando migrate de ADT , como se describe en Firma de una versión actualizada de una aplicación de AIR .

Nota: El comando migrate de ADT no se puede usar con aplicaciones AIR de escritorio que incluyan extensiones nativas, ya que dichas aplicaciones están empaquetadas como instaladores nativos, no como archivos .air. Para cambiar certificados de una aplicación AIR de escritorio que incluya una extensión nativa, empaquete la aplicación utilizando el Comando package de ADT con el indicador -migrate.

Cambios de la identidad de la aplicación

Antes de AIR 1.5.3, la identidad de una aplicación de AIR cambiaba cuando se instalaba una actualización firmada con una firma de migración. El cambio de identidad de una aplicación tiene varias repercusiones, entre las que se incluyen:

  • La nueva versión de la aplicación no tiene acceso a los datos que están en el almacén local cifrado existente.

  • Cambia la ubicación del directorio de almacenamiento de la aplicación. Los datos de la ubicación anterior no se copian en el nuevo directorio. (Pero la nueva aplicación puede localizar el directorio original con base en el ID del editor anterior).

  • La aplicación ya no puede abrir conexiones locales con el ID del editor anterior.

  • La cadena de identidad utilizada para acceder a una aplicación desde una página web cambia.

  • El OSID de la aplicación cambia. (El OSID se utiliza al escribir programas de instalación o desinstalación personalizados.)

Al publicar una actualización con AIR 1.5.3 o posterior, la identidad de la aplicación no puede cambiar. Los ID de editor y la aplicación original se deben especificar en el descriptor de la aplicación del archivo de AIR de actualización. De lo contrario, el nuevo paquete no se reconocerá como actualización.

Nota: al publicar una nueva aplicación de AIR con AIR 1.5.3 o posterior, no se debe especificar un ID de editor.

Terminología

Esta sección contiene un glosario de algunos de los principales términos que necesita conocer al tomar decisiones sobre cómo firmar la aplicación para su distribución pública.

Término

Descripción

Entidad emisora de certificados (AC)

Entidad de una red de infraestructura de claves públicas que interviene como tercero de confianza y que, en última instancia, certifica la identidad del propietario de una clave pública. Una AC emite certificados digitales firmados por su propia clave privada para constatar que ha verificado la identidad del titular del certificado.

Declaración de prácticas de certificación (DPC)

Plantea las prácticas y políticas de la entidad emisora de certificados respecto de la emisión y verificación de certificados. La DPC forma parte del contracto entre la AC y sus suscriptores y partes confiantes. Reseña también las políticas de verificación de identidad y el nivel de garantía que ofrecen los certificados emitidos.

Lista de revocación de certificados (LRC)

Lista de certificados emitidos que han sido revocados y en los cuales ya no se debe confiar. AIR comprueba la LRC en el momento de firmarse una aplicación de AIR y, si no hay marca de hora, nuevamente cuando se instala la aplicación.

Cadena de certificación

Secuencia de certificados en la que cada certificado de la cadena ha sido firmado por el certificado siguiente.

Certificado digital

Documento digital que contiene información acerca de la identidad del propietario, la clave pública del propietario y la identidad del propio certificado. Un certificado emitido por una autoridad de certificación está firmado a su vez por un certificado de propiedad de la AC emisora.

Firma digital

Mensaje o resumen cifrado que solo puede descifrarse con la clave pública de un par clave pública-clave privada. En una PKI la firma digital contiene un certificado digital (o más) que en última instancia llevan hasta la entidad emisora de certificados. Una firma digital sirve para validar que un mensaje (o un archivo informático) no ha sido alterado desde que se firmó (dentro de los límites de garantía que ofrezca el algoritmo criptográfico que se utilizó) y, suponiendo que se confía en la entidad emisora de certificados, para validar la identidad del firmante.

Almacén de claves

Base de datos que contiene certificados digitales y, en algunos casos, las claves privadas asociadas.

Java Cryptography Architecture (JCA)

Arquitectura de criptografía de Java: arquitectura ampliable para administrar y acceder a los almacenes de claves. Para obtener más información, consulte la guía de consulta de Java Cryptography Architecture (en inglés).

PKCS #11

Cryptographic Token Interface Standard (norma de interfaces de tokens criptográficos) de RSA Laboratories. Un almacén de claves basado en tokens de hardware.

PKCS #12

Personal Information Exchange Syntax Standard (norma para la sintaxis de intercambio de información personal) de RSA Laboratories. Un almacén de claves basado en archivo que suele contener una clave privada y su certificado digital asociado.

Clave privada

La mitad privada de un sistema criptográfico asimétrico que consta de clave pública y clave privada. La clave privada es confidencial y no debe nunca transmitirse a través de una red. Los mensajes con firma digital son cifrados con la clave privada por parte del firmante.

Clave pública

La mitad pública de un sistema criptográfico asimétrico que consta de clave pública y clave privada. La clave pública se distribuye libremente y se utiliza para descifrar los mensajes cifrados con la clave privada.

Infraestructura de claves públicas (PKI)

Infraestructura de claves públicas: sistema de confianza en el que las autoridades de certificación autentican la identidad de los propietarios de claves públicas. Los clientes de la red confían en los certificados digitales emitidos por una AC de confianza para verificar la identidad del firmante de un mensaje o archivo digital.

Marca de hora

Dato firmando digitalmente que contiene la fecha y hora en que se produjo un evento. ADT puede incluir en un paquete de AIR una marca de hora provista por un servidor de hora en conformidad con la norma RFC 3161 . Cuando la hay, AIR utiliza la marca de hora para establecer la validez de un certificado en el momento de firmar. Esto permite instalar una aplicación de AIR una vez caducado su certificado de firma.

Autoridad de marcas de hora

Autoridad que emite marcas de hora. Para que AIR la reconozca, la marca de hora debe estar en conformidad con la norma RFC 3161 y la firma de la marca de hora debe encadenarse con un certificado raíz de confianza en la máquina en que se instale la aplicación.

Certificados de iOS

Los certificados de firma de código emitidos por Apple se utilizan para firmar aplicaciones de iOS, incluyendo las desarrolladas con Adobe AIR. La aplicación de una firma utilizando un certificado de desarrollo de Apple es necesario para instalar una aplicación en los dispositivos de prueba. La aplicación de una firma utilizando un certificado de distribución es necesaria para distribuir la aplicación finalizada.

Para firmar una aplicación, ADT necesita acceder al certificado de firma de código y a la clave privada asociada. El propio archivo de certificado no incluye la clave privada. Se debe crear un almacén de claves en el formulario de un archivo de intercambio de información personal (Personal Information Exchange file) (.p12 o .pfx) que contenga el certificado y la clave privada. Consulte Conversión de un certificado de desarrollador en un archivo de almacén de claves P12 .

Generación de una solicitud de firma de certificado

Para obtener un certificado de desarrollador, puede generar una solicitud de firma de certificado para enviarlo al Portal de suministro de Apple iOS (Apple iOS Provisioning Portal).

El proceso de solicitud de firma de certificado genera un par de claves públicas y privadas. La clave privada se conserva en el equipo. Se envía la solicitud de firma que contiene la clave pública y la información de identificación a Apple, que actúa como entidad emisora de certificados. Apple firma el certificado con su propio certificado de relaciones del desarrollador en todo el mundo (World Wide Developer Relations).

Generación de una solicitud de firma de certificado en Mac OS

En Mac OS, puede utilizar la aplicación Acceso a Llaveros para generar una solicitud de firma de código. La aplicación Acceso a Llaveros se encuentra en el subdirectorio Utilidades de la carpeta Aplicaciones. Las instrucciones para generar la solicitud de firma del certificado están disponibles en el portal Apple iOS Provisioning Portal.

Generación de una solicitud de firma de certificado en Windows

Para los desarrolladores de Windows es más fácil obtener el certificado de desarrollador de iPhone directamente en un ordenador Mac. No obstante, es posible obtener un certificado también en un ordenador con Windows. En primer lugar, cree una petición de firma de certificado (archivo CSR) con OpenSSL:

  1. Instale OpenSSL en el ordenador con Windows. (Vaya a http://www.openssl.org/related/binaries.html .)

    Si lo desea, puede instalar también los archivos de Visual C++ 2008 Redistributable que se muestran en la página de descargas de Open SSL. ( NO es necesario tener Visual C++ instalado en el ordenador.)

  2. Abra una sesión de comandos de Windows y la línea de comandos para abrir el directorio bin de OpenSSL (por ejemplo c:\OpenSSL\bin\).

  3. Para crear la clave privada, introduzca lo siguiente en la línea de comandos: 

    openssl genrsa -out mykey.key 2048

    Guarde este archivo de clave privada. Lo utilizará más adelante.

    Cuando utilice OpenSSL, tenga en cuenta los mensajes de error. Si OpenSSL genera un mensaje de error, los archivos pueden seguir produciéndose. Sin embargo, dichos archivos no se podrán utilizar. Si aparecen errores, revise la sintaxis y vuelva a ejecutar el comando.

  4. Para crear el archivo CSR, introduzca lo siguiente en la línea de comandos: 

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

    Reemplace los valores de dirección de correo electrónico, CN (nombre del certificado) y C (país) por los suyos propios.

  5. Cargue el archivo CSR a Apple en el centro de desarrollo de iPhone . (Consulte “Solicitud de un certificado de desarrollador de iPhone” y “Creación de un archivo de suministro”.)

Conversión de un certificado de desarrollador en un archivo de almacén de claves P12

Para crear un almacén de claves P12, se debe combinar el certificado de desarrollador de Apple y la clave privada asociada en un solo archivo. El proceso para crear el archivo del almacén de claves depende del método utilizado para generar la solicitud de firma del certificado original y del lugar donde se almacena la clave privada.

Conversión del certificado de desarrollador de iPhone en un archivo P12 en Mac OS

Una vez descargado el certificado de iPhone de Apple, expórtelo a formato de almacén de claves P12. Para hacerlo en Mac® OS:

  1. Abra la aplicación Acceso a Llaveros (en la carpeta Aplicaciones/Utilidades).

  2. Si aún no ha añadido el certificado al Llavero, seleccione Archivo > Importar. Vaya al archivo de certificado (archivo .cer) que ha obtenido de Apple.

  3. Seleccione la categoría Llaves en Acceso a Llaveros.

  4. Seleccione la clave privada asociada a su certificado de desarrollo de iPhone.

    La clave privada se identifica mediante el certificado de desarrollador de iPhone público <Nombre> <Apellido> emparejado con ella.

  5. Presione comando y haga clic en el certificado de desarrollador de (iPhone Developer) y seleccione Export “iPhone Developer: Name...” .

  6. Guarde la clave en formato de archivo de intercambio de información personal (.p12).

  7. Se solicitará que cree una contraseña que se utilice cuando el almacén de claves se use para firmar aplicaciones o transferir la clave y el certificado de este almacén de claves a otro almacén.

Conversión de un certificado de desarrollador de Apple en un archivo P12 en Windows

Para desarrollar AIR para aplicaciones de iOS, se debe utilizar un archivo de certificado P12. Podrá generar este certificado a partir del archivo de certificado de desarrollador de iPhone de Apple cuando lo reciba de Apple.

  1. Convierta el archivo de certificador de desarrollador recibido de Apple en un archivo de certificado PEM. Ejecute la siguiente declaración en la línea de comandos desde el directorio bin de OpenSSL: 

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

  2. Si utiliza una clave privada del Llavero de un equipo Mac, conviértala en una clave PEM: 

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

  3. Ahora puede generar un archivo P12 válido a partir de la clave y de la versión PEM del certificado de desarrollador de iPhone: 

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

    Si utiliza una clave del Llavero de Mac OS, utilice la versión PEM que generó en el paso anterior. En caso contrario, utilice la clave OpenSSL generada anteriormente (en Windows).