Escolha a verificação que responde ao problema
Um site pode aceitar uma conexão TCP, apresentar um certificado e depois mostrar uma página de erro. São etapas diferentes. O teste de porta verifica se a conexão foi estabelecida a partir do servidor de teste. A verificação do certificado examina a conexão TLS e o certificado recebido para um nome específico. Uma consulta HTTP observa a resposta da aplicação. Anote em qual etapa ocorre a falha antes de alterar configurações.
Comece pelo endereço exato que falha no navegador, incluindo um subdomínio como loja.example.com. Registre a mensagem, o horário e os dispositivos afetados. Uma falha limitada a um celular antigo pede uma investigação diferente de um tempo de espera esgotado em todos os aparelhos. Altere um ajuste por vez e repita o mesmo teste. Assim, uma mudança no resultado terá relação com uma mudança conhecida na configuração.
| Teste | O que observa | O que não comprova |
|---|---|---|
| Porta TCP | Uma conexão foi estabelecida na porta escolhida | Certificado válido ou página funcionando |
| Certificado TLS | Certificado recebido e resultado da validação | Segurança completa do site ou compatibilidade universal |
| Resposta HTTP | Status e conteúdo enviados pelo servidor | Funcionamento de todos os links, acessos e pagamentos |
Use o nome que os visitantes acessam
Na consulta do certificado, informe o nome público do servidor, sem senha, caminho privado ou endereço do painel de hospedagem. Em https://loja.example.com/carrinho, o nome é loja.example.com. O caminho /carrinho não seleciona o certificado TLS. A porta HTTPS habitual é 443, mas a configuração do serviço determina a porta correta. Um endereço HTTPS que redireciona para outro nome também precisa estabelecer TLS antes de entregar esse redirecionamento.
O domínio principal e a versão com www são nomes distintos. Um certificado para example.com não cobre automaticamente www.example.com. Um curinga como *.example.com normalmente cobre loja.example.com, mas não o domínio sem subdomínio nem um nome mais profundo, como pagar.loja.example.com. Compare os nomes alternativos do certificado com o nome consultado. O rótulo amigável mostrado no painel não substitui a lista real de cobertura.
Leia os campos em uma ordem útil
Confira primeiro a correspondência do nome, o período de validade e o resultado de confiança. Os nomes alternativos do titular, conhecidos como SAN, indicam os nomes incluídos no certificado. O emissor identifica a entidade indicada como responsável pela emissão. Esses dados não avaliam os produtos do site, a conduta comercial do operador ou as falhas do programa. Uma conexão autenticada também pode levar a um site prejudicial.
Compare a data e a hora de vencimento com o horário da consulta, não com uma captura antiga. Confira também o início da validade: um certificado pode vencer daqui a meses e ainda não ter entrado em vigor. Resumos com apenas a data escondem casos próximos à mudança de dia. O número de dias restantes ajuda no planejamento, mas conserve os horários completos ao relatar o problema.
As datas são apenas uma verificação
Separe a correspondência do nome da confiança
Um certificado pode conter o nome correto e falhar na validação de confiança. Uma cadeia incompleta, um certificado intermediário vencido, uma autoridade privada ou um repositório de confiança desatualizado produzem causas diferentes. A cadeia relaciona o certificado do site a uma autoridade reconhecida pelo cliente. A instalação do servidor e a configuração do cliente importam. Trocar apenas o certificado final não resolve necessariamente todos esses casos.
A verificação realizada no servidor usa a biblioteca TLS e o repositório de confiança daquele servidor. Não promete o mesmo resultado em todos os celulares, navegadores ou equipamentos conectados. Compare a versão do cliente que falhou, seu relógio e a mensagem exata com um navegador atualizado. Não instale uma autoridade desconhecida nem desative a validação para esconder o aviso. Peça à hospedagem o procedimento de instalação e a cadeia compatível recomendada.
Revise a CSR antes de solicitar o certificado
Uma solicitação de assinatura de certificado, ou CSR, contém uma chave pública e as informações de identidade solicitadas. Não é o certificado emitido, e sua decodificação não consulta o site em funcionamento. Cole somente o bloco da CSR no decodificador, mantendo os marcadores de início e fim. Um arquivo marcado PRIVATE KEY deve permanecer no armazenamento protegido de chaves, nunca em formulário público, chamado aberto de suporte ou captura de tela.
Compare os nomes e os detalhes da chave com o pedido do certificado e o plano de instalação. O decodificador mostra os campos presentes; não decide quais nomes a empresa precisa nem garante quais extensões a autoridade emitirá. A ausência de um SAN solicitado não comprova o conteúdo de um certificado futuro. Confira as opções do pedido e, depois da emissão, inspecione separadamente o certificado que será instalado.
Entenda o limite da decodificação
Ler a estrutura da CSR é diferente de verificar sua assinatura ou comprovar que a chave privada correspondente está disponível no servidor. Um nome decodificado é uma declaração da solicitação, não uma prova de controle do domínio. A autoridade certificadora faz sua própria validação. O decodificador do Savvy Toolkit ajuda na inspeção; uma solicitação legível não significa que o pedido foi aprovado ou que a instalação está pronta.
Um administrador pode analisar uma cópia local com openssl req -in request.csr -text -verify -noout. A opção -verify confere a assinatura da própria solicitação; não estabelece confiança pública em um certificado futuro. Execute o comando com a CSR salva e mantenha arquivos de chave privada fora de terminais e registros compartilhados. A leitura dos campos sem verificação de assinatura responde a uma pergunta mais limitada e deve ser descrita dessa maneira.
Interprete corretamente o teste de porta TCP
Teste uma única porta de um serviço público próprio ou para o qual exista autorização. Informe o nome ou IP público e a porta TCP configurada. Uma conexão aceita significa que algo respondeu naquele destino, a partir da rede do verificador e naquele momento. Isso não identifica o programa, não valida seu login e não comprova que o serviço deveria ficar acessível pela Internet.
Uma conexão recusada e um tempo de espera esgotado pedem verificações diferentes. A recusa costuma indicar uma rejeição explícita em algum ponto do caminho. O tempo esgotado significa que a conexão não foi concluída no prazo; filtros, problemas de rota, endereço incorreto ou falha no serviço continuam possíveis. Não classifique toda espera esgotada como porta fechada. O teste não verifica UDP; um resultado para TCP 53 não confirma o funcionamento de DNS por UDP.
Verifique o caminho completo do redirecionamento de portas
Para testar um servidor doméstico, a aplicação precisa estar em execução e escutar no endereço local e na porta esperados. A regra de encaminhamento direciona uma porta externa para aquele equipamento e serviço. O firewall do computador, o roteador e a rede do provedor podem afetar o percurso. Confira o serviço dentro da rede antes de ajustar o roteador. Preserve configurações não relacionadas e evite abrir faixas inteiras para investigar uma porta.
Compare o endereço WAN do roteador com o endereço público observado de fora. Endereçamento privado, CGNAT ou um segundo roteador podem significar que a regra do roteador mais próximo não representa todo o caminho. O IPv6 público tem um modelo de exposição e firewall diferente do NAT em IPv4. Um teste feito no mesmo Wi-Fi também pode usar uma rota diferente de uma conexão externa.
Quando DNS e hospedagem apresentam resultados diferentes
Depois de uma migração, alguns endereços podem alcançar o servidor antigo enquanto outros chegam ao novo. Um domínio pode publicar registros IPv4 e IPv6 cujos destinos entregam certificados diferentes. Uma rede de distribuição de conteúdo pode encerrar a conexão TLS do visitante antes de encaminhar o tráfego à origem. Assim, o certificado observado publicamente pode ser o da borda, não o que você acabou de instalar na hospedagem.
Registre o nome consultado e o endereço de destino quando o resultado realmente fornecer esse dado. Compare os registros DNS com as instruções do provedor e examine as duas famílias de endereços. Mantenha o nome na consulta TLS: uma conexão apenas ao IP pode fazer um servidor compartilhado entregar o certificado padrão. Evite alterar DNS repetidamente durante a comparação. Isso acrescenta variáveis em vez de isolar a causa da falha.
Um diagnóstico com observações concretas
Considere uma loja ilustrativa em que https://example.com funciona, mas https://www.example.com mostra um aviso de nome. O teste de porta conecta em 443 para ambos. A consulta de www.example.com recebe um certificado cuja lista SAN contém apenas example.com. Essa combinação aponta para cobertura de nome ou configuração do servidor virtual. Abrir outra porta no firewall não corrige o nome ausente. Confira qual certificado deveria atender ao endereço com www.
Agora mude a observação: os dois nomes apresentam o certificado esperado, mas um aparelho antigo informa emissor não confiável. Confira a cadeia fornecida, o relógio e o suporte do repositório de confiança daquele aparelho. O resultado não prova que todos os visitantes precisam de um certificado novo. Esses exemplos mostram como relacionar evidências; não são medições de uma loja real nem garantem que a mesma correção resolva todos os avisos.
Deixe uma correção que possa ser confirmada
Após alterar o certificado ou a cadeia, repita a consulta original. Guarde o novo número de série, a impressão digital ou as datas apenas quando esses campos estiverem disponíveis. A indicação instalado do painel oferece menos evidência que uma conexão nova recebendo o certificado previsto. Teste cada nome público, o navegador que falhava e as portas independentes usadas pela aplicação. Remova qualquer exposição temporária criada durante o diagnóstico.
Ao pedir suporte, inclua o nome público, a porta, o horário, a mensagem exata e um resultado breve de antes e depois. Não envie senhas, chaves privadas, cookies de sessão ou dados de clientes. Peça ao provedor que confirme a associação do certificado, os intermediários e o processo de renovação. Uma consulta registra um momento: defina quem acompanhará as renovações e como as falhas serão percebidas, sem depender da lembrança do teste de hoje.