Los certificados de Apple Push Notification service son válidos durante un año y deben renovarse anualmente en el Apple Developer Portal para evitar interrumpir la comunicación con los dispositivos. Si eres responsable de una app Capacitor, una credencial expirada o revocada puede detener las notificaciones aunque la app parezca funcionar correctamente.
El fallo suele aparecer en el peor momento posible. Se lanza una versión, se programa una campaña y, de repente, la entrega de notificaciones se detiene. Tu servidor de aplicación puede seguir aceptando trabajos, pero APNs puede rechazar la conexión TLS antes de que el mensaje llegue al dispositivo. La solución práctica no es solo crear otro certificado. Necesitas entender qué credencial de APNs usa tu sistema, conservar la clave privada, planificar la renovación y migrar las cargas de trabajo adecuadas a la autenticación basada en tokens.
Tabla de contenidos
- Por qué dejan de funcionar las notificaciones push
- Cómo crear y descargar tu certificado APNs
- Exporta el certificado a una clave privada
- Migración a la nueva autenticación basada en tokens
- Renovar y gestionar ciclos de vida de certificados
- Solución de problemas y gestión de credenciales perdidas
Por qué dejan de funcionar las notificaciones push
APNs se sitúa entre tu servidor de proveedor y el dispositivo Apple del usuario. Tu servidor se autentica con Apple, envía una notificación y confía en APNs para enrutarla a la aplicación y el dispositivo registrados. Si la credencial está caducada, revocada, asociada a la identidad incorrecta o instalada de forma errónea, la solicitud puede fallar antes de que comience la entrega.
Apple indica que APNs mantiene una lista de certificados revocados y rechaza las conexiones TLS de servidores que utilicen certificados de esa lista. Esto convierte el mantenimiento de certificados en un requisito de entrega, no en una preferencia administrativa. El servidor puede seguir procesando trabajos de notificación localmente, mientras Apple rechaza la conexión del proveedor.
Separar push de la app del push de MDM
La primera pregunta de diagnóstico es simple: ¿Qué servicio estás intentando operar?
| Ruta de credenciales | What it does | Propietario típico |
|---|---|---|
| Push de la app | Envía alertas y otras notificaciones de la aplicación a los dispositivos de los usuarios finales | Ingeniería móvil o backend |
| Push MDM | Permite que una plataforma de gestión de dispositivos se comunique con dispositivos Apple gestionados | Administración de IT, endpoints o movilidad empresarial |
Estas credenciales no son intercambiables. Una plataforma MDM puede perder contacto con los dispositivos registrados si su credencial de MDM push expira, mientras que el backend de una app puede dejar de entregar notificaciones si su credencial de App Push es inválida. Tratar ambas como un único problema de «certificado push de Apple» orienta mal el troubleshooting.
Para los equipos de Capacitor e Ionic, la ruta para las alertas de usuario suele ser Push de la app. La app aún requiere la capability Push Notifications, firma correcta, registro del dispositivo y un backend que envíe a través del entorno APNs adecuado. Si tu equipo también lanza assets web over-the-air, mantén ese workflow de release separado de la autenticación de push. La documentación del plugin de notificaciones de Capacitor cubre la integración en la aplicación, mientras que las credenciales de APNs pertenecen a la configuración del proveedor.
Empieza por el rechazo, no por la UI
Revisa la respuesta de APNs de tu servidor del proveedor antes de cambiar el texto de la notificación o recompilar la app. Luego verifica el bundle identifier, la identidad de la credencial, el entorno y el estado del certificado. Un problema de permisos de notificación afecta a la capacidad del usuario de ver alertas, pero no explica un rechazo TLS de APNs.
Si el fallo apareció tras un release, compara la firma y los entitlements del nuevo build con los del anterior. Si apareció sin cambios en la app, revisa primero la expiración y revocación del certificado, los cambios en el trust-store y los secrets de despliegue. Para una ruta de implementación más amplia, consulta esta guía sobre Configuración de notificaciones push de Expo.
Cómo crear y descargar tu certificado APNs
Un despliegue de push puede fallar antes de enviar la primera notificación si el certificado se emitió para un App ID incorrecto o si la clave privada quedó en otro Mac. El flujo de Apple tiene dos partes: tu máquina genera un Solicitud de firma de certificado, o CSR, y Apple lo firma para el App ID seleccionado. El CSR no es la credencial del servidor; sirve para vincular el certificado emitido con una clave privada creada localmente.
Prepara el App ID
Inicia sesión en el portal de Apple Developer y abre Certificates, Identifiers & Profiles. Selecciona Identificadores, elige el bundle identifier de la app y abre su configuración. Confirma que Notificaciones push se habilita antes de emitir nada.
Las credenciales de APNs están vinculadas a la identidad de la aplicación. No elijas un bundle identifier similar con un nombre parecido. Configura cada aplicación de forma independiente y emite la credencial correspondiente.
En la Mac que conservará la clave, abre Acceso a Llaveros y genera el CSR, o usa las herramientas de certificados aprobadas por tu organización. Mantén el archivo de solicitud y la clave privada bajo el mismo control de propiedad. Si otro administrador genera el CSR, ese administrador podría tener la clave privada necesaria más adelante para un bundle de servidor utilizable.
Genera el certificado firmado
En Certificados, elige la opción de certificado de Apple Push Notification service. Selecciona el App ID, sube el CSR y envía la solicitud. Descarga el certificado que emite Apple.
Haz doble clic en el archivo descargado en el Mac que posee la clave privada. Debería instalarse en Acceso a Llaveros, donde puedes verificar el certificado y su clave privada correspondiente. Un certificado importado sin esa clave no puede proporcionar la credencial completa que tu backend necesita.
Usa una convención de nombres que registre la identidad de la app, el entorno, el propietario y los detalles de expiración. Guarda el certificado original, la información de propiedad del CSR y los datos de la cuenta del portal en el sistema de credenciales de tu equipo. La carpeta Descargas de un dev o su laptop personal no son un backup operativo.
El certificado solo cubre una parte de la entrega. La app debe registrarse para notificaciones remotas, el servidor debe guardar el device token resultante y el proveedor debe enviar con el topic y el entorno correctos. Mantén esas dependencias en el mismo runbook. Para la configuración del lado del cliente, consulta la guía de integración de notificaciones de Capacitor. Trata este certificado como una credencial gestionada, no como una descarga de una sola vez, porque la exportación posterior, la migración de tokens, la renovación y la recuperación dependen de saber quién controla su clave.
Exporta el certificado a una clave privada
Un certificado de Apple descargado no está listo automáticamente para un servicio de Node.js o un proveedor de push gestionado. El servidor necesita el certificado y su clave privada correspondiente, normalmente empaquetados como un PKCS#12 .p12 archivo.
Abrir Acceso a Llaveros en el Mac donde instalaste el certificado. Busca el certificado APNs, despliégalo o inspecciónalo y localiza la clave privada cuya identidad y datos de expiración coincidan. Selecciona el certificado y la clave privada a la vez y usa la acción de exportación para guardar un .p12 archivo.
Valida el bundle antes del despliegue
Asigna una contraseña segura a la exportación. La contraseña protege la clave privada dentro del bundle, así que no la guardes en un repositorio, ticket, mensaje de chat o log de build. Sube el archivo y la contraseña mediante tu sistema de gestión de secretos y otorga acceso solo al servicio que envía las notificaciones.
Regla práctica: Una
.p12archivo sin su clave privada correspondiente no es una credencial de proveedor completa.
Antes de usarlo en producción, prueba el bundle en un entorno controlado. Confirma que tu backend puede cargar el archivo, establecer la conexión con APNs y devolver errores estructurados cuando Apple rechace una solicitud. Si un proveedor como Capgo solicita una credencial de push para iOS, sube el .p12 y su contraseña mediante la configuración de secretos correspondiente, en lugar de incluir cualquiera de los dos valores en el code de la aplicación.
El formato también evidencia la debilidad del flujo de trabajo heredado. Debes conservar la clave privada original, repetir una exportación manual, proteger el archivo y reemplazar el secreto de despliegue al renovar. Los equipos que gestionan varias apps pueden perder fácilmente el rastro de qué bundle corresponde a qué App ID.
Usa gestión segura de secretos en pipelines de CI/CD para controlar quién puede leer o reemplazar la credencial. Mantén un registro de auditoría para los uploads y rotaciones, pero nunca registres la clave privada ni la .p12 contraseña.
Para nuevos trabajos de backend, evalúa si la autenticación por certificados sigue siendo adecuada. Las integraciones existentes pueden requerir .p12, pero la autenticación por token suele eliminar el reemplazo anual del certificado en la conexión con el proveedor. Eso no elimina la gobernanza de credenciales. Cambia qué proteges y rotas.
Migración a la nueva autenticación basada en tokens
Apple ha orientado la autenticación de APNs hacia tokens de proveedor, lo que comúnmente se llama el workflow p8. En lugar de presentar un certificado y una clave privada para una identidad TLS de larga duración, tu proveedor firma tokens de autenticación con una Apple Push Notification service Authentication Key.
Crea la clave en el portal de Apple Developer bajo Certificates, Identifiers & Profiles, luego abre Claves y registra una clave de autenticación de APNs. Descarga el .p8 archivo y anota el Key ID y el Team ID asociados en tu gestor de secretos. Trata el archivo descargado como un secreto de firma de alto valor.
Realiza la migración de forma deliberada
No cambies el tráfico de producción reemplazando un archivo en un entorno no probado. Implementa la autenticación por token junto a la ruta de certificados actual, valida el comportamiento en sandbox y producción, y compara las respuestas de APNs. Después, haz el cambio de configuración del proveedor durante un despliegue controlado.
La migración elimina los pasos de renovación de certificados y exportación de Keychain del flujo de envío, pero tu equipo aún necesita un modelo claro de responsabilidades. Define quién puede crear, revocar y desplegar claves. Limita el acceso al servicio backend que firma los tokens del proveedor y asegúrate de que exista un proceso de reemplazo de emergencia antes de que la clave actual deje de estar disponible.
Para una app Capacitor, el cliente aún requiere el registro de notificaciones y los entitlements correctos. La migración cambia principalmente autenticación de servidor a APNs, no el registro del device token code. Tu backend debe seguir asociando los tokens con la aplicación y el entorno correctos.
Cuándo siguen siendo necesarios los certificados
Algunas herramientas empresariales e integraciones establecidas todavía exponen configuración basada en certificados. No fuerces una migración a p8 hasta que el sistema receptor la soporte y tu equipo haya probado la ruta completa. Mantén protegida la credencial legacy durante la transición, pero no crees nuevas dependencias de ella cuando encaje la autenticación por token.
Si necesitas entender el flujo de la aplicación en su contexto, revisa Notificaciones push de Ionic y Capacitor con FirebaseFirebase puede proporcionar una capa de entrega de aplicaciones, pero las credenciales de Apple, los permisos, el registro y las respuestas de APNs siguen requiriendo una configuración deliberada.
Renovar y gestionar ciclos de vida de certificados
Trata un certificado de APNs como una dependencia de producción con fecha de caducidad desde el día en que lo creas. Apple indica que estos certificados son válidos durante un año desde su creación y deben renovarse antes de la expiración para mantener la comunicación con los dispositivos. Apple también advierte que no renovar puede requerir que los usuarios vuelvan a registrar sus dispositivos iOS, iPadOS y Mac con APNs y puede causar interrupciones del servicio. Consulta la documentación de Apple sobre renovación de certificados de notificaciones push.
El proceso de renovación es preciso:
- Genera un nuevo CSR: Crea la solicitud mediante tu flujo de trabajo aprobado y conserva el material de claves asociado.
- Usa el Apple ID original: Inicia sesión con el mismo Apple ID que usaste para crear el certificado actual.
- Selecciona el certificado que va a expirar: Comprueba que App ID, Subject DN, UID y datos de expiración coincidan antes de seleccionar Renovar.
- Sube el CSR: Envía la nueva solicitud en el Apple Push Certificates Portal.
- Descarga y reinstala: Obtén el certificado renovado
.pem, instálalo donde esté la clave privada y exporta un reemplazo.p12si tu proveedor lo requiere. - Despliega y prueba: Actualiza el secret del servidor, envía una notificación controlada e inspecciona la respuesta de APNs.
Compara los formatos de los proveedores
| Requisito | Flujo de certificados | Flujo de tokens |
|---|---|---|
| Secret principal | Certificado y clave privada | .p8 Clave de autenticación |
| Problemas de renovación | La expiración del certificado requiere reemplazos periódicos | Sin reemplazo anual de certificados |
| Trabajo de despliegue | Instalar, emparejar, exportar y subir | Guardar clave de firma y configurar generación de tokens |
| Principal riesgo de fallo | Certificado incorrecto, falta de clave privada, caducidad o revocación | Clave de autenticación perdida, expuesta o revocada |
El ecosistema de certificados de Apple también ha requerido trabajo programado en la cadena de confianza. Apple anunció actualizaciones de certificados de servidor APNs para sandbox el 20 de enero de 2025 y para producción el 24 de febrero de 2025, lo que requiere que los trust stores incluyan el certificado SHA-2 Root USERTrust RSA Certification Authority certificado. Consulta la anuncio de Apple sobre certificados de servidor APNs e integra la gestión del trust-store en tu checklist de plataforma.
Usa un calendario de renovación compartido, un responsable asignado y un runbook de despliegue. La Documentación de gestión de certificados de Capgo puede acompañar a ese runbook para equipos que gestionan credenciales de iOS en su proceso de release móvil.
Solución de problemas y gestión de credenciales perdidas
El incidente crítico no siempre es un aviso de expiración. Es esa mañana en la que el administrador que creó el certificado ya no está, la clave privada solo existe en un Mac antiguo, o un certificado fue revocado durante un intento de limpieza. El flujo de renovación estándar depende del Apple ID original y de la identidad correcta del certificado, por lo que el acceso y la procedencia importan tanto como el archivo mismo.
Empieza clasificando el fallo:
- Certificado expirado: Genera un reemplazo mediante la cuenta original, reinstálalo con la clave privada correspondiente, actualiza el provider y prueba el envío. Si la comunicación con los dispositivos ya se interrumpió, sigue la guía de recuperación de Apple en lugar de asumir que un reemplazo en el servidor restaurará todos los dispositivos al instante.
- Certificado revocado: Deja de intentar recuperar la credencial antigua. Apple rechaza conexiones TLS de servidores que usan certificados revocados, así que crea un reemplazo válido y elimina el secreto revocado de los despliegues activos. Comprueba quién lo revocó y si otros sistemas copiaron la misma credencial.
- Perdido
.p12contraseña: Un archivo de certificado sin la contraseña utilizable puede quedar inoperativo. Recupera el backup aprobado o emite un reemplazo en lugar de debilitar los controles de secretos de producción. - Clave privada perdida: Volver a descargar el certificado público no recreará la clave privada. Genera un nuevo CSR en una máquina controlada y emite una credencial de reemplazo.
- Acceso a Apple ID perdido: Confirma si la organización puede recuperar la cuenta mediante sus procesos de identidad y despliegue. Apple deriva el soporte de certificados APNs creados a través del portal correspondiente a Soporte de programas de despliegue.
La recuperación requiere identidad, no solo un nombre de archivo. Registra el dueño del Apple ID, App ID, identidad del certificado, ubicación de la clave privada, configuración del proveedor y el procedimiento de reemplazo antes de que ocurra un incidente.
Crea una red de seguridad operativa
Guarda los certificados y .p8 claves en una bóveda compartida con control de acceso. Guarda la .p12 contraseña aparte del archivo, restringe el acceso a producción y documenta la cuenta exacta del portal usada para la renovación. Tu sistema CI/CD debe inyectar los secrets al desplegar y ejecutar un health check que detecte fallos de autenticación antes de que los usuarios reporten la falta de alertas.
Mantén la credencial antigua disponible durante un reemplazo controlado cuando la plataforma lo permita, pero no dejes secrets obsoletos activos indefinidamente. Prueba el reemplazo en la misma ruta de backend que usa producción, incluyendo el entorno del proveedor, el bundle identifier y el almacén de device tokens.
Si ya ocurrió una caída, conserva los bodies de respuesta de APNs y los timestamps, identifica la primera solicitud rechazada y compara el secret de despliegue antes y después del incidente. No reintentes indefinidamente con una credencial inválida. Corrige primero el problema de identidad o autenticación y luego envía una pequeña notificación de verificación a un dispositivo de prueba conocido.
Capgo puede almacenar y configurar credenciales de push para iOS como parte de un flujo de trabajo de notificaciones de Capacitor, mientras tu equipo mantiene la responsabilidad del acceso a la cuenta de Apple, la custodia de los secrets y las decisiones de renovación. Visita Capgo para revisar cómo sus herramientas de entrega móvil pueden integrarse con su ciclo de vida de credenciales APNs y su proceso de lanzamiento.
Preguntas frecuentes
¿Se transfieren los certificados SSL de cliente para notificaciones push cuando se transfiere una app a otra cuenta de Apple?
No. La documentación de transferencia de apps de Apple indica que los certificados SSL de cliente para notificaciones push no se transfieren. Tras la transferencia, el equipo receptor debe crear nuevos certificados de APNs o, mejor aún, usar una clave .p8 basada en tokens de su propia cuenta y luego actualizar el proveedor de push. Ver migrar a autenticación basada en tokens.
