Les certificats du service de notification Push d'Apple sont valables pendant un an et doivent être renouvelés chaque année dans le portail des développeurs 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 empêcher les notifications même si l'application elle-même semble en bonne santé.
La panne se produit souvent au pire moment. Une mise à jour est déployée, une campagne est planifiée, et la livraison des notifications devient soudainement silencieuse. Le serveur de votre application peut toujours accepter des tâches, mais APNs peuvent rejeter la connexion TLS avant que le message n'atteigne un appareil. La solution pratique n'est pas seulement de créer un autre certificat. Vous devez comprendre quelles informations d'identification APNs votre système utilise, conserver la clé privée, planifier la renouvellement et déplacer les charges de travail appropriées vers l'authentification basée sur jeton.
Sommaire
- Pourquoi les notifications Push cessent-elles de fonctionner ?
- Créer et télécharger votre certificat APNs
- Exporter le certificat vers une paire de clés privées
- Migrer vers la nouvelle authentification basée sur jeton
- Renouveler et Gérer les Cycles de Certificats
- Dépannage et Gestion des Identifiants Perdus
Pourquoi les Notifications Push Arrêtent de Fonctionner
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 router vers l'application et l'appareil enregistrés. Si le credencial est expiré, révoqué, associé à l'identité incorrecte ou installé incorrectement, la demande peut échouer avant que le processus de livraison commence.
Apple indique que APNs garde une liste de 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 exigence de livraison, et non une préférence administrative. Le serveur peut continuer à traiter les tâches de notification localement, tandis qu'Apple rejette la connexion de fournisseur.
Separez les notifications push de l'application des notifications MDM
La première question de diagnostic est simple: Quel service essayez-vous de mettre en œuvre?
| Voie de l'identifiant | Ce qu'il fait | Propriétaire typique |
|---|---|---|
| App Push | Envoie des alertes et d'autres notifications d'application aux appareils de l'utilisateur final | Ingénierie mobile ou backend |
| MDM Push | Permet à une plateforme de gestion de dispositifs de communiquer avec des appareils Apple gérés | Administration IT, point d'entrée ou mobilité d'entreprise |
Ces informations d'identification 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 les équipes Capacitor et Ionic, la voie pertinente pour les alertes utilisateurs est généralement App PushL'application a toujours besoin de la capacité de notifications Push, de la signature correcte, de l'enregistrement des appareils et d'un backend qui envoie à travers l'environnement APNs approprié. Si votre équipe expédie également des actifs web sur le fil de l'air, gardez ce flux de mise à jour distinct de l'authentification de push. Capacitor documentation du plugin de notifications couvre l'intégration côté application, tandis que les informations de connexion APNs appartiennent à la configuration du fournisseur.
Démarrez par le refus, pas par l'interface utilisateur
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 ne justifie 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 version avec la version 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 lieu. Pour un chemin d'implémentation plus large, consultez ce guide sur la mise en place des notifications de l'Expo Mise en place des notifications de l'Expo.
Création et téléchargement de votre certificat APNs
Une mise en production de notifications 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 Demander un certificat de signature, ou CSR, et Apple le signe pour l’ID d'application sélectionné. Le CSR n'est pas le mot de passe du 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, Identificateurs & Profils. Sélectionner Identificateurs, choisissez l'identifiant de l'application, et ouvrez sa configuration. Confirmez que Notifications Push context: Page/zone : Site de marketing Capgo. Rôle : Étiquette de navigation ou élément UI court. Clé de message `push_notifications` (Notifications Push).
est activé avant de procéder à l'émission.
Les informations d'identification APNs sont liées à l'identité de l'application. N'allez pas choisir un identifiant de bundle proche avec un nom similaire. Configurez chaque application séparée indépendamment et émettez le certificat correspondant. Sur le Mac qui conservera la clé, ouvrez Accès à la clé
Un moniteur d'ordinateur affichant une interface de ligne de commande Linux utilisée pour générer des certificats SSL.
In CertificatsChoisissez 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.
Double-cliquez sur le fichier téléchargé sur le Mac qui possède la clé privée. Il doit 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édential complet dont votre serveur 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'appartenance au CSR et les détails du compte du portail dans le système de crédentials de votre équipe. Un répertoire de téléchargements d'un développeur ou un ordinateur portable personnel ne constituent pas un système de sauvegarde opérationnel.
Le certificat ne prend en charge que la livraison d'une partie. L'application doit s'inscrire pour les notifications à distance, le serveur doit conserver le jeton de dispositif résultant et le fournisseur doit envoyer avec le sujet correspondant et l'environnement. Conservez ces dépendances dans le même livre de tâches. Pour la configuration côté client, consultez le Capacitor guide d'intégration de notifications.
Traitez ce certificat comme un crédential géré, et non comme un téléchargement unique, car l'exportation ultérieure, la migration de jetons, la renouvellement et la récupération dépendent de la connaissance de qui contrôle sa clé.
A un téléchargé certificat Apple, il 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, communément emballés dans un PKCS#12 .p12 fichier.
Ouvrir Clés d'accès sur le Mac où vous avez installé le certificat. Cherchez le certificat APNs, développez-l’ou inspectez-le, 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
Attribuez un mot de passe fort à l'export. Le mot de passe protège la clé privée à l'intérieur du bundle, n'en 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 les notifications.
Règle pratique : Un
.p12fichier 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 de push iOS, téléchargez le .p12 et son mot de passe à travers la configuration secrète désignée plutôt que d'insérer une valeur dans l'application code.
Le format met également en évidence la faiblesse du workflow de l'époque. Vous devez conserver la clé privée d'origine, répéter une exportation manuelle, protéger le fichier et remplacer le secret de déploiement à l'heure de la renouvellement. Les équipes gérant plusieurs applications peuvent facilement perdre de vue lequel du bundle appartient à quel ID d'application.
Utilisez la gestion sécurisée des secrets 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'enregistrez 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 du 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 les jetons
Apple a déplacé l'authentification APNs vers les jetons de fournisseur, souvent appelé le flux p8. Au lieu de présenter un certificat et une paire de clés privées pour une identité TLS à durée de vie longue, votre fournisseur signe des jetons d'authentification avec une clé d'authentification du service de notification Push d'Apple.
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 les identifiants de clé et d'équipe associés dans votre magasin de secrets. Traitez le fichier téléchargé comme un secret de signature de haute valeur.
Effectuez la migration délibérément
N'effectuez pas le basculement du trafic de production en remplaçant un fichier dans un environnement non testé. Construisez l'authentification de jetons à côté de la voie existante du certificat, validez le comportement de l'ensemble sandbox et de production, et comparez les réponses APNs. Ensuite, effectuez 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 nécessite toujours une inscription et des autorisations de notification correctes. La migration change principalement l'authentification serveur-APNset non l'enregistrement du jeton de l'appareil code. Votre serveur doit continuer à associer les jetons avec l'application et l'environnement corrects.
Savoir quand les certificats restent nécessaires
Certaines outils d'entreprise et des intégrations établies exposent toujours une configuration basée sur les certificats. N'imposez 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 credencial de l'ancien protégé pendant la transition, mais ne créez 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 les notifications push d'Capacitor et Ionic avec Firebase. Firebase peut fournir un couche de livraison d'application, mais les crédentiels d'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 où vous le créez. Apple dit que ces certificats sont valides pendant une année à compter de leur création et doit être renouvelé avant expiration pour préserver la communication avec les appareils. Apple avertit également que le renouvellement échoué peut obliger les utilisateurs à réinscrire les appareils iOS, iPadOS et Mac avec APNs et peut entraîner des interruptions de service. Consultez la documentation de renouvellement de certificat de notification push d'Apple la documentation de renouvellement de certificat de notification push d'Apple .
Le chemin de renouvellement est précis :
- Générer un nouveau CSR : Créer la demande à travers votre workflow approuvé et conserver le matériel clé associé.
- Utiliser l'ID Apple original : Se connecter avec le même ID Apple utilisé pour créer le certificat existant.
- Sélectionner le certificat expirant : Correspondre à l'ID d'application, au sujet DN, à l'UID et aux détails d'expiration avant de sélectionner Renouveler.
- Charger le CSR : Soumettre la nouvelle demande dans le Portail des certificats de notification push d'Apple.
- Téléchargez et réinstallez : Récupérez le certificat renouvelé
.pem, installez-le là où la clé privée est disponible, et exportez une remplaçante.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 des fournisseurs
| Exigence | Flux de certificat | Flux de jeton |
|---|---|---|
| Secret principal | Certificat plus clé privée | .p8 clé d'authentification |
| Préoccupation de renouvellement | L'expiration du certificat nécessite un remplacement récurrent | Pas de remplacement de certificat annuel |
| Travail de déploiement | Installez, pair, exportez et téléchargez | 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é des travaux de chaîne de confiance planifiés. Apple a annoncé des mises à jour des certificats de serveur APNs pour le sandbox le 20 janvier 2025 et en production le le 24 février 2025, nécessitant les magasins de confiance d'inclure le le certificat de certification racine SHA-2 USERTrust RSA Certification Authority l'annonce du serveur de certificats APNs d'Apple et faire de la propriété du magasin de confiance partie de votre liste de vérification de plateforme. Utilisez un calendrier de renouvellement partagé, un propriétaire nommé et un livre de déploiement. Le
__CAPGO_KEEP_0__ document de gestion des certificats Capgo certificate management documentation Résolution des problèmes et Gestion des Identifiants Perdus
L'incident difficile n'est pas toujours un avertissement d'expiration. C'est le matin où l'administrateur qui a créé le certificat a quitté, la clé privée existe uniquement sur un ancien Mac, ou un certificat a été révoqué lors d'un nettoyage tenté. Le flux de renouvellement standard repose sur l'ID d'Apple original et l'identité du certificat correcte, donc l'accès et la provenance comptent autant que le fichier lui-même.
Troubleshooting et Gestion des Identifiants Perdus
Commencez par classer l'échec :
- Certificat expiré : Générez un remplacement à partir du compte original, réinstallez-l’avec la clé privée correspondante, mettez à jour le fournisseur et testez la livraison. Si la communication avec le dispositif a déjà été interrompue, suivez les instructions de récupération d'Apple plutôt que de supposer que le remplacement du serveur rétablit instantanément tous les appareils.
- Certificat révoqué : Arrêtez de traiter l'ancien credencial comme récupérable. Apple refuse les connexions TLS de serveurs utilisant des certificats révoqués, créez donc un remplacement valide et supprimez le secret révoqué des déploiements actifs. Vérifiez qui l'a révoqué et si d'autres systèmes ont copié le même credencial.
- Mot de passe perdu :
.p12Un fichier de certificat sans le mot de passe utilisable peut être opérationnellement indisponible. Récupérez le backup approuvé ou émettez un remplacement au lieu de réduire les contrôles de secrets de production. Clé privée perdue : - Le téléchargement à nouveau du certificat public ne recrée pas la clé privée. Créez un nouveau CSR sur un ordinateur contrôlé et émettez un remplacement de credencial. Perte d'accès à l'ID Apple :
- 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 __CAPGO_KEEP_0__ Programmes de déploiement Support.
La récupération nécessite une identité, et non juste un nom de fichier. Enregistrez l'identité du propriétaire de l'Apple ID, de l'ID de l'application, de l'identité du certificat, de l'emplacement de la clé privée, de la configuration du fournisseur et de 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 l'accès. Stockez le mot de passe séparément du fichier, restreignez l'accès en production et documentez le compte de portail exact utilisé pour la renouvellement. Votre système CI/CD doit injecter des secrets lors du déploiement et exécuter une vérification de santé qui détecte les échecs d'authentification avant que les utilisateurs ne signalent les alertes manquantes. .p12 Conservez le vieux mot de passe disponible pendant une remplacement contrôlée lorsque le plateforme le permet, mais ne laissez pas les secrets obsolètes actifs indéfiniment. Testez une remplacement dans le même chemin de backend que la production utilise, y compris l'environnement du fournisseur, l'identifiant de l'application et le stockage 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 de réessayer indéfiniment contre un mot de passe 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_KEEP_0__ peut stocker et configurer les crédentiels de push iOS comme partie d'un workflow de notification __CAPGO_KEEP_1__, tandis que votre équipe conserve la responsabilité de l'accès à l'Apple, de la garde des secrets et des décisions de renouvellement. Visitez
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 pour examiner comment ses outils de livraison mobile peuvent s'adapter à votre cycle de vie et à la mise en production de vos certificats APNs.
