# Apple Push-Zertifikat: .p8 oder .p12 mit Expo > Apple bietet für Push einen .p8-Schlüssel ohne Ablauf für alle Apps oder ein jährliches .p12-Zertifikat. Mit Expo verwaltet EAS den Schlüssel. Originalseite: [Apple Push-Zertifikat: .p8 oder .p12 mit Expo](https://devoria.fr/de/blog/apple-push-zertifikat-p8-p12-expo) Autor: [Mehdi Azizi](https://devoria.fr/de/mehdi-azizi) Veröffentlicht: 2026-11-04 Letzte inhaltliche Überarbeitung: 2026-11-04 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](https://devoria.fr/de/blog/ios-zertifikat-provisioning-profile-expo) 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](https://developer.apple.com/documentation/usernotifications/establishing-a-token-based-connection-to-apns) 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](https://developer.apple.com/documentation/usernotifications/establishing-a-certificate-based-connection-to-apns), dass dieses Zertifikat an eine einzige App gebunden ist und ein Jahr gilt. Mehrere Apps, mehrere Zertifikate. [Apples Seite zu Abläufen](https://developer.apple.com/support/expiration/) 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](https://developer.apple.com/help/account/keys/create-a-private-key): Apple speichert sie nicht in deinem Account. Das .p12 dagegen [wird aus dem Schlüsselbund des Macs exportiert](https://developer.apple.com/help/account/capabilities/communicate-with-apns-using-a-tls-certificate), 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](https://docs.expo.dev/app-signing/app-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](https://developer.apple.com/documentation/usernotifications/sending-notification-requests-to-apns) 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](https://developer.apple.com/documentation/bundleresources/entitlements/aps-environment) 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](https://docs.expo.dev/versions/latest/sdk/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](https://developer.apple.com/help/account/capabilities/communicate-with-apns-using-authentication-tokens) 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](https://docs.expo.dev/push-notifications/push-notifications-setup/), 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](https://docs.expo.dev/push-notifications/sending-notifications/), etwa 15 Minuten nach dem Senden: Dort tauchen die Fehler auf. - **Das Plugin setzt das Entitlement.** Trag `expo-notifications` unter `plugins` ein: ```json { "expo": { "plugins": ["expo-notifications"] } } ``` Zwei Fallen. [Expos FAQ](https://docs.expo.dev/push-notifications/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](https://devoria.fr/de/blog/geheimer-api-schluessel-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](https://developer.apple.com/help/account/capabilities/communicate-with-apns-using-authentication-tokens), 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](https://developer.apple.com/help/account/certificates/certificates-overview) 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](https://support.apple.com/guide/deployment/dep2de55389a), 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](https://developer.apple.com/documentation/usernotifications/handling-notification-responses-from-apns). 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](https://github.com/expo/fyi/blob/main/apns-entitlement-sdk-51.md) 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](https://docs.expo.dev/build-reference/ios-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](https://devoria.fr/de/blog/testflight-iphone-app-testen). Wenn du stille Benachrichtigungen sendest, um die App aufzuwecken, lies noch einmal [Guideline 2.5.4 zu Hintergrundmodi](https://devoria.fr/de/blog/guideline-2-5-4-hintergrundmodus-apple-ablehnung). Die ganze Kette ohne Mac findest du in [iOS-App ohne Mac veröffentlichen](https://devoria.fr/de/blog/ios-app-ohne-mac-veroeffentlichen-expo-eas), und die Schritte zum Release auf der Seite [eine App im App Store veröffentlichen](https://devoria.fr/de/expertise/app-im-app-store-veroeffentlichen). Mach vor deinem ersten Versand die [kostenlose Diagnose](https://devoria.fr/de/diagnostic): 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](https://devoria.fr/de/kits/ios) 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. ## Dein Projekt [Review Kit](https://devoria.fr/de/kits/app-review): Meine Checkliste für die App Store Review, meine von Apple abgelehnten und korrigierten Fälle, die für Google Play und drei Claude Code Skills. 49 €. [iOS & Android Kit](https://devoria.fr/de/kits/ios): Bau deine iPhone- und Android-App mit Claude Code: der Startcode meiner Apps, der Weg bis in die Stores und alle Kits. 99 €. [Diagnose: Was dich von deiner iPhone-App trennt](https://devoria.fr/de/diagnostic): 7 Fragen, 60 Sekunden: Du erfährst, was dich wirklich davon abhält, deine iPhone-App zu veröffentlichen, bekommst deinen Weg in 4 Schritten und das passende Kit.