Los certificados de Apple Push Notification service son válidos por un año y deben renovarse anualmente en el Apple Developer Portal para evitar interrupciones en 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.
Este fallo suele aparecer en el peor momento posible. Lanzas una versión, programas una campaña y, de repente, las notificaciones dejan de llegar. Tu servidor de aplicaciones puede seguir aceptando tareas, pero APNs puede rechazar la conexión TLS antes de que el mensaje llegue al dispositivo. La solución real no es solo crear otro certificado. Necesitas saber qué credencial de APNs usa tu sistema, preservar la clave privada, planificar la renovación y migrar las cargas de trabajo a autenticación basada en tokens.
Table of Contents
- Por qué dejan de funcionar las Push Notifications
- 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 actúa como intermediario entre tu servidor y el dispositivo Apple del usuario. Tu servidor se autentica ante Apple, envía una notificación y confía en APNs para dirigirla a la aplicación y al dispositivo registrados. Si la credencial ha expirado, ha sido revocada, está asociada a una identidad incorrecta o se instaló mal, la solicitud puede fallar antes de iniciar la entrega.
Apple afirma que APNs mantiene una lista de certificados revocados y rechaza las conexiones TLS de servidores que utilicen certificados de dicha lista. Esto convierte la higiene de los certificados en un requisito de entrega, no en una preferencia administrativa. El servidor puede seguir procesando tareas de notificación localmente, mientras Apple rechaza la conexión del proveedor.
Separa el push de la app del push de MDM
La primera pregunta de diagnóstico es sencilla: ¿qué servicio estás intentando operar?
| Ruta de la credencial | What it does | Propietario típico |
|---|---|---|
| App Push | Envía alertas y otras notificaciones de la aplicación a los dispositivos de los usuarios finales | Ingeniería móvil o backend |
| MDM Push | 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 App Push. 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 error ocurrió tras un release, compara la firma y los entitlements del nuevo build con el anterior. Si ocurrió sin cambios en la app, revisa primero la expiración del certificado, revocaciones, cambios en el trust-store y secrets de despliegue. Para más detalles, consulta esta guía sobre la configuración de Expo push notification.
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 private key 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; conecta el certificado emitido con una private key creada localmente.
Prepara el App ID
Inicia sesión en el portal de Apple Developer y abre Certificados, Identificadores y Perfiles. Selecciona Identifiers, elige el bundle identifier de la app y abre su configuración. Confirma que Notificaciones push is enabled before issuing anything.
Las credenciales de APNs están vinculadas a la identidad de la aplicación. No elijas un bundle identifier similar. Configura cada aplicación de forma independiente y emite la credencial correspondiente.
En el Mac que conservará la clave, abre Acceso a Llaveros y crea el CSR, o usa las herramientas de certificados aprobadas por tu organización. Mantén el archivo de solicitud y la clave privada bajo la misma propiedad controlada. Si otro administrador crea el CSR, ese administrador podría tener la clave privada necesaria para el bundle del servidor.
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 podrá proporcionar las credenciales completas 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 info del CSR y los datos de la cuenta del portal en el sistema de credenciales de tu equipo. La carpeta de Descargas de un dev o su laptop personal no son un backup operativo.
El certificado solo cubre una parte del proceso. La app debe registrarse para notificaciones remotas, el servidor debe guardar el device token resultante y el proveedor debe enviar con el topic y entorno correctos. Mantén esas dependencias en el mismo runbook. Para la configuración 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, ya que 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, comúnmente 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 o 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 la necesidad de renovar el certificado anualmente en la conexión con el proveedor. Esto no elimina la gobernanza de credenciales; simplemente cambia qué proteges y rotas.
Migración a la nueva autenticación basada en tokens
Apple ha movido la autenticación de APNs hacia tokens del proveedor, comúnmente llamado 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 Keys y registra una clave de autenticación APNs. Descarga el .p8 archivo y guarda 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 redirijas 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. Luego, cambia la 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 de responsabilidad claro. 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 tener un proceso de reemplazo de emergencia antes de que la clave actual deje de funcionar.
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 de device tokens 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 aún usan configuración basada en certificados. No fuerces una migración a p8 hasta que el sistema receptor la soporte y tu equipo haya probado todo el flujo. Mantén las credenciales legacy protegidas durante la transición, pero no crees nuevas dependencias de ellas si la autenticación por token es viable.
Si necesitas entender el flujo de la aplicación, revisa Ionic y Capacitor push notifications con Firebase. Firebase puede actuar como capa de entrega, pero las credenciales de Apple, entitlements, el registro y las respuestas de APNs siguen requiriendo una configuración precisa.
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 primer día. Apple indica que estos certificados son válidos por un año desde su creación y deben renovarse antes de que expiren para mantener la comunicación con los dispositivos. Apple también advierte que no renovarlos puede obligar a los usuarios a volver a registrar sus dispositivos iOS, iPadOS y Mac en APNs, causando interrupciones en el servicio. Consulta la documentación para renovar certificados de push notifications.
El proceso de renovación es exacto:
- Genera un nuevo CSR: Crea la solicitud mediante tu workflow aprobado y conserva el material de clave asociado.
- Usa el Apple ID original: Inicia sesión con el mismo Apple ID usado para crear el certificado actual.
- Selecciona el certificado que va a expirar: Verifica que el App ID, Subject DN, UID y la fecha de expiración coincidan antes de elegir Renew.
- 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 reemplazo recurrente | Sin reemplazo anual de certificados |
| Trabajo de despliegue | Instalar, emparejar, exportar y subir | Guardar la clave de firma y configurar la generación de tokens |
| Principal riesgo de fallo | Certificado incorrecto, falta la clave privada, expiración o revocación | Clave de autenticación perdida, expuesta o revocada |
El ecosistema de certificados de Apple también requiere mantenimiento programado de 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. Lee el Anuncio sobre el certificado del servidor Apple 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 una 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 proveedor 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 restaura instantáneamente todos los dispositivos.
- Certificado revocado: Deja de tratar la credencial antigua como recuperable. 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 necesaria puede quedar inutilizable. Recupera el backup aprobado o genera uno nuevo en lugar de debilitar los controles de seguridad en 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 segura y solicita una nueva credencial.
- Acceso a Apple ID perdido: Confirma si la organización puede recuperar la cuenta mediante sus procesos de identidad y despliegue. Apple dirige el soporte para certificados APNs creados en su portal a Soporte para 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 proceso 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.
