FAQ Hero
CRIPTOGRAFÍA

¿Cuál es actualmente la compatibilidad de Certificate Transparency (CT) con los registros, navegadores y autoridades de certificación?

¿Cuál es actualmente la compatibilidad de Certificate Transparency (CT) con los registros, navegadores y autoridades de certificación?

Registros

Desde febrero de 2018, DigiCert comenzó a enviar todos los certificados TLS/SSL recién emitidos y de confianza pública a los registros de Certificate Transparency (CT) de forma predeterminada. Hicimos este cambio antes de que Google lo estableciera como requisito para todo el sector en abril de 2018, a fin de mejorar la seguridad de nuestros clientes y fomentar la adopción. Antes de 2018, solo era necesario crear registros de los certificados con EV.

DigiCert gestiona su propio registro de CT, que también utiliza Google. La inclusión de un registro requiere un alto grado de disponibilidad, demostrado mediante un periodo de prueba de 90 días. Los registros que no cumplen estos estrictos requisitos no son de confianza. Por ello, DigiCert tomó precauciones adicionales a la hora de crear su registro y garantizar que fuera lo suficientemente robusto como para gestionar todos los certificados emitidos.

Navegadores

Chrome: Chrome empezó a ofrecer compatibilidad con el marco CT a principios de 2014. Ahora está ampliando esta compatibilidad como requisito para todas las CA que emiten certificados.

Para obtener un certificado de un año, Google exigía comprobantes de CT de dos registros independientes. Para un certificado de dos años emitido antes de 2020 —es decir, antes de que los certificados de un año se convirtieran en la norma—, el certificado debía incluir comprobantes de CT de al menos tres registros independientes. Para facilitarles la transición a las CA, Google relajó temporalmente este requisito relativo a los registros independientes, y permitió a las CA incluir dos comprobantes de los registros de Google y otro del registro de DigiCert. Se esperaba que más autoridades de certificación y partes interesadas crearan registros durante ese periodo transitorio para garantizar una cantidad suficiente de registros operativos.

Firefox: actualmente, Firefox no comprueba ni requiere el uso de registros de CT para los sitios que visitan los usuarios.

Safari: Apple requiere una cantidad variable de SCT para que Safari y otros servidores confíen en los certificados de servidor.

Autoridades de certificación:

Según la RFC 9162 del Internet Engineering Task Force (IETF), se espera que las CA públicas aporten todos sus certificados recién emitidos a uno o varios registros; sin embargo, los titulares de certificados también pueden aportar sus propias cadenas de certificados (algo que también pueden hacer las entidades de terceros).

En enero de 2015, las principales CA empezaron a incluir los certificados con EV emitidos en los servidores de registro de CT. Cualquier CA que emitiera certificados con EV debía utilizar los dos registros de Google disponibles y el registro de DigiCert para cumplir el requisito de Google.

¿Cómo cumple DigiCert la normativa sobre Certificate Transparency?

El marco CT refuerza el sistema de certificados TLS/SSL mediante la creación de registros públicos auditables de la emisión de certificados. Desde 2015, Google exige a las CA que registren los certificados con EV en los registros de CT públicos. En abril de 2018, Google comenzó a exigir a las CA que registraran también los certificados con OV y DV en los registros de CT públicos.

El 1 de febrero de 2018, DigiCert comenzó a publicar todos los certificados TLS/SSL públicos recién emitidos en los registros de CT públicos. Este cambio no afectó a los certificados con OV o DV emitidos antes de esa fecha.

Navegadores con políticas de Certificate Transparency:

A partir de abril de 2018, Google exigió a las CA que registraran todos los certificados TLS/SSL (EV, OV y DV).

A partir del 15 de octubre de 2018, Apple exigió a las CA que registraran todos los certificados TLS/SSL (EV, OV y DV).

¿Cuáles son los antecedentes de Certificate Transparency?

En 2011, una autoridad de certificación holandesa llamada DigiNotar sufrió un ataque, circunstancia que permitió a los hackers crear más de 500 certificados fraudulentos emitidos desde la raíz de confianza de DigiNotar. Los ciberdelincuentes utilizaron los certificados para hacerse pasar por numerosos sitios, como Google y Facebook, y perpetrar ataques de interposición «Man-in-the-Middle» contra usuarios desprevenidos.

Este hecho, entre otros incidentes sonados relacionados con certificados emitidos por error o de forma malintencionada por CA ajenas a DigiCert, llevó a los ingenieros de Google a idear nuevas soluciones. En las reuniones de trabajo, a dos ingenieros llamados Ben Laurie y Adam Langley se les ocurrió el concepto de Certificate Transparency (CT) y empezaron a desarrollar el marco como un proyecto de código abierto. En 2012, Laurie y Langley crearon un borrador de trabajo en el que esbozaron el marco Certificate Transparency junto con el IETF, y en 2013 publicaron una RFC.

En 2013, Google lanzó dos registros públicos y anunció sus planes de, más adelante, exigir CT para todos los certificados SSL con EV en Google Chrome.

Desde 2012, DigiCert ha experimentado con la integración de CT y ha aportado sus opiniones sobre las implementaciones de CT propuestas. En septiembre de 2013, DigiCert se convirtió en la primera CA en implementar CT en sus sistemas, y en octubre del mismo año se convirtió en la primera CA en ofrecer a los clientes la opción de incluir comprobantes de CT en los certificados SSL.

En septiembre de 2014, DigiCert presentó un registro privado ante Google para su inclusión en Google Chrome. El registro de DigiCert fue aceptado el 31 de diciembre de 2014. DigiCert fue la primera CA en crear un registro de CT.