Apple-Push-Benachrichtigungsdienstzertifikate sind für ein Jahr gültig und müssen jährlich in der Apple-Entwickler-Portal erneuert werden, um eine Unterbrechung der Gerätekommunikation zu vermeiden. Wenn Sie für ein Capacitor-App verantwortlich sind, kann ein abgelaufenes oder zurückgezogenes Zertifikat die Benachrichtigungen auch dann unterbrechen, wenn das App selbst gesund erscheint.
Die Fehlfunktion tritt oft zum schlimmsten Zeitpunkt auf. Ein Release wird veröffentlicht, eine Kampagne ist geplant, und die Benachrichtigungsübermittlung wird plötzlich still. Ihr Anwendungs-Server mag noch Jobs akzeptieren, aber APNs können die TLS-Verbindung ablehnen, bevor eine Nachricht an ein Gerät gelangt. Der praktische Fix besteht nicht nur darin, ein weiteres Zertifikat zu erstellen. Sie müssen verstehen, welches APNs-Zertifikat Ihr System verwendet, den privaten Schlüssel aufbewahren, die Verlängerung planen und geeignete Workloads auf Token-basierte Authentifizierung umstellen.
Inhaltsverzeichnis
- Warum Push-Benachrichtigungen nicht funktionieren
- Erstellen und herunterladen Sie Ihr APNs-Zertifikat
- Das Zertifikat in einen privaten Schlüssel exportieren
- Migrieren Sie auf die neue Token-basierte Authentifizierung
- Zurücksetzen und Verwalten von Zertifikatslebenszyklen
- Fehlerbehebung und Umgang mit verlorenen Anmeldeinformationen
Wie Push-Benachrichtigungen funktionieren
APNs befindet sich zwischen Ihrem Anbieter-Server und dem Apple-Gerät des Benutzers. Ihr Server authentifiziert sich bei Apple, sendet eine Benachrichtigung und hängt sich an APNs, um sie an die registrierte Anwendung und das Gerät zu leiten. Wenn das Zertifikat abgelaufen ist, widerrufen, mit der falschen Identität verbunden oder falsch installiert wurde, kann die Anfrage scheitern, bevor die Lieferung beginnt.
Apple besagt, dass APNs eine Liste von widerrufenen Zertifikaten führt und TLS-Verbindungen von Servern ablehnt, die Zertifikate auf dieser Liste verwenden. Das macht die Zertifikatsreinigung ein Lieferungsanforderung und nicht eine Verwaltungsvorliebe. Der Server kann weiterhin Benachrichtigungsjobs lokal verarbeiten, während Apple die Anbieterverbindung ablehnt.
Separieren Sie die App-Push von der MDM-Push
Die erste diagnostische Frage ist einfach: Bei welchem Dienst versuchen Sie, zu arbeiten?
| Zertifikatspfad | Was es tut | Typischer Besitzer |
|---|---|---|
| App Push | Sendet Benachrichtigungen und andere Anwendungsbenachrichtigungen an Endgeräte des Benutzers | Mobiles oder Backend-Engineering |
| MDM Push | Lässt eine Gerätemanagementsplattform mit verwalteten Apple-Geräten kommunizieren | IT, Endpunkt- oder Enterprise-Mobilitätsverwaltung |
Diese Zertifikate sind nicht austauschbar. Ein MDM-Plattform kann den Kontakt mit registrierten Geräten verlieren, wenn das MDM-Push-Zertifikat abläuft, während ein Anwendungs-Backend die Benachrichtigungslieferung verliert, weil das App-Push-Zertifikat ungültig ist. Die Behandlung beider als ein einziges "Apple-Push-Zertifikat"-Problem lenkt die Fehlerbehebung in die falsche Richtung.
Für Capacitor- und Ionic-Teams ist der relevante Weg für Benutzerbenachrichtigungen in der Regel App PushDie App benötigt jedoch weiterhin die Push-Benachrichtigungs-Fähigkeit, die richtige Signierung, die Geräeregistrierung und einen Backend, der durch den entsprechenden APNs-Umgebung sendet. Wenn Ihr Team auch Web-Assets über das Internet bereitstellt, halten Sie das Release-Workflow getrennt von der Push-Authentifizierung. Capacitor Benachrichtigungs-Plugin-Dokumentation beschäftigt sich mit der Anwendungsbereich-Integration, während die APNs-Zugangsdaten in der Anbieterkonfiguration gehören.
Beginne mit der Ablehnung, nicht mit der Benutzeroberfläche
Überprüfe die APNs-Antwort Ihres Anbieter-Servers, bevor Sie die Benachrichtigungsanzeige ändern oder das App-Programm neu erstellen. Überprüfe dann die App-Identifikationsnummer, die Zugangsidentität, die Umgebung und den Zertifikatsstatus. Ein Benachrichtigungs-Erlaubnisproblem beeinträchtigt die Fähigkeit eines Benutzers, Benachrichtigungen zu sehen, aber es erklärt nicht eine TLS-Ablehnung von APNs.
Wenn die Fehlfunktion nach einer Veröffentlichung erschien, vergleichen Sie die Signierung und die Berechtigungen in der neuen Version mit der vorherigen Version. Wenn sie ohne eine App-Änderung erschien, überprüfen Sie das Zertifikats-Ablaufdatum, die Zertifikats-Entscheidung, Änderungen im Trust-Store und die Bereitstellungsschlüssel zuerst. Für einen umfassenderen Implementierungsverlauf sehen Sie sich diese Anleitung zu Expo-Benachrichtigungs-Setup.
Erstellung und Herunterladen Ihres APNs-Zertifikats
Ein Push-Rollout kann fehlschlagen, bevor die erste Benachrichtigung gesendet wird, wenn das Zertifikat für die falsche App-Identifikationsnummer ausgestellt wurde oder der private Schlüssel auf einem anderen Mac bleibt. Apples Workflow besteht aus zwei Teilen: Ihr Computer erstellt ein Zertifikatsanforderung, oder CSR, und Apple signiert es für die ausgewählte App-Identifikationsnummer. Die CSR ist nicht der Server-Zugriff. Sie verbindet das ausgestellte Zertifikat mit einem lokalen privaten Schlüssel.Vorbereitung der App-Identifikationsnummer
Melden Sie sich bei der Apple-Entwickler-Plattform an und öffnen Sie
die App-Identifikationsnummer Zertifikate, Identifikatoren & Profile. Wählen Sie Identifikatoren, wählen Sie die App-Identifikator und öffnen Sie die Konfiguration. Bestätigen Sie, dass Push-Benachrichtigungen context: Seite/ Bereich: Capgo-Marketing-Website. Rolle: Kurzer Benutzerschnittstelle-Label oder Navigationselement. Nachrichtenschlüssel `push_notifications` (Push-Benachrichtigungen).
aktiviert ist, bevor Sie etwas ausstellen.
Die APNs-Zertifikate sind der Anwendungsidentität zugeordnet. Wählen Sie nicht einen nahegelegenen App-Identifikator mit einem ähnlichen Namen. Konfigurieren Sie jede separate Anwendung unabhängig und stellen Sie die entsprechende Zertifizierung aus. Öffnen Sie auf dem Mac, der die Schlüssel behält, Keychain Access
Eine Computeranzeige, die eine Linux-Terminal-Befehlszeile verwendet, um SSL-Zertifikate zu generieren.
In Zertifikate, wählen Sie die Option für das Apple-Push-Benachrichtigungsdienstzertifikat. Wählen Sie das App-ID, laden Sie das CSR hoch und senden Sie die Anfrage ab. Laden Sie das von Apple ausgestellte Zertifikat herunter.
Doppelklicken Sie auf das heruntergeladene Datei auf dem Mac, der den privaten Schlüssel besitzt. Es sollte sich in Keychain Accessinstallieren, wo Sie das Zertifikat und seinen passenden privaten Schlüssel überprüfen können. Ein ohne diesen Schlüssel importiertes Zertifikat kann die vollständige Authentifizierung Ihres Backends nicht bereitstellen.
Verwenden Sie eine Namenskonvention, die die Anwendungsidentität, Umgebung, Besitzer und Ablaufdatum aufzeichnet. Speichern Sie das Originalzertifikat, die CSR-Besitzinformationen und die Portal-Konto-Daten in Ihrem Teams-Kredentials-System. Ein Entwicklers-Downloads-Ordner oder ein persönlicher Laptop ist kein operativer Backup.
Das Zertifikat unterstützt nur einen Teil der Lieferung. Die App muss sich für Remotebenachrichtigungen anmelden, der Server muss den resultierenden Geräte-Token aufbewahren und der Anbieter muss mit dem passenden Thema und Umgebung senden. Halten Sie diese Abhängigkeiten in derselben Runbook. Für die clientseitige Einrichtung siehe die CapacitorBenachrichtigungsintegration-Anleitung
. Behandeln Sie dieses Zertifikat als ein verwaltetes Kredentials, nicht als eine einmalige Herunterladung, da die spätere Exportierung, Tokenmigration, Erneuerung und Wiederherstellung von der Kenntnis abhängen, wer den Schlüssel kontrolliert.
Aus einem heruntergeladenen Apple-Zertifikat ist noch nicht automatisch ein Node.js-Dienst oder ein verwalteter Push-Dienst bereit. Der Server benötigt das Zertifikat und seine entsprechende private Schlüssel, die häufig als ein PKCS#12 .p12 Datei.
Öffnen Schlüsselkette auf dem Mac, auf dem Sie das Zertifikat installiert haben. Suchen Sie nach dem APNs-Zertifikat, erweitern oder untersuchen Sie es, und finden Sie den privaten Schlüssel mit der passenden Identität und Ablaufinformationen. Wählen Sie das Zertifikat und den privaten Schlüssel aus, und verwenden Sie dann die Exportaktion, um eine .p12 Datei zu speichern.
Validieren Sie das Bundle vor der Bereitstellung
Geben Sie dem Export einen starken Passwort. Das Passwort schützt den privaten Schlüssel innerhalb des Bundles, also sollten Sie es nicht in einem Repository, Ticket, Chatnachricht oder Build-Protokoll platzieren. Laden Sie die Datei und das Passwort über Ihr geheimes Verwaltungssystem hoch, und gewähren Sie dann nur dem Dienst Zugriff, der Benachrichtigungen sendet.
Praktische Regel: Eine
.p12Datei ohne ihren passenden privaten Schlüssel ist kein vollständiges Anbieterkonto.
Bevor Sie die Veröffentlichung verwenden, testen Sie das Bundle in einem kontrollierten Umfeld. Bestätigen Sie, dass Ihr Backend den Datei laden, die APNs-Verbindung herstellen und strukturierte Fehler zurückgeben kann, wenn Apple eine Anfrage ablehnt. Wenn ein Anbieter wie Capgo eine iOS-Push-Zugriffsberechtigung anfordert, laden Sie die .p12 und ihr Passwort über die zugewiesene geheime Konfiguration hoch, anstatt entweder Wert in der Anwendung code einzubinden.
Die Formatierung offenbart auch die Schwäche des alten Workflows. Sie müssen das ursprüngliche privatschlüssel, eine manuelle Exportwiederholung, den Schutz der Datei und den Austausch der Bereitstellungsschlüssel bei der Erneuerung aufrechterhalten. Teams, die mehrere Apps betreiben, können leicht den Überblick über die zugehörigen Bundle verlieren.
Verwenden Sie zu kontrollieren, wer den Zugriff auf oder den Austausch des Zugriffsberechtigungen hat. Halten Sie einen Audit-Trail für Uploads und Rotationen, aber loggen Sie nie den privatschlüssel oder das Passwort. .p12 Für neue Backend-Arbeiten bewerten Sie, ob die Zertifikatsauthentifizierung noch angemessen ist. Bestehende Integrations erfordern
, aber die Tokenauthentifizierung entfernt normalerweise die jährliche Zertifikatserneuerung vom Anbieterverbindung. Das eliminiert nicht die Zugriffsberechtigung. Es ändert, was Sie schützen und rotieren. .p12Migrieren Sie zu der neuen Token-basierten Authentifizierung
Apple hat die APNs-Authentifizierung in Richtung
Anbieter-Token provider tokens, auch bekannt als das p8-Workflow. Anstatt ein Zertifikat und eine private Schlüssel für eine langfristige TLS-Identität vorzulegen, signiert Ihr Anbieter Authentifizierungstoken mit einem Apple Push Notification service Authentication Key.
Erstellen Sie die Schlüssel in der Apple Developer-Portal unter Zertifikate, Identifikatoren und Profile, öffnen Sie dann Schlüssel und registrieren Sie einen APNs-Authentifizierungsschlüssel. Laden Sie das .p8 Datei herunter und notieren Sie sich die zugehörige Schlüssel-ID und Team-ID in Ihrem geheimen Speicher. Behandeln Sie die heruntergeladene Datei als einen hochwertigen Signierungsschlüssel.
Erstellen Sie die Migration absichtlich
Schalten Sie nicht die Produktionsverkehr, indem Sie eine Datei in einem ungetesteten Umfeld ersetzen. Bauen Sie die Tokenauthentifizierung neben dem bestehenden Zertifikatspfad auf, überprüfen Sie die Sandbox- und Produktionsverhalten und vergleichen Sie die APNs-Antworten. Dann ändern Sie die Anbieterkonfiguration während eines kontrollierten Deployments.
Die Migration entfernt die Zertifikatsverlängerung und die Keychain-Export-Schritte aus dem Absendenpfad, aber Ihr Team benötigt immer noch ein klares Eigentümerschaftsmodell. Bestimmen Sie, wer Schlüssel erstellen, widerrufen und bereitstellen kann. Limitieren Sie den Zugriff auf das Backend-Service, das Anbieter-Token signiert, und stellen Sie sicher, dass ein Notfall-Ersatzprozess vorliegt, bevor der aktuelle Schlüssel nicht mehr verfügbar ist.
Für eine Capacitor-App benötigt der Client noch korrekte Benachrichtigungsanmeldungen und Berechtigungen. Die Migration ändert hauptsächlich Server-zu-APNs-Authentifizierung, nicht die Gerätekennwortanmeldung code. Ihr Backend muss weiterhin Token mit der richtigen Anwendung und Umgebung verbinden.
Wissen, wann Zertifikate noch notwendig sind
Einige Unternehmenswerkzeuge und etablierte Integrationsmöglichkeiten offenbaren noch Zertifikat-basierte Konfigurationen. Zwingen Sie eine p8-Migration nicht vor, bis das empfangende System sie unterstützt und Ihr Team die komplette Strecke getestet hat. Bewahren Sie die Legacy-Kredenzialen während der Übergangsphase geschützt, aber schaffen Sie keine neuen Abhängigkeiten davon, wenn Token-Authentifizierung geeignet ist.
Wenn Sie das umgebende Anwendungsfluss verstehen müssen, überprüfen Sie Ionic und Capacitor Push-Benachrichtigungen mit Firebase. Firebase kann eine Anwendungslieferungsschicht bereitstellen, aber Apple-Zertifikate, Berechtigungen, Anmeldungen und APNs-Antworten erfordern eine bewusste Konfiguration.
Erneuerung und Verwaltung von Zertifikatslebenszyklen
Behandeln Sie ein APNs-Zertifikat als einen ablaufenden Produktionsabhängigkeit von dem Tag an, an dem Sie es erstellen. Apple sagt, diese Zertifikate sind für und muss vor Ablauf erneuert werden, um die Geräteverbindung aufrechtzuerhalten. Apple warnt auch davor, dass das Fehlen einer Erneuerung dazu führen kann, dass Benutzer iOS-, iPadOS- und Mac-Geräte mit APNs neu registrieren müssen und dass dies zu Serviceunterbrechungen führen kann. Siehe Apple’s Apple-Push-Zertifikats-erneuerungs-Dokumentation.
Der Erneuerungsweg ist genau:
- Erstellen Sie ein neues CSR: Erstellen Sie die Anfrage über Ihren genehmigten Workflow und bewahren Sie das damit verbundene Schlüsselmaterial auf.
- Verwenden Sie den ursprünglichen Apple-Konto: Melde sich mit demselben Apple-Konto an, das zum Erstellen des bestehenden Zertifikats verwendet wurde.
- Wählen Sie das ablaufende Zertifikat: Passen Sie die App-ID, den Subject DN, die UID und die Ablaufdaten an, bevor Sie auswählen Erneuern.
- Hochladen Sie das CSR: Senden Sie die neue Anfrage im Apple Push Certificates Portal.
- Herunterladen und erneut installieren: Das erneuerte
.peminstallieren, wobei der private Schlüssel verfügbar sein muss, und einen Ersatz exportieren.p12sofern Ihr Anbieter dies erfordert. - Implementieren und testen: Die Server-Secrets aktualisieren, eine kontrollierte Benachrichtigung senden und die APNs-Antwort überprüfen.
Die Anbieterformate vergleichen
| Anforderung | Zertifikatsworkflow | Token-Workflow |
|---|---|---|
| Haupt-Secret | Zertifikat plus privater Schlüssel | .p8 Authentifizierungs-Schlüssel |
| Renewal-Beschwerde | Zertifikatsablauf erfordert wiederkehrende Ersetzung | Keine jährliche Zertifikatsersetzung |
| Entwicklungsarbeit | Installieren, pairing, exportieren und hochladen | Zertifikatsignierungs-Schlüssel speichern und Token-Generierung konfigurieren |
| Hauptversagensrisiko | Falsches Zertifikat, fehlender privater Schlüssel, Ablaufdatum oder Rückruf | Authentifizierungs-Schlüssel verloren, offengelegt oder zurückgezogen |
Apple's Zertifikatsystem erfordert auch geplante Vertrauensketten-Arbeit. Apple hat APNs-Serverzertifikat-Updates für Sandbox am 20. Januar 2025 und in der Produktion auf 24. Februar 2025, wodurch die Trust-Stores das Zertifikat SHA-2 Root USERTrust RSA-Zertifizierungsbehörde zur Zertifizierung enthalten müssen. Lesen Sie die Apple APNs-Serverzertifikatsankündigung und machen Sie die Eigentümerschaft des Trust-Stores Teil Ihres Plattformenchecklisten.
Verwenden Sie ein gemeinsames Rennkalender, einen benannten Besitzer und ein Bereitstellungsrunbook. Die Capgo Zertifikatsverwaltungsdokumentation liegt neben dem Runbook für Teams, die iOS-Lieferkennungen mit ihrem mobilen Release-Prozess verwalten.
Troubleshooting und Verlust von Anmeldeinformationen
Ein schwieriger Vorfall ist nicht immer eine Ablaufdatumwarnung. Es ist der Morgen, an dem der Administrator, der das Zertifikat erstellt hat, gegangen ist, der private Schlüssel existiert nur auf einem alten Mac oder ein Zertifikat wurde während eines geplanten Reinigungsversuchs zurückgezogen. Die standardmäßige Rennablaufabhängigkeit hängt von der ursprünglichen Apple-ID und der richtigen Zertifikatsidentität ab, daher zählen Zugriff und Herkunft genauso viel wie das Datei selbst.
Beginnen Sie mit der Klassifizierung des Fehlers:
- Abgelaufenes Zertifikat: Erstellen Sie ein Ersatzzertifikat über das Originalkonto, installieren Sie es mit dem passenden privaten Schlüssel neu, aktualisieren Sie den Provider und testen Sie die Lieferung. Wenn die Geräteverbindung bereits unterbrochen wurde, folgen Sie den Wiederherstellungsanweisungen von Apple anstatt davon auszugehen, dass eine serverseitige Ersatzvergabe sofort alle Geräte wiederherstellt.
- Zurückgezogenes Zertifikat: Behandeln Sie das alte Konto nicht mehr als wiederherstellbar. Apple lehnt TLS-Verbindungen von Servern ab, die mit zurückgezogenen Zertifikaten arbeiten, also erstellen Sie ein gültiges Ersatzzertifikat und entfernen Sie das zurückgezogene Geheimnis aus den aktiven Bereitstellungen. Überprüfen Sie, wer es zurückgezogen hat, und ob andere Systeme das gleiche Konto kopiert haben.
- Verloren:
.p12Passwort: Eine Zertifikatsdatei ohne das verwendbare Passwort kann nicht betriebsbereit sein. Rufen Sie die genehmigte Sicherungskopie ab oder erstellen Sie ein Ersatzzertifikat anstatt die Produktionsgeheimnisse zu schwächen. - Verlorenen privaten Schlüssel: Das erneute Herunterladen des öffentlichen Zertifikats wird den privaten Schlüssel nicht wiederherstellen. Erstellen Sie einen neuen CSR auf einem kontrollierten Rechner und erstellen Sie ein Ersatzzertifikat.
- Verlorenen Zugriff auf Apple-ID: Bestätigen Sie, ob die Organisation das Konto über seine Identität und Bereitstellungsprozesse wiederherstellen kann. Apple leitet die Unterstützung für APNs-Zertifikate, die über den relevanten Portal erstellt wurden, zu Zuordnungsprogramme Unterstützung.
Die Wiederherstellung erfordert eine Identität, nicht nur einen Dateinamen. Beachten Sie sich den Apple ID-Besitzer, die App-ID, die Zertifikatsidentität, die private-Schlüssellage, die Anbieterkonfiguration und die Ersatzverfahren vor einem Vorfall.
Erstellen Sie ein Betriebsnetz für die Sicherheit
Legen Sie Zertifikate und Schlüssel in einem gemeinsamen, Zugriffskontrollierten Safe ab. Speichern Sie das Passwort getrennt vom Datei und beschränken Sie den Zugriff auf die Produktion. Dokumentieren Sie genau das Portal-Konto, das für die Erneuerung verwendet wird. Ihr CI/CD-System sollte Geheimnisse bei der Bereitstellung injizieren und eine Gesundheitsprüfung durchführen, die Authentifizierungsfehler vor der Zeit, zu der Benutzer fehlende Benachrichtigungen melden, erkennt. .p8 Halten Sie das alte Konto während einer kontrollierten Ersetzung verfügbar, wenn die Plattform dies zulässt, aber lassen Sie keine veralteten Geheimnisse aktiv bleiben. Testen Sie eine Ersetzung in demselben Backend-Pfad, der von der Produktion verwendet wird, einschließlich der Anbieterumgebung, des Bundle-Identifiers und des Geräte-Token-Speichers. .p12 Wenn ein Ausfall bereits aufgetreten ist, bewahren Sie die APNs-Antwortkörper und -Zeitstempel auf, identifizieren Sie den ersten abgelehnten Antrag und vergleichen Sie das Bereitstellungsschlüssel vor und nach dem Vorfall. Versuchen Sie nicht unendlich gegen ein ungültiges Konto. Korrigieren Sie die Identität oder das Authentifizierungsproblem zuerst und senden Sie dann eine kleine Verifizierungsbenachrichtigung an ein bekanntes Testgerät.
__CAPGO_KEEP_0__ kann iOS-Push-Zertifikate speichern und konfigurieren, als Teil eines __CAPGO_KEEP_1__-Benachrichtigungsworkflow, während Ihr Team die Verantwortung für den Zugriff auf das Apple-Konto, die Geheimniskasse und die Erneuerungsentscheidungen behält. Besuchen Sie
__CAPGO_KEEP_0__
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 um zu überprüfen, wie Ihre mobile Lieferungstools neben Ihrem APNs-Zertifikatslebenszyklus und Ihrer Veröffentlichungsprozess passen können.
