certificado ssl expirado

Certificado SSL expirado: o site está de pé e ninguém lá chega.

É a falha mais evitável que existe num site — tem data marcada com meses de antecedência — e continua a ser das mais comuns. O servidor está impecável; o browser é que recusa mostrar a página.

// de quem é o problema É do site. Não é de quem está a visitar. Um certificado expirado aparece a toda a gente, em todos os browsers e em todos os dispositivos. Se só tu é que vês o aviso, o problema é outro — costuma ser a data e a hora do teu computador estarem erradas, e vale a pena confirmar isso antes de avisares alguém.

Um certificado TLS — o que faz aparecer o cadeado, e a que quase toda a gente continua a chamar SSL — tem uma data de fim. No Let’s Encrypt são 90 dias; em certificados comprados costumam ser 12 meses. Passada essa data, o certificado deixa de ser válido e o browser recusa-se a estabelecer a ligação sem primeiro mostrar um aviso a ecrã inteiro.

O site continua exactamente como estava. O servidor responde, o WordPress funciona, a base de dados está bem. O que se partiu foi a confiança na identidade do servidor — e o browser trata isso com a mesma severidade com que trataria um site falsificado, porque do ponto de vista dele os dois casos são indistinguíveis.

O efeito prático é o pior que há: um aviso vermelho, com linguagem de segurança, que assusta qualquer visitante e que a maior parte das pessoas não sabe contornar. Em termos de negócio, um certificado expirado é mais grave do que um servidor em baixo — porque parece deliberado.

// causas prováveis

Por onde é que isto costuma vir.

Por ordem de frequência. A primeira explica mais casos do que todas as outras juntas.

  • A renovação automática falhou em silêncio

    É a causa em quase todos os casos. O `certbot` deixou de correr, o cron foi apagado numa migração, ou a validação falhou porque o site mudou de servidor. Nada disto dá erro visível — só se descobre no dia em que o certificado morre.

  • O site mudou de alojamento e o certificado ficou para trás

    O novo servidor emitiu o seu, ou não emitiu nenhum. Migrações são o momento em que isto mais acontece, porque toda a gente confirma que o site abre e ninguém confirma até quando.

  • A validação por HTTP deixou de passar

    O Let’s Encrypt confirma que és dono do domínio pedindo um ficheiro em `/.well-known/acme-challenge/`. Um redireccionamento novo, uma regra de firewall ou um plugin de segurança podem tapar esse caminho — e a renovação falha em cada tentativa, calada.

  • Ninguém era responsável por aquele domínio

    O caso mais comum em carteiras de clientes: o site foi entregue há dois anos, o cliente não sabe o que é um certificado, e a pessoa que o configurou já não trabalha lá.

// o que fazer

Passo a passo, e o primeiro é confirmar.

Antes de mexer no servidor, vale a pena saber o que ele está mesmo a apresentar. É o que a ferramenta aqui em baixo responde.

  1. 01

    Confirma que expirou mesmo, e há quanto tempo

    Antes de mexer, verifica o certificado a partir de fora. O verificador diz-te a data exacta de fim, quem o emitiu e se o problema é mesmo a validade ou outra coisa — muitas vezes o certificado está válido e o que falta são os intermédios.

  2. 02

    Vê se o alojamento renova por ti

    Quase todos os painéis modernos — cPanel, Plesk, os painéis próprios da Hostinger, da SiteGround e afins — têm SSL gratuito com renovação automática, e muitas vezes o trabalho todo é activá-lo ou carregar em renovar. É o caminho mais curto e é o certo em alojamento partilhado.

  3. 03

    Se é um servidor teu, corre a renovação à mão e lê o erro

    Um `certbot renew` diz-te em texto claro porque é que falhou. A mensagem costuma apontar directamente para a causa: o desafio não passou, o caminho está bloqueado, a porta 80 está fechada. Não adivinhes — o comando responde.

  4. 04

    Confirma que o caminho de validação está aberto

    Cria um ficheiro de teste em `/.well-known/acme-challenge/` e tenta abri-lo pelo browser, em HTTP. Se não abrir, encontraste a razão pela qual a renovação falhava — e é quase sempre um redireccionamento forçado para HTTPS que apanha também este caminho.

  5. 05

    Reinicia o servidor web depois de instalar

    O certificado novo só entra em vigor quando o Nginx ou o Apache recarregam a configuração. É o passo esquecido que faz alguém pensar que a renovação não funcionou.

  6. 06

    Verifica outra vez, de fora

    O teu browser guarda certificados em cache e pode continuar a mostrar o antigo durante minutos. Uma verificação externa vê o que o servidor está mesmo a apresentar agora — que é a única confirmação que conta.

