El comando Xcode / usr / bin / codesign falló con el código de salida 1: errSecInternalComponent


105

Estoy tratando de agregar un nuevo perfil de aprovisionamiento a mi Xcode para probar una aplicación en el dispositivo. Estos son los pasos que seguí:

  1. Eliminó todos los certificados y perfiles de aprovisionamiento

  2. Crear / Agregar certificado de desarrollo de IOS

  3. Agregar mi dispositivo IOS en línea

  4. Crear perfil de aprovisionamiento de IOS

  5. Agregar perfil de aprovisionamiento de IOS

  6. Aplicación limpia

  7. Crear y ejecutar la aplicación

  8. Establecer perfil de aprovisionamiento y diseño de código en la configuración de compilación

  9. Muchas búsquedas en Google> sin éxito

Aquí está el error que obtengo:

CSSM_SignData returned: 800108E6
/Users/alexpelletier/Library/Developer/Xcode/DerivedData/MyExpense-efnqzvoqwngzcmazaotyalepiice/Build/Products/Debug-iphoneos/MyExpense.app:     errSecInternalComponent
Command /usr/bin/codesign failed with exit code 1

1
El error proviene de una falta de coincidencia en la configuración del perfil de aprovisionamiento y los certificados y el ID del paquete. Asegúrese de que su PP, ID de paquete y certificados estén configurados correctamente y asignados correctamente en itunes connect y en la aplicación.
Alex Pelletier

1
Encontré este problema al pasar de Xcode 11.2.1 a 11.3 durante la firma de código de los marcos creados por mí. No se incluyeron perfiles de aprovisionamiento. La respuesta de Mohit Man lo ha aclarado.
Daniel Zhang

Esto sucede si está utilizando SSH y codeign no tiene permitido el acceso a la clave privada en Keychain. Para comprobar esto, busque la clave en Llavero, haga clic derecho y seleccione "Obtener información", cambie a "Control de acceso" y vea si la aplicación 'codeign' está en la lista de "permitir siempre el acceso". Vea este comentario github.com/electron-userland/electron-builder/issues/… Lo que hice fue ejecutar los scripts una vez desde la GUI y hacer clic en "Permitir siempre" para el acceso de la clave, luego comenzó a funcionar.
ArticIceJuice

Respuestas:


240

Abra Acceso a Llaveros , luego en el menú Archivo seleccione Bloquear Todos los Llaveros .

Luego regrese a Xcode y limpie y reconstruya. Le pedirá su contraseña nuevamente para desbloquear el llavero.

Después de esto, suponiendo que no tenga otros problemas de compilación, ¡tendrá éxito!


7
¡Increíble que este tonto bloqueo y desbloqueo ayude! Gracias
Josip B.

8
Esta debería ser la respuesta aceptada. ¡Mucho más cuerdo que un reinicio!
yonix

3
También funcionó para mí. Crea una apk para Android 30 segundos, crea una aplicación para iOS .. 2hs.
Gabe

1
¡¿En serio WTF ?! ¡Gracias!
Peter N Lewis

1
@FredericP Para mí, recientemente había cambiado mi contraseña. Así que hubo cierta interacción entre la última vez que xcode desbloqueó el llavero y la contraseña utilizada para hacerlo.
sherrellbc

77

Parece un error en el mecanismo de firma de código, reiniciar tu Mac debería resolver el problema


caso diferente, pero mensaje de error similar - reiniciar funcionó.
Mikus

Casi cuatro años después, ¡y todavía funciona! Olvidé la regla de oro: "¡Si tienes dudas, reinicia!"
Alan

2
Si está esperando una solución menos destructiva, consulte la respuesta de Mohit Manhas a continuación
yonix

no me ayudó
Anoop Vaidya

70

Esto ocurre cuando el llavero de inicio de sesión está bloqueado. Para desbloquear el llavero de inicio de sesión, ejecute:

security unlock-keychain login.keychain

Si su llavero está protegido con contraseña, especifique la contraseña usando la -popción.

Luego intente nuevamente la operación de construcción o firma de código. El código de error en cuestión se describe en los documentos de Apple como un error interno, por lo que es muy posible que esto también ocurra en otros casos.


1
Desafortunadamente, esta solución parece completamente circular: ejecutar el comando anterior requiere que ingrese la contraseña, que obviamente no es posible en una sesión no interactiva (como cuando se ejecuta a través de un agente de CI como Jenkins).
Konrad Rudolph

