Acceso a Llavero (Keychain Access) sigue estando en todos los Mac, y su Asistente de Certificados sigue generando solicitudes de firma de certificado. Que esa solicitud sirva para firma de código depende por completo de qué certificado esté solicitando. Para un certificado Apple Developer ID, el que le permite distribuir software para Mac fuera de la Mac App Store, Acceso a Llavero es la herramienta correcta y los pasos que siguen están vigentes. Para un certificado comercial de firma de código de una Autoridad de Certificación pública, del tipo que se usa para firmar ejecutables de Windows, instaladores, controladores y aplicaciones Java, una solicitud generada en Acceso a Llavero no se acepta desde el 1 de junio de 2023, porque la clave privada ahora debe crearse en hardware.
Primero determine cuál de los dos necesita, y luego siga la sección correspondiente.
¿Qué certificado de firma de código está obteniendo en realidad?
Ambos productos se llaman certificados de firma de código y ambos prueban quién publicó una pieza de software, pero provienen de emisores diferentes y siguen reglas distintas. Los lectores llegan a esta página porque Apple y las Autoridades de Certificación públicas usan las mismas palabras para dos cosas diferentes.
- Certificado Apple Developer ID. Emitido por Apple, bajo su propia Developer ID Certification Authority, a los miembros del Apple Developer Program. Firma aplicaciones, plug-ins y paquetes instaladores para Mac que usted distribuye por su cuenta, de modo que macOS Gatekeeper lo reconoce como un desarrollador identificado. El par de claves se genera en su Mac y permanece en su llavero de inicio de sesión, y usted crea la solicitud en Acceso a Llavero.
- Certificado de firma de código de confianza pública. Comprado a una Autoridad de Certificación pública como Sectigo, DigiCert o GlobalSign. Firma ejecutables de Windows, instaladores MSI, controladores, scripts de PowerShell y aplicaciones Java. Se rige por los Requisitos de Referencia de Firma de Código del CA/Browser Forum, que exigen que la clave privada se genere y permanezca en hardware certificado, por lo que Acceso a Llavero no tiene nada que hacer aquí.
La regla de decisión rápida: si el software que está firmando se ejecuta en macOS y lo va a distribuir fuera de la Mac App Store, necesita un certificado Developer ID. Si está firmando algo para Windows, o una aplicación Java, necesita un certificado comercial de firma de código, incluso si lo compila en un Mac. Ninguno de los dos es un certificado SSL/TLS. Si lo que realmente quiere es HTTPS en un servidor Mac, siga en su lugar cómo generar un CSR en servidores macOS.
La vía comercial: por qué el método de Llavero ya no se aplica
Desde el 1 de junio de 2023, los Requisitos de Referencia de Firma de Código del CA/Browser Forum exigen que la clave privada de todo certificado de firma de código de confianza pública, tanto estándar (OV) como de Validación Extendida (EV), se genere y almacene en un módulo criptográfico de hardware que cumpla con FIPS 140-2 Nivel 2, Common Criteria EAL4+, o un estándar equivalente, y que sea no exportable. La firma de código EV siempre requirió hardware; el cambio de 2023 extendió la misma regla a los certificados estándar.
Una clave creada por el Asistente de Certificados no supera esa prueba por diseño, por tres razones distintas:
- La clave es material de clave de software exportable. Se escribe en su llavero de inicio de sesión, y usted puede seleccionarla y exportarla como un archivo .p12. Esa portabilidad es conveniente para el desarrollo Apple y es exactamente la propiedad que el requisito de hardware existe para eliminar.
- El tamaño de clave no coincide. Los Requisitos de Referencia establecen un mínimo de RSA 3072 bits para firma de código, y el menú Tamaño de clave del Asistente de Certificados no tiene la opción de 3072.
- La solicitud lleva casi ninguna identidad. El Asistente de Certificados solo solicita un Nombre Común y direcciones de correo electrónico. No hay ningún lugar para ingresar los detalles de organización, localidad, estado o país que una Autoridad de Certificación valida para un certificado de firma de código validado por organización.
Eso deja dos formas válidas de obtener un certificado de firma de código de confianza pública, y cuál usa se decide al momento de pedirlo:
- Token más envío. La Autoridad de Certificación genera el par de claves y la solicitud en un token USB certificado de su lado, carga el certificado emitido en él, y le envía el token por correo. No hay ningún CSR que usted tenga que crear ni pegar en ningún lugar. Consulte qué método de entrega de certificado de firma de código elegir.
- Su propio token de hardware, HSM o HSM en la nube, con atestación. Usted genera la clave dentro del dispositivo, produce la solicitud ahí, y envía un archivo de atestación que demuestra que la clave se creó en hardware compatible y que no puede exportarse. Siga la guía de generación de CSR y atestación con YubiKey 5 FIPS o la guía de CSR y atestación con Luna Network Attached HSM v7.x, o la documentación propia de su proveedor de HSM.
Un cambio más que ya entró en vigor: la votación CSC-31 redujo la validez máxima de los certificados de firma de código de confianza pública de 39 meses a 460 días para los certificados emitidos a partir del 1 de marzo de 2026, por lo que las renovaciones ahora se producen aproximadamente cada 15 meses. Para tener una visión más amplia, consulte cómo generar un CSR para un certificado de firma de código y la versión de la misma guía con OpenSSL.
Genere el CSR en Acceso a Llavero para un certificado Apple Developer ID
Si ya guardó un archivo .certSigningRequest, pase directamente a cómo enviarlo en su cuenta de desarrollador.
Dos cosas que debe verificar antes de empezar. Necesita una membresía del Apple Developer Program, y Apple requiere el rol de Titular de la cuenta para crear un certificado Developer ID. También se le permite tener hasta cinco certificados Developer ID Application y cinco certificados Developer ID Installer por equipo. El portal le pide que suba una solicitud cada vez que crea un certificado, así que repita este proceso una vez por cada certificado.
Paso 1: Abra Acceso a Llavero e inicie la solicitud
Acceso a Llavero ya no está donde dicen la mayoría de los tutoriales. Hasta macOS Sonoma se encontraba en Aplicaciones > Utilidades. A partir de macOS Sequoia, Apple lo trasladó a /System/Library/CoreServices/Applications/, una carpeta del sistema que Finder no muestra al explorar Aplicaciones, por lo que buscar en Utilidades ahora no da ningún resultado. Las formas más rápidas de abrirlo son Spotlight (pulse Comando-Espacio y escriba Acceso a Llavero), o un solo comando en Terminal:
open "/System/Library/CoreServices/Applications/Keychain Access.app"Con la aplicación abierta, elija Acceso a Llavero > Asistente de Certificados > Solicitar un certificado a una autoridad de certificación en la barra de menú.
Antes de hacerlo, haga clic en un área vacía de la lista de elementos para que nada quede seleccionado. Si una clave o certificado está resaltado, el elemento de menú cambia a Solicitar un certificado a una autoridad de certificación con seguido del nombre de ese elemento, y construye la solicitud alrededor de la clave existente en lugar de crear un par nuevo. Eso es útil cuando quiere reutilizar una clave deliberadamente, y confuso cuando no.
Paso 2: Complete la ventana de Información del certificado
El Asistente de Certificados se abre en un panel titulado Información del certificado. Solicita muy poco:
- Dirección de correo electrónico del usuario: la dirección de correo electrónico de su cuenta de Apple Developer.
- Nombre común: una etiqueta para el par de claves, por ejemplo Developer ID Application Key. Este no es el nombre que terminará en el certificado. Apple construye el sujeto del certificado emitido a partir de su equipo, con el formato Developer ID Application: Nombre de su equipo (TEAMID), así que trate este campo como una referencia propia.
- Dirección de correo electrónico de la CA: déjela vacía. Solo se usa con la otra opción de entrega.
- La solicitud es: seleccione Guardada en el disco, no Enviada por correo a la CA. El portal de desarrolladores de Apple recibe un archivo subido.
Si también quiere elegir el tamaño de clave o el algoritmo, marque aquí Permitirme especificar información del par de claves. Luego haga clic en Continuar.
Paso 3: Elija los ajustes del par de claves, si lo necesita
Este panel aparece solo si marcó la casilla en el paso 2, y para un certificado Developer ID normalmente puede omitirlo. Los valores predeterminados son RSA a 2048 bits, que es lo que usan las propias instrucciones de Apple. Con RSA seleccionado, el menú Tamaño de clave ofrece 2048, 4096 y 8192 bits. El menú Algoritmo ofrece RSA y ECC, y cambiar a ECC sustituye esos tamaños por 256, 384 y 521 bits. Deje el algoritmo en RSA a menos que el servicio en el que se está inscribiendo pida específicamente una clave de curva elíptica.
Versiones anteriores de esta guía le indicaban seleccionar al menos 3072 bits en este punto. Esa cifra es el mínimo del CA/Browser Forum para certificados de firma de código comerciales. No se aplica a Developer ID, y no se ofrece en este menú, así que no hay nada que seleccionar. Haga clic en Continuar.
Paso 4: Guarde la solicitud y compruebe qué contiene
Elija dónde guardar el archivo y haga clic en Guardar. Obtendrá un archivo con la extensión .certSigningRequest, y el Asistente de Certificados también coloca el par de claves correspondiente en su llavero de inicio de sesión. El archivo en sí es texto PEM ordinario, así que puede abrirlo en TextEdit y leerlo, aunque el bloque codificado no le dirá mucho por sí solo.
Para confirmar los detalles antes de subirlo, decodifique la solicitud en Terminal. Esto funciona con el comando openssl ya presente en macOS, que en realidad es LibreSSL en lugar de OpenSSL propiamente dicho, así que no hay nada que instalar:
openssl req -noout -text -in CertificateSigningRequest.certSigningRequestVerifique tres cosas en la salida: la línea Subject muestra el Nombre Común y la dirección de correo electrónico que escribió, la línea de la clave pública indica 2048 bit (o el tamaño que haya elegido), y el algoritmo de firma es SHA-256. Si prefiere no usar Terminal, pegue el contenido del archivo en nuestro decodificador de CSR para leer los mismos campos.
Paso 5: Envíe la solicitud e instale el certificado
Inicie sesión en su cuenta de Apple Developer y abra Certificates, Identifiers & Profiles. Haga clic en Certificates en la barra lateral, luego en el botón de agregar, y en Software seleccione Developer ID. Elija el tipo que necesita:
- Developer ID Application firma una aplicación, plug-in o paquete para Mac.
- Developer ID Installer firma un paquete instalador para Mac que contiene su aplicación firmada.
Haga clic en Continue, luego en Choose File, seleccione su archivo .certSigningRequest, haga clic de nuevo en Continue, y haga clic en Download. Apple devuelve un archivo de certificado con extensión .cer. Haga doble clic en él para instalarlo, y aparecerá en Acceso a Llavero bajo Mis certificados, emparejado con la clave privada creada en el paso 4.
Firmar con el certificado es solo la mitad de lo que verifica macOS. Gatekeeper espera que el software descargado fuera de la Mac App Store esté firmado con un certificado Developer ID y notarizado por Apple, así que envíe la compilación firmada para su notarización antes de distribuirla. La notarización no sustituye a la firma, se ejecuta sobre ella.
Localice la clave privada y haga una copia de seguridad
El certificado no vale nada sin la clave privada que generó el Asistente de Certificados, y esa clave existe en un único lugar hasta que usted la copie. Para encontrarla, abra Acceso a Llavero, seleccione el llavero login, luego la categoría Claves, y busque el Nombre Común que escribió en el paso 2. Verá dos entradas bajo ese nombre, una clave pública y una clave privada. Tenga en cuenta que la clave pública no es su CSR: el CSR es el archivo .certSigningRequest que guardó en el disco.
Una vez instalado el archivo .cer, busque en cambio bajo Mis certificados. Ahí el certificado y su clave privada aparecen como una sola entrada, que es la identidad de firma que usan codesign, Xcode y sus scripts de compilación. Para mover esa identidad a otro Mac o a un servidor de compilación, haga clic derecho en la entrada y elija Exportar, lo que produce un archivo .p12 protegido por una contraseña que usted establece. Guarde ese archivo de la misma manera en que guardaría cualquier clave de firma, porque cualquiera que lo tenga junto con la contraseña puede firmar software en su nombre.
Haga una copia de seguridad antes de necesitarla. Los certificados Developer ID son válidos durante cinco años y no pueden renovarse: cuando uno caduca, se crea un reemplazo. Si pierde la clave privada, el certificado nunca podrá volver a usarse y tendrá que crear otro, lo que consume una de sus cinco ranuras de Developer ID Application o cinco de Developer ID Installer. Resista la tentación de revocar el que quedó inservible solo por orden. Apple es explícito en que una aplicación firmada con un certificado Developer ID revocado no se instalará, y no se abrirá para un usuario que ya la tenga, así que revocarlo rompería todas las copias que ya circulan. Revoque solo si la clave fue realmente robada, y prepárese para esa ruptura.
Una nota de mantenimiento para quien haya llegado aquí buscando un certificado comercial: si ya generó un par de claves en Acceso a Llavero para un pedido a una Autoridad de Certificación pública, no podrá usarse y ninguna CA lo aceptará. No pasa nada si lo deja como está, pero hay poca razón para mantener material de clave de firma exportable en un llavero. Seleccione tanto la clave pública como la privada bajo Claves y elimínelas, y luego haga el pedido a través de un token o un HSM en su lugar.
Preguntas frecuentes
Para un certificado Apple Developer ID, sí, y es el método que documenta Apple. Para un certificado de firma de código de confianza pública de una Autoridad de Certificación comercial, no. Desde el 1 de junio de 2023, esas claves privadas deben generarse y almacenarse en un módulo criptográfico de hardware que cumpla con FIPS 140-2 Nivel 2, Common Criteria EAL4+, o un estándar equivalente, y una clave creada en Acceso a Llavero es material de clave de software exportable.
En /System/Library/CoreServices/Applications/. Apple lo trasladó allí en macOS Sequoia, por lo que ya no está en Aplicaciones > Utilidades y no aparece al explorar Aplicaciones en Finder. Ábralo con Spotlight, o ejecute open "/System/Library/CoreServices/Applications/Keychain Access.app" en Terminal. La aplicación Contraseñas independiente introducida junto con él gestiona solo contraseñas, no certificados ni claves.
RSA 2048 bits para un certificado Developer ID, que es el valor predeterminado, así que puede dejar sin marcar Permitirme especificar información del par de claves. Con RSA seleccionado, el menú Tamaño de clave ofrece 2048, 4096 y 8192 bits, y cambiar a ECC los sustituye por 256, 384 y 521 bits. En ningún ajuste ofrece 3072 bits, que es el mínimo del CA/Browser Forum para certificados comerciales de firma de código, y esa es una de varias razones por las que esta vía no encaja con un pedido comercial.
Porque la solicitud que construye lleva solo un Nombre Común y direcciones de correo electrónico. Apple no necesita más: completa el sujeto de un certificado Developer ID a partir de su cuenta de desarrollador. Una Autoridad de Certificación comercial sí necesita detalles de la organización, y los valida contra registros públicos, lo cual es otra razón por la que una solicitud de Llavero no tiene la forma adecuada para ese pedido.
No. La regla de hardware del CA/Browser Forum se aplica a los certificados de firma de código de confianza pública emitidos por Autoridades de Certificación comerciales. Los certificados Developer ID los emite la propia autoridad de certificación de Apple a los miembros del Apple Developer Program, y la clave se genera en su llavero de inicio de sesión mediante el Asistente de Certificados, tal como se describe arriba.
Genere uno para cada uno. El portal de desarrolladores le pide que suba una solicitud de firma de certificado en cada creación de certificado, y dar a cada identidad su propio par de claves significa que reemplazar o revocar una de ellas deja intacto el software firmado con la otra. Dé a cada solicitud un Nombre Común que pueda distinguir más adelante en Acceso a Llavero.
Revise la categoría Claves del llavero login, buscando el Nombre Común que escribió en lugar del nombre del archivo. Si genuinamente no está, las causas habituales son que el par de claves se creó en otro Mac o bajo otra cuenta de usuario, que el elemento del llavero se eliminó, o que la solicitud se construyó a partir de una clave existente con la variante del elemento de menú Solicitar un certificado a una autoridad de certificación con. Sin la clave privada la solicitud no se puede usar, así que genere una nueva.
Los certificados de firma de código de confianza pública emitidos a partir del 1 de marzo de 2026 tienen un límite de 460 días, reducido de 39 meses por la votación CSC-31 del CA/Browser Forum. Los certificados Apple Developer ID son válidos durante cinco años y se reemplazan en lugar de renovarse. En ambos casos, el software que firmó mientras el certificado era válido sigue funcionando después de que caduque, siempre que la firma tenga sello de tiempo. Apple aplica una excepción: verifica el certificado Developer ID Installer en el momento en que se ejecuta un paquete instalador, así que un .pkg debe volver a firmarse una vez que ese certificado caduque, aunque la aplicación que contiene no se vea afectada.
Para lecturas relacionadas, consulte nuestros tutoriales de firma de código, las otras formas de generar un CSR, y cómo firmar un archivo EXE usando un certificado de firma de código.
Ahorre un 10% en certificados SSL al realizar su pedido hoy mismo.
Emisión rápida, cifrado potente, 99,99% de confianza del navegador, asistencia dedicada y garantía de devolución del dinero en 25 días. Código del cupón: SAVE10