Cola o domínio e abrimos a ligação TLS a partir de um servidor em Portugal: validade, cadeia, nomes cobertos e quem emitiu. Sem conta, sem custo, e não guardamos o que verificares.

verificar_certificado servidor: PT

// que não volte

Como não voltar a esta página daqui a 90 dias.

  • Vigia a data em vez de confiar na automatização

    A renovação automática funciona 99% das vezes e falha calada na centésima. O que falta não é automatização — é alguém a confirmar que ela correu.

  • Trinta dias de antecedência, não três

    Com um mês, resolve-se numa terça-feira de manhã. Com três dias, resolve-se com o cliente ao telefone. É o mesmo trabalho, com stress completamente diferente.

  • Faz a lista dos domínios que geres

    Não dá para vigiar o que não está numa lista. Um ficheiro com domínio, alojamento, registrar e data de renovação é meia hora de trabalho e evita a maior parte destes incidentes.

  • Confirma o certificado depois de cada migração

    Toda a gente testa se o site abre. Quase ninguém testa até quando. É o passo de dez segundos que falta na maior parte das listas de entrega.

// limites

Onde é que esta página encalha.

  • Não conseguimos ver se a renovação automática está configurada. Isso vive no teu servidor e não é visível de fora — só se descobre no dia em que não renova, que é exactamente o problema.
  • Não verificamos revogação. Um certificado revogado mas ainda dentro da validade aparece como válido nesta leitura, e é um caso raro mas real.
  • Se o certificado está bom e o aviso continua, o problema é outro — cadeia incompleta, nome que não confere, ou o relógio do computador de quem está a ver.
  • Certificados internos e auto-assinados vão dar sempre aviso, por desenho. Não há aqui nada para corrigir se a intenção era mesmo essa.

// perguntas

O que nos perguntam a seguir.

Quanto tempo demora a resolver um certificado expirado?

Se o alojamento tem SSL gratuito no painel, minutos. Se é um servidor teu com `certbot`, o tempo de perceber porque é que a validação falhou — costuma ser um caminho bloqueado, e resolve-se numa tarde. O que demora nunca é emitir o certificado; é encontrar a razão pela qual ele deixou de renovar.

Posso dizer ao cliente para carregar em "avançar mesmo assim"?

Podes, e ele consegue. Mas convém saber o que estás a pedir: estás a ensinar alguém a ignorar um aviso de segurança, e quem aprende a ignorar este ignora o próximo. Para uma pessoa durante dez minutos, passa. Como resposta a visitantes, não.

Um certificado expirado afecta o SEO?

Afecta, e depressa. O Google não consegue rastrear um site cujo certificado não valida, e a taxa de abandono é próxima de total enquanto durar. Não é uma penalização — é o site deixar de estar acessível, com todas as consequências disso.

Vigiar aquele domínio, em vez de te lembrares dele.

Um certificado é a única falha de um site que tem data marcada com noventa dias de antecedência. Está tudo lá para não acontecer, e acontece na mesma — porque a automatização falha calada e ninguém está a confirmar. A De Olho vai ler a validade de cada domínio que vigiares e avisar-te aos trinta dias, aos sete e no dia. Enquanto não abre, esta leitura dá para fazer à mão, sempre que te lembrares.

A De Olho abre em 2026 e ainda não dá para usar. Quem estiver na lista de espera fica a saber primeiro e mantém o preço de lançamento enquanto a subscrição durar.