Renovar el certificado Pass Type ID de Apple sin romper la flota de pases instalados

Si tu certificado Pass Type ID expira, Apple es explícita: los pases ya instalados siguen funcionando con normalidad; lo que pierdes es la capacidad de firmar pases nuevos y de enviar actualizaciones a los existentes. Solo un certificado revocado deja a los pases sin funcionar. Renovarlo sin impacto tiene una sola regla: certificado nuevo para el mismo Pass Type ID, sin tocar passTypeIdentifier ni teamIdentifier y sin revocar el viejo — la próxima actualización sale firmada con el nuevo y el titular no se entera.

Eso dice la documentación viva de Apple a agosto de 2026. Lo demás —por qué el certificado nuevo sirve a pases firmados con el viejo, qué pasa con el push durante la ventana y qué monitorear— es lo que sigue. Generar el CSR y convertir a PEM ya está resuelto en la guía del CSR al PEM; aquí no se repite.

Qué se rompe de verdad cuando expira (y qué no)

La página de certificados de la cuenta de desarrollador lo dice en tres frases, y conviene leerlas completas porque el folclore las resume mal: si el certificado expira, los pases instalados siguen funcionando; ya no puedes firmar pases nuevos ni enviar actualizaciones; si el certificado es revocado, los pases dejan de funcionar.

La distinción importa operativamente. Un certificado vencido es una flota congelada: cada pase muestra su último contenido, el pago que se confirmó esta mañana no llega al teléfono, la entrada que se transfirió sigue mostrando al titular anterior. Un certificado revocado es una flota muerta. Por eso la revocación es solo para compromiso de la clave privada —Apple anota además que puede revocar certificados a su sola discreción— y jamás una forma de «limpiar» el certificado viejo tras rotar.

Nuestra cicatriz es de lectura: nuestro propio runbook decía que con el certificado vencido «todos los pases emitidos rompen». Para una operación que vive de las actualizaciones la sensación es esa, pero es impreciso, y lo corregimos al escribir este artículo contra la página viva. La versión correcta es menos dramática y más útil: lo que se rompe es el canal de actualización, y por eso el margen de renovación se mide en semanas, no en días.

Por qué el certificado nuevo sigue sirviendo a los pases viejos

Porque la identidad del pase es passTypeIdentifier + serialNumber, no el certificado que lo firmó. Es la consecuencia directa de tres frases de la documentación de pases:

1. «Cada combinación de identificador de pase y número de serie es un pase único. Agregar un pase con el mismo identificador y serial que uno que ya existe en el dispositivo sobrescribe al viejo.»
2. «Una actualización es un pase nuevo con el mismo pass type identifier y número de serie.»
3. «Firmar un pase requiere un certificado de firma para el pass type identifier.»

El certificado es solo la credencial con la que se firma esa versión. Cuando rotas, el Pass Type ID es el mismo y el certificado nuevo está emitido para él; la siguiente vez que el dispositivo pide el pase —tras el push silencioso, tu servidor responde el .pkpass completo, regenerado y firmado con el contenido vigente— la firma viene del certificado nuevo y el dispositivo sobrescribe la versión anterior. Nada que reinstalar, nada que avisar.

Dos cosas que una actualización no puede cambiar según Apple, y que la rotación tampoco toca: el authenticationToken y el serialNumber.

El procedimiento

1. Clave privada y CSR nuevos, en tu máquina, igual que la primera vez. Los comandos están en la guía del CSR al PEM; la clave nueva no sale de tu máquina y Apple nunca la ve.
2. Emite el certificado en el portal. En Certificates, Identifiers & Profiles → Certificates → botón + → bajo Services, Pass Type ID Certificate → Continue; elige el Pass Type ID que ya tienes —no crees uno nuevo— y sube el .certSigningRequest; Continue → Download. Baja un .cer en DER. Rol requerido: Account Holder o Admin.
3. Convierte a PEM (openssl x509 -inform DER -in pass.cer -out signerCert.pem) y comprueba que el subject nombra tu Pass Type ID y el vencimiento es el esperado (openssl x509 -in signerCert.pem -noout -subject -enddate).
4. Pega certificado y clave nuevos en tu plataforma y verifica con una firma real. En nuestro panel, guardar credenciales dispara la verificación —se firma un pase de prueba con exactamente esas credenciales— y re-empuja la flota de esa institución, para que la siguiente descarga ya salga bajo el certificado fresco sin esperar al próximo cambio de contenido.
5. No revoques el viejo. Al hablar de certificados comprometidos, Apple indica que puedes pedir un certificado adicional en tu cuenta y seguir distribuyendo pases — es decir, varios certificados del mismo Pass Type ID pueden existir a la vez. Nuestra práctica: dejar que el viejo muera de muerte natural; el viejo y el nuevo conviven hasta que el viejo venza. Revocarlo es el único camino que sí rompe pases instalados.
6. Criterio de éxito: un pase de prueba nuevo se instala en un iPhone sin error de firma, y una actualización empujada a un pase ya instalado antes de rotar llega y se refleja. Lo segundo es lo que demuestra que la flota sobrevivió.

