🚀 A CloudSEK se torna a primeira empresa de segurança cibernética de origem indiana a receber investimentos da
Leia mais
Um scanner SSL abre uma conexão criptografada real com um host e avalia tudo o que observa: o certificado apresentado, as versões de protocolo aceitas e os conjuntos de cifras oferecidos. Ele responde se um site pode ser confiável para um cliente limpo, se a criptografia por trás dessa confiança está atualizada e quanto tempo falta para o certificado expirar.
A pressão sobre essa última questão mudou drasticamente durante 2025 e 2026. O CA/Browser Forum aprovou o Ballot SC-081v3 em abril de 2025, reduzindo a validade máxima de certificados públicos de 398 dias para 200 dias em março de 2026, 100 dias em março de 2027 e 47 dias até março de 2029. O rastreamento manual de renovações deixou de ser viável em algum ponto desse cronograma, o que desloca o risco real de um lembrete esquecido para a falha silenciosa da automação de renovação.
A varredura é uma medição ativa, e não uma consulta de registros, porque as respostas vêm do próprio comportamento do servidor durante um handshake.
Suporte e imposição são medições diferentes, e a distinção é importante em todo o processo. Um servidor que suporta TLS 1.3, mas ainda aceita TLS 1.0, não eliminou o risco, porque um invasor capaz de influenciar a negociação solicitará a opção mais fraca.
O certificado é o documento de identidade de um site, e um scanner lê todos os campos que um navegador leria.
Um certificado expirado é uma interrupção, não apenas um aviso. Todos os visitantes encontram um aviso de tela cheia do navegador simultaneamente, e clientes de API que validam certificados param de se conectar sem que ninguém perceba. Os scanners relatam os dias restantes em todos os ativos descobertos, o que se torna mais importante à medida que as janelas de validade diminuem.
Um certificado deve ser fornecido com a cadeia completa de intermediários que o vincula a uma raiz confiável. Navegadores corrigem a falta de um intermediário buscando-o automaticamente, mas clientes de API e aplicativos móveis não fazem isso; portanto, uma cadeia incompleta produz falhas que parecem intermitentes e dependentes do navegador.
O certificado deve cobrir o nome do host que está servindo, listado em seu campo de Nomes Alternativos do Assunto (SAN). Incompatibilidades surgem após uma migração ou quando um certificado curinga é estendido para nomes que ele não cobre, e cada uma delas quebra a confiança para um cliente configurado corretamente.
Certificados de autoridades não confiáveis ou autoassinados falham na validação, independentemente da força da chave subjacente. Os scanners verificam a confiança do emissor e o status de revogação por meio de OCSP e listas de revogação de certificados, embora a maioria dos navegadores ignore falhas na verificação de revogação, o que é parte do motivo pelo qual o setor migrou para tempos de vida mais curtos.
A redução da validade é a mudança operacional mais importante na gestão de certificados na última década, e ela ocorre em um cronograma fixo, em vez de ser apenas uma recomendação.
As práticas de varredura mudam de duas maneiras específicas como resultado. A descoberta torna-se mais crítica do que o rastreamento, porque um certificado que nunca foi inventariado pode expirar silenciosamente e derrubar um serviço. Ao mesmo tempo, o modo de falha muda do esquecimento humano para a quebra da automação, portanto, a varredura deve confirmar que as renovações realmente ocorreram, em vez de apenas verificar se os lembretes foram enviados.
O alcance do novo cronograma é mais restrito do que a maioria das manchetes sugere. O cronograma rege certificados publicamente confiáveis emitidos por autoridades em programas raiz de navegadores. A PKI interna privada não se enquadra nisso, portanto, as organizações podem continuar emitindo certificados de longa duração para serviços internos.

Um certificado válido ainda pode estar em uma conexão fraca. O TLS 1.0 e 1.1 foram formalmente descontinuados pelo IETF em 2021, e a orientação do NIST sobre TLS define o TLS 1.2 como a versão mínima aceitável, com suporte esperado para o TLS 1.3. A adoção permanece incompleta: a análise da CloudSEK sobre configuração incorreta de SSL cita dados do Qualys SSL Pulse que colocam o suporte ao TLS 1.3 em 75,3% em 150.000 sites populares em junho de 2025, deixando cerca de um quarto dos principais sites com configurações mais antigas.
A enumeração aplica-se aos conjuntos de cifras exatamente como às versões de protocolo. Os scanners sinalizam RC4 e 3DES imediatamente, juntamente com construções mais antigas em modo CBC e qualquer conjunto que não possua sigilo de encaminhamento (forward secrecy). Oferecer um conjunto fraco ao lado de conjuntos fortes não oferece proteção, pois a negociação pode ser direcionada para a opção mais fraca que ambos os lados aceitam.
Ataques nomeados remontam a fraquezas específicas que uma varredura detecta. O POODLE explora o preenchimento (padding) do SSLv3, o BEAST tem como alvo cifras CBC no TLS 1.0 e o ROBOT abusa de implementações de troca de chaves RSA. Cada um permanece explorável apenas onde a configuração subjacente persiste, o que torna a enumeração de protocolos e cifras algo que vale a pena executar em vez de apenas presumir.

