Saltar al contenido principal

Cómo administrar certificados de servicio de notificaciones push de Apple

Domine los certificados del servicio de notificaciones de Apple con esta guía completa. Aprenda a crear, exportar a .p12, renovar, migrar a p8 y solucionar problemas.

Cómo administrar certificados del Servicio de Notificaciones Push de Apple

Los certificados del servicio de notificaciones de Apple Push son válidos durante un año y deben renovarse anualmente en el Portal del Desarrollador 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. Se lanza una versión, se programa una campaña 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 de la Tabla

Why Push Notifications Stop Working

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 que la envíe a la aplicación registrada y al 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 las 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 de proveedor.

Cuatro razones comunes por las que las notificaciones de Apple dejan de funcionar, incluyendo la expiración de certificados y la rechazación del servidor.

Separar la notificación de empuje 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
App Push Envía alertas y otras notificaciones de aplicación a dispositivos de usuarios finales Ingeniería móvil o backend
MDM Push 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 contacto con dispositivos inscritos cuando expire su credencial de empuje MDM, 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 empuje de Apple' envía la depuración en la dirección incorrecta.

Para Capacitor y equipos de Ionic, la ruta relevante para las alertas de usuario es generalmente App Push. La aplicación todavía necesita la capacidad de notificaciones de Push, firma correcta, registro de dispositivo y un backend que envíe a través del entorno de APNs adecuado. 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. La documentación del plugin de notificaciones de Capacitor Cubre la integración del lado de la aplicación, mientras que las credenciales de APNs pertenecen a la configuración del proveedor.

Comienza con el rechazo, no con la interfaz

Si la falla apareció después de una liberación, compare la firma y las facultades en la nueva compilación con la compilación anterior. Si apareció sin un cambio de aplicación, inspeccione la expiración del certificado, la revocación, los cambios en el almacén de confianza y los secretos de despliegue primero. Para una ruta de implementación más amplia, consulte esta guía para

If the failure appeared after a release, compare the signing and entitlements in the new build with the previous build. If it appeared without an app change, inspect certificate expiration, revocation, trust-store changes, and deployment secrets first. For a broader implementation path, see this guide to Crear y descargar su certificado de APNs.

Crear y Descargar su Certificado APNs

A push rollout can fail before the first notification is sent if the certificate is issued for the wrong App ID or the private key stays on another Mac. Apple’s workflow has two parts: your machine creates a Solicitud de firma de certificadoo CSR, y Apple lo 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

Iniciar sesión en el portal del desarrollador de Apple y abrir Certificados, Identificadores y Perfiles. Seleccionar Identificadores, elegir el identificador de paquete de la aplicación, y abrir su configuración. Confirmar que notificaciones de empuje está habilitado antes de emitir nada.

APNs credentials are tied to the application identity. Do not choose a nearby bundle identifier with a similar name. Configure each separate application independently and issue the matching credential.

Abra el Mac que retenga la clave Acceso a la Caja de Claves y crear el CSR, o utilice 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 mantener la clave privada necesaria más tarde para un paquete de servidor usable.

Un monitor de computadora mostrando una interfaz de línea de comandos de terminal de Linux utilizada para generar certificados SSL.

Emite el certificado firmado

In CertificadosElija la opción de certificado del servicio de notificación de Apple. Seleccione el ID de la aplicación, suba el CSR y envíe la solicitud. Descargue el certificado que Apple emita.

Doble-click en el archivo descargado en el Mac que posee la clave privada. Debe instalarse en Acceso a la Caja de Claves, 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 backend.

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. La carpeta de descargas de un desarrollador o la 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 el Capacitor guía de integración de notificacionesTrate este certificado como un 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.

Exportar el Certificado a una Clave Privada

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 archivo PKCS#12 .p12 archivo.

Abrir Acceso a la Caja de Llaves en la Mac donde instalaste el certificado. Busca el certificado APNs, expande o inspecciona y localiza la clave privada con la información de identidad y fecha de caducidad correspondientes. Selecciona el certificado y la clave privada juntos, luego utiliza la acción de exportación para guardar un .p12 archivo.

Validar el paquete antes de la implementación

Proporciona 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 .p12 archivo sin su clave privada correspondiente no es un credencial de proveedor completo.

Antes del uso en producción, pruebe el paquete en un entorno controlado. Confirme que su backend pueda 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 secreta designada en lugar de incluir cualquiera de los valores en el 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 flujos 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 de certificado sigue siendo apropiada. Las integraciones existentes pueden requerir .p12pero la autenticación de token suele eliminar la reemplazación anual del certificado de la conexión del proveedor. Eso no elimina la gobernanza de credenciales. Cambia qué proteges y rotas.

Migrar al nuevo token de autenticación

Apple ha movido la autenticación de 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 notificación de Apple Push.

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. Descargue el .p8 Almacene el ID de clave y el ID de equipo asociados 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 junto a la ruta de certificado existente, valide el comportamiento de sandbox y producción, y compare las respuestas de APNs. Luego, realice el cambio de configuración del proveedor durante una implementación controlada.

La migración elimina los pasos de renovación de certificado y exportación de Keychain de la ruta 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 los tokens de proveedor, y asegúrese de que existe 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 la registro de notificaciones y las concesiones correctas. La migración cambia principalmente autenticación del servidor con APNsNo es el registro del token del dispositivo code. Su backend debe seguir asociando tokens con la aplicación y entorno correctos.

Un desarrollador codificando en una laptop en una mesa con un tazón de café y una planta cerca.

Conozca cuándo siguen siendo necesarios los certificados

Algunas herramientas de empresa y integraciones establecidas siguen exponer la configuración basada en certificados. No fuerce una migración p8 hasta que el sistema receptor la 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 es adecuada.

