Developer ID Certification Authority vence el 1 de febrero de 2027

Apple anunció el 1 de octubre de 2026 que la Developer ID Certification Authority original vence el 1 de febrero de 2027 y que, a partir de esa fecha, los paquetes de instalación firmados con un certificado emitido por ella “will no longer install” (ya no se instalarán). Las apps notarizadas se salvan: “Previously signed and notarized Mac software (with a secure timestamp) will keep working.” (el software para Mac firmado y notarizado previamente, con una marca de tiempo segura, seguirá funcionando).¹ La autoridad de reemplazo, G2, emite certificados desde el 27 de enero de 2022, y Apple siguió ofreciendo la original a los equipos con versiones antiguas de Xcode, así que un equipo puede tener un certificado de cada una.²³ La prueba de Apple es la Organizational Unit (unidad organizativa) en el nombre del emisor del certificado, no la fecha de vencimiento.

A continuación encontrarás los comandos que la leen desde un llavero, un paquete y una app; lo que imprimen para las 66 apps Developer ID y los cuatro instaladores de mi propia Mac, donde 49 apps y los cuatro instaladores encadenan a la autoridad que vence; una frase del aviso de Apple con la que no coinciden los certificados que puedo inspeccionar; y el orden en que yo volvería a firmar.⁴

TL;DR

• La fecha. El certificado de la autoridad original termina a las 22:12:15 UTC del 1 de febrero de 2027, quince años exactos, al segundo, después de su inicio. Apple: “Certificates issued by this authority will stop working on that date.” (los certificados emitidos por esta autoridad dejarán de funcionar en esa fecha).¹⁴
• Los paquetes se detienen, las apps notarizadas no. “.pkg files signed with an affected certificate will no longer install” (los archivos .pkg firmados con un certificado afectado ya no se instalarán), mientras que el software notarizado con marca de tiempo segura “will keep working” (seguirá funcionando).¹
• Lee el emisor. La Organizational Unit del emisor es “Apple Certification Authority” en un certificado de la autoridad original y “G2” en uno de la autoridad actual. Apple dice que la fecha de vencimiento “doesn’t prove which authority issued a certificate” (no demuestra qué autoridad emitió un certificado).²
• La muestra de una Mac. Los cuatro instaladores firmados con Developer ID de mi carpeta Descargas encadenan a la autoridad original, y el más reciente se firmó el 29 de diciembre de 2025. De 66 apps Developer ID en mi carpeta Aplicaciones, 49 encadenan a ella y 17 a G2.⁴
• Hasta ahora, el vencimiento no ha detenido el software con marca de tiempo. Seis de las 49 apps están firmadas con certificados que vencieron entre 2022 y mayo de 2026, y un instalador con un certificado que venció en 2017. Gatekeeper acepta los siete hoy. El aviso de Apple dice que el vencimiento de la propia autoridad pone fin a eso para los paquetes.¹⁴
• Una discrepancia. Apple dice que los certificados G2 “expire annually” (vencen cada año). Los 12 certificados G2 de mis apps instaladas, y el mío propio de mayo de 2026, duran cinco años. Ninguna de las dos páginas dice cuándo empezaron los plazos de un año.¹²⁴

¿Qué anunció Apple?

El aviso es breve. Empieza así: “The original Developer ID Certification Authority (Sub-CA) expires on February 1, 2027. Certificates issued by this authority will stop working on that date.” (la Developer ID Certification Authority original, o Sub-CA, vence el 1 de febrero de 2027; los certificados emitidos por esta autoridad dejarán de funcionar en esa fecha).¹ Siguen tres pasos: comprobar si estás afectado, crear un certificado nuevo y volver a firmar. El tercer paso depende de lo que distribuyas:

• Paquetes de instalación. “Starting February 1, 2027, .pkg files signed with an affected certificate will no longer install. Re-sign all packages with your new certificate before this date.” (a partir del 1 de febrero de 2027, los archivos .pkg firmados con un certificado afectado ya no se instalarán; vuelve a firmar todos los paquetes con tu certificado nuevo antes de esa fecha).
• Apps para Mac. “Previously signed and notarized Mac software (with a secure timestamp) will keep working” (el software para Mac firmado y notarizado previamente, con marca de tiempo segura, seguirá funcionando), sin que haga falta hacer nada, y “For future updates, sign with your new certificate and include a secure timestamp for notarization.” (para futuras actualizaciones, firma con tu certificado nuevo e incluye una marca de tiempo segura para la notarización).¹

La página de ayuda a la que enlaza el aviso describe el efecto sobre la firma: “After that date, certificates issued from the original authority can no longer be used for signing and must be replaced with certificates from the current Developer ID Certification Authority (G2).” (después de esa fecha, los certificados emitidos por la autoridad original ya no pueden usarse para firmar y deben reemplazarse por certificados de la Developer ID Certification Authority actual, G2). También indica “Required role: Account Holder.” (rol requerido: Account Holder).²

La división entre apps y paquetes se parece bastante a la orientación que Apple mantiene sobre certificados vencidos. Para las apps, la página de ayuda de Developer ID de Apple dice: “As long as your Developer ID certificate was valid when you compiled your app, then users can download and run your app, even after the expiration date of the certificate.” (mientras tu certificado Developer ID fuera válido cuando compilaste tu app, los usuarios pueden descargarla y ejecutarla, incluso después de la fecha de vencimiento del certificado). Para los instaladores, las páginas de Apple no coinciden, ni siquiera consigo mismas. La misma página de ayuda dice “Your installer package will only launch if your Developer ID Installer certificate is valid.” (tu paquete de instalación solo se abrirá si tu certificado Developer ID Installer es válido). La entrada de Developer ID Installer en el resumen de certificados tira en ambas direcciones: los usuarios “can still install packages that were signed with this certificate as long as the package includes a trusted timestamp” (todavía pueden instalar paquetes firmados con este certificado siempre que el paquete incluya una marca de tiempo de confianza), pero dos frases después “new installations won’t be possible until you have re-signed your installer package with a valid Developer ID Installer certificate.” (no serán posibles nuevas instalaciones hasta que vuelvas a firmar tu paquete de instalación con un certificado Developer ID Installer válido).⁵ El aviso del 1 de octubre no concede a los paquetes ninguna excepción por marca de tiempo.

El aviso habla solo de instalar. No dice qué pasa con el software ya instalado a partir de un paquete afectado, ni si las instalaciones enviadas mediante gestión de dispositivos o ejecutadas con el comando installer reciben el mismo trato que un paquete que abre un usuario. Tampoco menciona las imágenes de disco firmadas. Sobre el primer punto, la entrada del resumen para un certificado de instalador vencido dice “Previously installed apps will continue to run.” (las apps instaladas previamente seguirán ejecutándose).¹⁵

¿Por qué hay dos autoridades?

Un certificado no puede durar más que la autoridad que lo emitió. La página de soporte de Apple de 2022 lo plantea como regla: “Certificates cannot be issued with a validity period that extends past the intermediate certificate’s expiration date.” (no se pueden emitir certificados con un periodo de validez que se extienda más allá de la fecha de vencimiento del certificado intermedio).³ Todos los certificados Developer ID anteriores a 2022 que encuentro duran cinco años, así que desde febrero de 2022 la autoridad original, a la que le quedaban cinco años, ya no podía emitir uno de plazo completo. La respuesta de Apple fue una segunda autoridad: “Starting January 27, 2022, the digital certificates you use to sign your software and installer packages on macOS will be issued from the new Developer ID intermediate certificate that expires on September 16, 2031.” (a partir del 27 de enero de 2022, los certificados digitales que usas para firmar tu software y tus paquetes de instalación en macOS se emitirán desde el nuevo certificado intermedio Developer ID, que vence el 16 de septiembre de 2031). (El certificado en sí termina el 17 de septiembre de 2031 a las 00:00:00 GMT, que en la hora del Pacífico todavía es 16 de septiembre).³⁴

