Apple Push-Zertifikat: .p8 oder .p12 mit Expo

Das Push-Zertifikat von Apple erlaubt einem Server, über APNs, den Benachrichtigungsdienst von Apple, Benachrichtigungen an deine App zu schicken. Es gibt zwei Formen: ein .p12-Zertifikat, das ein Jahr gilt und an eine einzige App gebunden ist, oder einen .p8-Schlüssel, der nicht abläuft und für alle Apps deines Accounts funktioniert. Mit Expo brauchst du das Zertifikat nicht: EAS bietet dir beim ersten Build an, einen .p8-Schlüssel zu erstellen, und der Push-Dienst von Expo nutzt ihn für dich.

Der Guide zu Entwicklerzertifikat und Provisioning Profile erwähnt den Push-Schlüssel nur in ein paar Zeilen. Hier gehen wir in die Tiefe: die Wahl zwischen den beiden Formaten, die Umgebungen Sandbox und Production, die Erneuerung und die Fehler, die Benachrichtigungen in TestFlight lahmlegen.

Ich veröffentliche meine Apps mit Expo und EAS. Solys und TradaZen deklarieren das Plugin expo-notifications in ihrer Konfiguration: Es bereitet die App darauf vor, Benachrichtigungen zu empfangen.

Warum Apple ein Zertifikat oder einen Schlüssel verlangt

Eine Push-Benachrichtigung startet auf einem Server, deinem oder dem von Expo. Der übergibt sie an APNs, und APNs liefert sie ans iPhone. APNs muss also prüfen, ob dieser Server deiner App schreiben darf. Apple bietet zwei Wege, das nachzuweisen.

• Die tokenbasierte Verbindung mit einem .p8-Schlüssel. Laut Apple ist sie schneller, von mehreren Servern aus nutzbar, und ein einziger Schlüssel deckt alle Apps deines Teams oder einen Teil davon ab. Dein Server signiert damit ein Token, das mindestens jede Stunde neu erstellt werden muss.
• Die zertifikatsbasierte Verbindung mit einer .p12-Datei. Apple stellt klar, dass dieses Zertifikat an eine einzige App gebunden ist und ein Jahr gilt. Mehrere Apps, mehrere Zertifikate.

Apples Seite zu Abläufen erinnert daran: Der Signaturschlüssel für APNs-Tokens läuft nie ab.

Die Tabelle .p8 / .p12

Kriterium	.p8-Schlüssel	.p12-Zertifikat
Laufzeit	Kein Ablauf	Ein Jahr
Reichweite	Alle deine Apps	Eine einzige App
Umgebung	Bei Erstellung gewählt	Sandbox und Production
Erneuerung	Keine, außer bei Widerruf	Jedes Jahr
Download	Nur einmal	Export vom Mac
Anzahl	Zwei pro Umgebung	Eins pro App
Nutzung mit Expo	Von EAS erstellt und verwaltet	Fehlt in der Expo-Doku

Drei Hinweise. Die .p8-Datei lässt sich nur einmal herunterladen: Apple speichert sie nicht in deinem Account. Das .p12 dagegen wird aus dem Schlüsselbund des Macs exportiert, der das Zertifikat erstellt hat. Und die Grenze von zwei Schlüsseln pro Umgebung gilt für Team-Schlüssel. Für Schlüssel, die auf bestimmte Apps beschränkt sind, erlaubt Apple bis zu 200 pro Umgebung.

Expos Seite zu den Credentials spricht nur vom Push-Schlüssel und nennt maximal zwei pro Account, ohne zwischen Umgebungen oder App-Schlüsseln zu unterscheiden. Für eine Expo-App ist der .p8-Schlüssel die richtige Wahl.

Sandbox und Production: zwei Umgebungen

APNs hat zwei Server: Development, auch Sandbox genannt, und Production. Apple reserviert den ersten für Tests und den zweiten für veröffentlichte Apps. Welchen die App nutzt, weiß sie über das Entitlement aps-environment. Laut Apple richtet sich sein Wert nach dem Signaturprofil: development mit einem Development-Profil, production mit einem Distribution-Profil und für TestFlight.

Ein TestFlight-Build spricht also mit Production, genau wie der App Store.

Bei Expo gibt es zwei Details. Die Doku von expo-notifications sagt, dass das Entitlement im Projekt immer als development geschrieben und im Archiv eines Release-Builds auf production umgestellt wird. Und beim Erstellen wird das Expo-Token automatisch der erkannten Umgebung der App zugeordnet: Beim Senden musst du nichts auswählen.

