AA
novembro 2, 2026
Atualizado novembro 2, 2026

Erros comuns de SSL em VPS e como corrigir

SSL VPS

Você publicou o site em um VPS, configurou o domínio e, no primeiro acesso, o navegador mostra uma tela vermelha com a frase “Sua conexão não é particular”. O visitante fecha a aba, o formulário de contato fica sem envios e a loja deixa de vender. Os erros de SSL em VPS estão entre os problemas mais frequentes de quem administra o próprio servidor, e quase sempre têm uma causa concreta e uma solução direta.

Neste guia, explicamos em linguagem simples:

  • o que o navegador confere antes de exibir o cadeado;

  • como saber se o defeito está no seu computador ou no servidor;

  • o que significa cada código de erro e como resolvê-lo;

  • por que o certificado às vezes não é emitido nem renovado;

  • quais hábitos evitam que o problema volte.

O material serve para donos de pequenos sites, freelancers e quem está começando a cuidar de um servidor. Você não precisa ser administrador de sistemas para acompanhar: os comandos aparecem com explicação, e cada etapa diz o que você deve ver na tela.

O que exatamente o navegador verifica antes de mostrar o cadeado?

SSL é o nome antigo do protocolo que criptografa a conexão entre o navegador e o site. Hoje quem faz esse trabalho é o TLS, sua versão moderna, mas o termo SSL continuou no vocabulário de hospedagens e painéis. Neste artigo usamos os dois como sinônimos.

O certificado funciona como um documento de identidade do site. Ele é emitido por uma autoridade certificadora (CA), organização em que navegadores e sistemas operacionais confiam. Entre o certificado do seu domínio e a CA existe uma cadeia: o certificado final, um ou mais certificados intermediários e o certificado raiz, que já vem instalado no dispositivo do visitante.

Pense em um passaporte. O agente de imigração confere quem emitiu o documento, se ele está dentro da validade e se o nome bate com o do viajante. O navegador faz quatro verificações parecidas:

  1. Validade. A data atual precisa estar entre o início e o fim do prazo do certificado.

  2. Nome. O domínio digitado deve constar no certificado.

  3. Emissor. A CA precisa estar na lista de entidades confiáveis.

  4. Cadeia completa. O servidor deve entregar também os certificados intermediários.

Se qualquer uma dessas checagens falhar, o cadeado some e aparece o aviso. Todos os erros descritos adiante quebram um desses quatro pontos, por isso vale guardar essa lista: ela orienta todo o diagnóstico.

O que um SSL quebrado custa para um site no Brasil?

O efeito mais visível é a perda de visitantes. A tela de alerta do Chrome, do Edge e do Safari foi desenhada para assustar, e quase ninguém clica em “Avançado” para seguir adiante. Em uma loja virtual, isso significa carrinhos abandonados. Em um site institucional, pedidos de orçamento que nunca chegam.

Há também a questão legal. O artigo 46 da LGPD obriga quem trata dados pessoais a adotar medidas técnicas de segurança para protegê-los. A lei não cita a criptografia pelo nome, porém a ANPD, no guia de segurança para agentes de tratamento de pequeno porte, recomenda protocolos de comunicação seguros como TLS e HTTPS. O artigo 48, por sua vez, prevê que na avaliação de um incidente conta a favor da empresa ter tornado os dados ininteligíveis para terceiros.

Na prática, um formulário que coleta nome, e-mail e telefone sem HTTPS válido envia essas informações de forma exposta. Corrigir o certificado leva poucos minutos e reduz um risco concreto para o negócio.

Por que os erros de certificado ficaram mais frequentes em 2026?

Até pouco tempo, um certificado pago durava cerca de um ano, e muitos administradores lembravam dele uma vez a cada doze meses. Esse cenário mudou.

Em abril de 2025, o CA/Browser Forum, grupo que reúne autoridades certificadoras e fabricantes de navegadores, aprovou a votação SC-081v3. A decisão foi unânime, com apoio de Apple, Google, Microsoft e Mozilla. O prazo máximo dos certificados públicos passou a cair em etapas:

  • desde 15 de março de 2026: até 200 dias;

  • a partir de 15 de março de 2027: até 100 dias;

  • a partir de 15 de março de 2029: até 47 dias.

O Let’s Encrypt, a CA gratuita mais usada em servidores virtuais, segue o mesmo caminho. Em maio de 2026 o perfil opcional tlsserver começou a emitir certificados de 45 dias. Em fevereiro de 2027 o perfil padrão passará para 64 dias e, em fevereiro de 2028, para 45.

