Los certificados de servicio de notificaciones 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 con los 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 está programada y la entrega de notificaciones se vuelve silenciosa. Su servidor de aplicación puede aceptar trabajos aún, 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. Necesitas entender qué credencial de APNs utiliza tu sistema, preservar la clave privada, planificar la renovación y mover las cargas de trabajo adecuadas a la autenticación basada en tokens.
Contenido de la Tabla
- ¿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 Gestionando Ciclos de Certificados
- Solucionando Problemas y Manejando Credenciales Perdidas
¿Por qué las Notificaciones de Pulsación 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 registrada y el dispositivo. 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 la entrega.
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 la aplicación 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 |
|---|---|---|
| Push de la aplicación | Envía alertas y otras notificaciones de la aplicación a dispositivos de usuario final | Ingeniería de móviles o backend |
| Push MDM | Permite que una plataforma de gestión de dispositivos comunique con dispositivos Apple gestionados | Administración de IT, punto final o movilidad empresarial |
Estos credenciales no son intercambiables. Una plataforma MDM puede perder el contacto con dispositivos inscritos cuando su credencial de push MDM expira, mientras que un backend de aplicación puede perder la entrega de notificaciones debido a que su credencial de App Push es inválida. Tratar a ambos como un problema de 'certificado de push Apple' envía la investigación de problemas en la dirección incorrecta.
Para Capacitor y equipos de Ionic, el camino relevante para alertas de usuario es generalmente Push de la aplicaciónEl aplicativo todavía necesita la capacidad de notificaciones de Push, firmado correctamente, registro de dispositivo y un backend que envíe a través del entorno de APNs apropiado. Si su equipo también está enviando activos web sobre la red, mantenga ese flujo de liberación separado de la autenticación de empuje. Capacitor plugin de notificaciones de la documentación de Capgo aborda la integración del lado de la aplicación, mientras que los credenciales de APNs pertenecen a la configuración del proveedor.
Comience con la rechazada, 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 notificaciones, pero no explica una rechazada de TLS de 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 de aplicación, inspeccione la expiración, revocación, cambios en el almacén de confianza y secretos de implementación primero. Para un camino de implementación más amplio, consulte esta guía sobre Configuración de notificaciones de Expo.
Crear y descargar su certificado de APNs
Una implementación de empuje puede fallar antes de enviar la primera notificación si el certificado se emite para el ID de App incorrecto o la clave privada permanece 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án habilitadas 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 Claves 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 servidor bundle usable.
Emite el certificado firmado
Inicia CertificadosPara elegir el certificado de servicio de notificaciones de Apple, selecciona la opción de certificado de servicio de notificaciones de Apple. Selecciona el ID de la aplicación, sube el CSR y envía la solicitud. Descarga el certificado que emite Apple.
Dobla el archivo descargado en el Mac que posee la clave privada. Debe instalarse en Acceso a la cadena de claves, donde puedes verificar el certificado y su clave privada correspondiente. Un certificado importado sin esa clave no puede proporcionar la credencial completa que necesita su servidor.
Utiliza una convención de nombres que registre la identidad de la aplicación, el entorno, el propietario y los detalles de expiración. Almacena el certificado original, la información de propiedad del CSR y los detalles de la cuenta del portal en el sistema de credenciales de tu equipo. Un carrito de descargas de un desarrollador o una laptop personal no es un respaldo operativo.
El certificado solo soporta 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. Mantén esas dependencias en el mismo libro de ejecución. Para la configuración del lado del cliente, consulta la Capacitor guía de integración de notificaciones
. Trata este certificado como una credencial administrada, no como una 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 administrado. El servidor necesita el certificado y su clave privada correspondiente, comúnmente empaquetados como un PKCS#12 .p12 archivo.
Abre Acceso a la llave de la caja 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. Sube 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 servidor de 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 de iOS, suba el archivo y su contraseña a través de la configuración de secreto designada en lugar de incluir cualquiera de estos valores en la aplicación Capgo. .p12 y su contraseña a través de la configuración de secreto designada en lugar de incluir cualquiera de estos 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 nueva autenticación basada en tokens
Apple ha movido la autenticación APNs hacia tokens de proveedorcomúnmente llamado el flujo de trabajo p8En 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 de APNs. Descargar el 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. .p8 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 tokens al lado del camino existente de certificado, valide el comportamiento de sandbox y producción, y compare las respuestas de APNs. Luego cambie 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 camino de envío, pero su equipo todavía necesita un modelo de propiedad claro. Decida quién puede crear, revocar y desplegar claves. Limitar el acceso al servicio de backend que firma tokens de proveedor, y asegúrese de que exista un proceso de reemplazo de emergencia antes de que la clave actual se vuelva inaccesible.
La migración elimina los pasos de renovación de certificados y exportación de Keychain del camino de envío, pero su equipo todavía necesita un modelo de propiedad claro. Decida quién puede crear, revocar y desplegar claves. Limitar el acceso al servicio de backend que firma tokens de proveedor, y asegúrese 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 todavía necesita una correcta registro y permisos de notificación. 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 entorno correctos.
Sabe cuándo siguen siendo necesarias las certificaciones
Algunas herramientas de empresa y integraciones establecidas siguen exponiendo configuraciones basadas en certificados. No fuerce una migración p8 hasta que el sistema receptor la soporte y su equipo haya probado el camino completo. Mantenga la credencial legado protegida durante la transición, pero no cree nuevas dependencias en ella cuando la autenticación de token se adapte.
Si necesita comprender el flujo de aplicación circundante, revise notificaciones de empuje de Ionic y Capacitor con Firebase. Firebase puede proporcionar una capa de entrega de aplicaciones, pero los credenciales de Apple, permisos, registro y respuestas de APNs requieren una configuración deliberada.
Renovando y Gestión de Ciclos de Vida de Certificados
Trate un certificado APNs como una dependencia de producción caducable desde el día 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 preservar la comunicación del dispositivo. Apple también advierte que no renovar puede requerir a los usuarios que vuelvan a registrarse los 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 certificado 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 App, DN de sujeto, UID y 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állo 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 | Ciclo de certificado | Ciclo 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 |
| Riesgo principal 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 Lea el anuncio del servidor de certificados de APNs de Apple y haga que la propiedad del almacén de confianza sea parte de su lista de verificación de plataforma. Utilice un calendario de renovación compartido, un propietario designado y un libro de despliegue. La
__CAPGO_KEEP_0__ documentación de gestión de certificados 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 se revocó 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 un 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 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 credenciales.
- Perdida acceso a Apple ID: Confirme si la organización puede recuperar la cuenta a través de sus procesos de identidad y implementación. Apple dirige el soporte para certificados 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, ID de la aplicación, identidad del certificado, ubicación de la clave privada, configuración del proveedor y 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 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 Considere mantener el antiguo credencial disponible 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 paquete y el almacenamiento de tokens de dispositivo.
Cuando un corte ya ha ocurrido, preservar los cuerpos de respuesta de APNs y los tiempos de marcaje, identifique la primera solicitud rechazada y compare la clave de despliegue antes y después del incidente. No intente de manera indefinida contra una credencial inválida. 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 ajustarse a su ciclo de vida de credenciales de APNs y proceso de lanzamiento.