Os logs de Transparência de Certificados registram cada certificado emitido por uma autoridade publicamente confiável, e monitorá-los responde a uma pergunta que nenhuma verificação local pode: alguém obteve um certificado para este domínio que a organização nunca solicitou?
Uma entrada inesperada sinaliza um erro da autoridade certificadora ou uma tentativa ativa de falsificação, e ela aparece nos logs antes que o certificado seja usado contra alguém. Combinar o monitoramento de CT com um registro CAA fecha o ciclo, já que o registro DNS restringe quais autoridades podem emitir e o log revela quem o fez. Certificados obtidos para domínios semelhantes aparecem da mesma forma, o que torna os logs de CT uma fonte de detecção para spoofing de domínio assim como para emissão indevida. Quando um certificado fraudulento já atende a um site falso, a remoção ocorre por meio de um takedown de domínio solicitação, com o padrão mais amplo coberto por imitação de marca.

As descobertas agrupam-se em um conjunto previsível, e cada uma corresponde a uma interrupção ou a um risco de interceptação.
A varredura mede o que um servidor apresenta, o que deixa várias coisas fora do seu alcance.
A propriedade torna-se complicada sempre que está envolvida uma infraestrutura partilhada. Os certificados fornecidos por uma CDN ou balanceador de carga pertencem a uma configuração que a organização não controla, pelo que uma descoberta de protocolo fraco requer um ticket para o fornecedor em vez de uma correção interna. Os scanners leem a configuração em vez da implementação, pelo que um servidor com protocolos atuais e cifras fortes ainda pode executar uma biblioteca que contém uma vulnerabilidade conhecida que apenas a verificação ao nível de patches deteta.
Tudo o que uma varredura reporta depende do que a descoberta encontrou primeiro. Um scanner reporta sobre os hosts para os quais está apontado, e os certificados que causam interrupções residem em ativos que ninguém inventariou, razão pela qual a monitorização de certificados funciona melhor como parte de uma descoberta externa contínua do que como uma verificação isolada.
Um pequeno conjunto de hábitos transforma os resultados da varredura em menos interrupções e menos risco de interceptação.
Os certificados expiram de acordo com o seu próprio cronograma, sem que ninguém precise implementar nada, o que torna este um problema de monitorização antes de ser um problema de configuração. CloudSEK BeVigil executa a digitalização SSL como uma das oito superfícies monitorizadas, descobrindo ativos voltados para a internet e os certificados que os servem, rastreando a expiração, testando protocolos obsoletos e cifras fracas, e sinalizando cadeias incompletas.
A descoberta é o que diferencia isto de um verificador de certificados. A plataforma revela a exposição de certificados em toda a infraestrutura, em vez de apenas nos ativos que uma equipa se lembra de verificar, que é a mesma razão pela qual a gestão da superfície de ataque externa trata certificados e registos DNS como uma única superfície de exposição. Ambas as camadas falham juntas com frequência suficiente para que avaliá-las separadamente resulte na perda de descobertas compostas, como um subdomínio esquecido que utiliza um certificado expirado.
A gestão de certificados costumava ser uma tarefa anual com uma margem de erro confortável. Um limite de 200 dias já elimina o ritmo anual, e o cronograma futuro comprime-o ainda mais, pelo que as práticas que funcionavam com 398 dias deixarão de funcionar antes de 2029.
O que sobrevive a essa transição é a automação aliada à verificação. A emissão automatizada lida com a frequência, e a digitalização contínua confirma que funcionou, porque a falha silenciosa de um pipeline de renovação produz o mesmo resultado que o esquecimento: um aviso de ecrã inteiro para todos os visitantes ao mesmo tempo.
Um verificador testa um único host mediante solicitação. Um scanner descobre ativos em toda a infraestrutura e, em seguida, testa todos os certificados que encontra, incluindo aqueles em hosts que ninguém inventariou.
Não. Um certificado comprova a identidade e permite a encriptação. Não diz nada sobre a força do protocolo, a configuração da cifra ou se o site em si é legítimo.
A verificação de revogação não é fiável porque os navegadores ignoram falhas nela. Uma validade mais curta limita o tempo durante o qual um certificado comprometido ou emitido incorretamente permanece utilizável.
Sim, por meio do monitoramento de logs de Transparência de Certificados. Qualquer certificado de uma autoridade publicamente confiável aparece nos logs, incluindo aqueles que o proprietário do domínio nunca solicitou.
Não. O cronograma do CA/Browser Forum rege apenas certificados publicamente confiáveis. PKIs internas privadas podem continuar emitindo certificados com prazos de validade mais longos.
Versões de protocolo aceitas, conjuntos de cifras oferecidos, integridade da cadeia, cobertura de nome de host, status de revogação e entradas de Transparência de Certificados para o domínio.
