Como Verificar se um Site Tem um Certificado SSL Válido

Confirme o host exato que você deseja verificar

Comece com o endereço exato, não com o nome da marca na sua cabeça. Um certificado para www.example.com não é o mesmo que um para example.com, e um subdomínio como shop.example.com pode ter seu próprio certificado, seu próprio emissor e seus próprios problemas.

Isso parece óbvio, mas é onde muitas verificações falham. Um visitante pode cair em um redirecionamento, um alias de marketing ou um subdomínio de país, e o certificado só precisa corresponder ao host que o navegador realmente vê.

Digite a URL completa com cuidado. Se o site usar tanto www quanto não-www, teste ambos. Se você estiver verificando uma área de login ou um host de API, verifique também esse nome de host exato, porque um host pode estar bom enquanto outro falha.

Isso é ainda mais importante em um site corporativo com vários pontos de entrada, onde a página inicial, a área de suporte e o domínio do aplicativo podem se comportar de maneira diferente. Um subdomínio perdido pode criar uma falsa sensação de segurança.

Uma nota rápida: um cadeado que parece seguro em uma página não prova que toda a família de domínios está coberta. Ele apenas prova que uma resposta em um host apresentou algum certificado.

Inspecione a cadeia de certificados, não apenas o cadeado

O cadeado é apenas a primeira pista. Um navegador pode mostrar HTTPS enquanto a cadeia de certificados está incompleta, desordenada ou ancorada a um emissor que o navegador não confia.

Abra os detalhes do certificado em seu navegador e procure pela cadeia completa: o certificado do site, quaisquer certificados intermediários e o caminho de confiança raiz. Se um intermediário estiver faltando, alguns navegadores podem ainda se recuperar, mas outros reclamarão, e alguns clientes rejeitarão a conexão imediatamente.

É por isso que saber como verificar se um site tem um certificado SSL válido não é uma questão de um clique. Você precisa ver o que o servidor envia, não apenas o que o ícone de cadeado sugere.

Na prática, uma cadeia incompleta geralmente aparece após uma renovação ou migração de servidor. O próprio certificado pode estar atual, mas a cadeia enviada pelo servidor está errada, então os usuários recebem avisos de qualquer maneira.

Use os detalhes do certificado do navegador, um verificador de SSL ou uma ferramenta de linha de comando se você tiver acesso. Um site que funciona em um navegador pode falhar em outro se o servidor omitir um certificado intermediário.

Um caso do mundo real: um site atrás de um CDN pode apresentar um certificado de folha válido na borda, mas uma cadeia quebrada em um caminho de origem legado. O visitante vê o problema apenas na rota menos comum.

Verifique se o certificado corresponde ao nome do host

Um certificado deve nomear o host que o navegador está visitando. Certificados modernos usam o campo SAN, e essa lista é mais importante do que o antigo campo CN, embora as pessoas ainda olhem para o CN primeiro.

Verifique se as entradas do SAN incluem o domínio exato e o subdomínio que você testou. Se o certificado listar example.com e www.example.com, isso pode ser bom para ambos. Se listar apenas example.com, então www.example.com ainda pode falhar.

Não assuma que curingas resolvem tudo. Um curinga como *.example.com geralmente cobre uma etiqueta de profundidade, então shop.example.com pode estar coberto, enquanto api.shop.example.com não está.

Aliases são uma armadilha comum. A equipe de marketing pode promover go.example.com, mas o certificado cobre apenas example.com e www.example.com. A página carrega, o cadeado aparece por um momento e então o navegador gera um erro de nome.

Aqui está o hábito útil: combine o que os usuários digitam, o que redireciona para o quê e quais são os nomes dos certificados. Três strings. Uma verificação.

Se você gerencia um site que depende de vários domínios de entrada, este é um bom lugar para conectar sua revisão de certificado com o trabalho de segurança do site. Um desvio de certificado não é apenas um incômodo para o navegador; pode quebrar fluxos de login, fluxos de pagamento e qualquer coisa ligada à confiança.

Verifique a expiração e o status de renovação

Todo certificado tem uma data de início e uma data de término. Verifique ambos. Se o certificado já estiver expirado, o aviso do navegador não é um mistério, e se expirar amanhã, isso ainda é um problema para os usuários que abrem o site após a meia-noite.

Olhe para a janela de validade no visualizador de certificados. Algumas ferramentas mostram “não antes” e “não depois”. Essas duas linhas informam se o certificado está ativo agora e se uma renovação já está atrasada.

A renovação nem sempre é instantânea. Um site pode estar no meio de uma implementação, com o antigo certificado ainda visível em um servidor e o novo em outro. Isso pode criar resultados inconsistentes durante uma janela de transição.

Um curto período de expiração não é, por si só, um defeito, mas aumenta as apostas. Se uma tarefa de renovação automática falhar uma vez, o site pode passar de bom a bloqueado com muito pouco aviso.

Mantenha a data em mente ao inspecionar um certificado suspeito. Um certificado que expira em 2 dias merece atenção mais rápida do que um com meses restantes, porque a solução pode ser simplesmente uma renovação que ainda não se propagou.

Para equipes que já utilizam uma plataforma de análise e monitoramento de sites, combinar verificações de certificados com alertas de tempo de atividade ajuda a detectar uma falha de renovação antes que os usuários o façam. O cronograma é importante aqui, não a teoria.

Procure por problemas de confiança da autoridade emissora

Um certificado pode ser válido no papel e ainda assim acionar um aviso de confiança. Isso geralmente aponta para a autoridade certificadora emissora, a cadeia de confiança ou um dispositivo que não possui o certificado raiz correto.

