Comprometimento das chaves da CA eMudhra: o que as empresas devem verificar e corrigir agora

No sábado, 17 de outubro de 2026, um investigador de segurança comunicou que oito autoridades de certificação intermédias geridas pela eMudhra, uma autoridade de certificação (CA) indiana, tinham chaves privadas que qualquer pessoa podia calcular a partir dos certificados públicos. Todas essas chaves eram números inferiores a 256. Uma delas era o número 4. Seis das oito podiam emitir certificados TLS aceites como fidedignos pela Apple, pela Google, pela Microsoft e pela Mozilla; as outras duas podiam assinar software para Windows.

O Chrome bloqueou as seis chaves TLS uma hora e quarenta minutos depois da comunicação, e o Firefox na mesma noite. Para quem navega na web, o perigo estava ultrapassado no sábado à noite.

Para tudo o resto, não estava. Servidores, contentores, aplicações Java, scripts Python, integrações de pagamento e dispositivos conectados verificam os certificados com base na sua própria cópia da lista de autoridades de confiança, e a maior parte dessas cópias só muda quando alguém instala uma atualização. Até lá, um certificado para qualquer domínio assinado com uma destas chaves passa por autêntico, e as chaves são públicas desde 20 de outubro.

Na mesma semana, a GoDaddy começou a revogar 404 607 certificados, porque as informações de política que continham não correspondiam aos seus próprios documentos publicados. Os clientes tiveram de descarregar e instalar eles próprios os certificados de substituição.

Este guia destina-se a quem tem de responder à pergunta «somos afetados?»: responsáveis de TI e de operações, CTO e fundadores cujo negócio assenta num site, numa API ou num produto conectado. Explica o que aconteceu, com base nos registos do incidente publicados pela Mozilla, pela Google, pela eMudhra, pela GoDaddy e pelos fornecedores de software; o que verificar hoje; o que atualizar esta semana; e o que pôr em prática para que o próximo incidente deste tipo seja rotina. Tudo o que aqui se diz corresponde à situação a 22 de outubro de 2026, e o incidente continua em aberto.

O que aconteceu

A eMudhra criou os oito intermédios numa cerimónia de chaves a 30 de abril de 2025. A versão da empresa, publicada a 19 de outubro no bug do incidente na Mozilla: um teste de um passo de encapsulamento e desencapsulamento de chaves (key wrap e unwrap), aprovado como desvio ao procedimento habitual, tinha uma falha que criou um segundo conjunto de chaves, fracas, no módulo de segurança de hardware, ao lado das chaves previstas. As etiquetas eram parecidas, as chaves fracas foram usadas por engano para criar os pedidos de certificado, e a raiz da eMudhra assinou-os. Os mesmos pedidos foram enviados à Sectigo, que fez a assinatura cruzada dos oito a partir da sua raiz AAA Certificate Services a 14 de maio de 2025. A eMudhra diz que «ainda não confirmou a causa raiz exata».

A Mozilla descreveu o resultado: «As chaves privadas P384 são inteiros escolhidos aleatoriamente entre 1 e a ordem do grupo. As 8 chaves afetadas usavam todas inteiros inferiores a 256.» A Mozilla recebeu a comunicação às 20:06 UTC e recuperou ela própria as chaves às 21:48, «sem qualquer conhecimento do método usado por quem fez a comunicação original». O investigador diz que as encontrou com a biblioteca de código aberto paranoid_crypto, da Google, «tal como vem de origem». As chaves fracas fizeram parte de cadeias com confiança pública durante quase 18 meses.

Os oito certificados:

Cada chave está em dois certificados. Um foi emitido pela emSign Root TLS CA - G3 ou pela emSign Root CS CA - G3 da eMudhra, cuja cadeia termina na emSign ECC Root CA - G3; o outro é o certificado cruzado da Sectigo, emitido a partir da AAA Certificate Services. O segundo caminho é importante, porque alguns trust stores que nunca incluíram uma raiz da eMudhra continuam a confiar nessa antiga raiz da Sectigo.

Houve algum ataque?

Ninguém comunicou qualquer utilização abusiva e, no caso dos browsers, há boas razões para pensar que não houve nenhuma. O Chrome, tal como outros clientes que exigem a Certificate Transparency (CT), só aceita um certificado se este tiver sido registado nos logs públicos de CT. Segundo a Google, não foi registado nenhum certificado TLS com cadeia até estes seis intermédios antes do bloqueio, pelo que «nenhum certificado fraudulento emitido por estas CA poderia ter sido usado contra clientes que exigem a CT».

