Les certificats du service de notification Push Apple sont valables pendant une année et doivent être renouvelés chaque année dans le Portail du développeur Apple pour éviter d'interrompre la communication avec les appareils. Si vous êtes responsable d'une application Capacitor, un certificat expiré ou révoqué peut arrêter les notifications même si l'application elle-même semble en bonne santé.
La panne se produit souvent au moment le plus inopportun. Une mise à jour est lancée, une campagne est planifiée, et la livraison des notifications devient soudainement silencieuse. Votre serveur d'application peut toujours accepter des tâches, mais APNs peuvent rejeter la connexion TLS avant que le message atteigne un appareil. La solution pratique n'est pas seulement de créer un autre certificat. Vous devez comprendre quelles informations APNs votre système utilise, conserver la clé privée, planifier le renouvellement et déplacer les charges de travail appropriées vers l'authentification basée sur jeton.
Table des matières
- Why Push Notifications Stop Working
- Créer et télécharger votre certificat APNs
- Exporter le certificat vers une clé privée
- Migrer vers la nouvelle authentification basée sur jeton
- Gestion et renouvellement des cycles de vie des certificats
- Diagnostic et gestion des informations d'identification perdues
Why Push Notifications Stop Working
APNs se situe entre votre serveur de fournisseur et l'appareil Apple de l'utilisateur. Votre serveur s'authentifie auprès d'Apple, soumet une notification et se fie à APNs pour la transmettre à l'application et à l'appareil enregistrés. Si les informations d'identification sont expirées, révoquées, associées à une identité incorrecte ou installées incorrectement, la demande peut échouer avant le début de la livraison.
Apple indique que APNs garde une liste des certificats révoqués et refuse les connexions TLS de serveurs utilisant des certificats sur cette liste. Cela rend l'hygiène des certificats un prérequis de livraison, et non une préférence administrative. Le serveur peut continuer à traiter les tâches de notification localement, tandis que Apple rejette la connexion du fournisseur.
Séparer la push de l'application de la push MDM
La première question de diagnostic est simple : Quel service essayez-vous de mettre en œuvre ?
| Chemin des certificats | Ce qu'il fait | Propriétaire typique |
|---|---|---|
| App Push | Envoie des alertes et d'autres notifications d'application aux appareils de fin d'utilisateur | Ingénierie mobile ou backend |
| Mise à jour Push | Permet à une plateforme de gestion de dispositifs de communiquer avec des appareils Apple gérés | Administration IT, point de terminaison ou mobilité d'entreprise |
Ces certificats ne sont pas interchangeables. Une plateforme MDM peut perdre contact avec les appareils inscrits lorsque son certificat MDM push expire, tandis qu'un backend d'application peut perdre la livraison de notifications en raison d'un certificat App Push non valide. Considérer les deux comme un problème de « certificat Apple push » envoie la recherche de solutions dans la mauvaise direction.
Pour Capacitor et les équipes Ionic, le chemin pertinent pour les alertes destinées aux utilisateurs est généralement App Push. L'application nécessite toujours la capacité de notifications Push, la signature correcte, l'enregistrement du dispositif et un backend qui envoie dans l'environnement APNs approprié. Si votre équipe expédie également des actifs web à distance, gardez ce flux de publication séparé de l'authentification Push. La Capacitor documentation du plugin de notifications couvre l'intégration côté application, tandis que les informations de compte APNs appartiennent à la configuration du fournisseur.
Commencez par la réjection, pas par l'interface.
Vérifiez la réponse APNs de votre serveur de fournisseur avant de modifier le texte des notifications ou de reconstruire l'application. Vérifiez ensuite l'identifiant de l'ensemble, l'identité de la clé, l'environnement et l'état du certificat. Un problème de permission de notification affecte la capacité d'un utilisateur à voir les alertes, mais il n'explique pas un rejet TLS de la part d'APNs.
Si l'échec est apparu après une mise à jour, comparez les signatures et les autorisations dans la nouvelle build avec la build précédente. Si l'échec est apparu sans changement d'application, inspectez l'expiration, la révocation, les modifications du magasin de confiance et les secrets de déploiement en premier. Pour un chemin d'implémentation plus large, consultez ce guide sur la configuration de notifications push Expo.
la création et le téléchargement de votre certificat APNs
Une mise en production de Push peut échouer avant que la première notification soit envoyée si le certificat est émis pour le mauvais ID d'application ou si la clé privée reste sur un autre Mac. Le workflow d'Apple comporte deux parties : votre machine crée une requête de signature de certificatou CSR, et Apple la signe pour l'ID d'application sélectionné. Le CSR n'est pas le certificat de serveur. Il relie le certificat émis à une clé privée créée localement.
Préparez l'ID d'application
Connectez-vous au portail Apple Developer et ouvrez Certificats, Identifiants & Profils. Sélectionnez Identifiants, choisissez l'identifiant de l'application, et ouvrez sa configuration. Confirmez que Notifications Push est activé avant d'émettre quoi que ce soit.
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.
est activé avant de procéder à l'émission. Accès au cléchain et créez le CSR, ou utilisez les outils de certification approuvés par votre organisation. Gardez le fichier de demande et la clé privée sous le même contrôle d'accès. Si un autre administrateur crée le CSR, cet administrateur peut conserver la clé privée requise ultérieurement pour un serveur bundle utilisable.
Émettre le certificat signé
In Certificats, choisissez l'option de certificat du service de notification Push Apple. Sélectionnez l'ID d'application, téléchargez le CSR et soumettez la demande. Téléchargez le certificat émis par Apple.
Dédoublez sur le Mac qui possède la clé privée. Il devrait s'installer dans Accès à la clé, où vous pouvez vérifier le certificat et sa clé privée correspondante. Un certificat importé sans cette clé ne peut pas fournir le crédit complet dont votre backend a besoin.
Utilisez une convention de nommage qui enregistre l'identité de l'application, l'environnement, le propriétaire et les détails d'expiration. Stockez le certificat original, les informations d'ownership du CSR et les détails du compte de portail dans votre système de crédentials d'équipe. Le dossier Téléchargements d'un développeur ou le portable personnel ne constituent pas un système de sauvegarde opérationnel.
Le certificat ne prend en charge que la partie de la livraison. L'application doit s'inscrire pour les notifications à distance, le serveur doit conserver le jeton de périphérique résultant et le fournisseur doit envoyer avec le sujet correspondant et l'environnement. Conservez ces dépendances dans le même livre de cours. Pour la configuration côté client, consultez le Capacitor guide d'intégration des notificationsConsidérez ce certificat comme un crédential géré, et non comme un téléchargement unique, car l'exportation ultérieure, la migration du jeton, la renouvellement et la récupération dépendent de la connaissance de qui contrôle sa clé.
Exporter le Certificat vers une Clé Privée
Un certificat Apple téléchargé n'est pas automatiquement prêt pour un service Node.js ou un fournisseur de push géré. Le serveur a besoin du certificat et de sa clé privée correspondante, généralement emballée dans un fichier PKCS#12 .p12 fichier.
Ouvrir Clés d'Accès sur le Mac où vous avez installé le certificat. Cherchez le certificat APNs, le développez ou l'inspectez, et localisez la clé privée avec l'identité et les informations d'expiration correspondantes. Sélectionnez le certificat et la clé privée ensemble, puis utilisez l'action d'exportation pour sauvegarder un .p12 fichier.
Valider le bundle avant déploiement
Donnez à l'export un mot de passe solide. Le mot de passe protège la clé privée à l'intérieur du bundle, ne le placez donc pas dans un dépôt, un ticket, un message de chat ou un journal de construction. Envoyez le fichier et le mot de passe à travers votre système de gestion des secrets, puis accordez l'accès uniquement au service qui envoie des notifications.
Règle pratique : Un
.p12Un fichier sans sa clé privée correspondante n'est pas un credencial de fournisseur complet.
Avant une utilisation en production, testez le bundle dans un environnement contrôlé. Confirmez que votre backend peut charger le fichier, établir la connexion APNs et retourner des erreurs structurées lorsque Apple rejette une demande. Si un fournisseur tel que Capgo demande un credencial iOS de push, téléchargez le .p12 et son mot de passe à travers la configuration secrète désignée plutôt que de les intégrer dans l'application code.
La forme expose également la faiblesse du workflow de legacy. Vous devez conserver la clé privée originale, répéter une exportation manuelle, protéger le fichier et remplacer le secret de déploiement à l'heure de la renouvellement. Les équipes opérant plusieurs applications peuvent facilement perdre le fil de quel bundle appartient à quel ID d'application.
Utilisez la gestion de secrets sécurisée dans les pipelines CI/CD pour contrôler qui peut lire ou remplacer le credencial. Conservez un journal d'audit pour les téléchargements et les rotations, mais n'inscrivez jamais la clé privée ou le .p12 mot de passe.
Pour de nouvelles tâches backend, évaluez si l'authentification par certificat est toujours appropriée. Les intégrations existantes peuvent nécessiter .p12mais l'authentification par jeton supprime généralement la remplacement annuel du certificat de la connexion au fournisseur. Cela n'élimine pas la gouvernance des credenciaux. Cela change ce que vous protégez et que vous faites tourner.
Migrer vers la nouvelle authentification basée sur jeton
Apple a déplacé l'authentification APNs vers les jetons de fournisseur, communément appelés le flux de travail p8. Au lieu de présenter un certificat et une clé privée pour une identité TLS à durée de vie longue, votre fournisseur signe les jetons d'authentification avec une clé de notification Push Apple Authentication.
Créez la clé dans le portail Apple Developer sous Certificats, Identifiants & Profils, puis ouvrez Clés et enregistrez une clé d'authentification APNs. Téléchargez le .p8 fichier et enregistrez l'ID de clé et l'ID d'équipe dans votre magasin de secrets. Traitez le fichier téléchargé comme un secret de signature à haute valeur.
Effectuez la migration délibérément
N'activez pas le trafic de production en remplaçant un fichier dans un environnement non testé. Créez une authentification par jeton à côté de la voie existante du certificat, validez le comportement de l'environnement de test et de production, et comparez les réponses APNs. Faites ensuite la modification de la configuration du fournisseur lors d'une mise en production contrôlée.
La migration supprime les étapes de renouvellement de certificat et d'exportation de cléchain de la voie d'envoi, mais votre équipe a toujours besoin d'un modèle d'appartenance clair. Décidez qui peut créer, révoquer et déployer des clés. Limitez l'accès au service backend qui signe les jetons de fournisseur, et assurez-vous qu'un processus de remplacement d'urgence existe avant que la clé actuelle ne devienne indisponible.
Pour une application Capacitor, le client a toujours besoin d'une inscription correcte aux notifications et d'entitlements. La migration change principalement l'authentification serveur-APNset non l'inscription du jeton de l'appareil code. Votre backend doit continuer à associer les jetons avec l'application et l'environnement corrects.
Sachez quand les certificats restent nécessaires
Certains outils d'entreprise et des intégrations établies exposent encore une configuration basée sur des certificats. N'obligez pas une migration p8 jusqu'à ce que le système de réception le supporte et que votre équipe ait testé la voie complète. Gardez le crédentiel de legacy protégé pendant la transition, mais n'installez pas de nouvelles dépendances à son égard lorsque l'authentification par jeton convient.
Si vous avez besoin de comprendre le flux d'application entourant, passez en revue Ionic et Capacitor notifications push avec FirebaseFirebase peut fournir un niveau de livraison d'application, mais les informations d'identification Apple, les autorisations, l'enregistrement et les réponses APNs nécessitent une configuration délibérée.
Renouveler et Gérer les Cycles de Vie des Certificats
Traitez un certificat APNs comme une dépendance de production expirante à partir du jour de sa création. Apple indique que ces certificats sont valables pendant une année à partir de leur création 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 Le chemin de renouvellement est précis :.
Générez une nouvelle demande de certificat :
- Générer un nouveau CSR : Créez la demande à travers votre workflow approuvé et conservez le matériel de clé associé.
- Utilisez l'identifiant Apple original : Se connecter avec le même identifiant Apple utilisé pour créer le certificat existant.
- Sélectionnez le certificat expirant : Vérifiez l'ID d'application, le sujet DN, l'UID et les détails d'expiration avant de sélectionner Renouvelez.
- Téléchargez le CSR : Soumettez la nouvelle demande dans le Portail des Certificats Push Apple.
- Téléchargez et réinstallez : Récupérez le renouvelé
.pem, installez-le là où la clé privée est disponible, et exportez une remplacement.p12Si votre fournisseur le nécessite. - Déployez et testez : Mettez à jour le secret du serveur, envoyez une notification contrôlée, et inspectez la réponse APNs.
Comparez les formats du fournisseur
| Exigence | Flux de certificat | Flux de jeton |
|---|---|---|
| Secret principal | Certificat et clé privée | .p8 Clé d'authentification |
| Préoccupation de renouvellement | Remplacement de certificat nécessitant un renouvellement récurrent | Pas de remplacement de certificat annuel |
| Travail de déploiement | Installer, pair, exporter et télécharger | Stockez la clé de signature et configurez la génération de jetons |
| Principal risque de panne | Certificat incorrect, clé privée manquante, expiration ou révocation | Clé d'authentification perdue, exposée ou révoquée |
L'écosystème de certificat d'Apple a également nécessité du travail de chaîne de confiance planifié. Apple a annoncé des mises à jour des certificats de serveur APNs pour le sandbox. 20 janvier 2025 et pour la production le 24 février 2025exigeant que les magasins de confiance incluent le certificat SHA-2 Root USERTrust RSA Certification Authority certificat. Lisez le Annonce de certificat du serveur APNs d'Apple faire partie de votre liste de vérification de plateforme pour la propriété du trust-store.
Utilisez un calendrier de renouvellement partagé, un propriétaire nommé et un livre de déploiement. Documentation de gestion des certificats Capgo Puisqu'ils peuvent s'assoir côte à côte avec ce runbook pour les équipes gérant les certificats de livraison iOS avec leur processus de mise à jour mobile.
Résolution de problèmes et gestion des certificats perdues
The difficult incident isn’t always an expiration warning. It’s the morning when the administrator who created the certificate has left, the private key exists only on an old Mac, or a certificate was revoked during an attempted cleanup. The standard renewal flow depends on the original Apple ID and the correct certificate identity, so access and provenance matter as much as the file itself.
Commencez par classer l'échec :
- Certificat expiré : Generate a replacement through the original account, reinstall it with the matching private key, update the provider, and test delivery. If device communication has already been interrupted, follow Apple’s recovery guidance rather than assuming a server-side replacement instantly restores every device.
- Certificat révoqué : Stop treating the old credential as recoverable. Apple refuses TLS connections from servers using revoked certificates, so create a valid replacement and remove the revoked secret from active deployments. Check who revoked it and whether other systems copied the same credential.
- Lost
.p12password: Ainsi, un fichier de certificat sans mot de passe utilisable peut être opérationnellement indisponible. Récupérez le certificat de secours approuvé ou émettez un nouveau certificat au lieu de réduire les contrôles de secret de production. - Clé privée perdue : Le redownloading du certificat public ne recrée pas la clé privée. Créez un nouveau CSR sur un ordinateur contrôlé et émettez un nouveau certificat.
- Accès à l'ID Apple perdu : Confirmez si l'organisation peut récupérer le compte à travers ses processus d'identité et de déploiement. Apple dirige le support pour les certificats APNs créés à travers le portail pertinent vers Support des programmes de déploiement.
La récupération nécessite une identité, pas seulement un nom de fichier. Enregistrez l'identifiant Apple propriétaire, l'ID d'application, l'identité du certificat, l'emplacement de la clé privée, la configuration du fournisseur et la procédure de remplacement avant qu'un incident ne se produise.
Construire un filet de sécurité opérationnel
Placez les certificats et les .p8 clés dans un coffre partagé, contrôlé par des accès. Stockez les .p12 keys in a shared, access-controlled vault. Store the password separately from the file, restrict production access, and document the exact portal account used for renewal. Your CI/CD system should inject secrets at deployment time and run a health check that detects authentication failures before users report missing alerts.
Conservez la vieille clé d'authentification disponible pendant une remplacement contrôlé lorsque la plateforme le permet, mais ne laissez pas les secrets obsolètes actifs indéfiniment. Testez un remplacement dans le même chemin de backend que la production utilise, y compris l'environnement du fournisseur, l'identifiant de l'ensemble de l'application et le magasin de jetons de dispositif.
Lorsqu'un défaillance a déjà eu lieu, préservez les corps de réponse APNs et les horodatages, identifiez la première demande rejetée et comparez le secret de déploiement avant et après l'incident. N'essayez pas indéfiniment contre une clé d'authentification invalide. Corrigez d'abord l'identité ou le problème d'authentification, puis envoyez une petite notification de vérification à un appareil de test connu.
Capgo peut stocker et configurer les certificats de push iOS en tant que partie d'un flux de notification Capacitor, tandis que votre équipe conserve la responsabilité de l'accès à la compte Apple, de la garde des secrets et des décisions de renouvellement. Capgo Voir comment son outil de livraison mobile peut s'adapter à votre cycle de vie et à la mise en production de vos certificats APNs.