Wenn du den Schlüssel selbst erstellst, fragt Apple nach Umgebung und Reichweite: das ganze Team oder bestimmte Apps. Die Entwicklerdoku beschreibt inzwischen Team-Schlüssel, die auf Sandbox oder Production beschränkt sind, wobei ältere, überall gültige Schlüssel weiter akzeptiert werden. Die Account-Hilfe behauptet dagegen noch, der Schlüssel gelte für beide Umgebungen. Apple widerspricht sich selbst: Merk dir die Umgebung, die du beim Erstellen wählst. Ein reiner Sandbox-Schlüssel funktioniert weder mit TestFlight noch mit dem App Store.

Wie Expo den Push-Schlüssel verwaltet

Laut Expos Setup-Guide, aktualisiert am 28. Juli 2026, bietet dir dein erster Development-Build an, Push-Benachrichtigungen einzurichten und einen APNs-Schlüssel zu generieren. Antworte beide Male mit Ja. Ohne EAS Build startest du eas credentials. Du brauchst einen bezahlten Apple-Developer-Account.

Danach:

• EAS speichert den Schlüssel und verknüpft ihn mit deiner App. Laut Expo funktioniert ein Schlüssel für beliebig viele Apps, und das Hochladen eines neuen ändert die Expo-Push-Tokens deiner Nutzer nicht.
• Dein Server ruft APNs nicht auf. Er sendet an den Push-Dienst von Expo, der an APNs weiterleitet. Expo bittet dich, die Receipts zu lesen, etwa 15 Minuten nach dem Senden: Dort tauchen die Fehler auf.
• Das Plugin setzt das Entitlement. Trag expo-notifications unter plugins ein:

{
  "expo": {
    "plugins": ["expo-notifications"]
  }
}

Zwei Fallen. Expos FAQ sagt, dass Expo Go seit SDK 53 keine Push-Benachrichtigungen mehr unterstützt, während die Seite von expo-notifications nur Android nennt. In beiden Fällen empfiehlt Expo einen Development-Build: Teste damit. Und wenn du den Schlüssel mit eas credentials löschst, verschwindet er von den Expo-Servern, nicht aus deinem Apple-Account. Um einen Platz freizumachen, widerrufst du ihn im Apple-Portal. Wie jedes Geheimnis darf die .p8-Datei nie in deinem Repository landen: Es gilt dieselbe Regel wie für API-Schlüssel einer Expo-App.

Erneuern: was wirklich abläuft

Beim .p8-Schlüssel gibt es nichts zu erneuern. Er hört nur auf zu funktionieren, wenn du ihn widerrufst. Wenn du glaubst, dass er kompromittiert ist, empfiehlt Apple, einen neuen Schlüssel zu erstellen, darauf umzustellen und erst dann den alten zu widerrufen. Zum Ersetzen mit Expo nennt die FAQ den Ablauf: eas credentials, iOS, dein Build-Profil, dann den Push-Schlüssel entfernen und einen neuen generieren.

Das .p12-Zertifikat läuft jedes Jahr ab. Apple verlangt, es vor dem Ablauf zu aktualisieren und das Datum im Schlüsselbund im Blick zu behalten. Ist es abgelaufen oder widerrufen, kannst du keine Benachrichtigungen mehr an deine App senden. Eine eigene Erneuerung beschreibt Apple nicht: Du erstellst ein neues Zertifikat über die App-ID, installierst es vor dem Ablauf auf deinem Server und entfernst dann das alte. Die beste Erneuerung ist immer noch der Wechsel zum Schlüssel.

Du verwaltest iPhones mit Intune oder einem anderen Gerätemanagement-Tool? Das ist nicht dasselbe Zertifikat. Das Push-Zertifikat für die Geräteverwaltung wird im Apple Push Certificates Portal erstellt und jedes Jahr erneuert. Apple empfiehlt, dir den verwendeten Apple-Account zu notieren: Du brauchst ihn für die Erneuerung.

Typische Fehler und ihre Lösung

Funktioniert in Development, nicht in TestFlight

1. Du sendest an das falsche Token. Der TestFlight-Build registriert sich in Production und bekommt ein neues Token. Ein Token aus deinem Development-Build funktioniert nicht: Apple antwortet mit BadDeviceToken, wenn das Token nicht zur Umgebung passt. Hol dir das Token direkt aus der TestFlight-App.
2. Die Production-App hat keine Push-Credentials. Das ist die Diagnose aus Expos FAQ. Prüf die Credentials-Seite des Projekts auf expo.dev oder eas credentials.
3. Dein Schlüssel ist auf die Sandbox beschränkt. Ersetze ihn durch einen Schlüssel, der in Production gilt.
4. Das iPhone bekommt kein Token. Wenn du den TestFlight-Build über einen Xcode-Build installiert hast, empfiehlt Expo, das Gerät neu zu starten.

„No valid aps-environment entitlement string found“

