# Certificado push da Apple: .p8 ou .p12 com Expo

> Para push, a Apple oferece uma chave .p8 que não expira e serve para todos os apps, ou um certificado .p12 anual. Com Expo, o EAS cuida da chave.

Página original: [Certificado push da Apple: .p8 ou .p12 com Expo](https://devoria.fr/pt-br/blog/certificado-push-apple-p8-p12-expo)
Autor: [Mehdi Azizi](https://devoria.fr/pt-br/mehdi-azizi)
Publicação: 2026-11-04
Última revisão do conteúdo: 2026-11-04


O certificado push da Apple autoriza um servidor a enviar notificações para o seu app pelo APNs, o serviço de notificações da Apple. Ele existe em duas formas: um certificado .p12, válido por um ano e ligado a um único app, ou uma chave .p8, que não expira e serve para todos os apps da sua conta. **Com Expo, você não precisa do certificado: o EAS oferece criar uma chave .p8 no primeiro build, e o serviço push da Expo usa essa chave por você.**

O guia sobre [o certificado de desenvolvedor e o provisioning profile](https://devoria.fr/pt-br/blog/certificado-ios-provisioning-profile-expo) fala da chave push em poucas linhas. Aqui eu vou até o fim: a escolha entre os dois formatos, os ambientes sandbox e produção, a renovação, e as falhas que cortam as notificações no TestFlight.

Eu publico meus apps com Expo e EAS. O Solys e o TradaZen declaram o plugin `expo-notifications` na configuração: é ele que prepara o app para receber notificações.

## Por que a Apple pede um certificado ou uma chave

Uma notificação push sai de um servidor, o seu ou o da Expo, que a entrega ao APNs, que a entrega ao iPhone. Então o APNs precisa verificar se esse servidor tem o direito de escrever para o seu app. A Apple oferece duas formas de provar isso.

- **A conexão por token, com uma chave .p8.** [Segundo a Apple](https://developer.apple.com/documentation/usernotifications/establishing-a-token-based-connection-to-apns), ela é mais rápida, pode ser usada a partir de vários servidores, e uma mesma chave cobre todos os apps da sua equipe ou parte deles. Seu servidor assina com ela um token, que precisa ser refeito pelo menos a cada hora.
- **A conexão por certificado, com um arquivo .p12.** [A Apple explica](https://developer.apple.com/documentation/usernotifications/establishing-a-certificate-based-connection-to-apns) que esse certificado é ligado a um único app e vale por um ano. Vários apps, vários certificados.

[A página da Apple sobre expirações](https://developer.apple.com/support/expiration/) lembra: a chave de assinatura dos tokens APNs nunca expira.

## A tabela .p8 / .p12

| Critério     | Chave .p8                    | Certificado .p12       |
| ------------ | ---------------------------- | ---------------------- |
| Duração      | Não expira                   | Um ano                 |
| Alcance      | Todos os seus apps           | Um único app           |
| Ambiente     | Escolhido na criação         | Sandbox e produção     |
| Renovação    | Nenhuma, salvo revogação     | Todo ano               |
| Download     | Uma única vez                | Exportado do Mac       |
| Quantidade   | Duas por ambiente            | Um por app             |
| Uso com Expo | Criada e gerenciada pelo EAS | Ausente da doc da Expo |

Três detalhes. O arquivo .p8 [só pode ser baixado uma vez](https://developer.apple.com/help/account/keys/create-a-private-key): a Apple não guarda o arquivo na sua conta. Já o .p12 [é exportado do Keychain do Mac](https://developer.apple.com/help/account/capabilities/communicate-with-apns-using-a-tls-certificate) que criou o certificado. E o limite de duas chaves por ambiente vale para as chaves de equipe. Para chaves limitadas a certos apps, a Apple permite até 200 por ambiente.

[A página da Expo sobre credenciais](https://docs.expo.dev/app-signing/app-credentials/) só fala da chave push, e conta no máximo duas por conta, sem distinguir ambientes nem chaves por app. **Para um app Expo, a chave .p8 é a escolha certa.**

## Sandbox e produção: dois ambientes

O APNs tem dois servidores: desenvolvimento, também chamado de sandbox, e produção. A [Apple](https://developer.apple.com/documentation/usernotifications/sending-notification-requests-to-apns) reserva o primeiro para testes e o segundo para apps publicados. O app sabe qual usar graças ao entitlement `aps-environment`. [Segundo a Apple](https://developer.apple.com/documentation/bundleresources/entitlements/aps-environment), o valor segue o perfil de assinatura: `development` com um perfil de desenvolvimento, `production` com um perfil de distribuição e para o TestFlight.

**Ou seja, um build do TestFlight fala com a produção, exatamente como a App Store.**

Do lado da Expo, dois detalhes. [A documentação do expo-notifications](https://docs.expo.dev/versions/latest/sdk/notifications/) diz que o entitlement é sempre escrito como `development` no projeto, e depois trocado para `production` no arquivo de um build de release. E, na criação, o token Expo fica vinculado ao ambiente do app, detectado automaticamente: você não precisa escolher nada no envio.

Se você mesmo criar a chave, a Apple pergunta o ambiente e o alcance: a equipe toda ou alguns apps. A documentação para desenvolvedores agora descreve chaves de equipe limitadas ao sandbox ou à produção, e as chaves antigas válidas em todo lugar continuam aceitas. Já [a ajuda da conta](https://developer.apple.com/help/account/capabilities/communicate-with-apns-using-authentication-tokens) ainda afirma que a chave serve para os dois ambientes. A Apple se contradiz: guarde o ambiente que você escolheu na criação. **Uma chave reservada ao sandbox não vai servir nem para o TestFlight nem para a App Store.**

## Como a Expo gerencia a chave push

Segundo [o guia de configuração da Expo](https://docs.expo.dev/push-notifications/push-notifications-setup/), atualizado em 28 de julho de 2026, seu primeiro build de desenvolvimento oferece configurar as notificações push e gerar uma chave APNs. Responda sim às duas. Sem EAS Build, rode `eas credentials`. Você precisa de uma conta Apple Developer paga.

Depois:

- **O EAS guarda a chave e associa ao seu app.** Segundo a Expo, uma chave serve para quantos apps você quiser, e enviar uma nova não muda os tokens Expo Push dos seus usuários.
- **Seu servidor não chama o APNs.** Ele envia para o serviço push da Expo, que repassa ao APNs. [A Expo pede que você leia os recibos](https://docs.expo.dev/push-notifications/sending-notifications/) cerca de 15 minutos depois do envio: é ali que os erros aparecem.
- **O plugin adiciona o entitlement.** Declare `expo-notifications` em `plugins`:

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

Duas armadilhas. [O FAQ da Expo](https://docs.expo.dev/push-notifications/faq/) diz que o Expo Go não suporta mais notificações push desde o SDK 53, enquanto a página do expo-notifications só fala do Android. Nos dois casos, a Expo recomenda um build de desenvolvimento: teste com ele. E apagar a chave com `eas credentials` remove a chave dos servidores da Expo, não da sua conta Apple. Para liberar uma vaga, revogue a chave no portal da Apple. Como qualquer segredo, o arquivo .p8 nunca deve parar no seu repositório: a regra é a mesma das [chaves de API de um app Expo](https://devoria.fr/pt-br/blog/chave-api-secreta-expo-o-que-proteger).

## Renovar: o que realmente expira

**A chave .p8 não tem nada para renovar.** Ela só para se você revogar. Se achar que ela foi comprometida, [a Apple recomenda](https://developer.apple.com/help/account/capabilities/communicate-with-apns-using-authentication-tokens) criar uma nova chave, migrar para ela e só depois revogar a antiga. Para trocar a chave com Expo, o FAQ dá o passo a passo: `eas credentials`, iOS, seu perfil de build, depois remover a chave push e gerar uma nova.

**O certificado .p12 expira todo ano.** A Apple pede que você atualize antes do vencimento e acompanhe a data no Keychain. Depois de expirado ou revogado, [você não consegue mais enviar notificações](https://developer.apple.com/help/account/certificates/certificates-overview) para o seu app. A Apple não descreve uma renovação à parte: você cria um novo certificado a partir do identificador do app, instala no seu servidor antes do vencimento e depois remove o antigo. **A melhor renovação ainda é migrar para a chave.**

> Você gerencia iPhones com Intune ou outra ferramenta de gestão de dispositivos? Não é o mesmo certificado. O certificado push de gestão de dispositivos é criado no Apple Push Certificates Portal e renovado todo ano. [A Apple recomenda](https://support.apple.com/guide/deployment/dep2de55389a) anotar a conta Apple usada: ela vai servir na renovação.

## As falhas típicas e como corrigir

### Funciona em desenvolvimento, não no TestFlight

1. **Você está enviando para o token errado.** O build do TestFlight se registra em produção e recebe um novo token. Um token vindo do seu build de desenvolvimento não funciona: a Apple responde `BadDeviceToken` quando [o token não corresponde ao ambiente](https://developer.apple.com/documentation/usernotifications/handling-notification-responses-from-apns). Pegue o token no próprio app do TestFlight.
2. **O app de produção não tem credenciais push.** Esse é o diagnóstico do FAQ da Expo. Confira a página de credenciais do projeto em expo.dev, ou `eas credentials`.
3. **Sua chave está limitada ao sandbox.** Troque por uma chave válida em produção.
4. **O iPhone não recebe token.** Se você instalou o build do TestFlight por cima de um build do Xcode, a Expo sugere reiniciar o aparelho.

### "No valid aps-environment entitlement string found"

Segundo o FAQ da Expo, esse erro indica que nenhuma chave push está configurada para o seu projeto iOS. Confira a página de credenciais e rode um novo build: o EAS vai oferecer gerar a chave. Confira também se `expo-notifications` está mesmo em `plugins`.

### ITMS-90078: Missing Push Notification Entitlement

A Apple manda esse e-mail depois do envio: seu app parece se registrar no APNs, mas a assinatura não contém o entitlement `aps-environment`. [A nota da Expo sobre o SDK 51](https://github.com/expo/fyi/blob/main/apns-entitlement-sdk-51.md) explica. Desde esse SDK, o entitlement só é adicionado se o `expo-notifications` estiver instalado. O aviso vem de duas checagens da Apple. A primeira compara as capabilities do identificador do app com os entitlements do app. A segunda detecta no binário um método de registro de notificações, que o código da Expo contém em todos os apps.

**É um aviso, não uma rejeição**, explica a Expo. Se você usa notificações, adicione o plugin e faça um novo build: [o EAS sincroniza as capabilities](https://docs.expo.dev/build-reference/ios-capabilities/) do identificador do app a cada build. Se não usa, remova a capability Push Notifications do seu identificador no portal da Apple. O aviso pode continuar aparecendo, sem consequência.

### InvalidCredentials ou todos os apps mudos de uma vez

`InvalidCredentials` em um recibo quer dizer que suas credenciais push não são mais válidas, muitas vezes porque a chave foi revogada. Todos os apps que usavam essa chave ficam mudos ao mesmo tempo. A correção da Expo: `eas credentials`, depois uma nova chave. Se o recibo mencionar `InvalidProviderToken`, a Expo recomenda fazer um novo build regenerando a chave push e o perfil.

## Antes de ativar as notificações

Para testar as notificações no seu iPhone antes do lançamento, siga [TestFlight para testar seu app](https://devoria.fr/pt-br/blog/testflight-como-testar-app-iphone-antes-envio). Se você envia notificações silenciosas para acordar o app, releia [a guideline 2.5.4 sobre modos em segundo plano](https://devoria.fr/pt-br/blog/guideline-2-5-4-modo-segundo-plano-recusado-apple). A cadeia inteira, sem Mac, está em [publicar um app iOS sem Mac](https://devoria.fr/pt-br/blog/publicar-app-ios-sem-mac-expo-eas), e as etapas do lançamento na página [publicar um aplicativo na App Store](https://devoria.fr/pt-br/expertise/publicar-app-na-app-store).

Antes do seu primeiro envio, faça o [diagnóstico gratuito](https://devoria.fr/pt-br/diagnostic): ele mostra o que está travando no seu projeto e te manda meu checklist anti-rejeição da Apple. Para construir o app, conectar as assinaturas e publicar, o [iOS & Android Kit](https://devoria.fr/pt-br/kits/ios) segue o caminho em quatro etapas com o código inicial dos meus apps, no seu ritmo.

## Perguntas frequentes

### O certificado push da Apple expira?

O certificado .p12 expira depois de um ano, e suas notificações param se ele não for substituído. A chave .p8 nunca expira: ela só para se você revogar. Esse é o principal motivo para preferir a chave.

### Preciso de um certificado push por app?

Com um certificado .p12, sim: cada certificado é ligado a um único app. Uma chave .p8 serve para todos os apps da sua conta. Então, com Expo, uma única chave pode cobrir todo o seu catálogo.

### Como renovar um certificado push da Apple?

Crie um novo certificado a partir do identificador do seu app, com uma nova solicitação de assinatura, instale no seu servidor e depois remova o antigo. Faça isso antes do vencimento. O mais simples ainda é migrar para uma chave .p8, que não precisa de renovação.

### Perdi meu arquivo .p8, o que fazer?

A Apple só permite baixar uma vez. Se o EAS criou a chave, a Expo guarda e suas notificações continuam. Se não, crie uma nova chave, adicione com `eas credentials` e depois revogue a antiga no portal da Apple. Os tokens Expo Push dos seus usuários não mudam.

### Preciso fazer um novo build depois de trocar a chave push?

Em geral, não. A chave serve ao servidor que envia, não ao app instalado, e a Expo diz que uma nova chave não muda os tokens. Exceção: se os recibos mostrarem `InvalidProviderToken`, a Expo recomenda fazer um novo build com uma nova chave e um novo perfil.


## Seu projeto

[Review Kit](https://devoria.fr/pt-br/kits/app-review): Meu checklist de revisão da App Store, as recusas da Apple que corrigi, o checklist do Google Play e três skills do Claude Code. R$ 289.

[iOS & Android Kit](https://devoria.fr/pt-br/kits/ios): Crie seu app para iPhone e Android com o Claude Code: o código inicial dos meus apps, o caminho até as lojas e todos os kits. R$ 589.

[Diagnóstico: o que te separa do seu app de iPhone](https://devoria.fr/pt-br/diagnostic): 7 perguntas, 60 segundos: descubra o que realmente te impede de publicar seu app de iPhone, seu caminho em 4 etapas e o kit certo para você.