GlobalSign Revoga 20.000 Certificados: Um Guia Abrangente para o Impacto na Web Russa

Na última semana, o cenário da web russa foi abalado por duas mudanças significativas. Em 13 de junho, a GlobalSign, uma das maiores autoridades certificadoras (CAs) do mundo, iniciou uma revogação em massa de certificados para empresas russas, afetando potencialmente até 20.000 domínios de segundo nível, segundo estimativas do mercado. Paralelamente, a Duma Estatal aprovou uma lei que proíbe sites russos de utilizarem serviços de autenticação estrangeiros, levando o Avito a desativar o login via Google em 14 de junho. Este artigo foca no primeiro evento, a revogação de certificados TLS, com um material separado sobre OAuth a ser publicado posteriormente.

Como profissional de infraestrutura e segurança, gerencio cerca de uma dúzia de domínios ativos, todos utilizando Let's Encrypt. Antes de 13 de junho, a autoridade certificadora por trás dos meus certificados era uma preocupação secundária, pois a renovação automática ocorria em segundo plano, sem sequer figurar na documentação da infraestrutura. Agora, estou revisando sistematicamente cada um dos meus sites para avaliar o emissor, os riscos associados, as ações necessárias e a ordem de prioridade para as mudanças. Compartilho aqui minhas descobertas e o plano de ação.

O Que Aconteceu Tecnicamente

A cronologia dos eventos é a seguinte:

• 4 de maio: O CA/Browser Forum atualizou seus requisitos para autoridades certificadoras. De acordo com relatos da mídia, a partir desta data, a verificação de signatários de certificados em listas de sanções tornou-se obrigatória. É importante notar que esta norma específica não foi encontrada na lista pública de votações do consórcio, um fato destacado pela publicação "Teplitsa Social Technologies". Portanto, a afirmação de "novas regras do CA/B Forum" deve ser tratada com cautela, pois não é confirmada pela fonte primária.
• 4 de junho: A Let's Encrypt publicou uma nova versão de seus Termos de Serviço (LE-SA v1.7). Nela, foram formalizadas as restrições de sanções: certificados não serão emitidos para residentes de países sob sanções abrangentes dos EUA e para empresas listadas pelo OFAC. A própria Let's Encrypt, em comentários no Hacker News e para o Ministério da Digitalização russo, enfatiza que para a maioria dos usuários russos nada muda, pois isso apenas formaliza uma prática já existente. Assim, sites comerciais e pessoais comuns continuarão a ser renovados normalmente.
• 6 de junho: O primeiro precedente notório ocorreu. O certificado do mensageiro MAX foi revogado. A Let's Encrypt emitiu uma substituição no mesmo dia, mas alertou que não o faria mais após 4 de setembro.
• 13 de junho: A GlobalSign, a maior autoridade certificadora comercial no mercado russo, iniciou a revogação forçada de certificados para empresas russas. Estimativas de participantes do mercado de hospedagem e segurança da informação indicam que isso afetará até 20.000 domínios de segundo nível; considerando subdomínios, o número pode chegar a centenas de milhares de certificados. A GlobalSign detinha cerca de 90% do mercado comercial russo.
• Paralelamente: A ZeroSSL, a segunda provedora ACME de certificados gratuitos mais popular depois da Let's Encrypt, também formalizou restrições de sanções, segundo relatos do mercado. Isso significa que "fugir" da Let's Encrypt para a ZeroSSL não é uma estratégia viável para todos.

De acordo com dados da W3Techs de junho de 2026, a distribuição no mercado é a seguinte: 68,2% dos sites são assinados pela Let's Encrypt, 20,4% pela GlobalSign. Os restantes 11% são de todas as outras autoridades certificadoras combinadas. Portanto, a revogação da GlobalSign não é apenas "uma CA fechando um serviço", mas um golpe em um quinto do mercado global de certificados.

Quem Está Realmente em Risco e em Que Ordem

Esta é a seção mais crucial. A migração de uma CA para outra pode levar meia hora, mas antes de mudar, é preciso entender quem está em chamas e quem está apenas conversando.