Ese es un buen punto, como usted dice, esto no es apropiado para una sesión no interactiva como un bot de CI. Es útil cuando se ejecutan compilaciones remotas en una sesión de línea de comandos (por ejemplo, a través de ssh).
cbracken

3
Tuvimos un problema similar en Jenkins, y además de lo que se menciona en el comando anterior, tuvimos que pasar la contraseña como argumento al comando, así que hicimos "security unlock-keychain -p $ KeychainPassword <login-keychain>", donde puede almacenar fácilmente KeychainPaasword en Jenkins de forma segura.
Mohit Tater

1
No puedo agradecerles lo suficiente por esta publicación. ¡He pasado unos días tratando de averiguar por qué codesignestaba fallando y este es el comando mágico que me salvó!
Dimu4

32

Tuvo el mismo problema en High Sierra/ Xcode 9.4.1, todos los intentos de iniciar sesión terminaron enerrSecInternalComponent

    • Ir a Acceso a llaveros
    • Ir al llavero de inicio de sesión
    • Seleccione la categoría "Mis certificados"
    • Busque el certificado con el que está firmando y expándalo para ver la clave.
    • Haga doble clic en la clave
    • Vaya a la pestaña "Control de acceso".
    • Actualice el control de acceso clave a "Permitir que todas las aplicaciones accedan a este elemento"

Alternativamente:

ejecutar el comando codesign en el terminal mac y "Permitir siempre" / usr / bin / codesign acceso a la clave

  1. Si intenta iniciar sesión desde ssh / CI, también debe ejecutar

    security unlock-keychain login.keychain

    antes de intentar firmar el paquete de aplicaciones


¿Puedes dar más detalles sobre "actualizar el control de acceso clave a" Permitir que todas las aplicaciones accedan a este elemento "? No tengo idea de lo que eso significa.
Jon McClung

2
@JonMcClung Abra el acceso al llavero, vaya al llavero de inicio de sesión: mis certificados. Busque el certificado con el que está firmando, amplíelo para ver la clave. Haga doble clic en la clave y debería ver la pestaña "Control de acceso". Cambiar para permitir está ahí
Equilibrium

5
@KonradRudolph security unlock-keychain -p <password> login.keychainde CI.
Equilibrium

1
@KonradRudolph no es necesario proporcionar una contraseña para el desbloqueo de seguridad del llavero si permitió que codesign acceda a una clave privada. Basta con dejar una cadena vacía como contraseña.
Kamil Szostakowski

1
@KonradRudolph probablemente aún no sea ideal, pero podría mover ese comando de desbloqueo para ~/.bash_profileque el llavero se desbloquee al iniciar el cliente SSH, pero no necesita hacer referencia a él desde su script de CI
sschilli

17

Me encontré con el mismo problema, reinicio mi macOS y funciona.

En China, tenemos un dicho entre desarrolladores:

Pequeños problemas, solo reinicie Grandes problemas, debería reinstalar.

¡A veces, el dicho anterior te ayudará mucho!


7
Tenemos un dicho en Estados Unidos: 'Nunca reinicie hardware antiguo'
Brant

@Brant ¿Por qué tienes este dicho? Es interesante.
ifeegoo

Solo bromeaba, pero tuvimos un problema similar y finalmente recurrimos a reiniciar un servidor antiguo.
Brant

1
@ifeegoo Los servidores antiguos pueden tener problemas para reiniciar (¿tal vez el sistema operativo se actualizó? ¿Quizás alguien rompió los scripts de inicio?) o necesitan algún procedimiento de inicio manual que nadie que esté disponible conozca. No puedes saberlo antes de intentarlo. Quizás la rom de la BIOS se había estropeado. Es solo una de esas cosas que no deberían ser un problema en un entorno bien mantenido, pero en realidad no lo sabe antes de intentarlo y prefiere no intentarlo.
Lassi Kinnunen

1
@LassiKinnunen Tienes razón, somos desarrolladores móviles para Android e iOS, así que este tipo de situaciones no se preocupan por los servidores. Los servidores son realmente peligrosos, no es situable.
ifeegoo

8

En caso de que ayude a alguien más, encontré un errSecInternalComponenterror concodesign porque lo estaba ejecutando en una sesión ssh en mi máquina macOS. Ejecutar el mismo comando desde una ventana de terminal en la máquina macOS funcionó.