La original siguió disponible. Para los equipos “running Xcode 11.4 or earlier” (que usan Xcode 11.4 o anterior), Apple escribió que “the Apple Developer website will continue to offer Developer ID certificates associated with the original intermediate certificate. Newly issued certificates from this intermediate certificate will be valid for less than five years” (el sitio Apple Developer seguirá ofreciendo certificados Developer ID asociados al certificado intermedio original; los certificados emitidos desde este intermedio serán válidos por menos de cinco años), una opción que “will be available for at least one year, starting January 27, 2022.” (estará disponible durante al menos un año, a partir del 27 de enero de 2022).³

Los certificados de mi Mac muestran las dos mitades de esa historia. Las 49 apps que encadenan a la autoridad original llevan 27 certificados de firma distintos. Los cinco emitidos antes de febrero de 2022 duran cinco años cada uno. Los 22 emitidos a partir del 8 de febrero de 2022 terminan todos en el mismo segundo, las 22:12:15 UTC del 1 de febrero de 2027, que es el último segundo de la propia autoridad, y el más reciente de ellos se emitió el 15 de enero de 2026. La autoridad original seguía emitiendo certificados casi cuatro años después de la llegada de G2, cada uno más corto que el anterior.⁴

¿Cómo sé qué autoridad emitió mi certificado?

La página de ayuda de Apple empieza en el portal de desarrolladores: “Any certificates expiring on or before February 1, 2027, are likely affected. However, the expiration date alone doesn’t prove which authority issued a certificate.” (cualquier certificado que venza el 1 de febrero de 2027 o antes probablemente esté afectado; no obstante, la fecha de vencimiento por sí sola no demuestra qué autoridad emitió un certificado). La razón que da: “A team can hold a certificate from each authority with identical names, such as the same Developer ID Installer entry twice, differing only in expiration date.” (un equipo puede tener un certificado de cada autoridad con nombres idénticos, como la misma entrada Developer ID Installer dos veces, que solo se diferencian en la fecha de vencimiento). La prueba de Apple está en Keychain Access: selecciona el certificado, “expand the Issuer Name field, and review the Organizational Unit field” (expande el campo Issuer Name y revisa el campo Organizational Unit). “Apple Certification Authority” significa “The certificate was issued from the previous Sub-CA. Replace this certificate.” (el certificado lo emitió la Sub-CA anterior; reemplázalo). “G2” significa “The certificate was issued from the current Sub-CA. No action needed.” (el certificado lo emitió la Sub-CA actual; no hace falta hacer nada). La página añade una advertencia: “Check your own certificate, not the Developer ID Certification Authority entry in your keychain. That entry is the authority itself, and it’s issued by Apple Root CA, whose Organizational Unit is also Apple Certification Authority.” (revisa tu propio certificado, no la entrada Developer ID Certification Authority de tu llavero; esa entrada es la autoridad en sí, y la emite Apple Root CA, cuya Organizational Unit también es Apple Certification Authority).²

La misma prueba se puede hacer desde una terminal, en tres lugares.

Un certificado en tu llavero.

security find-certificate -a -c "Developer ID Installer" -p \
  | openssl crl2pkcs7 -nocrl -certfile /dev/stdin \
  | openssl pkcs7 -print_certs -noout

El flag -a devuelve todas las coincidencias, algo importante por la advertencia de Apple sobre los nombres idénticos, y la cadena de comandos imprime una línea de sujeto y una de emisor para cada una. Cambia a “Developer ID Application” para el certificado de firma de apps. Mi Mac tiene un certificado Developer ID Application y ningún certificado Installer, y con el /usr/bin/openssl del sistema su línea de emisor dice issuer=/CN=Developer ID Certification Authority/OU=G2/O=Apple Inc./C=US. El OpenSSL 3 de Homebrew imprime los mismos campos separados por comas. Un nombre sin coincidencias no imprime nada.⁴

Un paquete que ya distribuiste.

pkgutil --check-signature YourProduct.pkg

