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 Apple Developer pour éviter d'interrompre la communication des 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. 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 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.
Tableau de Contenu
- Pourquoi les notifications Push cessent-elles de fonctionner ?
- 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
- Renouveler et gérer les cycles de vie des certificats
- Dépanner et gérer les informations d'identification perdues
Pourquoi les notifications Push cessent 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 réfie à APNs pour la router vers l'application et l'appareil enregistrés. Si l'information d'identification est expirée, révoquée, associée à la mauvaise identité ou installée 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 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 du 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 des informations d'identification | 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 final 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 d'envoi Apple » envoie les dépannages dans la mauvaise direction.
Pour les équipes de Capacitor et Ionic, le chemin pertinent 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, gardez ce flux de livraison séparé de l'authentification de la poussée. 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.
Commencez 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'application, 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 build avec la build précédente. Si l'échec est apparu sans changement d'application, inspectez d'abord l'expiration, la révocation, les modifications du magasin de confiance et les secrets de déploiement. Pour une implémentation plus large, consultez ce guide sur la mise en place de notifications push par Expo. Paramètres de notification push par Expo.
Création et téléchargement de votre certificat APNs
Une mise en production de notifications 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 Demande de signature de certificat, ou CSR, et Apple la signe pour l’ID d'application sélectionné. Le CSR n'est pas la clé 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, 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 d'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ément et émettez le certificat correspondant. On l'ordinateur 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 devrait s'installer dans Keychain Accessoù 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 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 de 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 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 tâches. Pour la configuration côté client, consultez le guide d'intégration de notifications Capacitor. Traitez ce certificat comme un crédentiel 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é.
Exporter le Certificat vers une Clé Privée
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 correspondante avec les informations d'identité et 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 des 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 iOS de push, 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 de ces valeurs dans l'application code.
Le format met également en évidence la faiblesse du workflow de legacy. Vous devez conserver la clé privée d'origine, répéter une exportation manuelle, protéger le fichier et remplacer la clé de déploiement à la date de renouvellement. Les équipes opé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 de backend, évaluez si l'authentification par certificat est toujours appropriée. Les intégrations existantes peuvent nécessiter .p12, mais 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, appelé couramment le flux p8. Au lieu de présenter un certificat et une clé privée pour une identité TLS à vie courte, votre fournisseur signe des jetons d'authentification avec une clé d'authentification de service de notification Push d'Apple.
Créez la clé dans le portail Apple Developer sous Certificats, Identifiants et 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
Ne passez pas la circulation 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 sandbox et de production, et comparez les réponses APNs. Ensuite, effectuez la modification de la configuration du fournisseur lors d'un déploiement contrôlé.
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-APNs, et non l'enregistrement du jeton de l'appareil code. Votre serveur doit continuer à associer les jetons avec l'application et l'environnement corrects.
Sachez quand les certificats restent nécessaires
Certains outils d'entreprise et les intégrations établies exposent toujours une configuration basée sur des 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 d'Ionic avec Firebase. Firebase peut fournir un couche de livraison d'application, mais les crédits Apple, les autorisations, l'enregistrement et les réponses APNs nécessitent une configuration délibérée.
Gestion et renouvellement des 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 l'appareil. 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. Voir 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 DN de sujet, à 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 nouvelle.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 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 | 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é un travail de chaîne de confiance planifié. 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 des magasins de confiance qui incluent le le certificat de certification racine SHA-2 USERTrust RSA Certification Authority l'annonce du certificat de serveur Apple APNs et faites 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 informations d'identification perdues
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 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 informations d'identification perdues
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 instantané par le serveur rétablit tous les appareils.
- Certificat révoqué : Arrêtez de traiter l'ancien credencial comme étant récupérable. Apple refuse les connexions TLS de serveurs utilisant des certificats révoqués, donc créez 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 d'Apple, 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 l'accès. Stockez le mot de passe séparément du fichier, restreignez l'accès de 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 credencial ancien disponible pendant un remplacement contrôlé lorsque le plateforme le permet, mais n'abandonnez pas les secrets obsolètes activement 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 la trousse, 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 requête 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 credencial 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 credenciaux 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.