Fora do browser, o cenário é diferente. Diz a página do incidente da Mozilla: «muitos clientes fora do ecossistema dos browsers não exigem a Certificate Transparency. Não sabemos se houve atacantes a explorar a falha na geração de chaves para visar esses clientes.» Essa janela abriu-se na primavera de 2025 e só se fecha, em cada cliente, quando este é atualizado. A eMudhra diz não ter conhecimento de qualquer indício de que as chaves tenham sido recuperadas antes da divulgação, e a Cloudflare diz que a sua análise não encontrou exploração ativa nos seus serviços.

Agora que as chaves são públicas, forjar um certificado não exige qualquer competência. A página do incidente da Mozilla indica servidores de teste que apresentam certificados emitidos com as chaves comprometidas, para que qualquer pessoa possa testar os seus clientes com eles (os comandos estão mais abaixo).

O que um certificado forjado permite: alguém que consiga intercetar o tráfego entre o seu software e um serviço que ele chama (numa rede partilhada, através de um router comprometido ou de uma resposta DNS envenenada) pode fazer-se passar por esse serviço, ler o que o seu software envia, incluindo chaves de API e dados pessoais, e alterar o que ele recebe. Software assinado com uma das duas chaves de assinatura de código teria passado a verificação de assinaturas do Windows até o bloqueio da Microsoft chegar à máquina.

Quem é afetado

Há três problemas distintos, e uma empresa pode ter os três.

1. Software que ainda confia nas chaves comprometidas

Quase todas as empresas têm este: qualquer programa que faça chamadas HTTPS, cujo trust store ainda contenha a emSign ECC Root CA - G3 ou a AAA Certificate Services e que não tenha recebido um bloqueio das oito chaves. Os sítios habituais:

• Servidores Linux e imagens de contentor construídas antes de 20 ou 21 de outubro. Um Debian 12 sem atualizações, por exemplo, confia nas duas cadeias.
• Runtimes de linguagens que trazem a sua própria lista: Node.js, o certifi do Python, o cacerts do Java, o bundle do Composer no PHP, o webpki-roots do Rust.
• Ferramentas de linha de comandos do macOS. A página do incidente da Mozilla diz que o curl, o git, o python3, o perl, o ruby e o openssl incluídos no sistema verificam os certificados com base em /etc/ssl/cert.pem sem verificar a revogação, e que a Apple não atualizou esse ficheiro.
• Máquinas Windows que não recebem as atualizações automáticas da Microsoft à sua lista de certificados não permitidos, normalmente porque a Política de Grupo as desativa ou porque a rede está offline.
• Appliances, dispositivos e software de terceiros que trazem o seu próprio ficheiro de CA, como balanceadores de carga, gateways VPN, SDK e controladores embebidos.

Cada runtime tem de ser verificado separadamente. Num teste que fizemos a 22 de outubro, uma máquina Debian 12 sem atualizações, com o Node.js 24.18, aceitou a cadeia que termina na raiz da eMudhra e rejeitou a que termina na da Sectigo, enquanto o Python, na mesma máquina, aceitou as duas.

2. Empresas cujos próprios certificados têm cadeia até à raiz retirada

A Mozilla e as distribuições Linux retiraram a emSign ECC Root CA - G3, e o Chrome segue-se a 27 de outubro. Os certificados válidos sob essa raiz deixam de funcionar em cada cliente à medida que este é atualizado. A instrução da Google: os operadores de sites com certificados destes «têm de obter e instalar de imediato um novo certificado TLS de outra hierarquia PKI incluída no Chrome Root Store».

O Chrome contou nos logs de CT, a 21 de outubro, cerca de 30 800 certificados não expirados sob essa raiz. Destes, 30 791 vinham de dois intermédios do InCommon, o serviço de certificados que a Internet2 gere para universidades e instituições de investigação dos EUA, e que emite certificados ECC através do CERTInext, a plataforma da eMudhra. E 18 vinham dos próprios intermédios da eMudhra. A eMudhra diz que cerca de 30 000 certificados precisam de ser migrados, cerca de 97 % dos quais emitidos através de ACME, e que está a emitir substitutos a partir de outra hierarquia.

