Los certificados de servicio de notificación push de Apple son válidos durante un año y deben renovarse anualmente en el Portal de Desarrolladores de Apple para evitar interrumpir la comunicación de dispositivos. Si eres responsable de una aplicación Capacitor, un credencial vencida o revocada puede detener las notificaciones incluso cuando la aplicación misma parece saludable.
La falla a menudo se manifiesta en el peor momento posible. Una versión se lanza, una campaña se programa y la entrega de notificaciones se vuelve silenciosa. Su servidor de aplicación puede seguir aceptando trabajos, pero APNs puede rechazar la conexión TLS antes de que un mensaje llegue a un dispositivo. La solución práctica no es solo crear otro certificado. Necesita entender qué credencial de APNs utiliza su sistema, preservar la clave privada, planificar la renovación y mover las cargas de trabajo adecuadas a la autenticación basada en tokens.
Contenido del Cuadro de Herramientas
- ¿Por qué las notificaciones de empuje dejan de funcionar
- Crear y descargar su certificado APNs
- Exportar el certificado a una clave privada
- Migrar a la autenticación basada en tokens
- Renovando y Administrando Ciclos de Certificados
- Solucionar Problemas y Manejar Credenciales Perdidas
¿Por qué las Notificaciones de Empuje dejan de Funcionar?
APNs se encuentra entre su servidor de proveedor y el dispositivo de Apple del usuario. Su servidor se autentica con Apple, envía una notificación y confía en APNs para enviarla a la aplicación y dispositivo registrados. Si la credencial ha expirado, ha sido revocada, está asociada con la identidad incorrecta o se ha instalado de manera incorrecta, la solicitud puede fallar antes de que comience el envío.
Apple afirma que APNs mantiene una lista de certificados revocados y rechaza conexiones TLS de servidores que utilizan certificados en esa lista. Esto hace que la higiene de certificados sea un requisito de entrega, no una preferencia administrativa. El servidor puede seguir procesando trabajos de notificación localmente, mientras que Apple rechaza la conexión del proveedor.
Separar la notificación de aplicaciones de la notificación de MDM
La primera pregunta diagnóstica es simple: ¿Qué servicio estás tratando de operar?
| Ruta de credenciales | ¿Qué hace | Propietario típico |
|---|---|---|
| Envía alertas y otras notificaciones de aplicación a dispositivos de usuario final | Ingeniería de aplicaciones móviles o backend | Envía notificaciones a dispositivos Apple administrados por una plataforma de gestión de dispositivos |
| Administración de IT, puntos finales o movilidad empresarial | Estos credenciales no son intercambiables. Una plataforma de gestión de dispositivos puede perder contacto con dispositivos inscritos cuando su credencial de envío de notificaciones MDM expira, mientras que un backend de aplicación puede perder la entrega de notificaciones debido a que su credencial de envío de notificaciones App Push es inválida. Tratar a ambos como un problema de “certificado de envío de notificaciones Apple” envía la investigación en la dirección incorrecta. | Para __CAPGO_KEEP_0__ y equipos de Ionic, el camino relevante para alertas de usuario es generalmente |
Envía alertas y otras notificaciones de aplicación a dispositivos de usuario final
For Capacitor and Ionic teams, the relevant path for user-facing alerts is generally App PushIngeniería de aplicaciones móviles o backend documentación del plugin de notificaciones Capacitor cubre la integración de lado de la aplicación, mientras que las credenciales de APNs pertenecen a la configuración del proveedor.
Comience con la rechazación, no con la interfaz de usuario
Verifique la respuesta de APNs desde el servidor de proveedor antes de cambiar el texto de la notificación o reconstruir la aplicación. Luego, verifique el identificador de paquete, la identidad de credenciales, el entorno y el estado del certificado. Un problema de permiso de notificación afecta la capacidad de un usuario para ver las alertas, pero no explica una rechazación de TLS desde APNs.
Si la falla apareció después de una liberación, compare la firma y las autorizaciones en la nueva compilación con la compilación anterior. Si apareció sin un cambio en la aplicación, inspeccione la expiración del certificado, la revocación, los cambios en el almacén de confianza y los secretos de implementación primero. Para un camino de implementación más amplio, consulte esta guía sobre Configuración de notificaciones de empuje de Expo.
Crear y descargar su certificado APNs
Una implementación de empuje puede fallar antes de que se envíe la primera notificación si el certificado se emite para el ID de App incorrecto o la clave privada se queda en otro Mac. El flujo de trabajo de Apple tiene dos partes: su máquina crea un Solicitud de firma de certificado, o CSR, y Apple la firma para el ID de App seleccionado. El CSR no es la credencial del servidor. Conecta el certificado emitido a una clave privada creada localmente.
Preparar el ID de App
Inicie sesión en el portal de desarrolladores de Apple y abra Certificados, Identificadores y Perfiles. Seleccionar Identificadores, elija el identificador de paquete de la aplicación y abra su configuración. Confirme que Notificaciones de Pulsación está habilitado antes de emitir cualquier cosa.
Los credenciales de APNs están vinculadas a la identidad de la aplicación. No elija un identificador de paquete cercano con un nombre similar. Configure cada aplicación independiente y emita el credencial correspondiente.
En el Mac que retendrá la clave, abra Acceso a la Caja de Llaves y cree el CSR, o utilice las herramientas de certificado aprobadas por su organización. Mantenga el archivo de solicitud y la clave privada bajo el mismo control de propiedad. Si otro administrador crea el CSR, ese administrador puede tener la clave privada necesaria más tarde para un paquete de servidor usable.
Emite el certificado firmado
Ingrese en Certificados, elija la opción de certificado del servicio de notificaciones de Apple. Seleccione el ID de la aplicación, suba el CSR y envíe la solicitud. Descargue el certificado que emita Apple.
Doble-click en el archivo descargado en el Mac que posee la clave privada. Debe instalarse en Acceso a la Caja de Llaves, donde puede verificar el certificado y su clave privada correspondiente. Un certificado importado sin esa clave no puede proporcionar la credencial completa que necesita su servidor.
Utilice una convención de nombres que registre la identidad de la aplicación, el entorno, el propietario y los detalles de expiración. Almacene el certificado original, la información de propiedad del CSR y los detalles de la cuenta del portal en el sistema de credenciales de su equipo. Un directorio de descargas de un desarrollador o una laptop personal no es un respaldo operativo.
El certificado solo apoya una parte de la entrega. La aplicación debe registrarse para notificaciones remotas, el servidor debe retener el token de dispositivo resultante y el proveedor debe enviar con el tema correspondiente y el entorno. Mantenga esas dependencias en el mismo libro de ejecución. Para la configuración del lado del cliente, consulte la Capacitor guía de integración de notificaciones
. Trate este certificado como una credencial administrada, no como un descarga única, 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.
A un certificado de Apple descargado no está automáticamente listo para un servicio de Node.js o un proveedor de notificaciones gestionado. El servidor necesita el certificado y su clave privada correspondiente, comúnmente empaquetados como un PKCS#12 .p12 archivo.
Abre Acceso a la llave en el Mac donde instalaste el certificado. Busca el certificado APNs, expande o inspecciona y localiza la clave privada con la información de identidad y expiración correspondiente. Selecciona el certificado y la clave privada juntos, luego utiliza la acción de exportación para guardar un .p12 archivo.
Valida el paquete antes de la implementación
Dale a la exportación una contraseña fuerte. La contraseña protege la clave privada dentro del paquete, así que no la coloques en un repositorio, ticket, mensaje de chat o registro de construcción. Carga el archivo y la contraseña a través de tu sistema de gestión de secretos, luego concede acceso solo al servicio que envía notificaciones.
Regla práctica: Un
.p12archivo sin su clave privada correspondiente no es un conjunto de credenciales de proveedor completo.
Antes del uso en producción, pruebe el paquete en un entorno controlado. Confirme que su backend puede cargar el archivo, establecer la conexión APNs y devolver errores estructurados cuando Apple rechace una solicitud. Si un proveedor como Capgo solicita un credencial de empuje iOS, suba el .p12 y su contraseña a través de la configuración de secreto designada en lugar de incorporar cualquiera de los valores en la aplicación code.
El formato también expone la debilidad del flujo de trabajo heredado. Debe preservar la clave privada original, repetir la exportación manual, proteger el archivo y reemplazar la clave de despliegue en el momento de la renovación. Los equipos que operan varios aplicativos pueden perder fácilmente el rastro de cuál paquete pertenece a qué ID de aplicación.
Use gestión de secretos seguros en las líneas de producción de CI/CD para controlar quién puede leer o reemplazar la credencial. Mantenga un registro de auditoría para las subidas y rotaciones, pero nunca registre la clave privada o la .p12 contraseña.
Para nuevos trabajos de backend, evalúe si la autenticación con certificado sigue siendo apropiada. Las integraciones existentes pueden requerir .p12pero la autenticación con token suele eliminar la reemplazación anual del certificado del proveedor de conexión. Eso no elimina la gobernanza de credenciales. Cambia qué proteges y rotas.
Migrar a la autenticación basada en tokens
Apple ha movido la autenticación APNs hacia tokens de proveedor, comúnmente llamado el flujo de trabajo p8. En lugar de presentar un certificado y una clave privada para una identidad TLS de larga duración, su proveedor firma tokens de autenticación con una clave de autenticación de servicio de notificación de Apple.
Crear la clave en el portal del desarrollador de Apple bajo Certificados, Identificadores y Perfiles, luego abrir Claves y registrar una clave de autenticación APNs. Descargar el .p8 archivo y registrar el ID de clave y el ID de equipo en su almacén secreto. Trate el archivo descargado como un secreto de firma de alto valor.
Hacer la migración de manera deliberada
No cambie el tráfico de producción reemplazando un archivo en un entorno no probado. Construya la autenticación de token al lado del camino de certificado existente, valide el comportamiento de sandbox y producción, y compare las respuestas APNs. Luego cambie la configuración del proveedor durante un despliegue controlado.
La migración elimina los pasos de renovación de certificado y exportación de Keychain del camino de envío, pero su equipo todavía necesita un modelo claro de propiedad. Decida quién puede crear, revocar y desplegar claves. Limitar el acceso al servicio de backend que firma tokens de proveedor y asegurarse de que exista un proceso de reemplazo de emergencia antes de que la clave actual se vuelva inaccesible.
Para una aplicación Capacitor, el cliente sigue necesitando la registro de notificaciones correcto y los permisos. La migración cambia principalmente la autenticación del servidor a APNsy no el registro del token de dispositivo code. Su servidor debe seguir asociando tokens con la aplicación y el entorno correctos.
Sabe cuándo siguen siendo necesarios los certificados
Algunas herramientas de empresa y las integraciones establecidas siguen exponiendo la configuración basada en certificados. No fuerce una migración p8 hasta que el sistema receptor lo soporte y su equipo haya probado el camino completo. Mantenga el legado protegido durante la transición, pero no cree nuevas dependencias en él cuando la autenticación de token se ajusta.
Si necesita comprender el flujo de aplicación circundante, revise notificaciones de Ionic y Capacitor con FirebaseFirebase puede proporcionar una capa de entrega de aplicaciones, pero los credenciales de Apple, los permisos, el registro y las respuestas de APNs requieren una configuración deliberada.
Renovando y Gestión del Ciclo de Vida de los Certificados
Trate un certificado APNs como una dependencia de producción caducada desde el día en que lo cree. Apple dice que estos certificados son válidos durante un año desde su creación y debe renovarse antes de la expiración para mantener la comunicación con el dispositivo. Apple también advierte que no renovar puede requerir a los usuarios que vuelvan a registrar dispositivos iOS, iPadOS y Mac con APNs y puede causar interrupciones de servicio. Consulte la documentación de renovación de certificados de notificación de Apple. documentación de renovación de certificados de notificación de Apple.
El camino de renovación es preciso:
- Generar un nuevo CSR: Crear la solicitud a través de su flujo de trabajo aprobado y preservar el material de clave asociado.
- Usar el ID de Apple original: Iniciar sesión con el mismo ID de Apple utilizado para crear el certificado existente.
- Seleccionar el certificado que vence: Coincidir con el ID de aplicación, el DN de sujeto, el UID y los detalles de expiración antes de seleccionar Renovar.
- Subir el CSR: Enviar la nueva solicitud en el Portal de Certificados de Notificación de Apple Push.
- Descargar e instalar de nuevo: Recuperar el renovado
.pem, instálalo donde esté disponible la clave privada, y exporta una reemplazo.p12si tu proveedor lo requiere. - Desplegar y probar: Actualizar el secreto del servidor, enviar una notificación controlada, e inspeccionar la respuesta de APNs.
Comparar los formatos del proveedor
| Requisito | Flujo de certificado | Flujo de token |
|---|---|---|
| Secreto principal | Certificado más clave privada | .p8 clave de autenticación |
| Preocupación de renovación | La expiración del certificado requiere reemplazo recurrente | Sin reemplazo anual de certificado |
| Trabajo de implementación | Instalar, pair, exportar y subir | Almacenar la clave de firma y configurar la generación de tokens |
| Principal riesgo de falla | Certificado incorrecto, clave privada faltante, vencimiento o revocación | Clave de autenticación perdida, expuesta o revocada |
El ecosistema de certificados de Apple también ha requerido trabajo de cadena de confianza programado. Apple anunció actualizaciones del servidor de certificados APNs para el entorno de pruebas el 20 de enero de 2025 y producción en 24 de febrero de 2025, requiriendo que los almacenes de confianza incluyan el certificado de la Autoridad de Certificación RSA de USERTrust SHA-2 Root Lee el anuncio del servidor de certificados APNs de Apple y haz que la propiedad del almacén de confianza sea parte de tu lista de verificación de plataforma. Utiliza un calendario de renovación compartido, un propietario designado y un libro de despliegue. La
documentación de gestión de certificados __CAPGO_KEEP_0__ Capgo certificate management documentation Resolución de problemas y manejo de credenciales perdidas
El incidente difícil no siempre es una advertencia de expiración. Es la mañana en que el administrador que creó el certificado ha dejado, la clave privada existe solo en un viejo Mac, o un certificado fue revocado durante una limpieza intentada. El flujo de renovación estándar depende de la ID original de Apple y la identidad del certificado correcta, por lo que el acceso y la procedencia importan tanto como el archivo en sí.
Resolución de problemas y manejo de credenciales perdidas
Comience clasificando la falla:
- Certificado vencido: Genere una reemplazo a través de la cuenta original, vuelva a instalarlo con la clave privada correspondiente, actualice el proveedor y pruebe la entrega. Si la comunicación con el dispositivo ya ha sido interrumpida, siga la guía de recuperación de Apple en lugar de asumir que un reemplazo de servidor instantáneo restaura todos los dispositivos.
- Certificado revocado: Deje de tratar la credencial antigua como recuperable. Apple rechaza las conexiones TLS de servidores que utilizan certificados revocados, por lo que cree un reemplazo válido y elimine el secreto revocado de las implementaciones activas. Verifique quién lo revocó y si otros sistemas copiaron la misma credencial.
- Perdido
.p12contraseña: Un archivo de certificado sin la contraseña usable puede estar inoperativo. Recupere el respaldo aprobado o emita un reemplazo en lugar de debilitar los controles de secretos de producción. - Perdida la clave privada: Re-descargando el certificado público no recreará la clave privada. Crea un nuevo CSR en una máquina controlada y emita un reemplazo de credencial.
- Perdida la accesibilidad a Apple ID: Confirme si la organización puede recuperar la cuenta a través de sus procesos de identidad y despliegue. Apple dirige el soporte para los certificados de APNs creados a través del portal relevante a Programas de Despliegue Soporte.
La recuperación requiere identidad, no solo un nombre de archivo. Registre el dueño de Apple ID, el ID de la aplicación, la identidad del certificado, la ubicación de la clave privada, la configuración del proveedor y el procedimiento de reemplazo antes de que ocurra un incidente.
Construya una red de seguridad operativa
Coloque los certificados y las .p8 llaves en un almacén compartido, controlado por acceso. Almacene la contraseña por separado del archivo, restrinja el acceso a producción y documente el portal de cuentas exacto utilizado para la renovación. Su sistema de CI/CD debe inyectar secretos en el momento de despliegue y ejecutar una verificación de salud que detecte fallos de autenticación antes de que los usuarios informen de alertas faltantes. .p12 Mantenga disponible el antiguo credencial durante un reemplazo controlado cuando el plataforma lo permita, pero no deje secretos obsoletos activos indefinidamente. Pruebe un reemplazo en el mismo camino de backend que la producción utiliza, incluyendo el entorno del proveedor, el identificador de la aplicación y el almacenamiento de tokens de dispositivo.
Cuando ya ha ocurrido un corte, preservar los cuerpos de respuesta de APNs y los tiempos de marcaje, identifique la primera solicitud rechazada y compare el secreto de despliegue antes y después del incidente. No retente indefinidamente contra un credencial inválido. Corrija el problema de identidad o autenticación primero, luego envíe una pequeña notificación de verificación a un dispositivo de prueba conocido.
__CAPGO_KEEP_0__ puede almacenar y configurar credenciales de empuje de iOS como parte de un flujo de trabajo de notificación __CAPGO_KEEP_1__, mientras su equipo retiene la responsabilidad de acceso a la cuenta de Apple, custodia de secretos y decisiones de renovación. Visite
Capgo can store and configure iOS push credentials as part of a Capacitor notification workflow, while your team retains responsibility for Apple account access, secret custody, and renewal decisions. Visit Capgo para revisar cómo su herramienta de entrega móvil puede adaptarse a su ciclo de credenciales de APNs y proceso de lanzamiento.
