O que verifica este teste?
O KernelHost SSL Checker obtém o certificado do servidor através de um handshake TLS a partir do nó de Frankfurt e mostra os campos mais importantes, sem chamadas a terceiros. É verificado e exibido o seguinte:
- Emitido para e por: Common Name (Subject CN), o Subject DN completo e o Issuer (que CA assinou o certificado).
- Período de validade: Data de início e fim em UTC, mais os dias restantes. Codificado por cor: verde (>30 dias), laranja (7 a 30 dias), vermelho (menos de 7 dias ou já expirado).
- Subject Alternative Names (SANs): Lista completa de hostnames que o certificado cobre, incluindo entradas wildcard.
- Correspondência de hostname: Verifica se o domínio introduzido está realmente coberto pelo Common Name ou por uma SAN wildcard (RFC 6125).
- Chave e assinatura: Algoritmo da chave pública (RSA, ECDSA), tamanho da chave em bits ou nome da curva, e o algoritmo de assinatura.
- Fingerprints e número de série: Fingerprint SHA-256 e SHA-1 do certificado codificado em DER, mais o número de série em hexadecimal.
- Cadeia completa: Todos os certificados que o servidor entregou no handshake, com subject, issuer e papel (leaf, intermédio, raiz).
Erros SSL comuns e o que significam
Os navegadores mostram muitas vezes erros crípticos como NET::ERR_CERT_DATE_INVALID ou SSL_ERROR_BAD_CERT_DOMAIN. Aqui ficam as causas mais frequentes e como as resolver:
- Certificado expirado: A data notAfter está no passado. Os navegadores bloqueiam a página por completo. Solução: renove o certificado. Com Let's Encrypt isto acontece automaticamente a cada 60 dias via certbot ou acme.sh.
- Hostname não coincide: O hostname não consta nem no Common Name nem em nenhuma SAN. Solução: ao reemitir, adicione todos os domínios e subdomínios necessários como SAN.
- Auto-assinado ou CA desconhecida: O Issuer não é uma raiz confiável. Os navegadores mostram NET::ERR_CERT_AUTHORITY_INVALID. Solução: obtenha um certificado de uma CA reconhecida como Let's Encrypt, ZeroSSL, Sectigo ou DigiCert.
- Cadeia incompleta: O servidor envia apenas o certificado leaf, sem intermédios. Navegadores móveis e dispositivos antigos falham. Solução: configure a cadeia completa (fullchain.pem) no servidor web.
- Chave fraca ou assinatura fraca: RSA abaixo de 2048 bit ou assinaturas SHA-1 já não são aceites. Solução: reemitir com RSA 2048+ ou ECDSA P-256.
- Conteúdo misto e armadilha do HSTS: Se enviou um cabeçalho HSTS válido e o certificado expira, os visitantes não conseguem clicar para passar o aviso. Ação imediata: renove o certificado, em emergência reduza o max-age do HSTS.
Let's Encrypt vs. certificados comerciais
Let's Encrypt é uma CA gratuita e automatizada, gerida pela ISRG. Os certificados são tecnicamente idênticos aos certificados DV comerciais e são confiados por todos os navegadores modernos.
Quando faz sentido um certificado pago? Apenas em casos especiais:
- Extended Validation (EV): Antes mostrava barra de endereço verde, hoje quase invisível. Só vale a pena para bancos ou plataformas de trading quando a lei o exige.
- Wildcard sem desafio DNS: Let's Encrypt só suporta wildcards via desafio DNS-01. Se não tem acesso API ao DNS, ZeroSSL Premium ou Sectigo são alternativas.
- Garantia e seguro: CAs comerciais oferecem montantes de seguro em caso de emissão indevida. Na prática raramente relevante, mas alguns frameworks de compliance exigem-no.
O KernelHost Webhosting e o cPanel incluem integração gratuita com Let's Encrypt. Os certificados são renovados a cada 60 dias via AutoSSL sem qualquer ação da sua parte. Certificados wildcard via desafio DNS também são possíveis assim que o domínio esteja alojado no DNS KernelHost.
TLS 1.2 vs. TLS 1.3
TLS 1.2 é o padrão desde 2008, o TLS 1.3 foi publicado como RFC 8446 em 2018 e está amplamente implementado desde 2020. Versões mais antigas (SSL 3.0, TLS 1.0, TLS 1.1) são inseguras e devem estar desativadas na configuração do servidor.
O que o TLS 1.3 faz melhor:
- Handshake mais rápido: 1-RTT em vez de 2-RTT, mais 0-RTT opcional na retoma. Notavelmente mais rápido em páginas com muito TLS.
- Conjunto de cifras mais limpo: Apenas 5 cifras AEAD permitidas. Sem mais troca de chaves RSA, sempre forward secrecy.
- Handshake encriptado: O próprio certificado do servidor é transmitido encriptado. Com ESNI/ECH até o SNI fica privado.
- Compatível com versões anteriores: Servidores podem oferecer TLS 1.2 e 1.3 em paralelo. Os navegadores negoceiam automaticamente a versão comum mais alta.
O que significa um certificado expirado?
Um certificado SSL expirado significa concretamente: os navegadores mostram um aviso em ecrã inteiro e bloqueiam o site. Os visitantes não conseguem clicar para passar na maioria dos casos, especialmente quando há um cabeçalho HSTS ativo.
Consequências para quem opera:
- Perda de ranking no Google (HTTPS é fator de ranking e os sinais relacionados com confiança são avaliados).
- Servidores de email (MX/SMTP com STARTTLS) recusam ligações de entrada, as mensagens fazem bounce ou são entregues com atraso.
- Clientes API e apps móveis com certificate pinning falham e podem precisar de uma atualização da app.
HSTS, CAA e OCSP stapling
Um certificado válido é apenas o início. Três mecanismos extra elevam a segurança TLS ao nível das melhores práticas:
- HSTS (HTTP Strict Transport Security): Cabeçalho que obriga os navegadores a usar apenas HTTPS daqui em diante. Recomendado: max-age=63072000; includeSubDomains; preload (dois anos, todos os subdomínios, lista preload). Cuidado ao ativar, uma má configuração não é reversível enquanto o max-age corre.
- CAA (Certification Authority Authorization): Registo DNS que define quais CAs podem emitir certificados para o seu domínio. Exemplo: 'kernelhost.com. CAA 0 issue "letsencrypt.org"' previne emissão indevida por outras CAs.
- OCSP stapling: O servidor web entrega ele próprio a resposta de revogação da CA, em vez de cada navegador perguntar separadamente à CA. Mais rápido para os visitantes e mais leve para a infraestrutura da CA. Apache: SSLUseStapling On, nginx: ssl_stapling on.
Privacidade
O KernelHost SSL Checker corre inteiramente no nosso nó de Frankfurt, sem chamadas a terceiros:
- Sem reencaminhamento da entrada para APIs externas (sem SSL Labs, Hardenize ou Cryptomon).
- Sem armazenamento do domínio verificado para além do logging de pedidos padrão (log do servidor web, retenção de 14 dias).
- Filtro anti-SSRF bloqueia pedidos para gamas de IP privadas, loopback e link-local.
- Rate limit por IP contra abuso. hCaptcha opcional no submit.