Certificado não confiável: três causas além do vencimento

Ontem o seu aplicativo carregava sem problema. Hoje alguém manda um print de um aviso do navegador em tela cheia, dizendo que a conexão não é particular, e pergunta se o seu site foi invadido. Você abre o certificado e ele vale até a próxima primavera. Não venceu, e mesmo assim o navegador diz que o certificado não é confiável.

O caminho óbvio é renovar, e para essa tela ele é o errado. Cada uma das três causas abaixo acontece com um certificado que já está dentro da validade, então uma renovação dá a você uma data de vencimento mais distante num certificado que continua recusado por outro motivo.

No nosso post sobre vencimento, o certificado é o alvará na vitrine dizendo que esta loja é mesmo a da placa. O navegador de um visitante lê três coisas nesse alvará antes de deixar alguém entrar: a data, o nome da loja para a qual ele foi emitido e a assinatura de quem o emitiu. O vencimento é a data. Este artigo trata das outras duas.

Certificado não confiável sem ter vencido: por quê?

Porque o nome ou a assinatura falhou, e o navegador ergue o mesmo muro para cada uma das verificações dele.

Um certificado só é confiável se cita exatamente o endereço que está na barra do visitante e foi assinado por uma autoridade em que o navegador já confia, com cada certificado intermediário enviado junto. Se qualquer um dos dois falha, o Chrome mostra o aviso de que a conexão não é particular e o Firefox o de um possível risco de segurança, exatamente como num vencido.

O que muda são as letras miúdas embaixo do aviso. Leia antes de mexer em qualquer coisa:

O Chrome mostra o mesmo código para a segunda e a terceira linha, e é por isso que vale a pena abrir o próprio certificado.

Se só uma pessoa avisou e mais ninguém vê o problema, pergunte em que rede ela estava. O código-fonte do Chrome cita uma rede wifi que manda os usuários para uma página de login como uma das causas do erro de nome. Essa some assim que a pessoa entra na rede.

Como vejo o que o certificado diz?

Abra o certificado a partir do aviso e leia dois campos: para quem ele foi emitido e quem o emitiu.

No Chrome, clique na indicação de alerta à esquerda da barra de endereço (Not secure num Chrome em inglês) e abra o certificado pelo painel que aparece. No Firefox, clique em Advanced no aviso e depois no link para o certificado do site (são esses os nomes num Firefox em inglês). Os dois navegadores chamam os mesmos campos de jeitos diferentes:

• O campo que diz para quem o certificado foi emitido (Issued To num Chrome em inglês, Subject Name no Firefox) traz o nome para o qual ele foi feito. A lista completa de nomes que ele cobre fica em Subject Alternative Name, e é essa lista que o navegador compara com o endereço.
• O campo que diz quem o emitiu (Issued By no Chrome, Issuer Name no Firefox) traz a autoridade que o assinou.

Cada uma das três causas aparece de um jeito ali:

• O certificado cita outro endereço. É a causa 1.
• Titular e emissor têm o mesmo nome. Ele assinou a si mesmo: é a causa 2.
• Ele cita o seu endereço, o emissor é uma autoridade de que você já ouviu falar, e o navegador recusa assim mesmo. É a causa 3, a cadeia.

Causa 1: o certificado é de outro endereço

O certificado é autêntico e está na validade, e foi emitido para outro nome. É o alvará de outra loja, pendurado na sua vitrine.

Ele aparece de três formas:

• Seu domínio aponta para uma hospedagem que ainda não tem certificado para ele. A hospedagem responde com o certificado que tem, emitido para um nome dela. A documentação da Lovable diz isso com todas as letras: até o certificado ficar pronto, o navegador mostra um aviso de segurança no lugar do seu site.
• O certificado cobre uma grafia do seu endereço e o visitante digitou a outra. www.yourapp.com e yourapp.com são dois nomes para um certificado, e cada um precisa estar na lista dele.
• Uma parte do seu DNS ainda aponta para um lugar que você deixou. Uma hospedagem antiga, ou a página de estacionamento que o seu registrador mostrava antes de você conectar qualquer coisa, responde nesse nome com um certificado próprio.

Na Lovable e na Vercel, você não compra nem instala esse certificado. A hospedagem emite um para cada nome que você adiciona nas configurações de domínio dela, depois que o seu DNS aponta esse nome para ela. A documentação da Lovable acrescenta que a hospedagem dela não usa de forma alguma um certificado comprado no seu registrador. Adicione as duas grafias, aponte as duas para a hospedagem e espere cada uma aparecer como ativa.

Causa 2: o certificado assinou a si mesmo

Ninguém responde por esse certificado além do servidor que o apresenta. É um alvará que o lojista imprimiu em casa.

Todo navegador recusa um desses num site público, e é para recusar mesmo. Um comentário no código-fonte do Chrome dá o motivo em uma linha: um certificado autoassinado não oferece nenhuma defesa contra um atacante posicionado entre o seu visitante e o seu aplicativo.

Ele aparece em servidores que alguém configurou à mão: um servidor alugado, uma ferramenta auto-hospedada, uma configuração de teste que foi para produção junto com o aplicativo. Um builder emite certificados de verdade para os domínios que você adiciona nele. Um certificado autoassinado num aplicativo hospedado por um builder significa, então, que outra coisa que não o builder está respondendo no seu endereço. Confira para onde o seu DNS aponta antes de mudar qualquer outra coisa.

A solução é um certificado de uma autoridade de verdade. O Let's Encrypt emite de graça, e é a autoridade que a Vercel usa quando emite o seu.