Se o seu site está atrás da Cloudflare no modo Full (strict) e a origem apresenta um certificado sob esta raiz, a Cloudflare diz que a retirada de confiança «causaria falhas», e pede aos clientes: «Revejam os seus certificados de origem personalizados e as configurações dos servidores».

Os certificados RSA da outra raiz da eMudhra, a emSign Root CA - G1, não foram afetados até agora. A Mozilla diz que não vai retirar essa raiz «neste momento»; o Chrome está «a analisar atentamente a continuidade da inclusão dos restantes certificados de CA da eMudhra». Se depende de certificados da eMudhra ou do CERTInext, de qualquer tipo, garanta já uma segunda autoridade de certificação.

3. Clientes da GoDaddy

O caso da GoDaddy nada tem a ver com a eMudhra, mas surgiu na mesma semana e atingiu muitos mais sites. A 15 de outubro, a GoDaddy comunicou à Mozilla que os certificados das suas hierarquias GoDaddy e Starfield continham informações de política de certificado (OID de política e links para a CPS) que não correspondiam aos perfis da sua própria CP/CPS, o documento em que uma autoridade de certificação declara o que emite. Não se trata de uma falha de segurança nos certificados. Ainda assim, ao abrigo dos Baseline Requirements, as regras que todas as autoridades de certificação públicas seguem, é motivo para os revogar no prazo de cinco dias.

Foram afetados 404 607 certificados, 396 055 dos quais com validação de domínio. A GoDaddy revogou 170 566 até ao fim do prazo, a 18 de outubro às 23:45 UTC, e 227 422 até à manhã seguinte; o seu aviso aos clientes diz que os restantes foram revogados a 21 de outubro. A GoDaddy volta a emitir os certificados, mas instalá-los cabe ao cliente: «os visitantes do seu site podem ver avisos de segurança, e o seu site pode ficar inacessível até ser instalado um novo certificado».

O que verificar hoje

1. O que enviam os seus próprios servidores? Para cada hostname público, liste os emissores da cadeia que ele apresenta:

h=www.example.com
openssl s_client -connect "$h:443" -servername "$h" -showcerts </dev/null 2>/dev/null | grep -E '^ +i:'

Uma linha que mencione a eMudhra, emSign, uma das autoridades EM ... G3B ou G3C, ou InCommon Intermediate CA - DVG3C, OVG3C ou EVG3C significa que o certificado tem de ser substituído antes de 27 de outubro. A AAA Certificate Services, sozinha, é normal, porque muitas cadeias comuns da Sectigo ainda a incluem. Para serviços de correio e de diretório, acrescente -starttls smtp (ou imap, ldap) e a porta certa. Inclua servidores internos, balanceadores de carga e origens atrás de uma CDN.

2. O que foi emitido para os seus domínios? A CT lista todos os certificados que uma autoridade de certificação pública emitiu para os seus nomes, incluindo os que ninguém na empresa se lembra de ter pedido:

curl -s 'https://crt.sh/?q=%25.example.com&output=json&exclude=expired' | jq -r '.[].issuer_name' | sort | uniq -c

O resultado mostra também que autoridades de certificação a sua empresa usa de facto, que é o ponto de partida do inventário descrito mais abaixo.

3. Os seus clientes confiam nas chaves comprometidas? Os servidores de teste da Mozilla apresentam certificados emitidos com as chaves comprometidas, por isso um erro de certificado é o bom resultado. Teste as duas famílias: o primeiro servidor tem cadeia até à raiz da eMudhra, o segundo até à da Sectigo, e o mesmo trust store pode rejeitar um e aceitar o outro.

curl -sS -o /dev/null https://dv-g3b-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"
curl -sS -o /dev/null https://dv-g3b-aaa-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"

O curl só responde pelo curl. Faça o mesmo pedido através da pilha TLS de cada aplicação, no ambiente em que a aplicação corre:

node -e "require('https').get('https://dv-g3b-emudhra.we-have-a-problem.com/', () => console.log('TRUSTED')).on('error', e => console.log('rejected:', e.code))"
python3 -c "import urllib.request; urllib.request.urlopen('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"
python3 -c "import requests; requests.get('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"