Duas mudanças anteriores aumentam o risco para quem ainda não automatizou nada:

  • Sem e-mails de aviso. Desde junho de 2025 o Let’s Encrypt deixou de mandar mensagens avisando que o certificado está perto de expirar.

  • Fim do OCSP. Em agosto de 2025 o Let’s Encrypt desligou seus servidores OCSP e passou a usar apenas listas de revogação (CRL). Configurações de OCSP stapling copiadas de tutoriais antigos perderam o sentido.

Resultado: renovações mais frequentes e menos lembretes. Quem renova à mão ou depende de um agendamento fixo vai encontrar o erro de certificado expirado com cada vez mais frequência.

Como saber se o problema está no seu dispositivo ou no servidor?

Antes de mexer em configurações, vale descobrir de que lado está a falha. Siga a ordem abaixo.

  1. Abra o site em outro aparelho. Use o celular com dados móveis, fora do Wi-Fi da empresa. Se lá o cadeado aparece normalmente, o problema provavelmente está no computador ou na rede original.

  2. Confira a data e a hora. Um relógio errado faz o navegador acreditar que um certificado válido já expirou ou ainda não começou a valer.

  3. Teste no SSL Labs. O serviço gratuito da Qualys analisa o domínio e aponta certificado vencido, cadeia incompleta e protocolos antigos. A nota final, de A+ a F, ajuda a priorizar as correções.

  4. Veja o certificado direto do servidor. No terminal do VPS, rode openssl s_client -connect seudominio.com.br:443 -servername seudominio.com.br. A saída mostra o emissor, o nome e as datas.

  5. Liste os certificados do Certbot. O comando sudo certbot certificates informa quais domínios estão cobertos e quantos dias restam.

  6. Confirme que a porta 443 está ativa. Com sudo ss -tlnp | grep 443, você vê se o Nginx ou o Apache está escutando nessa porta.

Se o aviso aparece em qualquer dispositivo e o SSL Labs também acusa falha, a causa está no servidor. Os próximos tópicos mostram como identificá-la.

O que significa cada mensagem de erro que o visitante vê?

O Chrome exibe um código abaixo do texto do alerta. Ele indica qual das quatro verificações falhou e já sugere o caminho da correção.

NET::ERR_CERT_DATE_INVALID

O certificado está fora do prazo. Na maioria dos casos ele expirou porque a renovação automática parou de funcionar. Com menos frequência, o relógio do visitante ou do próprio servidor está errado.

Como corrigir: renove com sudo certbot renew, recarregue o servidor web e descubra por que o agendamento falhou (veja o tópico sobre renovação logo abaixo).

NET::ERR_CERT_AUTHORITY_INVALID

O navegador não reconhece quem emitiu o certificado. Acontece com certificados autoassinados, criados pelo próprio servidor, e quando o servidor entrega o certificado sem os intermediários. Alguns painéis, como o CyberPanel, instalam um certificado autoassinado quando a emissão falha, e o site passa a exibir o alerta sem que o dono perceba.

Como corrigir: emita um certificado de uma CA confiável e aponte o servidor para o arquivo com a cadeia completa (no Certbot, fullchain.pem).

NET::ERR_CERT_COMMON_NAME_INVALID

O domínio acessado não aparece no certificado. O caso típico é o certificado emitido para seudominio.com.br enquanto o visitante digita www.seudominio.com.br.

Como corrigir: emita um novo certificado incluindo todas as variações, por exemplo -d seudominio.com.br -d www.seudominio.com.br.

ERR_SSL_PROTOCOL_ERROR e ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Navegador e servidor não chegam a um acordo sobre como criptografar a conexão. As causas mais comuns são protocolos ultrapassados (TLS 1.0 e 1.1) ainda ativos, um bloco de configuração da porta 443 sem certificado ou um erro de sintaxe no arquivo do servidor.

Como corrigir: deixe ativos apenas TLS 1.2 e TLS 1.3, rode sudo nginx -t para validar a configuração e recarregue o serviço.

ERR_TOO_MANY_REDIRECTS

O site entra em um ciclo de redirecionamentos. É comum com a Cloudflare no modo Flexible: ela acessa o servidor por HTTP, o servidor redireciona para HTTPS, e o processo se repete sem fim.

Como corrigir: com o certificado instalado no VPS, mude o modo na Cloudflare para Full (strict). Também revise regras duplicadas de redirecionamento no servidor e no CMS.

Cadeado com aviso de conteúdo misto

O certificado está correto, mas parte da página (imagens, scripts, fontes) ainda carrega por http://. O navegador então marca a página como parcialmente insegura.

Como corrigir: substitua os endereços antigos no banco de dados ou no tema e use links relativos ou iniciados por https://.

Por que o certificado não é emitido ou renovado no VPS?