Causa 3: um elo da cadeia nunca foi enviado

O certificado é do seu endereço e foi assinado por uma autoridade de verdade, mas o servidor o mandou sem o certificado intermediário, então o navegador não consegue ligá-lo a ninguém em quem confia. O alvará foi assinado por uma filial, e falta na vitrine a carta da matriz que responde por essa filial.

A Mozilla chama um certificado intermediário faltando de um dos problemas de configuração de servidor mais comuns. O Firefox agora baixa com antecedência uma cópia de cada certificado intermediário confiável, para que os usuários dele parem de dar com o erro.

É isso que torna essa causa difícil de ver: no seu notebook pode estar tudo certo enquanto para outra pessoa falha. Um navegador que tem a própria cópia do elo que falta preenche o buraco. Um software que usa só o que o seu servidor envia não tem com que preencher. O nosso scanner é esse tipo de software, e por isso ele pode apontar um certificado como não confiável enquanto o seu navegador mostra um cadeado.

Num builder, é ele quem cuida da cadeia. Ela falta em servidores configurados à mão, e ali a solução é servir o certificado seguido do certificado intermediário, num único arquivo. Se você usa o certbot do Let's Encrypt, esse arquivo é o fullchain.pem, e o erro é apontar o servidor para o cert.pem no lugar dele. Para conferir de fora, o teste de servidor gratuito do SSL Labs mostra um certificado intermediário faltando como um problema na cadeia.

O caso do domínio próprio, em ordem

Quando você conecta o seu próprio domínio a um builder, os visitantes veem esse aviso até a hospedagem ter um certificado para o seu nome, e o aviso está dizendo a verdade. Ele acaba sozinho quando o certificado é emitido.

A ordem, na Lovable:

1. Adicione o domínio na Lovable. Ela configura yourapp.com e www.yourapp.com e lista cada um separadamente.
2. Troque os registros DNS no seu registrador pelos valores que a Lovable passar. Segundo a Lovable, a maior parte das mudanças fica ativa em poucas horas, e a propagação pode levar até 72.
3. A Lovable verifica o domínio e emite o certificado. A Vercel funciona do mesmo jeito: prova ao Let's Encrypt que o nome é seu, automaticamente, desde que o domínio aponte para a Vercel.
4. Abra o site quando o domínio aparecer como Live, que é o que a própria Lovable recomenda.

Se o aviso ainda estiver lá depois de 72 horas, a Lovable pede que você fale com o suporte dela. Duas configurações valem uma conferida antes de escrever:

• Procure um registro CAA. É uma entrada de DNS que diz quais autoridades podem emitir certificados para o seu domínio. Uma que deixa de fora a autoridade da sua hospedagem bloqueia o certificado, e um subdomínio herda os registros CAA do domínio pai quando não tem os próprios. O post sobre vencimento encontra o mesmo registro como motivo de uma renovação falhar. Aqui ele impede que o primeiro certificado chegue a ser emitido.
• Procure um proxy na frente. Se o seu DNS está na Cloudflare com a nuvem laranja ligada nos registros que a sua hospedagem passou, quem responde é a Cloudflare, e não a sua hospedagem. A Lovable diz que aí não consegue verificar o domínio nem emitir certificados para ele, e tanto a Lovable quanto a Vercel dizem para colocar esses registros em DNS only.

O que encontramos em 30.879 aplicativos

Oito tinham um certificado em que nenhum navegador confiaria, e todos estavam num domínio que o dono tinha conectado.

Em agosto de 2026 o nosso scan leu o certificado de 30.879 aplicativos no ar: 29.927 no subdomínio do próprio builder e 952 num domínio próprio. Os oito certificados não confiáveis estavam todos entre os 952, um pouco menos de um em cada cem. Nenhum dos aplicativos no subdomínio de um builder tinha um, o que bate com tudo o que vem acima. No endereço do próprio builder, o nome e o certificado são do builder.

O nosso achado registra que o certificado falhou, mas não qual das três causas foi, então não temos como dizer como os oito se dividem. Os certificados vencidos ou perto de vencer do mesmo scan estão contados no post sobre vencimento.

Para conferir o seu próprio aplicativo, o nosso scan gratuito lê de fora o certificado que o seu servidor envia e aponta esse achado quando o encontra. Leva cerca de 20 segundos e não pede conta.

Ficar sabendo da próxima vez que algo mudar

Um certificado passa de confiável a recusado quando alguma coisa muda em volta dele: um domínio novo, uma mudança de DNS, um proxy ligado. A verificação que importa é a que roda depois da mudança.

Escaneie o seu aplicativo de graça para ver o que o navegador de um visitante recebe hoje.

• Lê de fora o certificado que o seu servidor envia, junto com outras oito verificações.
• Aponta o achado quando o certificado não é confiável, e quando venceu ou está perto de vencer.
• Cerca de 20 segundos, e sem conta.

Reeve Monitor para saber logo depois da mudança.

• Verifica o seu aplicativo a cada 60 segundos, e um certificado em que ele não pode confiar conta como o seu aplicativo fora do ar. Você fica sabendo, então, como ficaria de qualquer outra queda.
• Roda as nove verificações de novo a cada hora e manda um e-mail quando a sua nota cai.
• Cobre até três aplicativos.

O que fazer agora

Quando o aviso some e o aplicativo continua sem carregar, a próxima pergunta é se o problema é o seu aplicativo ou a plataforma embaixo dele, e o Supabase caiu ou é o seu aplicativo? mostra como diferenciar.