As duas linhas de Python não são redundantes: o urllib usa o trust store do sistema operativo, o requests usa o certifi. Repita cada linha com o servidor dv-g3b-aaa-emudhra. Para Java, faça uma chamada HTTPS qualquer aos servidores de teste a partir da JVM em causa, e verifique se o seu trust store contém alguma das duas raízes (Java 9 ou posterior; no Java 8 use -keystore $JAVA_HOME/jre/lib/security/cacerts):

keytool -list -v -cacerts -storepass changeit | grep -E 'Owner: .*(emSign ECC Root CA - G3|AAA Certificate Services)'

Uma raiz num trust store não prova, por si só, que há exposição, porque o Go, o Node.js, o Deno e o rustls-webpki do Rust já bloqueiam as oito chaves, independentemente do que diga o trust store. Os servidores de teste tiram as dúvidas.

4. Parques de máquinas Windows. A Microsoft não publicou nada sobre o incidente, mas a lista de certificados não permitidos que o Windows descarrega automaticamente bloqueia as oito chaves desde 20 de outubro. As exceções são as máquinas em que a Política de Grupo desativa a atualização automática de certificados de raiz e as redes sem caminho até ao Windows Update; essas precisam de receber a lista por outra via. certutil -verifyCTL Disallowed mostra a cópia que uma máquina tem em cache. A página do incidente da Mozilla disponibiliza um script para máquinas individuais e diz que «não é recomendado para dispositivos geridos por empresas».

5. Certificados da GoDaddy. Verifique que certificado cada servidor apresenta de facto:

echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -issuer -serial -startdate

Se o emissor for a GoDaddy ou a Starfield, compare o número de série com os certificados da sua conta GoDaddy. Onde a GoDaddy mostrar «Install your new certificate» («Instale o seu novo certificado»), o servidor ainda tem o certificado revogado.

Uma regra para tudo: não faça um erro desaparecer desativando a verificação de certificados. Nas palavras da Cloudflare: «É importante não resolver estes erros desativando a verificação.» Um cliente que não verifica confia em todos os certificados forjados, e não só nestes.

O que atualizar esta semana

Há dois tipos de correção. Retirar as duas raízes fecha todos os caminhos para um cliente que use esse trust store, mas também inutiliza os certificados válidos que estão sob elas. Bloquear as oito chaves pelo hash da chave pública, como fazem o Go, o Node.js, o Deno, o Electron, o rustls-webpki, o Composer e o Windows, fecha a brecha sem estragar mais nada. Onde a sua plataforma oferecer a segunda, prefira-a.

Onde se lê «ainda sem» ou «ainda não», nada tinha sido publicado até 22 de outubro. Volte a verificar antes de fazer planos com base nisso.

Há quatro coisas que apanham as equipas desprevenidas:

• As imagens de contentor mantêm a lista antiga. Uma imagem construída antes de 20 ou 21 de outubro confia nas chaves até ser reconstruída sobre uma imagem base atualizada, e voltar a fazer pull da mesma tag só ajuda depois de a imagem base ter sido reconstruída. Reconstrua, volte a fazer o deploy e pergunte aos fornecedores cujas imagens corre.
• Os processos mantêm o que carregaram. Um programa lê o seu trust store quando arranca, por isso reinicie os serviços de longa duração depois de atualizar. O Node.js acrescenta que as sessões TLS retomadas de antes da atualização não voltam a ser verificadas.
• As aplicações trazem os seus próprios ficheiros de CA. Os SDK e as aplicações incluem muitas vezes um cacert.pem ou ca-bundle.crt próprio. Procure-os nos repositórios e nas imagens, por exemplo com find / -xdev \( -name 'cacert*.pem' -o -name 'ca-bundle*.crt' \) 2>/dev/null, e conte com mais do que um: o pip, por exemplo, traz a sua própria cópia do certifi.
• Os dispositivos esperam pelo fornecedor. Pergunte por escrito a cada fornecedor que trust store o produto usa e quando sai a atualização. Até lá, o dispositivo confia em certificados forjados para todos os serviços que chama, por isso limite aquilo a que ele pode aceder.

Se retirar a AAA Certificate Services à mão, como fazem o Debian, o Ubuntu ESM, o Fedora e a solução alternativa da Red Hat, teste depois as ligações a serviços com certificados da Sectigo: alguns servidores mais antigos ainda enviam uma cadeia que termina nessa raiz.

