Es posible que haya visto informes sobre un problema que está afectando a varias autoridades de certificación, incluidas Apple, Google, GoDaddy y (desafortunadamente) SSL.com. La mayoría de estas empresas utilizan un programa llamado EJBCA (Enterprise Java Beans Certificate Authority) para una variedad de actividades de CA. Como ha señalado el Director de Arquitectura de Seguridad de SSL.com, Fotis Loukos:
"El método de EJBCA para generar números de serie ha dado lugar a una discrepancia entre el comportamiento y la salida esperados y reales, de modo que cualquier CA que utilice EJBCA con la configuración predeterminada encontrará este problema (y, por lo tanto, infringirá la BR 7.1)".
“BR 7.1” se refiere a la Sección 7.1 de los Requisitos básicos del Foro CA / B, que establece:
"A partir del 30 de septiembre de 2016, las CA DEBERÁN generar números de serie de certificados no secuenciales mayores que cero (0) que contengan al menos 64 bits de salida de un CSPRNG".
CSPRNG es la abreviatura de "generador de números pseudoaleatorios criptográficamente seguro" y es el mecanismo utilizado para generar números con suficiente aleatoriedad (o "entropía") para garantizar que sean seguros y únicos. Sin embargo, el método que EJBCA eligió usar al generar números de serie establece automáticamente el bit inicial en cero, lo que significa que en una cadena de 64 bits, el número de serie contendrá solo 63 bits de salida del CSPRNG.
El impacto en la seguridad de este problema en el mundo real es muy pequeño, pero incluso si la diferencia entre 63 y 64 bits de entropía no pone en riesgo a los usuarios de Internet, sigue infringiendo los requisitos que SSL.com y todos los demás Las CA observan. Es por eso que SSL.com está revocando todos los certificados afectados y emitiendo certificados de reemplazo para todos los clientes afectados.
Los certificados de reemplazo serán del mismo tipo que los revocados y contendrán los mismos nombres DNS. Además, la vida útil de estos certificados de reemplazo será de duración completa del certificado comprado originalmente. Eso significa que incluso si compró un certificado de un año hace cuatro meses, su nuevo certificado de reemplazo será válido por un año completo a partir de la fecha de emisión, lo que le otorga un total de 16 meses.
Finalmente, este problema aplica only al SSL de SSL.com /TLS certificados (Basic, Premium, High Assurance, Enterprise EV, Wildcard y Multi-domain). Otros tipos de certificados, incluidos S/MIME, NAESB y la firma de código no se ven afectados de ninguna manera.