Quem renova o certificado SSL do seu PWA?

O roteiro é sempre o mesmo. O site funcionava ontem. Ninguém mexeu em nada — nem no conteúdo, nem nas configurações, nem no código. E hoje de manhã cada visitante cai em um aviso de tela cheia, com um botão para voltar que a maioria se apressa em clicar. Nada está quebrado, a rigor: está tudo lá, intacto. Uma data passou, só isso.

Seu app também tem uma face web: seu PWA — a versão do seu app que abre no navegador, no seu endereço, no seu domínio. Esse endereço é protegido pelo mesmo mecanismo que o resto da web: um certificado. A pergunta deste artigo cabe, então, em uma linha: esse certificado tem data de fim; quem cuida da próxima?

Um certificado SSL — o nome vem dos primórdios da web; o protocolo foi substituído há tempos pelo seu sucessor, o TLS, mas o "SSL" ficou — faz duas coisas: prova que o endereço que o seu usuário visita é realmente o seu, e criptografa as trocas. É ele, o cadeado na barra de endereço.

E ele expira. Não é defeito nem negligência: é o modelo de segurança. Um certificado roubado ou comprometido é perigoso enquanto for válido — quanto mais curta a vida, mais estreita a janela. O Let's Encrypt, a autoridade que protege boa parte da web, emite certificados de 90 dias, de propósito.

E o movimento acelera. Em 2025, a indústria — navegadores e autoridades certificadoras reunidos no CA/Browser Forum — aprovou uma redução em etapas da vida máxima dos certificados públicos: 398 dias hoje, 200 em 2026, 100 em 2027, 47 dias a partir de março de 2029. Nesse horizonte, um certificado se renova cerca de oito vezes por ano. A web não apenas aceitou que os certificados expiram: decidiu que eles expirariam cada vez mais.

Uma data só é perigosa se ninguém mantém o calendário. A indústria acabou de multiplicar as datas.

Imagine manter você mesmo o seu app e a infraestrutura dele. Esse calendário seria seu. Obter o certificado, instalá-lo, provar a cada renovação que o domínio é realmente seu, recomeçar antes de cada vencimento. Montar uma automação, claro — e depois vigiar a própria automação, porque esse é o grande clássico do gênero: o script de renovação que parou de rodar há meses, descoberto na manhã em que o certificado expira. Os avisos, enquanto isso, vão para um endereço de e-mail consultado uma vez por ano.

Com vidas de 90 dias, esse trabalho já é um plantão. Com 47, muda de natureza: a renovação manual deixa de ser uma opção, mesmo ruim. Manter esse calendário vira um ofício — ou algo que se confia a alguém cujo ofício é esse.

Quando você conecta o seu nome de domínio, o certificado desse domínio é provisionado automaticamente — não há nada para comprar, nada para instalar. A data de expiração passa a ser acompanhada como um estado do sistema, e o certificado é renovado antes do vencimento: o incidente não é consertado rápido, é antecipado. Essa é toda a diferença entre reagir a uma pane e fazer com que ela nunca aconteça.

É também por isso que essa família de incidentes se presta tão bem a ser assumida: é a pane mais previsível do mundo. Tudo tem data, tudo se sabe de antemão. Só é preciso que alguém faça disso o seu trabalho — todos os dias, para todos os apps ao mesmo tempo, inclusive quando os vencimentos começarem a se aproximar.

O mapa completo de quem cuida do quê está no primeiro artigo; em matéria de vencimentos, ele é curto.

Seu nome de domínio. Ele está registrado no seu registrador, no seu nome — é isso que faz com que ele seja seu — e se renova. Um domínio expirado leva junto tudo o que vive nele, por mais saudável que esteja o resto. Essa renovação só pode vir de você.

Suas contas de desenvolvedor Apple e Google. Mesma lógica, mesma conclusão — estão no seu nome, e as datas delas são suas. A regra vale para toda esta série: o que é comum a todos os apps vive do lado da plataforma; o que está registrado no seu nome vive com você.

O benefício, como costuma acontecer nesta série, é invisível: o cadeado está na barra de endereço hoje de manhã, como ontem, como na próxima renovação — e não há mais nada para contar. Enquanto as vidas dos certificados encurtam, a única coisa que muda para você é: nada.

Para a versão de engenharia do que expira e se degrada em três anos, o detalhe está no dev.to. E se o seu app ainda não existe, melhor construí-lo onde o calendário é mantido para você: criar meu app com a GoodBarber.

É preciso comprar um certificado SSL para o seu PWA?

Com a GoodBarber, não: quando você conecta o seu nome de domínio, um certificado é provisionado automaticamente e depois renovado antes de cada vencimento. Se você mantém a própria infraestrutura, obter, instalar e renovar — todas as vezes — fica por sua conta.

O que acontece quando um certificado SSL expira?

Os navegadores mostram um aviso de tela cheia — "Sua conexão não é particular" — e a maioria dos visitantes dá meia-volta. Nada está quebrado: o site e o conteúdo estão intactos; uma data simplesmente passou. Voltar ao ar significa renovar o certificado; em uma plataforma que mantém o calendário, essa renovação vem antes da data.

Por que os certificados SSL expiram cada vez mais rápido?

Porque é mais seguro: um certificado comprometido é perigoso enquanto for válido, e uma vida curta estreita essa janela. Em 2025, a indústria aprovou uma redução em etapas, dos 398 dias de hoje para 47 dias em 2029. A consequência prática: a renovação manual se torna insustentável, e automatizar o calendário deixa de ser um conforto para se tornar a única abordagem viável.

Meu app nativo é afetado?

A tela "Sua conexão não é particular" é uma história de navegador: ela diz respeito ao seu PWA e às páginas web ligadas ao seu app. Seu app nativo, instalado pelas lojas, não vai exibi-la — mas ele também se comunica por conexões criptografadas, e uma parte das chamadas dele se apoia no mesmo certificado do seu PWA. O calendário de que fala este artigo, portanto, também o cobre.