Si necesita comprender el flujo de aplicación circundante, revise Ionic y Capacitor de notificaciones push con FirebaseFirebase puede proporcionar una capa de entrega de aplicaciones, pero los credenciales de Apple, las autorizaciones, la inscripción y las respuestas de APNs requieren una configuración deliberada.

Renovar y Administrar Ciclos de Certificados

Trate un certificado de APNs como una dependencia de producción caducable desde el día que lo crees. Apple dice que estos certificados son válidos durante un año desde su creación and must be renewed before expiration to preserve device communication. Apple also warns that failing to renew can require users to reregister iOS, iPadOS, and Mac devices with APNs and can cause service interruptions. See Apple’s documentación de renovación de certificados de notificaciones push.

La ruta de renovación es precisa:

  1. Usar la cuenta de Apple original: Iniciar sesión con la misma cuenta de Apple utilizada para crear el certificado existente.
  2. Utilice la ID de Apple original: Inicia sesión con la misma cuenta de Apple utilizada para crear el certificado existente.
  3. Seleccione el certificado que vence: Coincidir el ID de la aplicación, el DN del sujeto, el UID y los detalles de expiración antes de seleccionar Renueva.
  4. Suba el CSR: Envíe la nueva solicitud en el Portal de Certificados de Push de Apple.
  5. Descargue e instale: Recupere el renovado .pem, instálelo donde esté disponible la clave privada, y exporte una reemplazo .p12 Si su proveedor lo requiere.
  6. Implemente y pruebe: Actualice el secreto del servidor, envíe una notificación controlada y inspeccione la respuesta de APNs.

Compare 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 No reemplazo anual de certificado
Trabajo de despliegue Instalar, pair, exportar y subir Clave de firma de tienda 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 en cadena de confianza programado. Apple anunció actualizaciones de certificados de servidor APNs para sandbox en 20 de enero de 2025 y para la producción el 24 de febrero de 2025requiriendo que las tiendas de confianza incluyan el Autoridad de Certificación RSA de Usuario de Raíz SHA-2 certificado. Lee el Anuncio de certificado de servidor APNs de Apple haga parte de su lista de verificación de plataforma.

Utilice un calendario de renovación compartido, un propietario nombrado y un libro de ejecución de despliegue. La documentación de gestión de certificados Capgo pueden estar junto a ese runbook para equipos que gestionan credenciales de iOS en su proceso de lanzamiento móvil.

Resolución de problemas y manejo de credenciales perdidas

No siempre el incidente difícil 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 cuenta Apple original y la identidad del certificado correcta, por lo que el acceso y la procedencia importan tanto como el archivo en sí.

Comience clasificando el fracaso:

  • Certificado vencido: Genere un reemplazo a través de la cuenta original, reinstálelo con la clave privada correspondiente, actualice el proveedor y pruebe la entrega. Si la comunicación con los dispositivos ya ha sido interrumpida, siga la guía de recuperación de Apple en lugar de asumir que un reemplazo de servidor instantáneamente restaura todos los dispositivos.
  • Certificado revocado: Deje de tratar la credencial antigua como recuperable. Apple rechaza conexiones TLS de servidores que utilizan certificados revocados, así 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.
  • Lost .p12 password: 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 secreto de producción.
  • Clave privada perdida: Descargar nuevamente el certificado público no recreará la clave privada. Crea un nuevo CSR en una máquina controlada y emita un reemplazo de credenciales.
  • Acceso a Apple ID perdido: Confirme si la organización puede recuperar la cuenta a través de sus procesos de identidad y despliegue. Apple dirige el soporte para certificados APNs creados a través del portal relevante a Apoyo de Programas de Despliegue.

La recuperación requiere identidad, no solo un nombre de archivo. Registre el dueño de Apple ID, ID de aplicación, identidad de 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 .p8 Almacenar las llaves en un almacén compartido y controlado por acceso. .p12 contraseña separadamente del archivo, restrinja el acceso de producción, y documente el portal de cuenta exacto utilizado para la renovación. Su sistema de CI/CD debe inyectar secretos en el momento de la implementación y ejecutar una verificación de salud que detecte fallas de autenticación antes de que los usuarios informen de alertas faltantes.

Considere mantener disponible la credencial antigua durante un reemplazo controlado cuando el plataforma lo permita, pero no dejes secretos obsoletos activos indefinidamente. Prueba un reemplazo en el mismo camino de backend que el producción utiliza, incluyendo el proveedor de entorno, identificador de paquete y almacén de tokens de dispositivo.

Cuando ya ha ocurrido una interrupción, preserva los cuerpos de respuesta de APNs y los tiempos de marcaje, identifica la primera solicitud rechazada y compara el secreto de despliegue antes y después del incidente. No retires indefinidamente contra una credencial inválida. Corrige el problema de identidad o autenticación primero, luego envía una pequeña notificación de verificación a un dispositivo de prueba conocido.

Capgo puede almacenar y configurar credenciales de empuje iOS como parte de un flujo de trabajo de notificación Capacitor, mientras que su equipo retiene la responsabilidad de acceso a la cuenta de Apple, custodia de secretos y decisiones de renovación. Visite Capgo Revisar cómo sus herramientas de entrega móvil pueden adaptarse a su ciclo de credenciales de APNs y proceso de lanzamiento.

Actualizaciones en vivo para aplicaciones Capacitor

When a web-layer bug is live, ship the fix through Capgo instead of waiting days for app store approval. Users get the update in the background while native changes stay in the normal review path.

Soporte humano de Martin

Comienza Ahora

Últimas noticias de nuestro Blog

Capgo gives you the best insights you need to create a truly professional mobile app.