Laut Expos FAQ bedeutet dieser Fehler, dass für dein iOS-Projekt kein Push-Schlüssel eingerichtet ist. Prüf die Credentials-Seite und starte dann einen neuen Build: EAS bietet dir dann an, den Schlüssel zu generieren. Prüf auch, ob expo-notifications wirklich unter plugins steht.

ITMS-90078: Missing Push Notification Entitlement

Apple schickt diese E-Mail nach dem Hochladen: Deine App scheint sich bei APNs zu registrieren, aber ihre Signatur enthält das Entitlement aps-environment nicht. Expos Hinweis zu SDK 51 erklärt das. Seit diesem SDK wird das Entitlement nur hinzugefügt, wenn expo-notifications installiert ist. Die Warnung stammt aus zwei Prüfungen von Apple. Die erste vergleicht die Capabilities deiner App-ID mit den Entitlements der App. Die zweite findet im Binary eine Methode zur Registrierung für Benachrichtigungen, die der Expo-Code in allen Apps enthält.

Das ist eine Warnung, keine Ablehnung, stellt Expo klar. Wenn du Benachrichtigungen nutzt, füg das Plugin hinzu und mach einen neuen Build: EAS synchronisiert die Capabilities der App-ID bei jedem Build. Andernfalls entferne die Capability Push Notifications von deiner App-ID im Apple-Portal. Die Warnung kann bestehen bleiben, ohne Folgen.

InvalidCredentials oder alle Apps auf einmal stumm

InvalidCredentials in einem Receipt heißt, dass deine Push-Credentials nicht mehr gültig sind, oft weil der Schlüssel widerrufen wurde. Alle Apps, die ihn genutzt haben, verstummen gleichzeitig. Expos Lösung: eas credentials, dann ein neuer Schlüssel. Steht im Receipt InvalidProviderToken, empfiehlt Expo einen neuen Build, bei dem Push-Schlüssel und Profil neu generiert werden.

Bevor du Benachrichtigungen aktivierst

Um Benachrichtigungen vor dem Release auf deinem iPhone zu testen, folge TestFlight zum Testen deiner App. Wenn du stille Benachrichtigungen sendest, um die App aufzuwecken, lies noch einmal Guideline 2.5.4 zu Hintergrundmodi. Die ganze Kette ohne Mac findest du in iOS-App ohne Mac veröffentlichen, und die Schritte zum Release auf der Seite eine App im App Store veröffentlichen.

Mach vor deinem ersten Versand die kostenlose Diagnose: Sie zeigt dir, was in deinem Projekt hakt, und schickt dir meine Checkliste gegen Apple-Ablehnungen. Um die App zu bauen, Abos einzubinden und sie zu veröffentlichen, begleitet dich das iOS & Android Kit in vier Schritten mit dem Startcode meiner Apps, in deinem eigenen Tempo.

Häufige Fragen

Läuft das Apple Push-Zertifikat ab?

Das .p12-Zertifikat läuft nach einem Jahr ab, und deine Benachrichtigungen stoppen, wenn es nicht ersetzt wird. Der .p8-Schlüssel läuft nie ab: Er hört nur auf zu funktionieren, wenn du ihn widerrufst. Das ist der Hauptgrund, den Schlüssel zu bevorzugen.

Brauche ich ein Push-Zertifikat pro App?

Mit einem .p12-Zertifikat ja: Jedes Zertifikat ist an eine einzige App gebunden. Ein .p8-Schlüssel funktioniert für alle Apps deines Accounts. Mit Expo kann ein einziger Schlüssel also deinen ganzen Katalog abdecken.

Wie erneuere ich ein Apple Push-Zertifikat?

Erstelle über die ID deiner App ein neues Zertifikat mit einer neuen Signieranforderung, installiere es auf deinem Server und entferne dann das alte. Mach das vor dem Ablauf. Am einfachsten ist der Wechsel zu einem .p8-Schlüssel, der nicht erneuert werden muss.

Ich habe meine .p8-Datei verloren, was tun?

Apple erlaubt den Download nur einmal. Wenn EAS den Schlüssel erstellt hat, bewahrt Expo ihn auf und deine Benachrichtigungen laufen weiter. Andernfalls erstellst du einen neuen Schlüssel, fügst ihn mit eas credentials hinzu und widerrufst den alten im Apple-Portal. Die Expo-Push-Tokens deiner Nutzer ändern sich nicht.

Muss ich nach einem Wechsel des Push-Schlüssels neu builden?

In der Regel nicht. Der Schlüssel dient dem sendenden Server, nicht der installierten App, und Expo sagt, dass ein neuer Schlüssel die Tokens nicht ändert. Ausnahme: Wenn die Receipts InvalidProviderToken melden, empfiehlt Expo einen neuen Build mit neuem Schlüssel und neuem Profil.