Il certificato del servizio di notifica push di Apple è valido per un anno e deve essere rinnovato annualmente nel portale dello sviluppatore Apple per evitare di interrompere la comunicazione con i dispositivi. Se sei responsabile di un'app Capacitor, un credenziale scaduto o revocato può fermare le notifiche anche se l'app stessa sembra sana.
Il fallimento spesso si manifesta al momento peggiore. Una versione viene rilasciata, una campagna è programmata, e la consegna delle notifiche diventa improvvisamente silenziosa. Il tuo server di applicazione può ancora accettare i lavori, ma APNs può rifiutare la connessione TLS prima che un messaggio raggiunga un dispositivo. La soluzione pratica non è solo creare un altro certificato. Hai bisogno di capire quale credenziale APNs il tuo sistema utilizza, conservare la chiave privata, pianificare il rinnovo e spostare le workload adatte all'autenticazione basata su token.
Tavola dei contenuti
- Perché le notifiche push smettono di funzionare
- Creare e scaricare il certificato APNs
- Esportare il certificato in una chiave privata
- Migrazione al Nuovo Autenticazione con Token
- Rinnovare e Gestire Cicli di Vita dei Certificati
- Risolvere e Gestire le Credenziali Persi
Perché le Notifiche Push Non Funzionano
APNs si trova tra il tuo server di provider e il dispositivo Apple dell'utente. Il tuo server si autentica con Apple, invia una notifica e si appoggia su APNs per inviarla al'applicazione e al dispositivo registrati. Se la credenziale è scaduta, revocata, associata all'identità sbagliata o installata in modo errato, la richiesta può fallire prima che la consegna inizi.
Apple afferma che APNs mantiene una lista dei certificati revocati e rifiuta le connessioni TLS dai server che utilizzano certificati in quella lista. Ciò rende l'igiene dei certificati un requisito di consegna, non una preferenza amministrativa. Il server può continuare a elaborare i lavori di notifica localmente, mentre Apple rifiuta la connessione del provider.
Separare la push dell'applicazione dalla push MDM
La prima domanda diagnostica è semplice: Quali servizi stai cercando di utilizzare?
| Percorso delle credenziali | What it does | Proprietario tipico |
|---|---|---|
| App Push | Invia avvisi e altre notifiche di applicazione ai dispositivi degli utenti finali | Ingegneria mobile o backend |
| MDM Push | Consente a una piattaforma di gestione dei dispositivi di comunicare con dispositivi Apple gestiti | Amministrazione IT, punto di accesso o mobilità aziendale |
Queste credenziali non sono intercambiabili. Una piattaforma MDM può perdere il contatto con i dispositivi iscritti quando la sua credenziale MDM push scade, mentre un backend di applicazione può perdere la consegna delle notifiche a causa della credenziale App Push non valida. Trattare entrambi come un problema di
Per Capacitor e Ionic, il percorso rilevante per le notifiche utente è generalmente App Push. L'applicazione richiede ancora la capacità di Push Notifications, firma corretta, registrazione dispositivo e un backend che invia attraverso l'ambiente APNs appropriato. Se il suo team sta anche distribuendo asset web in tempo reale, mantenga separato il flusso di rilascio per l'autenticazione push. La documentazione plugin di notifiche Capacitor copre l'integrazione di livello applicativo, mentre i credenziali APNs vanno inserite nella configurazione del provider.
Inizia con il rifiuto, non con l'interfaccia
Se il fallimento è apparso dopo un rilascio, confronta la firma e le autorizzazioni nella nuova build con la build precedente. Se è apparso senza un cambiamento dell'app, ispeziona la scadenza della certificazione, la revoca, i cambiamenti del trust-store e i segreti di distribuzione prima. Per un percorso di implementazione più ampio, consulta questa guida per
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 Creazione e download del certificato APNs.
Creazione e Download del Certificato 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 Richiesta di firma del certificatoo CSR, e Apple lo firma per l'ID App selezionato. Il CSR non è il credenziale del server. Collega il certificato rilasciato a una chiave privata creata localmente.
Preparare l'ID App
Accedi al portale dello sviluppatore Apple e apri Certificati, identificatori e profili. Seleziona Identificatori, scegli l'identificatore del pacchetto dell'applicazione e apri la sua configurazione. Assicurati che Le notifiche Push è abilitato prima di emettere qualsiasi cosa.
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.
On the Mac that will retain the key, open Accesso alla chiave e crea il CSR, o utilizza gli strumenti di certificazione approvati dall'organizzazione. Mantieni il file di richiesta e la chiave privata sotto lo stesso controllo di accesso. Se un altro amministratore crea il CSR, quell'amministratore potrebbe detenere la chiave privata necessaria in seguito per un bundle di server utilizzabile.
Emette il certificato firmato
In Certificati, scegli l'opzione per il servizio di notifica push Apple. Seleziona l'ID App, carica il CSR e invia la richiesta. Scarica il certificato emesso da Apple.
Duplica clicca sul file scaricato sul Mac che possiede la chiave privata. Dovrebbe installarsi in Accesso alla chiave, dove puoi verificare il certificato e la sua chiave privata corrispondente. Un certificato importato senza quella chiave non può fornire il credenziale completo che il tuo backend richiede.
Utilizza una convenzione di denominazione che registri l'identità dell'applicazione, l'ambiente, il proprietario e i dettagli di scadenza. Archivia il certificato originale, le informazioni di proprietà del CSR e i dettagli dell'account del portale nel sistema di credenziali della tua squadra. La cartella Download di un developer o il laptop personale non è un backup operativo.
Il certificato supporta solo una parte della consegna. L'app deve registrarsi per le notifiche remote, il server deve conservare il token dispositivo risultante e il provider deve inviare con il tema e l'ambiente corrispondenti. Mantieni quelle dipendenze nello stesso libro di procedure. Per la configurazione client-side, vedi il Guida di integrazione per le notifiche CapacitorConsidera questo certificato come un credenziale gestito, non come un download unico, poiché l'esportazione, la migrazione del token, la rinnovazione e il recupero dipendono dalla conoscenza di chi controlla la chiave.
Esportare il Certificato in una Chiave Privata
Un certificato Apple scaricato non è automaticamente pronto per un servizio Node.js o un provider di push gestito. Il server ha bisogno del certificato e della sua chiave privata corrispondente, comunemente confezionata in un file PKCS#12 .p12 file.
Apri Accesso alla Chiave sulla Mac dove hai installato il certificato. Cerca il certificato APNs, espandilo o esaminalo, e individua la chiave privata con l'informazione di identità e scadenza corrispondente. Seleziona il certificato e la chiave privata insieme, quindi utilizza l'azione di esportazione per salvare un .p12 file.
Verifica il bundle prima della distribuzione
Assegna alla esportazione una password forte. La password protegge la chiave privata all'interno del bundle, quindi non metterla in un repository, ticket, messaggio di chat o log di costruzione. Carica il file e la password attraverso il tuo sistema di gestione dei segreti, quindi concedi l'accesso solo al servizio che invia le notifiche.
Regola pratica: Un
.p12file senza la chiave privata corrispondente non è un credenziale di provider completo.
Prima dell'uso in produzione, testa il bundle in un ambiente controllato. Conferma che il tuo backend possa caricare il file, stabilire la connessione APNs e restituire errori strutturati quando Apple rifiuta una richiesta. Se un provider come Capgo richiede un credenziale di push iOS, carica il .p12 e la sua password attraverso la configurazione segreta designata anziché inserirli direttamente nell'applicazione code.
La formattazione esporre anche la debolezza del flusso di lavoro legacy. Dovrai preservare la chiave privata originale, ripetere l'esportazione manuale, proteggere il file e sostituire la chiave di deployment al momento della rinnovazione. Le squadre che gestiscono più app possono facilmente perdere il tracciato di quale bundle appartiene a quale ID App.
Usa gestione segreta sicura nei pipeline CI/CD per controllare chi può leggere o sostituire il credenziale. Conserva un registro degli upload e delle rotazioni, ma non registrare mai la chiave privata o la .p12 password.
Per nuove attività backend, valuta se l'autenticazione con certificato è ancora appropriata. Le integrazioni esistenti possono richiedere .p12, ma l'autenticazione con token rimuove di solito la sostituzione annuale del certificato dal provider. Ciò non elimina la governance dei credenziali. Cambia solo ciò che proteggi e ruota.
Migrazione al Nuovo Autenticazione con Token
Apple ha spostato l'autenticazione APNs verso token di provider, comunemente chiamato il flusso di lavoro p8. Invece di presentare un certificato e una chiave privata per un'identità TLS a lunga durata, il tuo provider firma i token di autenticazione con una chiave di notifica Push di Apple Authentication.
Creare la chiave nel portale dello sviluppatore Apple sotto Certificati, Identificatori e Profili, quindi aprire Chiavi e registra un token di autenticazione APNs. Scarica il .p8 registrare e conservare l'ID chiave e l'ID team associati nel tuo archivio segreto. Trattare il file scaricato come un segreto di firma di alto valore.
Effettuare la migrazione in modo deliberato
Non spostare il traffico di produzione sostituendo un file in un ambiente non testato. Costruisci l'autenticazione del token accanto alla cartella esistente del certificato, valuta il comportamento del sandbox e della produzione e confronta le risposte APNs. Poi apporta il cambio di configurazione del provider durante un'installazione controllata.
La migrazione elimina i passaggi di rinnovo del certificato e di esportazione della Keychain dal percorso di invio, ma il tuo team ha ancora bisogno di un modello di proprietà chiaro. Decidi chi può creare, revocare e distribuire le chiavi. Limita l'accesso al servizio backend che firma i token del provider e assicurati che esista un processo di sostituzione d'urgenza prima che la chiave attuale diventi inaccessibile.
Per un'app Capacitor, il client ha ancora bisogno di una registrazione delle notifiche corretta e delle autorizzazioni. La migrazione cambia principalmenteNon registrare il token dispositivo code. Il tuo backend deve continuare ad associare i token con l'applicazione e l'ambiente corretti.
Sappi quando i certificati rimangono necessari
Some enterprise tools and established integrations still expose certificate-based configuration. Don’t force a p8 migration until the receiving system supports it and your team has tested the complete path. Keep the legacy credential protected during the transition, but don’t create new dependencies on it when token authentication fits.
Se hai bisogno di comprendere il flusso di lavoro dell'applicazione circostante, rivedi Ionic e Capacitor notifiche push con FirebaseFirebase può fornire un layer di consegna dell'applicazione, ma le credenziali Apple, le autorizzazioni, la registrazione e le risposte APNs richiedono una configurazione deliberata.
Rinnovare e Gestire Cicli di Vita delle Certificazioni
Trattare un certificato APNs come una dipendenza di produzione che scade dal giorno della sua creazione. Apple afferma che questi certificati sono validi per un anno dalla creazione e devono essere rinnovati prima della scadenza per preservare la comunicazione con i dispositivi. Apple avverte anche che non rinnovare può richiedere agli utenti di reregistrare dispositivi iOS, iPadOS e Mac con APNs e può causare interruzioni del servizio. Consultare la documentazione di Apple per il rinnovo del certificato di notifica push documentazione di rinnovo dei certificati di notifica push.
Generare un nuovo CSR:
- Genera un nuovo CSR: Crea la richiesta attraverso il tuo workflow approvato e conserva il materiale di chiave associato.
- Usa l'ID Apple originale: Accedi con lo stesso ID Apple utilizzato per creare il certificato esistente.
- Scegli il certificato in scadenza: Verifica l'ID App, il DN Soggetto, l'UID e i dettagli di scadenza prima di selezionare Rinnova.
- Carica il CSR: Inviare la nuova richiesta nel portale dei certificati Push Apple.
- Scarica e reinstalla: Recupera il rinnovato
.pemInstalla dove è disponibile la chiave privata e esporta una sostituzione.p12Se il tuo provider lo richiede. - Distribuisci e testa: Aggiorna il segreto del server, invia una notifica controllata e ispeziona la risposta APNs.
Confronta i formati del provider
| Richiesta | Ciclo di certificato | Ciclo di token |
|---|---|---|
| Segreto primario | Certificato più chiave privata | .p8 Chiave di autenticazione |
| Preoccupazione di rinnovo | La scadenza del certificato richiede un rimpiazzo ricorrente | Nessun rimpiazzo annuale del certificato |
| Lavoro di distribuzione | Installare, associare, esportare e caricare | Conservare la chiave di firma e configurare la generazione di token |
| Rischio di fallimento principale | Certificato sbagliato, chiave privata mancante, scadenza o revoca | Chiave di autenticazione persa, esposta o revocata |
L'ecosistema di certificati di Apple richiede anche lavoro di trust-chain programmato. Apple ha annunciato aggiornamenti dei certificati del server APNs per sandbox. 20 gennaio 2025 e per la produzione il 24 febbraio 2025richiedendo di includere nei trust store il certificato SHA-2 Root USERTrust RSA Certification Authority certificato. Leggi il Annuncio del certificato server Apple APNs e includi la gestione delle chiavi di trust-store nella tua checklist di piattaforma.
Usa un calendario di rinnovo condiviso, un proprietario denominato e un libro di procedure di distribuzione. La documentazione di gestione del certificato Capgo Possono essere utilizzati insieme a quel runbook per le squadre che gestiscono le credenziali di consegna iOS con il loro processo di rilascio mobile.
Risolvere i problemi e gestire le credenziali perse
Il difficile incidente non è sempre un avviso di scadenza. È la mattina in cui l'amministratore che ha creato il certificato è partito, la chiave privata esiste solo su un vecchio Mac, o un certificato è stato revocato durante un tentativo di pulizia. Il flusso di rinnovo standard dipende dall'ID Apple originale e dall'identità del certificato corretta, quindi l'accesso e la provenienza contano quanto il file stesso.
Inizia classificando il fallimento:
- Certificato scaduto: Genera un rimpiazzo attraverso l'account originale, reinstallalo con la chiave privata corrispondente, aggiorna il provider e testa la consegna. Se la comunicazione con i dispositivi è già stata interrotta, segui le linee guida di recupero di Apple piuttosto che assumere che un rimpiazzo server-side riattivi immediatamente ogni dispositivo.
- Certificato revocato: Smetti di considerare la credenziale vecchia come recuperabile. Apple rifiuta le connessioni TLS da server che utilizzano certificati revocati, quindi crea un rimpiazzo valido e rimuovi il segreto revocato dalle distribuzioni attive. Controlla chi l'ha revocato e se altri sistemi hanno copiato la stessa credenziale.
- Lost
.p12password: A un file di certificato senza la password utilizzabile potrebbe essere inutilizzabile. Recupera il backup approvato o emetti un nuovo certificato al posto di indebolire i controlli di segretezza di produzione. - Chiave privata persa: Riscaricare il certificato pubblico non ricrea la chiave privata. Crea un nuovo CSR su una macchina controllata e emetti un nuovo credenziale.
- Accesso Apple ID perso: Verifica se l'organizzazione può recuperare l'account attraverso i suoi processi di identità e di distribuzione. Apple dirige il supporto per i certificati APNs creati attraverso il relativo portale a Sostegno dei Programmi di Distribuzione.
La ripristino richiede l'identità, non solo un nome di file. Ricordare l'ID Apple proprietario, ID App, identità del certificato, posizione della chiave privata, configurazione del provider e procedura di sostituzione prima che si verifichi un incidente.
Costruisci un reticolo di sicurezza operativa
Metti i certificati e .p8 le chiavi in un archivio condiviso e controllato. Conserva la .p12 password separatamente dal file, limita l'accesso di produzione e documenta l'account del portale esatto utilizzato per la rinnovazione. Il tuo sistema CI/CD dovrebbe iniettare i segreti al momento della distribuzione e eseguire un controllo di salute che rilevi gli errori di autenticazione prima che gli utenti segnalino gli avvisi mancanti.
Conservare il credenziale vecchio disponibile durante una sostituzione controllata quando la piattaforma lo consente, ma non lasciare segreti obsoleti attivi indefinitamente. Testare una sostituzione nella stessa path backend che la produzione utilizza, compreso l'ambiente del provider, l'identificatore del bundle e lo store dei token dispositivi.
Quando un'interruzione è già accaduta, preservare i corpi di risposta APNs e i timestamp, identificare la prima richiesta rifiutata e confrontare il segreto di distribuzione prima e dopo l'incidente. Non riprovare indefinitamente con un credenziale non valido. Correggere l'identità o il problema di autenticazione prima, quindi inviare una piccola notifica di verifica a un dispositivo di test noto.
Capgo può memorizzare e configurare le credenziali di push iOS come parte di un flusso di notifica Capacitor mentre il suo team mantiene la responsabilità dell'accesso all'account Apple, della custodia dei segreti e delle decisioni di rinnovo. Visita Capgo revisionare come il suo strumento di consegna mobile possa adattarsi al ciclo di credenziali e al processo di rilascio APNs.