La salida muestra el estado de la firma, el estado de la notarización, la marca de tiempo de confianza y la cadena de certificados. La fecha que hay que leer es la que aparece bajo la segunda entrada, “Developer ID Certification Authority”. En cada uno de mis cuatro instaladores es Expires: 2027-02-01 22:12:15 +0000. El certificado propio de G2 termina el 17 de septiembre de 2031 (GMT), así que un paquete firmado bajo G2 debería mostrar esa fecha en ese lugar. No tengo ningún paquete firmado bajo G2 para confirmarlo.⁴

Una app. codesign -dvv no basta por sí solo, porque ambas autoridades comparten un mismo nombre común y sus líneas Authority= se leen igual para cualquiera de las dos. Extrae la cadena y lee el intermedio:

codesign -d --extract-certificates=/tmp/chain. YourApp.app
openssl x509 -inform DER -in /tmp/chain.1 -noout -subject -enddate

En una app firmada bajo G2 de mi carpeta Aplicaciones, el segundo comando imprime OU=G2 en el sujeto y notAfter=Sep 17 00:00:00 2031 GMT. En una app firmada bajo la autoridad original imprime OU=Apple Certification Authority y notAfter=Feb 1 22:12:15 2027 GMT.⁴

¿Qué muestra el software de una Mac?

Instaladores. Mi carpeta Descargas contiene cuatro paquetes firmados con Developer ID, de dos proveedores, y los cuatro encadenan a la autoridad original. Tres vienen de un mismo proveedor, firmados el 28 de septiembre, el 14 de diciembre y el 29 de diciembre de 2025 con un certificado de instalador emitido el 13 de abril de 2022 que termina el 1 de febrero de 2027. Ese proveedor seguía firmando paquetes bajo la autoridad original hace nueve meses. El cuarto se firmó en febrero de 2014 con un certificado que venció el 29 de marzo de 2017.⁴

La evaluación de instalación de Gatekeeper, spctl -a -t install -vv, acepta hoy los cuatro como “Notarized Developer ID”, incluido aquel cuyo certificado de firma venció hace nueve años. Ese resultado coincide con la frase sobre la marca de tiempo de confianza en la entrada de instaladores del resumen de certificados, y no con la frase “new installations won’t be possible” (no serán posibles nuevas instalaciones) de esa misma entrada ni con la página de ayuda de Developer ID. También es el comportamiento que, según el aviso de Apple, termina para los paquetes el 1 de febrero. No puedo probar febrero desde octubre, así que lo que ocurra ese día es lo que afirma Apple, no algo que yo haya observado.¹⁴⁵

Apps. Entre las 66 apps de mi carpeta Aplicaciones firmadas con Developer ID, 49 encadenan a la autoridad original y 17 a G2. Las 66 firmas llevan una marca de tiempo segura. Gatekeeper reporta 63 como “Notarized Developer ID”, que es la combinación que según Apple sigue funcionando: 46 de las 49 bajo la autoridad original y las 17 bajo G2. De las otras tres, todas bajo la autoridad original, dos fallan la evaluación con “a sealed resource is missing or invalid”, un error sobre el contenido del bundle, y una, firmada en julio de 2018, se acepta como Developer ID sin notarización. La frase de Apple cubre el software notarizado, y el aviso no dice qué pasa con una app como esta última.¹⁴

Seis de las 49 están firmadas con certificados que ya habían vencido al 1 de octubre de 2026, el primero en agosto de 2022 y el último en mayo de 2026. Gatekeeper acepta las seis, cinco de ellas como notarizadas. La regla de Apple para las apps, según la cual basta con que el certificado fuera válido en el momento de firmar, ya está funcionando en software que uso.⁴⁵

¿Qué frase del aviso no coincide?

El aviso dice de G2: “This certificate authority is valid until 2031, but the certificates issued by the certificate authority expire annually and must be renewed each year.” (esta autoridad de certificación es válida hasta 2031, pero los certificados que emite vencen cada año y deben renovarse anualmente). La página de ayuda dice lo mismo: “Certificates issued from G2 are valid for one year and must be renewed annually.” (los certificados emitidos por G2 son válidos durante un año y deben renovarse anualmente).¹²

