Você deve ter visto relatórios sobre um problema que está afetando várias autoridades de certificação, incluindo Apple, Google, GoDaddy e (infelizmente) SSL.com. A maioria dessas empresas usa um programa chamado EJBCA (Enterprise Java Beans Certificate Authority) para uma variedade de atividades de CA. Como o Diretor de Arquitetura de Segurança da SSL.com, Fotis Loukos, observou:
“O método de geração de números de série de EJBCA levou a uma discrepância entre o comportamento esperado e real e a saída, de modo que qualquer CA usando EJBCA com as configurações padrão encontrará esse problema (e, portanto, violará BR 7.1).”
“BR 7.1” refere-se à Seção 7.1 dos Requisitos de Base do Fórum CA / B, que afirma:
“A partir de 30 de setembro de 2016, as CAs DEVEM gerar números de série de certificados não sequenciais maiores que zero (0) contendo pelo menos 64 bits de saída de um CSPRNG.”
CSPRNG é a abreviação de “gerador de números pseudo-aleatórios criptograficamente seguro” e é o mecanismo usado para gerar números com aleatoriedade suficiente (ou “entropia”) para garantir que sejam seguros e únicos. O método que EJBCA optou por usar ao gerar números de série, no entanto, define automaticamente o bit inicial como zero - o que significa que em uma string longa de 64 bits, o número de série conterá apenas 63 bits de saída do CSPRNG.
O impacto no mundo real desse problema sobre a segurança é incrivelmente pequeno, mas mesmo que a diferença entre 63 e 64 bits de entropia não coloque os usuários da Internet em risco, ainda está violando os requisitos de SSL.com e todos os outros respeitáveis CAs observam. É por isso que SSL.com está revogando todos os certificados afetados e emitindo certificados de substituição para todos os clientes afetados.
Os certificados de substituição serão do mesmo tipo que os revogados e conterão os mesmos nomes DNS. Além disso, a vida útil desses certificados de substituição será de duração total do certificado comprado originalmente. Isso significa que, mesmo que você tenha adquirido um certificado de um ano há quatro meses, seu novo certificado de substituição será válido por um ano inteiro a partir da data de emissão, oferecendo um total de 16 meses.
Por fim, esse problema se aplica só para SSL.com's /TLS certificados (Básico, Premium, Alta Garantia, Enterprise EV, Curinga e Vários Domínios). Outros tipos de certificados, incluindo S/MIME, NAESB e assinatura de código, não são afetados de forma alguma.
