Apple-Push-Benachrichtigungsdienst-Zertifikate sind für ein Jahr gültig und müssen jährlich in der Apple Developer Portal erneuert werden, um die Geräte-Kommunikation nicht zu unterbrechen. Wenn Sie für ein Capacitor-App verantwortlich sind, kann ein abgelaufenes oder zurückgezogenes Zertifikat die Benachrichtigungen auch dann unterbrechen, wenn die 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. Der Anwendungs-Server kann noch Aufträge annehmen, 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
- Weshalb Push-Benachrichtigungen nicht funktionieren
- Erstellung und Herunterladen Ihres APNs-Zertifikats
- Exportieren Sie das Zertifikat in eine private Schlüssel
- Migration auf die neue Token-basierte Authentifizierung
- Zurücksetzen und Verwalten von Zertifikatslebenszyklen
- Fehlerbehebung und Umgang mit verlorenen Anmeldeinformationen
Wie Push-Nachrichten 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 verlässt sich auf APNs, um sie an die registrierte Anwendung und das Gerät zu leiten. Wenn das Zertifikat abgelaufen ist, widerrufen wurde, mit der falschen Identität verbunden ist oder falsch installiert wurde, kann die Anfrage scheitern, bevor die Lieferung beginnt.
Apple stellt fest, dass APNs eine Liste von widerrufenen Zertifikaten führt und TLS-Verbindungen von Servern ablehnt, die Zertifikate auf dieser Liste verwenden. Das macht die Zertifikatspflege eine Lieferanforderung 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 Kontakt mit registrierten Geräten verlieren, wenn das MDM-Push-Zertifikat abläuft, während ein Anwendungs-Backend Benachrichtigungslieferungen verliert, weil das App-Push-Zertifikat ungültig ist. Die Behandlung beider als ein "Apple-Push-Zertifikat"-Problem sendet die Fehlersuche 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 Fähigkeit zum Push-Benachrichtigen, die richtige Signierung, die Geräeregistrierung und einen Backend, der durch die entsprechende 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 beschreibt die 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 du die Benachrichtigungsanzeige änderst oder das App-Programm neu erstellst. Überprüfe dann die Bundle-Identifikator, 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, vergleiche die Signierung und die Berechtigungen in der neuen Version mit der vorherigen Version. Wenn sie ohne eine App-Änderung erschien, überprüfe zunächst die Zertifikatsablaufzeit, die Zertifikatskündigung, Änderungen im Trust-Store und die Bereitstellungsschlüssel. Für einen umfassenderen Implementierungsverlauf siehe diese Anleitung zu Expo-Benachrichtigungs-Setup.
Erstellen und Herunterladen Ihres APNs-Zertifikats
Ein Push-Rollout kann fehlschlagen, bevor die erste Benachrichtigung gesendet wird, wenn das Zertifikat für den falschen App-ID erstellt 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-ID. Die CSR ist nicht der Server-Zugriff. Sie verbindet das ausgestellte Zertifikat mit einem lokal erstellten privaten Schlüssel.Vorbereiten Sie die App-ID
Melden Sie sich bei der Apple-Entwickler-Portal-Website an und öffnen Sie
die App-IDs-Übersicht Zertifikate, Identifikatoren & Profile. Wählen Sie Identifikatoren, wählen Sie die App-Identifikator und öffnen Sie die Konfiguration. Bestätigen Sie, dass Push-Benachrichtigungen aktiviert ist, bevor Sie etwas ausstellen.
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 und erstellen Sie das CSR oder verwenden Sie die von Ihrer Organisation genehmigte Zertifikats-Tooling. Halten Sie den Antrag und den privaten Schlüssel unter der gleichen Kontrolle. Wenn ein anderer Administrator das CSR erstellt, kann dieser Administrator den privaten Schlüssel benötigen, der später für eine verwendbare Server-Bundle erforderlich ist.
Ausstellen Sie das signierte Zertifikat
In ZertifikateWä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 dem Mac, der den privaten Schlüssel besitzt, auf das heruntergeladene Datei. 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-Kredentialsystem. 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 speichern und der Anbieter muss mit dem passenden Thema und Umgebung senden. Halten Sie diese Abhängigkeiten in derselben Runbook. Für die Client-Seitenausführung siehe die CapacitorBenachrichtigungsintegrationanleitung
. Behandeln Sie das Zertifikat als ein verwaltetes Credential und 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-Anbieter 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 zusammen aus, und verwenden Sie dann die Export-Aktion, 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 im Bundle, also legen Sie es nicht in eine Repository, Ticket, Chat-Nachricht oder Build-Protokoll. Laden Sie die Datei und das Passwort über Ihr Geheimhaltungssystem 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 die Produktion beginnt, 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 einen Antrag ablehnt. Wenn ein Anbieter wie Capgo einen iOS-Push-Zugriff anfordert, laden Sie die .p12 und ihr Passwort über die zugewiesene geheime Konfiguration hoch, anstatt entweder Wert in die Anwendung code einzubinden.
Die Formatierung offenbart auch die Schwäche des alten Workflows. Sie müssen den ursprünglichen privaten Schlüssel aufbewahren, eine manuelle Exportierung wiederholen, den Datei schützen und den Bereitstellungsschlüssel bei der Erneuerung ersetzen. Teams, die mehrere Apps betreiben, können leicht den Überblick über die zugehörige Bundle verlieren.
Verwenden Sie um zu kontrollieren, wer den Zugriff auf das Credential hat oder es ersetzen kann. Halten Sie eine Audit-Trail für Uploads und Rotationen, aber loggen Sie nie den privaten Schlü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 Credential-Governance. Es ändert nur, was Sie schützen und rotieren. .p12Migrieren Sie zur neuen Tokenbasierten 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-Zertifikatsschlüssel.
Erstellen Sie den Schlüssel im 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 Signaturgeheimnis.
Erstellen Sie die Migration absichtlich
Schalten Sie nicht ohne Testen die Produktionsverkehr, indem Sie eine Datei in einem ungetesteten Umfeld ersetzen. Bauen Sie die Tokenauthentifizierung neben dem bestehenden Zertifikatspfad, validieren Sie Sandbox- und Produktionsverhalten und vergleichen Sie 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 die Server-zu-APNs-Authentifizierung, nicht die Geräte-Token-Anmeldung code. Ihr Backend muss weiterhin Token mit der richtigen Anwendung und Umgebung verbinden.
Wissen Sie, 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 den gesamten Weg getestet hat. Bewahren Sie die Legacy-Zugriffsberechtigung während der Übergangsphase geschützt, schaffen Sie aber keine neuen Abhängigkeiten davon, wenn Token-Authentifizierung geeignet ist.
Wenn Sie den umgebenden 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.
Zertifikate für die Lebensdauer von APNs
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 ein Jahr ab der Erstellung gültig und muss vor Ablauf erneuert werden, um die Geräte-Kommunikation 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 push-Benachrichtigungs-Zertifikats-erneuerungs-Dokumentation.
Der Erneuerungsweg ist genau:
- Erstellen Sie ein neues CSR: Erstellen Sie den Antrag über Ihren genehmigten Workflow und speichern Sie das damit verbundene Schlüsselmaterial.
- Verwenden Sie den ursprünglichen Apple-ID: Mit der gleichen Apple-ID anmelden, die zum Erstellen des bestehenden Zertifikats verwendet wurde.
- Wählen Sie das ablaufende Zertifikat: Passen Sie die App-ID, das Unternehmensname, die UID und die Ablaufdaten an, bevor Sie auswählen Erneuern.
- Hochladen des CSR: Senden Sie den neuen Antrag 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.p12Wenn Ihr Anbieter dies erfordert. - Deploy und testen: Die Server-Schlüssel aktualisieren, eine kontrollierte Benachrichtigung senden und die APNs-Antwort überprüfen.
Die Anbieterformate vergleichen
| Anforderung | Zertifikatsworkflow | Token-Workflow |
|---|---|---|
| Haupt-Schlüssel | Zertifikat plus privater Schlüssel | .p8 Authentifizierungschlüssel |
| Renewal-Beschwerde | Eine Ablaufdatum des Zertifikats erfordert wiederholte Ersetzung | Keine jährliche Zertifikatsersetzung |
| Bereitstellungsaufgabe | Installieren, pairing, exportieren und hochladen | Sicherheitschlüssel für die App-Store-Zertifizierung speichern und Token-Generierung konfigurieren |
| Hauptversagensrisiko | Falsches Zertifikat, fehlender privater Schlüssel, Ablaufdatum oder Rückruf | Authentifizierungschlüssel verloren, offengelegt oder zurückgezogen |
Auch Apples Zertifikats-Ökosystem erfordert geplante Vertrauensketten-Arbeit. Apple hat APNs-Server-Zertifikat-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 zu Ihrem Plattform-Checkliste.
Verwenden Sie ein gemeinsames Rennkalender, einen benannten Eigentümer und ein Bereitstellungs-Runbook. Die Capgo Zertifikatsverwaltungsdokumentation liegt neben diesem Runbook für Teams, die iOS-Lieferkredite mit ihrem mobilen Release-Prozess verwalten.
Troubleshooting und Verlust von Anmeldeinformationen
Ein schwieriger Vorfall ist nicht immer eine Ablaufdatum-Warnung. 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 Rennablauf 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:
- Ablaufdatum des Zertifikats: Generieren 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 Ersetzung sofort alle Geräte wiederherstellt.
- Zertifikat zurückgezogen: 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:
.p12Kennwort: Ein Zertifikat ohne das verwendbare Kennwort kann operativ nicht verfügbar 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 Computer und erstellen Sie ein Ersatzzertifikat.
- Verlorenen Zugriff auf Apple-ID: Bestätigen Sie, ob die Organisation das Konto über seine Identität und Bereitstellungsvorgänge wiederherstellen kann. Apple leitet die Unterstützung für APNs-Zertifikate, die über den relevanten Portal erstellt wurden, an Zuordnungsprogramme Unterstützung.
Die Wiederherstellung erfordert eine Identität, nicht nur einen Dateinamen. Beachten Sie 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 Verlängerung verwendet wird. Ihr CI/CD-System sollte Geheimnisse bei der Bereitstellung injizieren und eine Gesundheitsüberprüfung durchführen, die Authentifizierungsfehler vor der Meldung durch Benutzer erkennen lässt. .p8 Halten Sie das alte Konto während einer kontrollierten Ersetzung verfügbar, wenn dies durch die Plattform erlaubt ist, aber veraltete Geheimnisse nicht unendlich aktiv lassen. 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, speichern Sie die APNs-Antwortkörper und -Zeitstempel, 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, dann senden Sie eine kleine Verifizierungsbenachrichtigung an ein bekanntes Testgerät.
__CAPGO_KEEP_0__ kann iOS-Push-Zertifikate speichern und konfigurieren, als Teil einer __CAPGO_KEEP_1__-Benachrichtigungsworkflow, während Ihr Team die Verantwortung für den Zugriff auf die Apple-Konten, die Geheimniskasse und die Entscheidungen zur Verlängerung behält. Besuchen Sie __CAPGO_KEEP_0__
__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 Lieferungswerkzeuge neben Ihrem APNs-Zertifikatslebenszyklus und -Freigabeprozess passen können.