Los certificados G2 que puedo inspeccionar no son de un año. Las 17 apps firmadas bajo G2 en mi Mac llevan 12 certificados de firma distintos, emitidos entre febrero de 2023 y el 29 de mayo de 2026, y todos duran cinco años. Tres de ellos se emitieron en abril y mayo de 2026. Mi propio certificado Developer ID Application, emitido el 10 de mayo de 2026, termina el 11 de mayo de 2031.⁴

Ninguna de las dos páginas dice cuándo empezó la validez de un año, y no he creado ningún certificado desde el aviso, así que no puedo decir con qué plazo sale un certificado emitido hoy. Planifica una renovación anual y lee las fechas del certificado que realmente te emitan. Si los certificados de un año son la norma de aquí en adelante, el desacuerdo entre las páginas de Apple, y dentro de la propia entrada del resumen, sobre los certificados de instalador vencidos empieza a importar más: si se cumple la frase de la marca de tiempo de confianza, un paquete sobrevive a su certificado, y si se cumplen las otras, no. El único dato que tengo es el paquete de 2014 mencionado arriba, que Gatekeeper todavía acepta. Cómo se ponderan esas frases entre sí es mi lectura, no la de Apple.

¿Qué haría yo, y en qué orden?

1. Inventario. Ejecuta la comprobación del llavero para ambos tipos de certificado, y pkgutil --check-signature en cada paquete que todavía ofrezcas para descargar, incluidas las versiones antiguas. La comprobación de paquetes también funciona con instaladores de otros proveedores, y así se encuentran los que tu equipo despliega y que necesitan un build vuelto a firmar por parte del proveedor.
2. Reemplaza. Si un emisor muestra “Apple Certification Authority”, crea un certificado G2. Los pasos de la página de ayuda dicen que, si te piden seleccionar un “Developer ID Certificate Intermediary” (el certificado intermedio de Developer ID), elijas “G2 Sub-CA (Xcode 11.4.1 or later)”, porque “Any other option might issue a certificate from the expiring Certificate Authority” (cualquier otra opción podría emitir un certificado de la autoridad de certificación que vence), y el aviso advierte que “Choosing another option may issue a certificate that also expires in 2027.” (elegir otra opción puede emitir un certificado que también vence en 2027). Si tienes ambos tipos, “repeat these steps for each, since one certificate does not cover the other.” (repite estos pasos para cada uno, ya que un certificado no cubre al otro). El aviso añade una condición previa: “If you’re using Xcode 11.4 or earlier, update before creating your new certificate.” (si usas Xcode 11.4 o anterior, actualiza antes de crear tu certificado nuevo).¹²
3. Prueba antes de que se vaya el viejo. Apple: “Because you can hold up to five Developer ID Application and five Developer ID Installer certificates at a time, you can create and test a replacement before your current certificate expires.” (como puedes tener hasta cinco certificados Developer ID Application y cinco Developer ID Installer a la vez, puedes crear y probar un reemplazo antes de que venza tu certificado actual).²
4. Vuelve a firmar los paquetes. El manual de productsign dice: “If you run productsign on a product archive that was previously signed, the existing signature will be replaced,” (si ejecutas productsign sobre un archivo de producto firmado previamente, la firma existente se reemplazará), y que una marca de tiempo de confianza “is enabled by default when signing with a Developer ID identity.” (está activada por defecto al firmar con una identidad Developer ID). También incrusta “any intermediate certificates that are found in the keychain” (cualquier certificado intermedio que se encuentre en el llavero), así que el intermedio G2 debería estar primero en el llavero (la opción --cert del manual nombra un intermedio por su nombre común, y ambas autoridades comparten un mismo nombre, así que yo no confiaría en ella para elegir entre las dos): la página de Apple de 2022 dice que Xcode 13.2 o posterior lo descarga automáticamente y que, si no, “you can download it from the Certificate Authority page.” (puedes descargarlo desde la página Certificate Authority). La cadena de comandos del llavero de arriba, ejecutada con el nombre “Developer ID Certification Authority”, lista las autoridades que tiene una Mac; la mía muestra las dos. Después, notariza y vuelve a grapar (staple) el resultado. El paso de notarización es mi lectura y no una frase de Apple: un paquete vuelto a firmar es un archivo distinto. No tengo ningún certificado Developer ID Installer, así que no he ejecutado este paso.³⁴
5. Comprueba el resultado. pkgutil --check-signature sobre el archivo vuelto a firmar ya no debería mostrar la fecha de 2027 bajo la autoridad, y spctl -a -t install -vv debería seguir diciendo “Notarized Developer ID”.
6. Mantén las firmas de las apps con marca de tiempo. Una marca de tiempo segura es la propiedad que Apple nombra para el software que sigue funcionando, y su instrucción para lo que viene es “sign with your new certificate and include a secure timestamp for notarization.” (firmar con tu certificado nuevo e incluir una marca de tiempo segura para la notarización).¹