O que pôr em prática antes do próximo incidente

Uma autoridade de certificação deixar chaves tão fracas é raro. Revogações em massa, nem por isso. Estas são as grandes de 2026 registadas no bug tracker da Mozilla:

Nenhum destes cinco casos foi uma falha de segurança. Em todos, um certificado contradizia o documento da própria autoridade, e os Baseline Requirements (secção 4.9.1.1) exigem mesmo assim a revogação no prazo de cinco dias. Quando uma chave é comprometida, ou quando já não se pode confiar na validação de domínio, o prazo é de 24 horas. Ninguém lho pode prorrogar. Na revogação de 83 267 certificados pela DigiCert, em 2024, o Chrome Root Program escreveu que «não tem autoridade para conceder exceções»; um cliente obteve uma ordem judicial para impedir a revogação dos seus certificados, e a ordem foi anulada quatro dias depois.

A forma como decorreram as substituições diz muito. Em julho, a HARICA usou o ACME Renewal Information (ARI) para pedir ao software ACME dos seus clientes que renovasse mais cedo, e voltou a emitir ela própria outros certificados; na maior das suas duas revogações, 87 % dos nomes afetados já tinham sido substituídos quando o prazo terminou. A GoDaddy, cujos clientes descarregam e instalam eles próprios cada substituto, tinha revogado 42 % dos certificados afetados até ao fim do prazo.

O ciclo de renovação está, de qualquer forma, a encurtar:

• Ao abrigo da votação SC-081 do CA/Browser Forum, os certificados TLS públicos estão limitados a 200 dias desde 15 de março de 2026. O limite desce para 100 dias a 15 de março de 2027 e para 47 dias a 15 de março de 2029, data a partir da qual a validação de domínio só pode ser reutilizada durante 10 dias.
• A Let's Encrypt passa a emitir por defeito certificados de 64 dias a 10 de fevereiro de 2027, e de 45 dias um ano depois.
• Os certificados TLS públicos estão a perder a autenticação de cliente. A Let's Encrypt deixou de a incluir a 8 de julho de 2026, e o Chrome Root Program exige que os certificados emitidos a partir de 15 de março de 2027 sirvam apenas para autenticação de servidor. Se usa certificados públicos como certificados de cliente para TLS mútuo, o que é comum em integrações de API B2B, essas ligações precisam de uma autoridade de certificação privada.

Com 100 dias, e depois com 47, instalar certificados à mão deixa de ser uma opção realista. Uma empresa que automatize para esse calendário fica também preparada para a próxima revogação em massa. O que é preciso:

1. Saiba o que tem, nos dois sentidos. Uma lista de todos os certificados que serve, com hostname, emissor, data de expiração, método de renovação e responsável. Uma segunda lista de todos os trust stores de que o seu software depende: o pacote do sistema operativo, cada bundle de cada linguagem, cada ficheiro de CA dentro de uma aplicação ou de um dispositivo. A pesquisa de CT acima dá início à primeira lista; uma lista de materiais de software (SBOM) ou um inventário de dependências dá início à segunda.
2. Automatize a emissão e a instalação. ACME onde quer que possa correr, com ARI (RFC 9773), para que uma autoridade de certificação possa pedir aos seus clientes ACME que renovem mais cedo. Onde um dispositivo não consiga correr ACME, use a automatização do fornecedor, ou faça a terminação TLS à frente dele, num equipamento que o consiga.
3. Tenha uma segunda autoridade de certificação pronta. Uma conta ACME funcional numa segunda autoridade, testada, e registos CAA no DNS que permitam ambas. Quando uma autoridade perde a confiança ou faz revogações em massa, mudar passa a ser uma alteração de configuração.
4. Monitorize a CT para os seus domínios. Receba um alerta para cada novo certificado emitido para os seus nomes. Fica a saber de emissões inesperadas no próprio dia.
5. Trate os trust stores como dependências. Atualize-os através da aplicação normal de correções, e reconstrua as imagens com uma periodicidade fixa, e não só quando o código muda.
6. Escreva o runbook em função dos dois relógios. 24 horas e cinco dias: quem decide, quem tem acesso a cada sistema, que sistemas exigem passos manuais, como contactar cada fornecedor. Ensaie-o uma vez por ano, trocando o certificado de um serviço que possa dar-se ao luxo de um erro. Desde 2025, as autoridades de certificação públicas têm de manter e testar um plano de revogação em massa próprio; os seus clientes precisam da outra metade.