Quando o Certbot retorna erro, a mensagem costuma apontar para uma destas causas.

  • O domínio não aponta para o servidor. O Let’s Encrypt precisa encontrar o VPS pelo nome. Se o registro A ainda leva ao IP da hospedagem antiga, ou a alteração no DNS não se propagou, a validação falha. Verifique com dig +short seudominio.com.br.

  • A porta 80 está fechada. A validação mais usada (HTTP-01) acessa um arquivo temporário pelo HTTP comum. Se o firewall bloqueia a porta 80 “por segurança”, a renovação para. Libere com sudo ufw allow 80/tcp e confira também as regras de rede do provedor.

  • Um registro CAA bloqueia a CA. O CAA é uma entrada DNS que define quais autoridades podem emitir certificados para o domínio. Se ele autoriza apenas outra CA, o Let’s Encrypt recusa o pedido. Para certificados wildcard, é preciso também a tag issuewild. Consulte com dig CAA seudominio.com.br.

  • O limite de emissões foi atingido. O Let’s Encrypt permite 50 certificados por domínio registrado por semana e 5 certificados idênticos no mesmo período. Repetir testes no ambiente de produção esgota esse limite rápido, e surge a mensagem “too many certificates already issued”. Para experimentar, use o ambiente de testes com a opção --staging.

  • A chave privada não corresponde ao certificado. Erro frequente na instalação manual de um certificado comprado. Compare os dois arquivos com openssl antes de colocá-los no ar.

  • O servidor web não foi recarregado. O Certbot renova o arquivo, mas o Nginx continua entregando a versão antiga até receber sudo systemctl reload nginx. Um hook de pós-renovação resolve isso de vez.

  • As permissões dos arquivos estão erradas. Se o processo do servidor não consegue ler a chave, o serviço não sobe com HTTPS.

Em um VPS da Serverspace você tem acesso root ao sistema, então portas, DNS e servidor web ficam sob seu controle. Essa liberdade permite resolver cada item da lista sem abrir chamado e, ao mesmo tempo, coloca a verificação nas mãos de quem administra o servidor.

Para consulta rápida, reunimos os sintomas mais comuns em uma tabela.

Sintoma Causa provável Como corrigir
NET::ERR_CERT_DATE_INVALID Certificado expirado ou relógio errado Renovar com certbot renew, recarregar o servidor e revisar o agendamento
NET::ERR_CERT_AUTHORITY_INVALID Certificado autoassinado ou cadeia incompleta Emitir por uma CA confiável e usar fullchain.pem
NET::ERR_CERT_COMMON_NAME_INVALID Domínio ou www ausente do certificado Reemitir incluindo todas as variações do domínio
ERR_SSL_PROTOCOL_ERROR Porta 443 sem certificado ou erro de sintaxe Validar com nginx -t e corrigir o bloco listen 443
ERR_SSL_VERSION_OR_CIPHER_MISMATCH Protocolos antigos ou cifras incompatíveis Manter apenas TLS 1.2 e TLS 1.3
ERR_TOO_MANY_REDIRECTS Cloudflare em Flexible e redirecionamento no servidor Mudar para Full (strict) e remover regras duplicadas
Aviso de conteúdo misto Recursos carregados por http:// Atualizar os links para https://
Certbot: Timeout during connect Porta 80 bloqueada no firewall Liberar a porta 80 e redirecionar para HTTPS
Certbot: unauthorized ou NXDOMAIN Registro A aponta para outro IP Corrigir o DNS e aguardar a propagação
Certbot: CAA record prevents issuance Registro CAA não autoriza a CA Adicionar issue e issuewild para letsencrypt.org
Certbot: too many certificates already issued Limite semanal do Let's Encrypt Aguardar o período, testar com --staging, avaliar um wildcard

Let’s Encrypt gratuito ou certificado pago: qual faz mais sentido no VPS?

Os dois tipos criptografam a conexão com a mesma força. A diferença está no nível de verificação, no suporte e na forma de renovação.

Let’s Encrypt

  • Vantagens: gratuito, emitido em segundos e renovado de forma totalmente automática pelo Certbot.

  • Limitações: valida apenas o controle do domínio (DV), não oferece suporte direto nem garantia financeira e exige automação bem configurada por causa do prazo curto.

Certificado pago (DV, OV, EV, Wildcard, SAN)

  • Vantagens: opções com validação da organização, garantia financeira, suporte do emissor e wildcard sem depender de validação por DNS a cada renovação automática.

  • Limitações: custo anual e, desde março de 2026, reemissão a cada 200 dias no máximo. A assinatura continua anual, porém o arquivo do certificado precisa ser trocado com mais frequência.