Abra as informações do emissor e confirme se a CA é reconhecida por navegadores e sistemas operacionais modernos. Se o emissor parecer desconhecido, ou se o certificado foi autoassinado, o navegador pode recusar a confiança mesmo quando o HTTPS aparece na barra de endereços.

Certificados autoassinados são comuns em ferramentas internas, servidores de teste e páginas administrativas privadas. Eles também são uma fonte comum de confusão quando alguém copia essa mesma configuração para um site público.

Os avisos do navegador valem a pena serem lidos linha por linha. Um aviso pode mencionar um emissor não confiável. Outro pode mencionar um problema de cadeia. Um terceiro pode dizer que o certificado não é destinado ao host.

Essas mensagens são diferentes. Trate-as de forma diferente.

Se você está verificando um site público que deve ser confiável por padrão, um aviso do navegador significa que o caminho de confiança está quebrado em algum lugar. Isso pode acontecer após uma migração mal gerenciada, uma configuração de proxy ruim ou um certificado instalado com o pacote intermediário errado.

Autoridade confiável não significa 'conteúdo seguro', é claro. Isso apenas significa que o navegador aceita o caminho do certificado como legítimo. Essa é uma afirmação mais restrita, e é a única afirmação que o certificado pode fazer.

Teste por conteúdo misto na página

Um certificado SSL válido não salva uma página que ainda carrega recursos inseguros. Conteúdo misto acontece quando a página principal usa HTTPS, mas imagens, scripts, fontes ou frames vêm de URLs HTTP.

Abra as ferramentas de desenvolvedor e atualize a página. Procure avisos sobre recursos bloqueados ou atualizados. Uma página pode ainda carregar visualmente enquanto um script falha silenciosamente porque o navegador bloqueou um arquivo inseguro.

Esse é um problema de segurança prático, não cosmético. Um único script inseguro pode enfraquecer a proteção que o certificado deve fornecer.

Os infratores comuns são URLs de imagens antigas, widgets de terceiros, tags de análise e players de vídeo incorporados. Um antigo link HTTP em um template pode contaminar dezenas de páginas.

Se você gerencia um portal de conteúdo sobre investimentos, essa verificação é ainda mais importante, pois um script de gráfico quebrado ou um widget de cotações pode fazer a página parecer confiável enquanto falha silenciosamente por trás. O ícone de cadeado não contará essa história.

Conteúdo misto também ajuda a explicar por que os usuários às vezes relatam “o site é seguro no meu laptop, mas não no meu telefone.” O certificado pode estar bem; os recursos da página não estão.

Compare o comportamento em desktop e mobile

Faça a mesma verificação em pelo menos 2 ambientes: um navegador de desktop e um navegador ou dispositivo móvel. Um certificado pode passar em um desktop moderno e falhar em um telefone mais antigo, especialmente se o repositório de confiança estiver desatualizado.

Essa diferença é importante. Uma cadeia de certificados que parece aceitável no Chrome em um laptop pode ainda acionar um aviso no Safari em um iPhone mais antigo ou em um navegador com certificados raiz desatualizados.

Tente o host principal e um subdomínio. Se o site redirecionar de www para não-www, repita o teste após o redirecionamento. Uma falha no host redirecionado ainda é uma falha.

Verificações de dispositivo também revelam peculiaridades de cookies e sessões. Às vezes, o aviso do navegador aparece apenas após o login, porque um host diferente é chamado assim que o usuário chega a uma área segura.

Simples é o melhor aqui. Abra o site, inspecione o cadeado, confirme o nome do host e compare os detalhes do certificado em ambos os dispositivos. Cinco minutos podem economizar um ticket de suporte mais tarde.

Equipes que já dependem do suporte ao site após o lançamento geralmente conhecem bem esse padrão: o relatório do navegador do cliente raramente é o mesmo que o resultado da máquina do desenvolvedor.

Saiba quando escalar para o proprietário do site ou provedor de hospedagem

Escalone quando o certificado estiver expirado, o nome do host não corresponder, a cadeia estiver quebrada ou o navegador mostrar um aviso de confiança que você não consegue explicar pelas configurações do dispositivo local. Essas não são descobertas de 'talvez mais tarde'.

Ao relatar o problema, inclua o host exato, a data e hora, o nome do navegador, o erro visível e uma captura de tela dos detalhes do certificado. Se possível, inclua as entradas SAN, o nome do emissor e a data de expiração.

Mantenha o relatório concreto. Diga 'shop.example.com falha no iPhone Safari com uma discrepância de nome do host' em vez de 'o SSL está quebrado'. A primeira frase dá a alguém um caminho para corrigir.

Se você gerencia o site para um cliente, informe se o problema está em um host ou em vários. Essa distinção pode decidir se a correção pertence ao DNS, ao balanceador de carga, ao servidor web ou ao provedor de certificados.

Provedores de hospedagem geralmente precisam da evidência exata para agir rapidamente. Uma reclamação vaga pode ser passada entre equipes por um dia. Uma precisa pode ser relacionada a uma renovação, a um intermediário ausente ou a uma implantação ruim em minutos.

Para equipes que trabalham em uma plataforma interna ou em um produto público, a transferência mais limpa é aquela que inclui o host, o tipo de falha e o caminho do navegador. Isso é suficiente para separar um problema de certificado de um problema de página, o que economiza todos de adivinhações.

Uma última verificação ajuda em casos teimosos: compare o certificado no site ao vivo com o que está no servidor de origem ou host de staging, se você tiver acesso. Uma implantação incompatível pode deixar um ambiente corrigido e outro ainda falhando, e o navegador só se importa com o host que alcança.