• Risco Agudo: Entidades legais sob sanções – estruturas russas listadas pelo OFAC, órgãos governamentais, organizações que formalmente se enquadram nas sanções completas dos EUA. Para elas, a nova versão do LE-SA não é uma formalidade, mas um bloqueio. Certificados não serão renovados. Incluem-se aqui todos que atualmente possuem um certificado GlobalSign, independentemente do tamanho ou jurisdição; eles estão na primeira onda de revogação forçada. O prazo é agora.
• Alto Risco, Janela de Semanas e Meses: Sites para os quais o provedor de cliente na verificação DV pode parecer sancionado. Nem sempre é óbvio – formalmente, isso pode não ser determinado pelo nome de domínio. O precedente MAX mostrou que a Let's Encrypt pode emitir uma substituição, mas com um aviso explícito sobre o prazo. Ou seja, "acabamos de receber um certificado" não significa "não seremos desconectados após 4 de setembro".
• Risco Médio: Sites comerciais comuns na Let's Encrypt – nenhuma parte do texto do acordo os aponta formalmente. No entanto, se os EUA expandirem suas listas de sanções e incluírem um provedor de hospedagem, um registrador de domínio ou o usuário final do serviço, qualquer componente da cadeia pode se tornar um gatilho. O prazo é indefinido – é preciso acompanhar as notícias e ter um plano de contingência.
• Baixo Risco, Mas Monitorar: Projetos pessoais e "pet projects" na Let's Encrypt – praticamente nada deve mudar. De acordo com as declarações da Let's Encrypt, restrições não ameaçam usuários privados comuns. A lógica aqui é "não entrar em pânico, mas também não ignorar", ou seja, preparar, mas não agir precipitadamente.

