objective c - Colisiones de CodeSign entre Developer y Enterprise Distribution

objective-c ios

Question

Mi empresa utiliza una máquina de compilación (una Mac Mini) como nodo CI para crear nuestra aplicación iOS. Actualmente construimos un Ad-Hoc y una configuración de App Store en el mini. Recientemente nos inscribimos en el Programa Enterprise y también queremos comenzar a construir una configuración Enterprise. Sin embargo, nuestro proceso de compilación ahora falla, porque ahora tenemos dos certificados llamados "iPhone Distribution: Widget Corporation". Uno es el certificado de distribución para AdHoc / AppStore, y uno es para Enterprise (Apple lo llama In-House).

He intentado modificar los llaveros de los minis para que un certificado esté en el llavero de inicio de sesión y otro en un nuevo llavero llamado "empresa", pero esto simplemente cambió el error desde el inicio de la compilación:

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

hasta el final de la construcción:

iPhone Distribution: Widget Corporation: ambiguous (matches "iPhone Distribution: Widget Corporation" in /Users/hudson.admin/Library/Keychains/login.keychain and "iPhone Distribution: Widget Corporation" in /Users/hudson.admin/Library/Keychains/enterprise.keychain)

Mi pregunta es si existe o no una manera de aislar adecuadamente los dos certificados para poder crear versiones Ad-Hoc, App Store e In-House de la aplicación en la misma máquina. La única solución posible que todavía no he probado es agrupar los certificados junto con la fuente y usar la security para agregar y eliminar los certificados cuando los necesite; Claramente esa solución no es muy bonita y plantea riesgos de seguridad.

¿Algunas ideas?

Answer 1

Después de discutir con el Soporte Técnico para Desarrolladores de Apple, recomendaron crear llaveros separados para albergar los diferentes certificados y luego pasar el argumento de --keychain filename en el paso de codesign para apuntar al archivo apropiado. Puede pasar este argumento a Xcode o xcodebuild usando la opción OTHER_CODE_SIGN_FLAGS . p.ej:

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

Además, después de crear un nuevo llavero, parece que se reinicia el bloqueo después de 5 minutos; es posible que desee cambiarlo si tiene versiones que demoran un tiempo.

Answer 2

Después de hablar con el equipo de xcode en WWDC, sugirieron una solución mucho más simple: que podría solicitar que mi certificado de empresa se cambie de nombre para que no haya un conflicto.

Para hacer esto, comuníquese con los Servicios del desarrollador haciendo clic en el enlace "Administrar su cuenta" en la página de contacto del desarrollador y luego seleccione "iOS Provisioning Portal" como el tema. Hicieron esto por mí dentro de un día después de preguntar.

Esto es mucho, mucho más simple que cualquier otra forma. Ahora tengo ambos conjuntos de certificados en mi llavero, y puedo complacerlos para la distribución de la appstore o la empresa sin hacer nada más que seleccionar la entidad correcta para codificar.

Answer 3

He tenido muchos problemas con esto. Probablemente, la mejor solución es simplemente pedirle a Apple que cambie el nombre de su certificado, pero si no quiere lidiar con eso, utilicé una solución diferente. Tengo una carpeta donde exporté los certificados normales y los certificados de empresa. Luego puede eliminar el certificado que no está utilizando e importar el otro. Tal vez esto sea más complicado, pero generalmente solo distribuyo aplicaciones en la empresa, por lo que no es tanto problema.

Por cierto, lo que hago para eliminar un certificado es seleccionar el filtro de certificados, que luego muestra la clave privada asociada, y luego elimino tanto el certificado como la clave. Si borro solo el certificado Xcode lo sigue creando de nuevo.

Answer 4

Otra forma que me ayudó es dar la identidad de firma como un hash SHA1 a codesign. Pasos:

1. Encuentre el hash SHA1 en el acceso al llavero del certificado necesario
2. Compare el hash SHA1 con el devuelto por: security find-identity -v -p codesigning
3. Use el SHA1 correcto del paso 2 para codesign: codesign -s "SHA1_FROM_STEP2" ...

Answer 5

Para elaborar la respuesta de homer_simpson: es posible calcular SHA1 de su archivo .p12 directamente (sin usar llamadas de security ), y luego xcrun el resultado a codesign o xcrun . Aquí hay un extracto de mi guión autobuild:

# get SHA1 of .p12 file and pass it to PackageApplication to prevent ambiguity in cert selection
# sample output of openssl: SHA1 Fingerprint=14:B0:58:D1:F9:1D:A5:74:0A:AA:BE:B9:F2:7A:7E:AD:58:82:A2:25
# fingerprint (everything after =) is extracted with cut, and : are removed with sed

# ${IDENTITY} is a variable that contains path to your .p12 file. passphrase is empty in this case.
P12_SHA=$(openssl pkcs12 -in "${IDENTITY}" -nodes -passin pass: | openssl x509 -noout -fingerprint -sha1 | cut -d = -f 2 | sed -e ''s/://g'')

/usr/bin/xcrun -sdk iphoneos PackageApplication -s "${P12_SHA}" ...