Presumiblemente esto se debe a codesign necesita acceso a la clave privada desde el llavero de inicio de sesión.

La ejecución security unlock-keychain login.keychain(como se explica en la respuesta de cbracken ) desde la misma sesión también debería funcionar.


Esto es muy extraño, incluso la ejecución del comando de desbloqueo del llavero parece fallar silenciosamente porque el signo de código aún no funciona. Pero ejecutar los mismos comandos usando el escritorio remoto (en lugar de SSH) funciona bien.
Máximo

2

Si intenta iniciar sesión desde el comando ssh run:

security unlock-keychain login.keychain

antes de intentar firmar el paquete de aplicaciones

o desde UI

Actualice el control de acceso clave a "Permitir que todas las aplicaciones accedan a este elemento"

Gracias a @Equilibrium y @Jon McClung


2

Tuve el mismo problema Descubrí que el problema es con el código que firma la aplicación.

Opened the developer account and accepted the updated agreement and it worked.  

ingrese la descripción de la imagen aquí


2

Corrí security unlock-keychain login.keychainy mi contraseña de inicio de sesión no funcionó. Así que reinicié, y luego simplemente ejecuté Xcode nuevamente y funcionó. Ejecutar el comando también funciona. Extraño problema.


2

Como señaló @Equilibrium en uno de los comentarios, si está en la línea de comando env. como Jenkins (mi caso), es posible que deba pasar la contraseña al comando de desbloqueo de seguridad mencionado en las soluciones.

Entonces, en lugar de usar,

security unlock-keychain login.keychain

utilizar:

security unlock-keychain -p <login-keychain-password> <path-to-login-keychain>

donde el llavero de ruta para iniciar sesión puede ser $ HOME / Library / Keychains / login.keychain (mi caso) o simplemente iniciar sesión.keychain


Su respuesta se basa en la respuesta de @equilibrium, pero la concebiré. En Bamboo CI , ayudé a controlar la seguridad unlock-keychain -p {account-password} login.keychain
A.Kant

2

para cualquiera que haya encontrado este problema de jenkins y ssh:

alta posibilidad de que no haya otorgado acceso a la clave privada en el llavero, lo intenté pero no estoy seguro de por qué todos estos no funcionan:

  1. archivo .p12 de importación de seguridad con -A o -T / usr / bin / codesign
  2. seguridad set-key-partition-list -S apple-tool:, apple:, codeign: -s -k # {contraseña} # {keychainPath}
  3. cambie todos los perfiles de aprovisionamiento a [UUID] .mobileprovision y cópielos en '~ / Library / MobileDevice / Provisioning \ Profiles' en el servidor jenkins
  4. limpiar los datos derivados y reiniciar el servidor jenkins
  5. asegúrese de que el llavero predeterminado sea llavero de inicio de sesión y desbloquéelo.

finalmente resuelto por:

1.ssh [usuario] @ [jenkinsServerIP] -L 5900: localhost: 5900, inicie sesión en el servidor jenkins

2.abra 'vnc: // localhost'

esto lanzará una pantalla remota, si su servidor jenkins lo permite ...

luego abra keychain.app para otorgar acceso de / usr / bin / codesign a la clave privada

buena suerte


1

Pruébelo una vez usando la terminal mac pero no desde la sesión ssh

security unlock-keychain login.keychain

Y elija permitir siempre en el cuadro de diálogo solicitado. Y luego podría xcodebuild en la sesión remota.


1

Al hacer clic con el botón derecho en la clave privada asociada con el certificado de firma de código en el llavero, y luego hacer clic en 'permitir todas las aplicaciones' en lugar de confiar en un mensaje, lo solucionó, ya que la compilación se estaba realizando a través de ssh.


0

Tuve que:

1) eliminar el certificado asociado al proyecto

2) Vuelva al Xcode y revoque el certificado de la aplicación

3) El Xcode requiere un nuevo certificado

4) Bloquear todas las llaves

5) Limpiar el proyecto

6) Reconstruir

Eso es. Espero que ayude a alguien.


0

Los métodos anteriores son inútiles para mí.

Lo resolví por:

  1. Acceso abierto al llavero.
  2. Haga clic en Menú de inicio de sesión.
  3. Elimina todos los certificados personales.
  4. Limpiar el proyecto.
  5. Reconstruir.

Eso es. Espero que ayude a alguien.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.