Nota del editor: Este blog se publicó originalmente en abril de 2021. Desde entonces se ha actualizado para proporcionar nuevas fechas para la rotación de ICA y la eliminación del campo OU, y también para proporcionar información adicional sobre los cambios en el uso de la clave ECC y el proceso de pensamiento detrás de ellos.
Los programas CA/Browser Forum y Root especifican los requisitos que deben cumplir las AC (Autoridad Certificadora) y que deben ser auditados para proporcionar requisitos uniformes en todas las AC y para proteger a los visitantes del sitio web estableciendo importantes requisitos de cumplimiento y seguridad. Todos ustedes saben que la validez máxima de los certificados TLS se redujo de 5 a 3 años a 825 días y, justo el pasado septiembre, a 397 días (unos 13 meses). En este post, nos gustaría informarle de algunos de los próximos cambios que han sido ordenados por los programas raíz y/o el Foro CAB.
La AC verificará los nombres de dominio y las direcciones IP como máximo 398 días antes de la emisión del certificado
Fecha de entrada en vigor: 1 de octubre de 2021
El pasado mes de septiembre, Apple impuso un periodo de validez máximo de 398 días, pero el periodo de reutilización de la validación de dominios y organizaciones se mantuvo en 825 días. Esta reducción del periodo de reutilización de dominios se esperaba y es poco probable que sea la última. Esto se deriva de varios estudios que encontraron que en ciertos casos, durante los cambios de propiedad de los dominios, los certificados existentes pueden seguir siendo reemplazados/reemitidos desde la AC anterior. Una forma de remediarlo es reducir el periodo de reutilización de la validación del dominio.
Dé un paso atrás y piense en la situación de esta manera:
- Hasta la reducción de la validez máxima impuesta por Apple, el tiempo entre la validación del dominio y la expiración del certificado era de 825 + 825 días, es decir, unos 4 años y medio. Eso es mucho tiempo.
- Con la reducción de Apple en la validez máxima, la diferencia es de 825+398 días, lo que sigue siendo más de 3 años.
- Con este último cambio, la diferencia máxima es de 398+398, es decir, un poco más de 2 años.
- A modo de comparación, la AC que emite más certificados al año, Let's Encrypt, emite certificados con una validez máxima de 90 días y reutiliza la validación del dominio durante un máximo de 30 días, o un máximo de 4 meses entre la validación y la expiración del certificado. Es de esperar que el sector se dirija hacia la línea de base de Let's Encrypt y que, con el tiempo, sea incluso más corta.
Prohibir el método de validación de dominios HTTP para la emisión de subdominios y wildcards
Fecha de entrada en vigor: 1 de diciembre de 2021
El método de validación de dominio HTTP (conocido oficialmente como método 6, Cambio acordado en el sitio web) se utiliza habitualmente para verificar el control del dominio. Si se puede colocar un archivo en un directorio específico del sitio web se "demuestra" el control sobre ese dominio. A diferencia de los DNS, los sitios web no tienen los mismos controles en los que hay una delegación formal de permisos del dominio a los subdominios. Así, si example.com fuera hackeado, o su propietario tuviera ciertas tendencias maliciosas, pueden aprobar example.com y luego emitir certificados a los subdominios. Pero esos subdominios podrían ser entidades diferentes y, de nuevo, como no existe el mismo nivel de delegación formal de control, Mozilla está exigiendo que la emisión de certificados que contengan dominios validados con el método HTTP se limite a la emisión de exactamente el dominio validado. En otras palabras, los Wildcards y los SANs de subdominios estarán prohibidos para los dominios validados con el método HTTP.
Esto afectará a los clientes, ya que es un método habitual para realizar la validación de dominios y, si se quiere seguir utilizando este método, se deberá validar cada SAN:DNSName individualmente.
Rotación de las ICA a intervalos más cortos
Calendario: 24 de agosto de 2021 y luego trimestralmente en 2022
GlobalSign empezará a rotar nuestras ACs TLS de Atlas de forma programada para promover una buena seguridad y agilidad del ecosistema. Históricamente, hemos creado ACs y las hemos utilizado durante muchos años, pero hay muchas razones para reducir este intervalo de tiempo. Al reducir el tiempo de uso de las AC, conseguimos los siguientes beneficios:
- Se limita el número de certificados emitidos por una sola AC y su correspondiente clave privada, lo que mejora nuestra propia criptoagilidad.
- Esto limita el impacto si hay un problema de integridad, cumplimiento o seguridad con la AC.
- Esto reduce el tamaño de las CRL, lo que aumenta el rendimiento de la validación.
- Esto capacita a nuestra base de clientes para que esperen y planifiquen la sustitución inmediata de las AC, lo que aumenta su criptoagilidad.
- Nuestro plan final hará que todas las AC TLS de GlobalSign Atlas roten cada trimestre y que todas las AC TLS de los clientes roten anualmente.
- La primera rotación de AC TLS de GlobalSign Atlas para 2021 tendrá lugar el 24 de agosto de 2021.
- A partir de 2022, actualizaremos las AC TLS de GlobalSign Atlas cada trimestre, el segundo lunes del trimestre, y actualizaremos las AC TLS de Atlas dedicadas al cliente anualmente cada enero.
Impacto y recomendaciones:
- Los clientes deben estar siempre preparados para aceptar nuevas AC cuando instalen nuevos certificados TLS. La AC emisora está disponible en la API y debe utilizarse al descargar el certificado para que la AC actual esté siempre provista del certificado emitido.
- Los clientes no DEBEN hacer un anclaje de clave pública a los certificados de AC, y desaconsejamos totalmente el anclaje de clave pública, ya que eso anula el propósito de la agilidad criptográfica.
- Animamos a los clientes a que sigan las prácticas ágiles de las AC emisoras y a que descarguen e instalen siempre el ICA proporcionado cuando obtengan nuevos certificados.
- Por favor, suscríbase a la página de estado de GlobalSign para obtener actualizaciones importantes.
Puede encontrar más información en nuestro sitio web de soporte.
Cambios en el uso de la clave ECC
Fecha de entrada en vigor: 26 de julio de 2021
Vamos a cambiar los usos de las claves en nuestros certificados ECC TLS para alinearlos con las mejores prácticas de la industria y con los cambios en curso de los requisitos básicos del AC/B Forum. Actualmente incluimos tanto la firma digital como el acuerdo de claves, pero a partir de esta fecha lo cambiaremos para incluir sólo la firma digital.
Nuestro TLS de confianza pública es utilizado por los navegadores y servidores web para soportar sesiones TLS para la protección del usuario final. Siempre mantendremos la seguridad de los usuarios de estos certificados en primer lugar en nuestras consideraciones al crear nuevos perfiles o emitir ACs. Se decidió que la necesidad de un acuerdo de claves en el uso de certificados ECC ya no era necesaria dentro de un certificado TLS, al tiempo que introducía posibles problemas de seguridad para los usuarios finales, ya que la clave de firma y la clave de cifrado deberían ser claves separadas dentro de una sesión TLS. Por estos motivos, la extensión se eliminó de nuestra oferta general de TLS. Los clientes que necesiten perfiles personalizados para herramientas y sistemas fuera de los límites de las sesiones TLS tradicionales entre navegadores y servidores deben considerar seriamente las ofertas de confianza privada.
Prohibición del uso del campo OU
Plazo: 31 de agosto de 2022
A Google le preocupa desde hace tiempo cómo se valida el campo OU en los certificados TLS. Los requisitos básicos tienen requisitos claros sobre todos los campos temáticos (C, S, L, Org, etc.) que requieren que los datos se obtengan de un repositorio empresarial; sin embargo, el requisito del campo OU sigue siendo el siguiente
La AC IMPLEMENTARÁ un proceso que impida que un atributo OU incluya un nombre, DBA, nombre comercial, marca comercial, dirección, ubicación u otro texto que se refiera a una persona física o jurídica específica, a menos que la AC haya verificado esta información.
Esto permite a los clientes suministrar información no validada, y posiblemente engañosa, en la que se puede confiar (inadvertidamente). Por ello, Google aboga firmemente por la eliminación de este campo.
Las organizaciones suelen utilizar este campo para ayudarles a gestionar los certificados especificando el departamento al que pertenece el certificado. Los informes sobre certificados ayudan a la organización a asignar renovaciones y sustituciones en función de este campo; sin embargo, el propósito de los datos de los certificados es para las partes que confían en ellos, es decir, aquellas que visitan el sitio y quieren tomar una decisión sobre si deben confiar en él o no, y no para la gestión de certificados de la organización.
Los clientes deben ser conscientes de este próximo cambio y empezar a planificar la desaparición del campo OU. Aunque la fecha límite se ha fijado en el 31 de agosto de 2022, en los próximos meses iremos eliminando progresivamente el uso general del campo OU y recopilando información para los programas raíz sobre por qué algunos siguen necesitando el campo OU.
¿Tiene preguntas? Visite nuestro sitio web de soporte para obtener más información y formas de ponerse en contacto.
