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 ist plötzlich still. Ihr Anwendungs-Server kann noch Jobs akzeptieren, aber APNs kann 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
- Erstellung und Herunterladen Ihres APNs-Zertifikats
- Exportieren Sie das Zertifikat zur privaten Schlüssel
- Migrieren Sie zur neuen Token-basierten 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 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 fehlschlagen, bevor die Lieferung beginnt.
Apple stellt fest, dass APNs eine Liste von widerrufenen Zertifikaten hält 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: welche Dienstleistung versuchen Sie zu betreiben?
| 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, Endgeräte- oder Enterprise-Mobilitätsverwaltung |
Diese Zugangsdaten sind nicht austauschbar. Ein MDM-Plattform kann, wenn ihr MDM-Push-Zugriff abläuft, Kontakt mit registrierten Geräten verlieren, während ein Anwendungs-Backend Benachrichtigungen nicht liefern kann, weil sein App-Push-Zugriff ungültig ist. Die Behandlung beider als ein "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 Fähigkeit zum Push-Benachrichtigen, 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, behalten Sie diese 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 Sie die Benachrichtigungsanzeige ändern oder das App-Programm neu erstellen. Dann überprüfen Sie die App-Identifikator, die Zertifikatsidentität, die Umgebung und den Zertifikatsstatus. Ein Benachrichtigungsrechteproblem beeinträchtigt die Fähigkeit eines Benutzers, Benachrichtigungen zu sehen, aber es erklärt nicht eine TLS-Ablehnung von APNs.
Wenn die Fehlschlag nach einer Veröffentlichung erschien, vergleichen Sie die Signierung und die Berechtigungen in der neuen Version mit der vorherigen Version. Wenn er ohne eine App-Änderung erschien, überprüfen Sie die Zertifikatsablaufzeit, die Zertifikatsentziehung, die Änderungen im Trust-Store und die Bereitstellungsschlüssel zuerst. 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 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 den ausgewählten App-Id. Die CSR ist nicht der Server-Zugriff. Sie verbindet das ausgestellte Zertifikat mit einem lokalen privaten Schlüssel.Vorbereiten Sie den App-Id
Melden Sie sich bei der Apple-Entwickler-Portal-Website an und öffnen Sie
die App-Portal-Website 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 Anwendung identisch. 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 Zertifikat-Tooling. Halten Sie das Antragsdokument 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 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 Kredenzial 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-Kredenzialsystem. 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 demselben Runbook. Für die clientseitige Einrichtung siehe die CapacitorBenachrichtigungsintegrationshandbuch
. Behandeln Sie dieses Zertifikat als ein verwaltetes Kredenzial und nicht als eine einmalige Herunterladung, da die spätere Exportierung, Tokenmigration, Verlängerung und Wiederherstellung von der Kenntnis abhängen, wer den Schlüssel kontrolliert.
A heruntergeladene Apple-Zertifizierung ist nicht automatisch für einen Node.js-Dienst oder einen verwalteten Push-Anbieter bereit. Der Server benötigt das Zertifikat und dessen entsprechenden privaten Schlüssel, der häufig als ein PKCS#12 .p12 Datei.
Öffnen Keychain Access 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 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 legen Sie es nicht in einem Repository, Ticket, Chat-Nachricht oder Build-Log ab. 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 Anwendung in Produktion einsetzen, testen Sie die 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-Zertifizierung anfordert, laden Sie die .p12 und das 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 Exportwiederholung durchführen, den Datei schützen und die Bereitstellungsschlüssel bei der Erneuerung ersetzen. Teams, die mehrere Apps betreiben, können leicht den Überblick über die zugehörige Bundle verlieren.
Verwenden Sie sichere geheime Verwaltung in CI/CD-Pipelines um zu kontrollieren, wer die Zertifizierung lesen oder ersetzen kann. Halten Sie einen Audit-Trail für Uploads und Rotationen, aber loggen Sie niemals den privaten Schlüssel oder das .p12 Passwort.
Für neue Backend-Arbeiten bewerten Sie, ob die Zertifikatsauthentifizierung noch angemessen ist. Bestehende Integrationsanforderungen mögen .p12, aber die Tokenauthentifizierung entfernt normalerweise die jährliche Zertifikatserneuerung vom Anbieterverbindung. Das eliminiert die Zertifikatsgovernance nicht. Es ändert nur, was Sie schützen und rotieren.
Zum Migrieren auf die neue Tokenbasierte Authentifizierung
Apple hat die APNs-Authentifizierung in Richtung Anbieter-Token, 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 Signierungsschlüssel.
Erledigen 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, validieren Sie 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 Sendepfad, aber Ihr Team benötigt trotzdem 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 weiterhin korrekte Benachrichtigungsregistrierung und Berechtigungen. Die Migration ändert hauptsächlich die Server-zu-APNs-Authentifizierung, nicht die Geräte-Token-Registrierung code. Ihr Backend muss weiterhin Token mit der richtigen Anwendung und Umgebung associieren.
Wissen Sie, wann Zertifikate weiterhin notwendig sind
Einige Unternehmenstools und etablierte Integrationsmodule offenbaren noch immer zertifikatbasierte 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-Zertifikate während der Übergangsphase geschützt, schaffen Sie jedoch keine neuen Abhängigkeiten davon, wenn Token-Authentifizierung geeignet ist.
Wenn Sie das umgebende Anwendungsfluss verstehen müssen, überprüfen Sie Ionic und Capacitor Pushbenachrichtigungen mit Firebase. Firebase kann eine Anwendungslieferungsschicht bereitstellen, aber Apple-Zertifikate, Berechtigungen, Registrierung und APNs-Antworten erfordern eine bewusste Konfiguration.
Zertifikate für die Erneuerung und Verwaltung von Lebenszyklen
Eine APNs-Zertifizierung zu behandeln, als verfügbare Produktionsabhängigkeit, die von dem Tag an abläuft, an dem Sie es erstellen, ist eine gute Idee. 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, 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 Erneuerungsprozess 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-Konto: Melden Sie 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 des CSR: Senden Sie den neuen Antrag im Apple Push Certificates Portal.
- Herunterladen und erneut installieren: Das erneuerte Zertifikat herunterladen
.pem, es dort installieren, wo der private Schlüssel verfügbar ist, und einen Ersatz exportieren.p12Wenn Ihr Anbieter dies erfordert. - Deploy und testen: Die Server-Secrets aktualisieren, einen kontrollierten Benachrichtigung senden und die APNs-Antwort überprüfen.
Die Anbieterformate vergleichen
| Anforderung | Zertifikatsworkflow | Token-Workflow |
|---|---|---|
| Haupt-Secret | Zertifikat plus privater Schlüssel | .p8 Authentifizierungschlüssel |
| Renewal-Beschwerde | Eine Ablaufdatum des Zertifikats erfordert einen wiederkehrenden Austausch | Keine jährliche Zertifikatsersetzung |
| Bereitstellungsaufwand | Installieren, pairing, exportieren und hochladen | Sicherheitschlüssel für die Signierung 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 Vertrauenskettenerneuerungen. Apple hat APNs-Serverzertifikat-Updates für Sandbox am 20. Januar 2025 und in der Produktion 24. Februar 2025, wodurch die Trust-Stores das Zertifikat "SHA-2 Root USERTrust RSA Certification Authority" enthalten müssen. Lesen Sie die Apple APNs Server-Zertifikatsankündigung und machen Sie die Eigentümerschaft des Trust-Stores zu Ihrem Plattform-Checkliste. Verwenden Sie ein gemeinsames Erneuerungsdatum, einen benannten Eigentümer und ein Bereitstellungs-Runbook. Die __CAPGO_KEEP_0__ Zertifikatsverwaltungsdokumentation
kann neben diesem Runbook für Teams, die iOS-Lieferkredenziale mit ihrem mobilen Release-Prozess verwalten, stehen. Capgo certificate management documentation 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 Reinigungsprozesses zurückgezogen. Die standardmäßige Erneuerungsablauf 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.
Troubleshooting und Verlust von Anmeldeinformationen
Die schwierigen Vorfälle sind nicht immer Ablaufdatum-Warnungen. 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 Reinigungsprozesses zurückgezogen. Der Standard-Erneuerungsablauf 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: 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 Kommunikation mit dem Gerät 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 Zertifikate verwenden, die zurückgezogen wurden, 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: Ein Zertifikat ohne das verwendbare Passwort 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 Rechner 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. Bevor ein Vorfall eintritt, müssen Sie den Apple-ID-Besitzer, die App-ID, die Zertifikatsidentität, die private-Schlüssellage, die Anbieterkonfiguration und die Ersetzungsanweisung aufzeichnen.
Ein Betriebssicherheitsnetz aufbauen
Zertifikate und .p8 Schlüssel in einem gemeinsamen, Zugriffskontrollierten Safe speichern. Speichern Sie das .p12 Passwort getrennt vom Datei, beschränken Sie den Zugriff auf die Produktion und dokumentieren Sie den genauen Portalaccount, der für die Erneuerung verwendet wird. Ihr CI/CD-System sollte Geheimnisse bei der Bereitstellung injizieren und eine Gesundheitsüberprüfung durchführen, die Authentifizierungsfehler vorher erkennt, bevor Benutzer fehlende Warnungen melden.
Halten Sie das alte Konto während einer kontrollierten Ersetzung verfügbar, wenn die Plattform dies erlaubt, aber verlassen Sie keine veralteten Geheimnisse aktiv. 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.
Wenn ein Ausfall bereits eingetreten 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 kann iOS-Push-Zertifikate speichern und konfigurieren, als Teil eines Capacitor-Benachrichtigungsworkflows, während Ihr Team die Verantwortung für den Zugriff auf die Apple-Konten, die Geheimniskasse und die Erneuerungsentscheidungen behält. Besuchen Sie Capgo um zu überprüfen, wie Ihre mobile Lieferungswerkzeuge neben Ihrem APNs-Zertifikatslebenszyklus und -Veröffentlichungsprozess passen können.