Meu próprio conjunto de dez sites foi classificado nessas quatro categorias. O resultado foi: zero na zona de risco agudo (não trabalhamos com entidades sancionadas), zero na GlobalSign (Let's Encrypt em todos os lugares), quatro em risco médio (sites comerciais de clientes que hipoteticamente podem ser incluídos em sanções expandidas), seis em baixo risco. Isso muda a prioridade: não "mudar urgentemente", mas "preparar um emissor paralelo e um cenário de migração".

Alternativas à Let's Encrypt em Junho de 2026

Uma introdução importante. Pessoalmente, ainda não trabalhei com esses provedores – todos os nossos certificados estão na Let's Encrypt. Esta seção é uma visão técnica do que está disponível no mercado e da compatibilidade com o stack ACME típico. Sem pretensão de experiência própria. Quando eu chegar à migração e verificar cada um em sites de produção, escreverei separadamente.

O Que Saiu, Embora Muitos Guias Ainda Apontem Para Isso

• Buypass Go SSL: Anteriormente uma alternativa padrão à Let's Encrypt: uma autoridade certificadora norueguesa, ACME gratuito, até 20 certificados por domínio registrado por semana. Em agosto de 2025, a Buypass anunciou o fim da emissão de certificados TLS. Novos certificados não são emitidos desde 15 de outubro de 2025, e o registro de novas contas ACME foi interrompido em 15 de setembro de 2025. Até 15 de abril de 2026, todos os certificados emitidos anteriormente expiraram e o serviço ACME foi encerrado. Como substituição, foi anunciada a Buypass GoTLS – parcialmente gratuita com limites rígidos, o modo principal é pago. Em meados de junho de 2026, este serviço ainda está em fase de lançamento. Portanto, o conselho popular "vá da Let's Encrypt para a Buypass" não funciona em 2026 – Buypass Go, em sua forma atual, não existe.
• ZeroSSL: Até recentemente, era o segundo provedor ACME gratuito mais popular. Segundo relatos do mercado, formalizou restrições de sanções paralelamente à Let's Encrypt. Ou seja, não é uma solução para entidades sancionadas, e para todos os outros, o risco é o mesmo.

O Que Está Realmente Disponível

• Google Trust Services Public CA: Autoridade certificadora pública gratuita do Google. Emite certificados DV via ACME, suporta wildcard, validade de 90 dias. Funciona não através de uma conta anônima, mas vinculada a um projeto do Google Cloud: é necessário criar um projeto, habilitar a API Public Certificate Authority, gerar um par de chaves EAB (External Account Binding) e registrar uma conta ACME com este EAB. Para acme.sh e Certbot, é um procedimento padrão com parâmetros adicionais --eab-kid e --eab-hmac-key. Para Caddy, é a especificação do servidor ACME https://dv.acme-v02.api.pki.goog/directory mais o EAB no bloco tls. A confiança do navegador é completa, nada precisa ser instalado. Risco geopolítico: a empresa é americana, e se as sanções atingirem o Google Cloud – a mesma história que com a Let's Encrypt se repetirá. Mas hoje, é uma opção funcional.
• SSL.com: Autoridade certificadora comercial americana com suporte ACME para planos pagos. Adequada como emissor de backup, mas não gratuita. Os planos começam em algumas dezenas de dólares por ano por domínio.
• Cloudflare Universal SSL: Um cenário separado: certificados gratuitos emitidos pela Cloudflare em nós de edge, se o site já estiver sendo proxy por meio da Cloudflare. Não é um provedor ACME no sentido direto – o certificado fica no ponto final da Cloudflare, e a comunicação com o servidor Cloudflare ocorre por meio de seu próprio protocolo (Origin Certificate ou Authenticated Origin Pulls). A abordagem requer a reconfiguração do tráfego através da CDN – nem sempre é uma opção, especialmente se o cliente tiver carga WebSocket ou requisitos rígidos de geografia de roteamento.

Autoridades Certificadoras Russas

• NÚC do Ministério da Digitalização (NUЦ Минцифры): Autoridade Certificadora Nacional baseada no NII "Voskohod". Emite certificados DV e OV gratuitos através do portal Gosuslugi. A principal limitação é a confiança do navegador. Certificados do NÚC estão embutidos no Yandex Browser e Atom. No Chrome, Firefox, Safari, Edge – não estão embutidos; o usuário deve instalar manualmente o certificado raiz do NÚC no armazenamento do sistema ou no armazenamento do navegador. Para um site comercial com audiência em massa, isso ainda não funciona sozinho – parte dos usuários verá um aviso "conexão insegura". Faz sentido como um emissor paralelo com instruções para os usuários, mas não como substituto do principal CA ocidental.
• Centros russos pagos via revendedores: Serviços vinculados a autoridades certificadoras russas através de revendedores comerciais – emitem certificados com confiança global através de acordos de parceria com CAs estrangeiras. No contexto da revogação em massa da GlobalSign, sua capacidade de emissão permanece em questão. As taxas atuais são de 8.000 a 30.000 rublos por ano por domínio, dependendo do tipo.

Plano de Inventário que Estou Aplicando em Dez Sites

Esta é a parte que estou realmente fazendo nestes dias. Os passos são simples, mas exigem disciplina – sem uma tabela, você rapidamente perde o controle do que tem onde.

• Passo 1. Lista Completa: Abro uma tabela comum. Na primeira coluna – o domínio. Na segunda – quem hospeda. Na terceira – quem emitiu o certificado atual. Na quarta – data de expiração. Na quinta – categoria de risco de acordo com o mapa da terceira seção. Para cada domínio, obtenho o certificado via openssl e verifico o campo Issuer:

  bash
  echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
    | openssl x509 -noout -issuer -dates

  Obtenho algo como:

  issuer=C = US, O = Let's Encrypt, CN = R10
  notBefore=Apr 10 12:14:32 2026 GMT
  notAfter=Jul  9 12:14:31 2026 GMT
  

  Registro na tabela. Para dez sites, isso leva cerca de quinze minutos.

• Passo 2. Verificação Cruzada via CT-Logs: Não confio em uma única linha do openssl. Um certificado pode ser recente, mas em paralelo pode existir outro, emitido por alguém que não me lembro – por exemplo, durante um experimento pontual com CDN ou um painel de controle de hospedagem alternativo. Para isso, existe o Certificate Transparency (CT): cada certificado público é publicado em servidores de log abertos. Abro o crt.sh e verifico cada domínio: https://crt.sh/?q=example.com Verifico quais issuers emitiram certificados historicamente. Se na lista houver apenas Let's Encrypt – normal. Se houver GlobalSign, Sectigo, DigiCert – sinal de alerta, investigo quem e por que encomendou, se está ativo, se não se tornará um problema em um mês.

• Passo 3. Agrupamento e Prioridades: Após os passos 1 e 2, tenho uma tabela preenchida. Para meus dez sites, o resultado foi:

  • Quatro sites comerciais de clientes em risco médio – para eles, faz sentido preparar um emissor de backup (Google Trust Services como paralelo), mas ainda não mudar.
  • Seis sites em baixo risco – apenas monitoramento. Ou seja, dos dez sites, nada precisa ser alterado hoje. É preciso preparar a infraestrutura para que a mudança leve minutos, não horas, caso aconteça amanhã.

• Passo 4. Emissor de Backup em Sistemas Críticos: O Caddy permite especificar vários provedores ACME em ordem de fallback. Bloco mínimo no Caddyfile:

  caddy
  example.com {
      tls {
          issuer acme {
              dir https://acme-v02.api.letsencrypt.org/directory
          }
          issuer acme {
              dir https://dv.acme-v02.api.pki.goog/directory
              eab {
                  key_id YOUR_EAB_KID
                  mac_key YOUR_EAB_HMAC_KEY
              }
          }
      }
      reverse_proxy upstream:3000
  }

  O Caddy primeiro tenta o primeiro emissor e, se não conseguir obter um certificado, passa para o segundo. Útil como seguro: se a Let's Encrypt parar de responder para um domínio específico, o Caddy mudará automaticamente para o Google. Para sites de clientes onde o Caddy não está instalado e é usada a combinação nginx + certbot, o equivalente é montado com dois certificados separados de duas CAs, que ficam lado a lado em /etc/letsencrypt/live/, e um script wrapper fino sobre o certbot, que, em caso de falha na renovação com um CA, tenta o segundo e substitui o symlink na configuração do nginx. Não é difícil no papel, mas precisa ser testado em produção.

• Passo 5. Monitoramento via CT-Logs: O mais útil é acompanhar os novos certificados que estão sendo emitidos para seus domínios. Se alguém emitir um certificado para o seu domínio sem o seu conhecimento, ou se uma CA emitir uma substituição que você desconhece, os CT-logs mostrarão isso. Ferramentas gratuitas:

  • crt.sh – busca por domínio, permite configurar um feed RSS de novos certificados.
  • certstream.calidog.io – fluxo em tempo real de todos os certificados que entram nos CT-logs. É fácil escrever um filtro para seus domínios – um script Python de dez linhas que envia uma notificação para o Telegram quando um certificado aparece para os domínios listados.
  • Facebook CT Monitoring – notificações por e-mail via API. Instalo um feed RSS do crt.sh para cada domínio – dez deles em um leitor RSS, verifico uma vez por semana.

O Que Planejo Para o Futuro

Até o final do verão de 2026, espero duas coisas. A primeira – a expansão da lista de CAs que formalizam restrições de sanções; outros centros certificadores globais podem se juntar à Let's Encrypt e ZeroSSL, para eles é uma questão de sobrevivência jurídica. A segunda – pressão interna do estado para a transição de sites comerciais para certificados do NÚC. O Ministério da Digitalização e os maiores bancos já estão incentivando os usuários a instalar o certificado raiz do NÚC no sistema; o próximo passo – recomendações (ou requisitos) para os proprietários de sites emitirem certificados paralelos do NÚC.

Até o final de agosto, darei o próximo passo: em dois domínios de teste da minha lista, implementarei certificados paralelos através do Google Trust Services e do NÚC. Depois disso, escreverei um material separado com a prática real – o que funcionou, quais foram as armadilhas, como os navegadores se comportam com dois certificados simultaneamente e o que exatamente eles mostram para usuários diferentes.

E uma história separada – a lei que proíbe sites russos de se autenticarem através de serviços estrangeiros. Em nossos sites de agência, o login via Google estava configurado em vários projetos de clientes, e agora isso precisa ser refeito. Este é o segundo ramo de mudanças de infraestrutura que estão impactando a web russa em junho de 2026 – sobre isso será o próximo artigo.

Se você atualmente possui um certificado GlobalSign, esta é a primeira onda, é preciso agir nos próximos dias. Se você usa Let's Encrypt e não é uma entidade sancionada – há tempo suficiente, mas vale a pena fazer a auditoria agora, enquanto os CT-logs podem ser lidos calmamente, e não em modo de combate a incêndio urgente.