El push durante la ventana

Con autenticación por token, rotar el certificado de firma no toca el push; con el modelo basado en certificado, sí. Los dos modelos:

• Modelo basado en certificado. La documentación de pases describe el push así: «la notificación usa el mismo certificado y la misma clave privada que el creador del pase usó para firmar el original». Si tu servidor de push está configurado de ese modo, rotar el certificado de firma obliga a recargarlo también en el servidor de push, y la ventana entre ambos cambios es una ventana sin push.
• Modelo basado en token. Una llave .p8 de APNs con su Key ID y tu Team ID, con la que tu servidor firma un JWT por conexión; Apple rechaza el token cuando su iat supera la hora (ExpiredProviderToken, 403); la llave misma solo se reemplaza cuando tú decides, y Apple describe ese reemplazo —para el caso de una llave comprometida— como «crea una llave nueva con APNs habilitado, transiciona, y después revoca la vieja». Es el modelo que usamos y que detalla APNs para pases digitales: el certificado de firma y la llave de push son credenciales distintas, y lo único que comparten es el topic de cada notificación, que es el passTypeIdentifier.

Con el modelo de token, rotar el certificado de firma no toca el push: el empuje sale igual antes, durante y después de la ventana, y lo único que cambia es la firma del pase que el dispositivo descarga a continuación.

Lo que nunca cambia: passTypeIdentifier y teamIdentifier

La lista de problemas comunes de Apple al construir un pase es una lista de coincidencias: el passTypeIdentifier del pass.json debe coincidir con el del certificado, el teamIdentifier con la cuenta de desarrollador del certificado, y el certificado no debe estar vencido. Cambiar el Pass Type ID no es una rotación: es una identidad nueva, y la flota instalada bajo la identidad vieja queda huérfana — nunca más recibe una actualización.

En los certificados que Apple emite, el subject lleva el Pass Type ID y el Team ID; compruébalo con openssl x509 -noout -subject antes de pegar nada. La cicatriz conocida: un Team ID mal tipeado firma sin queja en local y falla solo al instalar en el teléfono, porque la firma local no valida esa coherencia — la misma lección del verde que miente con el certificado intermedio.

Monitoreo: 60, 30, 7

La fecha de vencimiento está dentro del certificado; no hace falta recordarla, hace falta leerla. Nuestro patrón:

• Severidad progresiva desde 60 días antes (aviso), 30 (error) y 7 (crítico), visible en el panel de credenciales junto a la fecha exacta.
• Verificación periódica real: no basta con parsear la fecha; cada revisión firma un pase de prueba con las credenciales configuradas, y si algo deja de firmar, los administradores reciben un solo correo por institución con el detalle.
• Todos los juegos de certificados, no solo los que viste configurar. El hueco conocido: un certificado configurado fuera del panel —en una variable de entorno desde el piloto, por ejemplo— es justo el que el monitoreo no ve, y el que vencería sin aviso. Lo que firma, se monitorea; lo que no está en el panel, se pasa al panel.

Cuando hay varias instituciones con certificados propios —varias sedes, un solo panel—, cada una rota el suyo en su fecha; la rotación es por institución, nunca un evento global.

Preguntas frecuentes

¿Los pases ya instalados dejan de funcionar cuando el certificado expira?

No. Apple lo declara en su documentación: si el certificado expira, los pases instalados siguen funcionando con normalidad; lo que pierdes es firmar pases nuevos y enviar actualizaciones a los existentes. Solo un certificado revocado hace que los pases dejen de funcionar. En una operación que vive de las actualizaciones, un certificado vencido congela la flota en su último estado — no la rompe.

¿Tengo que reinstalar los pases después de rotar el certificado?

No. La identidad de un pase es su passTypeIdentifier más su serialNumber, no el certificado que lo firmó, y una actualización es un pase nuevo con el mismo identificador y serial. Si el Pass Type ID y el Team ID no cambian, la siguiente actualización sale firmada con el certificado nuevo y el titular no nota nada.

¿Rotar el certificado de firma afecta el push de APNs?

Depende de cómo autentiques el push. Con autenticación por token —una llave .p8 de APNs sin fecha de vencimiento publicada, que se rota solo por revocación— no: certificado de firma y llave de push son credenciales distintas que solo comparten el topic, que es el passTypeIdentifier. En el modelo basado en certificado que describe la documentación de pases, el mismo certificado firma y empuja, y rotarlo obliga a recargarlo también en el servidor de push.

¿Cuánto dura el certificado y cuántos puedo tener activos?

Apple no publica la duración en su documentación viva; en nuestra experiencia los certificados de Pass Type ID salen con alrededor de un año de validez — compruébalo en el tuyo con openssl x509 -noout -dates. Sobre la cantidad, Apple menciona —al hablar de certificados comprometidos— que puedes pedir un certificado adicional en tu cuenta y seguir distribuyendo pases; en nuestra práctica el viejo y el nuevo conviven hasta que el viejo venza, y no publicamos un tope porque la documentación no lo declara.