Les certificats Apple Push Notification service sont valables un an et doivent être renouvelés chaque année sur le portail Apple Developer pour éviter d'interrompre la communication avec les appareils. Si vous gérez une application Capacitor, un identifiant expiré ou révoqué peut bloquer les notifications même si l'application semble fonctionner normalement.
L'échec survient souvent au pire moment. Une release est publiée, une campagne est programmée, et l'envoi des notifications s'arrête soudainement. Votre serveur d'application peut encore accepter les tâches, mais APNs peut rejeter la connexion TLS avant qu'un message n'atteigne un appareil. La solution concrète ne consiste pas seulement à créer un autre certificat. Vous devez comprendre quel identifiant APNs votre système utilise, préserver la clé privée, planifier le renouvellement et faire basculer les charges de travail adaptées vers une authentification par token.
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 par token
- Renouveler et gérer le cycle de vie des certificats
- Dépannage et gestion des identifiants perdus
Why Push Notifications Stop Working
APNs se situe entre votre serveur fournisseur et l’appareil Apple de l’utilisateur. Votre serveur s’authentifie auprès d’Apple, soumet une notification et s’appuie sur APNs pour la router vers l’application et l’appareil enregistrés. Si l’identifiant est expiré, révoqué, associé à la mauvaise identité ou mal installé, la requête peut échouer avant même que la livraison ne commence.
Apple précise qu’APNs maintient une liste des certificats révoqués et refuse les connexions TLS provenant de serveurs utilisant des certificats figurant sur cette liste. Cela fait de l’hygiène des certificats une 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.
Séparez le push de l'app du push MDM
La première question de diagnostic est simple : quel service essayez-vous de faire fonctionner ?
| Chemin des identifiants | Ce qu’il fait | Responsable habituel |
|---|---|---|
| Push d'app | Envoie des alertes et autres notifications applicatives aux appareils des utilisateurs finaux | Ingénierie mobile ou backend |
| Push MDM | Permettre à une plateforme de gestion de communiquer avec les appareils Apple gérés | Administration IT, endpoint ou mobilité d'entreprise |
Ces identifiants ne sont pas interchangeables. Une plateforme MDM peut perdre le contact avec les appareils inscrits quand son identifiant MDM push expire, tandis qu'un backend d'application peut perdre l'acheminement des notifications parce que son identifiant App Push est invalide. Traiter les deux comme un seul problème de « certificat push Apple » oriente le diagnostic dans la mauvaise direction.
Pour les équipes Capacitor et Ionic, le chemin pertinent pour les alertes utilisateur est généralement Push d'app. L'application a toujours besoin de la capacité Push Notifications, d'une signature correcte, de l'enregistrement de l'appareil et d'un backend qui envoie via l'environnement APNs approprié. Si votre équipe déploie aussi des assets web en OTA, gardez ce workflow de release séparé de l'authentification push. La documentation du plugin de notifications Capacitor couvre l'intégration côté application, tandis que les identifiants APNs relèvent de la configuration du fournisseur.
Commencez par le rejet, pas par l'UI
Vérifiez la réponse APNs de votre serveur fournisseur avant de modifier le contenu de la notification ou de reconstruire l'app. Vérifiez ensuite le bundle identifier, l'identité de l'identifiant, l'environnement et le statut du certificat. Un problème d'autorisation de notification empêche l'utilisateur de voir les alertes, mais n'explique pas un rejet TLS d'APNs.
Si l'échec est apparu après une release, comparez la signature et les entitlements du nouveau build avec le build précédent. S'il est apparu sans modification de l'app, vérifiez d'abord l'expiration du certificat, sa révocation, les changements de trust-store et les secrets de déploiement. Pour une mise en œuvre plus complète, consultez ce guide sur la Configuration des notifications push Expo.
Créer et télécharger votre certificat APNs
Un déploiement push peut échouer avant l'envoi de la première notification si le certificat est émis pour le mauvais App ID ou si la clé privée reste sur un autre Mac. Le workflow Apple comporte deux étapes : votre machine crée une Demande de signature de certificat, ou CSR, et Apple le signe pour l’App ID sélectionné. Le CSR n’est pas l’identifiant serveur. Il associe le certificat émis à une clé privée générée localement.
Préparer l'App ID
Connectez-vous au portail Apple Developer et ouvrez Certificats, identifiants et profils. Sélectionnez Identifiants, choisissez l’identifiant de bundle de l’application et ouvrez sa configuration. Vérifiez que Notifications push est activé avant d’émettre quoi que ce soit.
Les identifiants APNs sont liés à l’identité de l’application. Ne choisissez pas un identifiant de bundle proche au nom similaire. Configurez chaque application indépendamment et émettez l’identifiant correspondant.
Sur le Mac qui conservera la clé, ouvrez Trousseau d'accès et créez le CSR, ou utilisez les outils de certification approuvés par votre organisation. Conservez le fichier de requête et la clé privée sous le contrôle d'une même personne. Si un autre administrateur crée le CSR, c'est lui qui peut détenir la clé privée nécessaire ensuite pour un bundle serveur utilisable.
Délivrer le certificat signé
Dans Certificats, choisissez l'option de certificat Apple Push Notification service. Sélectionnez l'App ID, envoyez le CSR et soumettez la demande. Téléchargez le certificat délivré 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 Trousseau d'accès, où vous pouvez vérifier le certificat et sa clé privée correspondante. Un certificat importé sans cette clé ne peut pas fournir l'identifiant 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. Conservez le certificat original, les informations de propriété du CSR et les détails du compte du portail dans le système de gestion des identifiants de votre équipe. Le dossier Téléchargements d'un développeur ou son ordinateur personnel ne constitue pas une sauvegarde opérationnelle.
Le certificat ne couvre qu'une partie de la livraison. L'application doit s'enregistrer pour les notifications distantes, le serveur doit conserver le device token obtenu, et le fournisseur doit envoyer avec le topic et l'environnement correspondants. Gardez ces dépendances dans le même runbook. Pour la configuration côté client, consultez le guide d'intégration des notifications Capacitor. Considérez ce certificat comme un identifiant géré, et non comme un téléchargement ponctuel, car l'export, la migration de token, le renouvellement et la récupération dépendent ensuite de qui contrôle sa clé.
Exporter le certificat vers une clé privée
Un certificat Apple téléchargé n'est pas prêt à l'emploi 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 empaquetés sous la forme d'un PKCS#12 .p12 fichier.
Ouvrez Trousseau d'accès sur le Mac où vous avez installé le certificat. Recherchez 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'export pour enregistrer un .p12 fichier.
Valider le bundle avant le déploiement
Attribuez un mot de passe robuste à l'export. Ce 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 les logs de build. Envoyez le fichier et le mot de passe via votre système de gestion de secrets, puis n'accordez l'accès qu'au service qui envoie les notifications.
Règle pratique : Un
.p12fichier sans sa clé privée correspondante ne constitue pas un identifiant de fournisseur complet.
Avant la mise en production, testez le bundle dans un environnement contrôlé. Confirmez que votre backend peut charger le fichier, établir la connexion APNs et renvoyer des erreurs structurées lorsqu'Apple rejette une requête. Si un fournisseur tel que Capgo demande un identifiant de push iOS, envoyez le .p12 et son mot de passe via la configuration secrète dédiée, plutôt que d'intégrer l'une ou l'autre de ces valeurs dans l'application code.
Ce format expose également la faiblesse de l'ancien workflow. 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 lors du renouvellement. Les équipes qui gèrent plusieurs apps peuvent facilement perdre de vue quel bundle correspond à quel App ID.
Utiliser une gestion sécurisée des secrets dans les pipelines CI/CD pour contrôler qui peut lire ou remplacer l'identifiant. Conservez un journal d'audit des uploads et des rotations, mais ne loguez jamais la clé privée ni le .p12 mot de passe.
Pour les nouveaux développements backend, vérifiez si l'authentification par certificat reste pertinente. Les intégrations existantes peuvent nécessiter .p12, mais l'authentification par token supprime généralement le remplacement annuel du certificat dans la connexion au fournisseur. Cela ne supprime pas pour autant la gouvernance des identifiants. Cela change ce que vous protégez et renouvelez.
Migrer vers la nouvelle authentification par token
Apple a fait évoluer l'authentification APNs vers les tokens de fournisseur, communément appelés le workflow p8. Au lieu de présenter un certificat et une clé privée pour une identité TLS à longue durée de vie, votre fournisseur signe des tokens d'authentification avec une clé d'authentification Apple Push Notification service.
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 notez le Key ID et le Team ID associés dans votre gestionnaire de secrets. Traitez le fichier téléchargé comme un secret de signature critique.
Migrer en connaissance de cause
Ne basculez pas le trafic de production en remplaçant un fichier dans un environnement non testé. Mettez en place l'authentification par token en parallèle du chemin de certificat existant, validez le comportement en sandbox et en production, et comparez les réponses APNs. Effectuez ensuite le changement de configuration du fournisseur lors d'un déploiement contrôlé.
La migration supprime les étapes de renouvellement de certificat et d'exportation du Keychain du flux d'envoi, mais votre équipe a toujours besoin d'une répartition claire des responsabilités. Décidez qui peut créer, révoquer et déployer les clés. Limitez l'accès au service backend qui signe les tokens du 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 un enregistrement des notifications et des entitlements corrects. La migration modifie principalement l'authentification serveur vers APNs, et non l'enregistrement du token de l'appareil code. Votre backend doit continuer à associer les tokens à l'application et à l'environnement corrects.
Savoir quand les certificats restent nécessaires
Certains outils d'entreprise et intégrations établies exposent encore une configuration basée sur des certificats. Ne forcez pas une migration vers p8 tant que le système destinataire ne le prend pas en charge et que votre équipe n'a pas testé le parcours complet. Gardez l'identifiant historique protégé pendant la transition, mais n'en créez pas de nouvelles dépendances lorsque l'authentification par token convient.
Si vous devez comprendre le flux applicatif environnant, consultez Ionic et les notifications push Capacitor avec FirebaseFirebase peut fournir une couche de diffusion d'application, mais les identifiants, les entitlements, l'enregistrement Apple et les réponses APNs nécessitent toujours une configuration délibérée.
Renouveler et gérer le cycle de vie des certificats
Considérez un certificat APNs comme une dépendance de production arrivant à expiration dès sa création. Apple indique que ces certificats sont valides pour un an à compter de leur création et doivent être renouvelés avant expiration pour maintenir la communication avec les appareils. Apple avertit également qu'un défaut de renouvellement peut obliger les utilisateurs à réenregistrer leurs appareils iOS, iPadOS et Mac auprès d'APNs et peut causer des interruptions de service. Consultez la documentation d'Apple sur le renouvellement des certificats de notification push.
Le processus de renouvellement est précis :
- Générer un nouveau CSR : Créez la requête via votre workflow approuvé et conservez les clés associées.
- Utilisez l'Apple ID d'origine : Connectez-vous avec le même Apple ID que celui utilisé pour créer le certificat existant.
- Sélectionnez le certificat arrivant à expiration : Vérifiez l'App ID, le Subject DN, l'UID et les détails d'expiration avant de sélectionner Renouveler.
- Envoyez le CSR : Soumettez la nouvelle demande sur Apple Push Certificates Portal.
- Télécharger et réinstaller : Récupérez le certificat renouvelé
.pem, installez-le là où la clé privée est disponible, et exportez un certificat de remplacement.p12si votre fournisseur l'exige. - Déployer et tester : Mettez à jour le secret du serveur, envoyez une notification contrôlée et inspectez la réponse APNs.
Comparer les formats des fournisseurs
| Exigence | Workflow avec certificat | Workflow avec token |
|---|---|---|
| Secret principal | Certificat et clé privée | .p8 clé d'authentification |
| Contrainte de renouvellement | L'expiration du certificat impose un remplacement récurrent | Pas de remplacement annuel de certificat |
| Effort de déploiement | Installer, appairer, exporter et envoyer | Stocker la clé de signature et configurer la génération de token |
| Principal risque d'échec | Certificat incorrect, clé privée manquante, expiration ou révocation | Clé d'authentification perdue, exposée ou révoquée |
L'écosystème de certificats d'Apple nécessite également une gestion planifiée de la chaîne de confiance. Apple a annoncé des mises à jour des certificats serveurs APNs pour le sandbox le 20 janvier 2025 et la production le 24 février 2025, ce qui nécessite que les trust stores incluent le SHA-2 Root USERTrust RSA Certification Authority certificat. Lire le Annonce Apple sur les certificats serveur APNs et intégrez la gestion du trust-store à votre checklist plateforme.
Utilisez un calendrier de renouvellement partagé, un responsable désigné et un runbook de déploiement. La documentation de gestion des certificats Capgo peut accompagner ce runbook pour les équipes gérant les identifiants de livraison iOS dans leur processus de release mobile.
Dépannage 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 est parti, où la clé privée n'existe que sur un vieux Mac, ou quand un certificat a été révoqué lors d'une tentative de nettoyage. Le flux de renouvellement standard dépend de l'Apple ID d'origine et de l'identité correcte du certificat ; l'accès et la provenance comptent donc autant que le fichier lui-même.
Commencez par identifier le type d'échec :
- Certificat expiré : Générez un remplacement via le compte d'origine, réinstallez-l’avec la clé privée correspondante, mettez à jour le fournisseur et testez l'envoi. Si la communication avec les appareils est déjà interrompue, suivez les recommandations de récupération d'Apple plutôt que de supposer qu'un remplacement côté serveur restaure instantanément chaque appareil.
- Certificat révoqué : Ne considérez plus l'ancien identifiant comme récupérable. Apple refuse les connexions TLS des 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é ce même identifiant.
- Perdu
.p12mot de passe : Un fichier de certificat sans mot de passe utilisable peut s'avérer inexploitable. Récupérez la sauvegarde approuvée ou émettez un certificat de remplacement plutôt que d'affaiblir les contrôles de secrets en production. - Clé privée perdue : Retélécharger le certificat public ne recréera pas la clé privée. Générez un nouveau CSR sur une machine maîtrisée et émettez un certificat de remplacement.
- Accès à l'Apple ID perdu : Vérifiez si l'organisation peut récupérer le compte via ses processus d'identité et de déploiement. Pour les certificats APNs créés via le portail concerné, Apple oriente le support vers le support des programmes de déploiement.
La récupération exige une identité, pas seulement un nom de fichier. Consignez le propriétaire de l'Apple ID, l'App ID, 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 survienne.
Mettre en place un filet de sécurité opérationnel
Stockez les certificats et .p8 clés dans un coffre-fort partagé avec contrôle d'accès. Stockez le .p12 mot de passe séparément du fichier, restreignez l'accès à la production et documentez le compte exact du portail utilisé pour le renouvellement. Votre système CI/CD doit injecter les secrets au moment du déploiement et exécuter un health check pour détecter les échecs d'authentification avant que les utilisateurs ne signalent l'absence d'alertes.
Gardez l'ancien identifiant disponible lors d'un remplacement contrôlé lorsque la plateforme le permet, mais ne laissez pas de secrets obsolètes actifs indéfiniment. Testez un remplacement sur le même chemin backend que la production, y compris l'environnement du fournisseur, le bundle identifier et le stockage des tokens d'appareil.
En cas d'interruption de service, conservez 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. Ne réessayez pas indéfiniment avec un identifiant invalide. Corrigez d'abord le problème d'identité ou d'authentification, puis envoyez une petite notification de vérification à un appareil de test connu.
Capgo peut stocker et configurer les identifiants push iOS dans le cadre d'un workflow de notification Capacitor, tandis que votre équipe conserve la responsabilité de l'accès au compte Apple, de la conservation des secrets et des décisions de renouvellement. Consultez Capgo pour voir comment ses outils de livraison mobile peuvent s'intégrer à votre cycle de vie des identifiants APNs et à votre processus de release.
Foire aux questions
Les certificats SSL client pour les notifications push sont-ils transférés lorsqu’une application est transférée vers un autre compte Apple ?
Non. La documentation de transfert d’applications d’Apple indique que les certificats SSL client pour les notifications push ne sont pas transférés. Après le transfert, l’équipe destinataire doit créer de nouveaux certificats APNs ou, mieux, utiliser une clé .p8 basée sur un token depuis son propre compte, puis mettre à jour le fournisseur de push. Voir la migration vers l’authentification basée sur des tokens.