Este plazo es el segundo cambio de instaladores de la temporada. El primero está en el propio macOS 27, donde un paquete que no indica ninguna arquitectura de host ahora usa arm64 por defecto; el artículo sobre Golden Gate explica a qué paquetes afecta, y un equipo que de todos modos vaya a volver a firmar sus instaladores puede revisar ambas cosas a la vez. El artículo sobre las notas de la versión de macOS 27 recoge el resto de esa versión para desarrolladores de Mac, el artículo sobre Xcode 27 y el artículo sobre Intel cubren la parte de las herramientas, el artículo sobre el acceso a contenedores entre equipos cubre un cambio que hace fallar apps para Mac ya publicadas al momento de leer, sin ningún aviso, y el artículo sobre ld64 cubre dos cambios de las herramientas que detienen los builds de Mac.

FAQ

¿Cuándo vence la Developer ID Certification Authority?

El 1 de febrero de 2027. El certificado de la autoridad original termina a las 22:12:15 UTC de ese día. La autoridad actual, G2, termina en septiembre de 2031; la página de soporte de Apple da el 16 de septiembre, y el propio certificado indica el 17 de septiembre a las 00:00:00 GMT.¹³⁴

¿Mi app Developer ID dejará de abrirse el 1 de febrero de 2027?

Apple dice que no para el software que se notarizó y se firmó con una marca de tiempo segura: “will keep working” (seguirá funcionando), sin que haga falta hacer nada. codesign -dvv YourApp.app imprime una línea Timestamp= cuando la firma tiene una, y spctl -a -t exec -vv YourApp.app reporta “source=Notarized Developer ID” para una app notarizada.¹⁴

¿Qué pasa con los instaladores .pkg firmados bajo la autoridad original?

Apple: “Starting February 1, 2027, .pkg files signed with an affected certificate will no longer install. Re-sign all packages with your new certificate before this date.” (a partir del 1 de febrero de 2027, los archivos .pkg firmados con un certificado afectado ya no se instalarán; vuelve a firmar todos los paquetes con tu certificado nuevo antes de esa fecha).¹

¿Cómo compruebo qué autoridad firmó un paquete?

Ejecuta pkgutil --check-signature sobre él y lee la fecha bajo la entrada “Developer ID Certification Authority” de la cadena. Expires: 2027-02-01 22:12:15 +0000 corresponde a la autoridad original.⁴

¿Los certificados G2 duran un año o cinco?

El aviso de Apple y su página de ayuda dicen un año. Todos los certificados G2 que pude inspeccionar el 1 de octubre de 2026, el más reciente emitido el 29 de mayo de 2026, duran cinco años. Ninguna de las dos páginas dice cuándo empezó el plazo de un año.¹²⁴

¿Quién del equipo puede crear el reemplazo?

La página de ayuda indica “Required role: Account Holder.” (rol requerido: Account Holder).²

Fuentes