Il certificato del servizio di notifica push 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.
La mancata funzionalità spesso si manifesta al momento peggiore. Una versione viene rilasciata, una campagna è programmata e la consegna delle notifiche improvvisamente cade nel silenzio. 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. Devi capire quale credenziale APNs il tuo sistema utilizza, conservare la chiave privata, pianificare il rinnovo e spostare le attività adatte all'autenticazione basata su token.
Indice dei contenuti
- Perché le notifiche push smettono di funzionare
- Creare e scaricare il certificato APNs
- Esportare il certificato in una chiave privata
- Migrare al nuovo autenticazione basata sui token
- Rinnovare e Gestire Cicli di Certificati
- Risolvere Problemi e Gestire 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 operare?
| Percorso delle credenziali | Cosa fa | Proprietario tipico |
|---|---|---|
| App Push | Inviare 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 |
Questi credenziali non sono intercambiabili. Una piattaforma MDM può perdere il contatto con i dispositivi iscritti quando scade il suo credenziale di push MDM, mentre un backend di applicazione può perdere la consegna delle notifiche a causa del suo credenziale App Push non valido. Considerare entrambi come un problema di certificato di push Apple porta la risoluzione dei problemi nella direzione sbagliata.
Per Capacitor e team Ionic, il percorso rilevante per le avvisi faccia a faccia degli utenti è generalmente App PushL'applicazione ha ancora bisogno della capacità di notifiche Push, firma corretta, registrazione del 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 di push dall'autenticazione di push. Il Capacitor plugin di notifiche documentazione Copre l'integrazione di applicazione, mentre i credenziali APNs appartengono alla configurazione del provider.
Inizia con il rifiuto, non con l'interfaccia utente
Controlla la risposta APNs dal tuo server di provider prima di modificare il testo delle notifiche o di ricostruire l'app. Verifica quindi l'identificatore del pacchetto, l'identità delle credenziali, l'ambiente e lo stato della certificazione. Un problema di autorizzazione delle notifiche influisce sulla capacità di un utente di vedere le notifiche, ma non spiega un rifiuto TLS da parte di APNs.
Se il fallimento è apparso dopo una rilascio, confronta la firma e le autorizzazioni nel nuovo build con il precedente build. Se è apparso senza una modifica dell'app, controlla l'espiazione della certificazione, la revoca, i cambiamenti del trust-store e i segreti di distribuzione prima. Per un percorso di implementazione più ampio, vedi questo guida per Configurazione delle notifiche push di Expo.
Creazione e Download del Certificato APNs
Una distribuzione push può fallire prima della prima notifica inviata se la certificazione è emessa per l'ID App sbagliato o la chiave privata rimane su un altro Mac. Il workflow di Apple ha due parti: la tua macchina crea un Richiesta di firma della certificazione, o CSR, e Apple la firma per l'ID App selezionato. Il CSR non è la credenziale del server. Collega la certificazione emessa a una chiave privata creata localmente.
Preparazione dell'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 Push Notifications context: Pagina/Area: Sito web di marketing Capgo. Ruolo: Etichetta breve o elemento di navigazione. Chiave messaggio `push_notifications` (Notifiche Push).
è abilitato prima di emettere qualsiasi cosa.
Le credenziali APNs sono legate all'identità dell'applicazione. Non scegliere un identificatore di pacchetto vicino con un nome simile. Configura ogni applicazione separata in modo independente e emetti il credenziale corrispondente. Sulla Mac che terrà la chiave, apri Accesso alla chiave
Un monitor di computer che visualizza una finestra di comando della riga di comando Linux utilizzata per generare certificati SSL.
Inserisci ScegliL'opzione del certificato del servizio di notifica push Apple. Seleziona l'ID dell'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 catena di chiavi, 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. Memorizza il certificato originale, le informazioni di proprietà del CSR e i dettagli dell'account del portale nel sistema di credenziali della tua squadra. Un cartellino dei download di un sviluppatore o un 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, consulta la guida di integrazione delle notifiche del Capacitor. Tratta questo certificato come un credenziale gestito, non come un download unico, perché l'esportazione successiva, la migrazione del token, la rinnovazione e la ripristino dipendono dal sapere chi controlla la sua chiave.
L'Esportazione del Certificato a una Chiave Privata
A 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 PKCS#12 .p12 file.
Apre Accesso alla chiave su Mac dove hai installato il certificato. Cerca il certificato APNs, espandilo o esaminalo, e individua la chiave privata con l'identità e le informazioni di scadenza corrispondenti. 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
Dai all'esportazione una password forte. La password protegge la chiave privata all'interno del bundle, quindi non metterla in un repository, un ticket, un messaggio di chat o un registro 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 sua chiave privata corrispondente non è un credenziale di provider completo.
Prima dell'uso in produzione, testa il pacchetto in un ambiente controllato. Assicurati 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. Devi preservare la chiave privata originale, ripetere l'esportazione manuale, proteggere il file e sostituire la chiave di deploymen segreta al momento della rinnovazione. Le squadre che gestiscono più app possono facilmente perdere il controllo di quale pacchetto appartiene a quale ID App.
Usa la gestione segreta sicura nei flussi di integrazione CI/CD per controllare chi può leggere o sostituire la credenziale. Conserva un registro degli upload e delle rotazioni, ma non registrare mai la chiave privata o la .p12 password.
Per il nuovo lavoro backend, valuta se l'autenticazione con certificato è ancora appropriata. Le integrazioni esistenti possono richiedere .p12ma l'autenticazione con token rimuove di solito la sostituzione annuale del certificato dal provider di connessione. Ciò non elimina la governance delle credenziali. Cambia solo ciò che proteggi e rotazione.
Migrare all'autenticazione basata su token
Apple ha spostato l'autenticazione APNs verso token del providerApple Push Notification Service Certificati flusso p8Al posto 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 autenticazione del servizio di notifica Push Apple.
Creare la chiave nel portale dello sviluppatore Apple sotto Certificati, Identificatori e Profili, quindi aprire Chiavi e registrare una chiave di autenticazione APNs. Scaricare il .p8 file e registrare l'ID chiave e l'ID team nel tuo archivio segreto. Trattare il file scaricato come un segreto di firma di alto valore.
Effettuare la migrazione deliberatamente
Non sostituire il traffico di produzione sostituendo un file in un ambiente non testato. Costruire l'autenticazione dei token accanto al percorso esistente del certificato, validare il comportamento sandbox e di produzione e confrontare le risposte APNs. Poi effettuare il cambio di configurazione del provider durante un'installazione controllata.
La migrazione elimina i passaggi di rinnovo del certificato e di esportazione della chiave di cassetta dal percorso di invio, ma il tuo team ancora ha bisogno di un modello di proprietà chiaro. Decidere chi può creare, revocare e distribuire le chiavi. Limitare l'accesso al servizio back-end che firma i token del provider e assicurarsi che esista un processo di sostituzione d'urgenza prima che la chiave corrente non sia più disponibile.
Per un'app Capacitor, il client ancora richiede una registrazione e un'abilitazione delle notifiche corrette. La migrazione cambia principalmente l'autenticazione server-APNs, non la registrazione del token dispositivo code. Il tuo backend deve continuare ad associare i token con l'applicazione e l'ambiente corretti.
Sapere quando i certificati rimangono necessari
Alcuni strumenti aziendali e le integrazioni stabilite espongono ancora una configurazione basata sui certificati. Non forzare una migrazione p8 fino a quando il sistema di ricezione non lo supporta e il tuo team non ha testato il percorso completo. Conserva il credenziale di transizione protetto durante la transizione, ma non crea nuove dipendenze da essa quando l'autenticazione dei token si adatta.
Se hai bisogno di comprendere il flusso di applicazione circostante, rivista Ionic e le notifiche push Capacitor con Firebase. Firebase può fornire un layer di consegna dell'applicazione, ma i credenziali di Apple, le abilitazioni, la registrazione e le risposte APNs richiedono una configurazione deliberata.
Gestione e Rinnovo dei Cicli di Vita dei Certificati
Tratta un certificato APNs come una dipendenza di produzione che scade dal giorno in cui lo crei. Apple dice che questi certificati sono validi per un anno dalla creazione e deve essere rinnovato prima della scadenza per preservare la comunicazione del dispositivo. Apple avverte anche che il mancato rinnovo può richiedere agli utenti di reregistrare dispositivi iOS, iPadOS e Mac con APNs e può causare interruzioni del servizio. Vedi la documentazione di Apple per il rinnovo del certificato di notifica push. la documentazione di Apple per il rinnovo del certificato di notifica push.
La strada di rinnovo è precisa:
- Genera un nuovo CSR: Crea la richiesta attraverso il tuo workflow approvato e conserva il materiale di chiave associato.
- Utilizza l'ID Apple originale: Accedi con lo stesso ID Apple utilizzato per creare il certificato esistente.
- Scegli il certificato in scadenza: Corrispondi l'ID App, il DN oggetto, l'UID e i dettagli di scadenza prima di selezionare Rinnova.
- Carica il CSR: Inviare la nuova richiesta nel Portale dei certificati di notifica push di Apple.
- Estrarre e reinstallare: Ricavare il certificato rinnovato
.pemE installarlo dove è disponibile la chiave privata, e esportare una sostituzione.p12se il tuo provider lo richiede. - Distribuire e testare: Aggiornare il segreto del server, inviare una notifica controllata, e ispezionare la risposta APNs.
Confrontare i formati del provider
| Requisito | Ciclo del certificato | Ciclo del 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 | Memorizzare la chiave di firma e configurare la generazione del token |
| Rischio principale di fallimento | Certificato sbagliato, chiave privata mancante, scadenza o revoca | Chiave di autenticazione persa, esposta o revocata |
L'ecosistema dei certificati di Apple richiede anche un lavoro di trust-chain programmato. Apple ha annunciato aggiornamenti dei certificati del server APNs per il sandbox il 20 gennaio 2025 e produzione il 24 febbraio 2025, richiede di includere negli archivi di trust il certificato SHA-2 Root USERTrust RSA Certification Authority Leggi l'annuncio del server di certificati APNs di Apple e assicurati che la proprietà degli archivi di trust sia parte della tua checklist di piattaforma. Utilizza un calendario di rinnovo condiviso, un proprietario denominato e un runbook di distribuzione. La
documentazione di gestione dei certificati __CAPGO_KEEP_0__ Capgo certificate management documentation 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.
Risolvere i problemi e gestire le credenziali perse
Avvia classificando il fallimento:
- Certificato scaduto: Genera un rimpiazzo attraverso il conto originale, reinstalla 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 ripristino di Apple piuttosto che supporre che un rimpiazzo server-side ripristini immediatamente ogni dispositivo.
- Certificato revocato: Smetti di trattare 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 deployment attive. Controlla chi l'ha revocato e se altri sistemi hanno copiato la stessa credenziale.
- Perduta:
.p12password: Un file di certificato senza la password utilizzabile può essere inutilizzabile. Recupera il backup approvato o emetti un rimpiazzo al posto di indebolire i controlli di segreti di produzione. - Perduta chiave privata: Riscaricare il certificato pubblico non ricrea la chiave privata. Crea un nuovo CSR su una macchina controllata e emetti un rimpiazzo di credenziale.
- Perduta accesso all'ID di Apple: Conferma se l'organizzazione può recuperare il conto attraverso i suoi processi di identità e deployment. Apple dirige il supporto per i certificati APNs creati attraverso il relativo portale a Programmi di distribuzione Supporto.
La ripresa richiede un'identità, non solo un nome di file. Ricordate l'ID Apple proprietario, l'ID App, l'identità del certificato, la posizione della chiave privata, la configurazione del provider e la procedura di sostituzione prima che si verifichi un incidente.
Costruire un reticolo di sicurezza operativa
Mettere i certificati e le .p8 chiavi in un deposito condiviso, controllato e accessibile. Conservate la .p12 password separatamente dal file, limitate l'accesso alla produzione, e documentate l'esatta account del portale utilizzato per la rinnovazione. Il vostro 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 le notifiche mancanti.
Tienere disponibile il vecchio credenziale durante una sostituzione controllata quando il piattaforma lo consente, ma non lasciare i segreti obsoleti attivi indefinitamente. Testate una sostituzione nella stessa via di backend utilizzata dalla produzione, compreso l'ambiente del provider, l'identificatore del bundle e lo store dei token di dispositivo.
Quando un'interruzione è già accaduta, conservate i corpi di risposta APNs e i timestamp, identificate la prima richiesta rifiutata e confrontate il segreto di distribuzione prima e dopo l'incidente. Non riprovate indefinitamente con un credenziale non valido. Correggete il problema di identità o autenticazione prima di 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 lavoro di notifica Capacitor, mentre il vostro team mantiene la responsabilità dell'accesso all'account Apple, della custodia dei segreti e delle decisioni di rinnovazione. Visita Capgo per esaminare come le sue strumentazioni di consegna mobile possano adattarsi al ciclo di credenziali e al processo di rilascio APNs.