Para um blog, um portfólio ou uma landing page, o Let’s Encrypt atende muito bem. Para lojas virtuais, sistemas com cadastro de clientes e empresas que querem exibir a razão social no certificado, um OV ou EV faz mais sentido. Na Serverspace é possível contratar certificados SSL da Sectigo de diferentes tipos no mesmo painel em que você gerencia o servidor.

Como esses erros aparecem em projetos reais?

Cenário 1: loja virtual com WooCommerce

Uma loja de cosméticos roda em um VPS da Serverspace no data center Equinix SP3, em São Paulo, perto dos clientes. Na migração para o novo servidor, a equipe copiou os arquivos do site, mas não reativou o agendamento do Certbot. Meses depois, num sábado, o certificado expirou e o checkout passou a exibir NET::ERR_CERT_DATE_INVALID.

Solução: renovação manual imediata, ativação do certbot.timer e teste com sudo certbot renew --dry-run.

Cenário 2: landing page atrás da Cloudflare

Uma agência lançou uma página de campanha usando a Cloudflare. Ao instalar o certificado no VPS e ativar o redirecionamento para HTTPS no Nginx, a página parou de abrir com ERR_TOO_MANY_REDIRECTS. O painel da Cloudflare continuava no modo Flexible.

Solução: mudar para Full (strict) encerrou o ciclo na hora.

Cenário 3: API de aplicativo móvel

Uma startup mantém a API do aplicativo em um VPS. No navegador tudo funcionava, mas usuários de Android relatavam falha de conexão. O Nginx apontava para cert.pem, que contém só o certificado final. Navegadores de desktop costumam completar a cadeia sozinhos, enquanto muitos clientes móveis e bibliotecas de código não fazem isso.

Solução: trocar o caminho para fullchain.pem e recarregar o Nginx.

Cenário 4: estúdio com subdomínios para clientes

Um estúdio de design cria um subdomínio para cada cliente. Em uma semana de muitos lançamentos, os pedidos começaram a ser recusados por excesso de emissões.

Solução: um certificado wildcard (*.estudio.com.br) com validação por DNS (DNS-01), que cobre todos os subdomínios com uma única emissão.

Quais falhas de configuração se repetem e como evitá-las?

  • Renovar por um agendamento fixo. Um cron que roda “a cada 60 dias” vai deixar um certificado de 45 dias expirar. Use o timer do Certbot, que verifica o prazo duas vezes por dia, ou um cliente com suporte a ARI, o recurso que informa ao servidor o momento ideal de renovar.

  • Contar com e-mails de aviso. O Let’s Encrypt não envia mais esses alertas. Configure um monitoramento externo que avise com algumas semanas de antecedência.

  • Instalar o certificado sem a cadeia. Prefira sempre fullchain.pem.

  • Esquecer o www. Inclua todas as variações do domínio no mesmo certificado.

  • Testar em produção. Use --staging até o comando funcionar e só então emita o certificado definitivo.

  • Fechar a porta 80. Mantenha a porta aberta e redirecione o tráfego HTTP para HTTPS.

  • Copiar configurações antigas. Remova TLS 1.0, TLS 1.1 e diretivas de OCSP stapling herdadas de tutoriais desatualizados.

  • Pedir ao visitante que ignore o aviso. Orientar o cliente a clicar em “Avançado” e “Continuar” ensina um hábito perigoso e deixa o problema intacto.

Conclusão: o que fazer agora para manter o HTTPS funcionando

Os erros de SSL em VPS parecem assustadores, mas seguem uma lógica simples: o navegador confere prazo, nome, emissor e cadeia, e cada código aponta qual dessas verificações falhou. Começar pelo diagnóstico, consultar a tabela de sintomas e só depois mexer no servidor economiza tempo e evita novos erros.

Para o HTTPS continuar estável com prazos cada vez mais curtos, três ações bastam:

  1. Rodar hoje sudo certbot renew --dry-run e confirmar que a renovação funciona.

  2. Testar o domínio no SSL Labs e corrigir o que aparecer.

  3. Configurar um monitoramento de validade e marcar na agenda março de 2027, quando o limite cai para 100 dias.

Se você está escolhendo onde hospedar o projeto, um VPS com acesso root e data center no Brasil dá controle total sobre portas, DNS e certificados, o que facilita aplicar tudo o que mostramos neste guia.

Avaliação:
5 fora de 5
Аverage rating : 5
Avaliado por: 1
CEP 01311-930 São Paulo Avenida Paulista, nº 1765, 7º andar, Cj. 72, CV 10172, Bela Vista
+ 55 11 5118-1047
ITGLOBAL.COM BR LTDA
Usamos cookies para melhorar sua experiência no Serverspace. Ao continuar a navegar em nosso site, você concorda com o Uso de Cookies e com a Política de Privacidade.