Se faz produtos que outros utilizam

Se o seu produto contém um trust store (um dispositivo, uma aplicação instalada, um SDK), os seus clientes só ficam protegidos quando a sua atualização lhes chegar. Lance-a, e diga aos clientes que versões estão corrigidas. O conselho da Mozilla aos operadores de trust stores: bloquear os oito intermédios, se o software o permitir; caso contrário, «ponderar se é adequado retirar a confiança nas raízes que assinaram estes intermédios».

O Regulamento de Ciber-Resiliência aplica-se aqui de duas formas. A obrigação de notificação, em vigor desde 11 de setembro de 2026, abrange vulnerabilidades ativamente exploradas, e neste caso não foi comunicada qualquer exploração. Os requisitos essenciais, que se aplicam a partir de 11 de dezembro de 2027, incluem a possibilidade de corrigir vulnerabilidades através de atualizações de segurança; um produto cuja lista de autoridades de confiança não possa ser atualizada não os cumpriria. Os clientes abrangidos pela Diretiva NIS 2 vão perguntar aos fornecedores com que rapidez trataram disto, e convém ter a resposta por escrito.

O que continua em aberto

• A raiz restante da eMudhra. O Chrome colocou doze perguntas à eMudhra a 21 de outubro e não anunciou qualquer decisão sobre a emSign Root CA - G1. A Mozilla não a vai retirar «neste momento».
• O caminho de migração da eMudhra. A empresa disse à Mozilla que ia passar os clientes para a sua hierarquia G1 (RSA); a sua página de estado fala de «uma hierarquia de CA alternativa, operada de forma independente e com confiança pública». O Chrome perguntou qual.
• A Microsoft e a Apple. Nenhuma das duas publicou uma declaração nem retirou qualquer das raízes do seu trust store.
• Correções pendentes. A Red Hat, o Amazon Linux, o Temurin e o Corretto não tinham lançado nada até 22 de outubro; a correção do Bun foi integrada, mas não lançada.
• A causa raiz. A eMudhra não a confirmou e disse que vai voltar a verificar todas as cerimónias de chaves que realizou.
• A Sectigo. Num caso separado, aberto desde 5 de setembro, a Sectigo recusou-se a revogar certificados cuja utilização alargada da chave (extended key usage) não correspondia a uma frase da sua CPS, argumentando que a frase era ambígua. A 18 de outubro, contava ainda cerca de 72 milhões desses certificados ativos. Alguns participantes na discussão pública pediram a retirada de confiança; nenhum programa de raízes anunciou uma decisão. As empresas com certificados da Sectigo devem acompanhar o caso.

Onde obter ajuda

Um problema de certificados raramente se apresenta como tal. Aparece como uma página de pagamento que deixa de carregar, uma integração que deixa de sincronizar ou um dispositivo que deixa de comunicar, normalmente ao fim de semana. Ajudamos as empresas a atravessar semanas como esta sem interrupções de serviço, e a deixar tudo preparado para que a próxima seja rotina:

• Uma verificação de exposição. Identificamos onde os seus sistemas estabelecem ou aceitam ligações TLS, que trust store cada um usa e que certificados serve, incluindo contentores, serviços Java, integrações com bancos, prestadores de pagamentos e de logística, e dispositivos.
• As correções. Atualizações, imagens reconstruídas, chaves bloqueadas ou certificados substituídos, feitos através do seu processo de gestão de alterações e confirmados com os servidores de teste da Mozilla.
• Automatização para 2027. ACME com ARI em servidores, balanceadores de carga e appliances, uma segunda autoridade de certificação, registos CAA, monitorização de CT e um runbook, prontos para os certificados de 100 dias a partir de 15 de março de 2027.
• Os sistemas em que ninguém quer mexer. Aplicações Java antigas, appliances e clientes embebidos com os seus próprios trust stores: é para isso que existe o nosso serviço de manutenção de sistemas legados.

Se não tem a certeza de que é afetado, escreva para office@c9group.dev com os domínios e as plataformas que utiliza, ou marque uma chamada. Dizemos-lhe o que verificar primeiro.