Let's Encrypt, una autoridad de certificación (CA) de confianza disponible para el público que Cloudflare utiliza para emitir certificados TLS, ha estado confiando en dos cadenas de certificados distintas. Una utiliza una firma cruzada con IdenTrust, una CA de confianza a nivel mundial que existe desde el año 2000, y la otra es la propia CA raíz de Let's Encrypt, ISRG Root X1. Desde el lanzamiento de Let's Encrypt, ISRG Root X1 ha ido consiguiendo de forma gradual su propia compatibilidad de dispositivos.
La cadena de certificados de Let's Encrypt que utiliza una firma cruzada con IdenTrust expirará el 30 de septiembre de 2024. A partir de ese momento, los servidores ya no podrán servir certificados firmados por la cadena con firma cruzada. En su lugar, todos los certificados de Let's Encrypt utilizarán la CA, ISRG Root X1.
La mayoría de los dispositivos y versiones de navegador lanzadas después de 2016 no se verán afectados por el cambio, ya que ISRG Root X1 ya estará instalado en los almacenes de confianza de esos clientes. La razón es que estos navegadores y sistemas operativos modernos se crearon para ser ágiles y flexibles, con almacenes de confianza que se pueden actualizar para incluir nuevas autoridades de certificación.
El cambio en la cadena de certificados afectará a los dispositivos y sistemas heredados, como los dispositivos que ejecutan la versión 7.1.1 de Android (lanzada en 2016) o anteriores, ya que dependen exclusivamente de la cadena con firma cruzada y carecen de la CA raíz ISRG X1 en su almacén de confianza. Estos clientes recibirán mensajes de error o advertencias de TLS cuando accedan a dominios protegidos por un certificado Let's Encrypt. Echamos un vistazo a los datos y descubrimos que, de todas las solicitudes de Android, el 2,96 % proceden de dispositivos que se verán afectados por el cambio. Esa es una parte sustancial del tráfico que perderá el acceso a Internet. Nos comprometemos a mantener a esos usuarios en línea y modificaremos nuestra canalización de certificados para que podamos seguir sirviendo a los usuarios en dispositivos más antiguos sin la necesidad de que tengan que realizar modificaciones manuales.
Mejoramos Internet para todos
En el pasado, dedicamos nuestros esfuerzos en iniciativas como "No Browsers Left Behind" para ayudar a garantizar un soporte ininterrumpido a los clientes mientras los algoritmos basados en SHA-1 estaban quedando obsoletos. Ahora, estamos adoptando el mismo enfoque para el próximo cambio de Let's Encrypt.
Hemos tomado la decisión de eliminar Let's Encrypt como autoridad de certificación de todos los flujos en los que Cloudflare dicta la CA, lo que afecta a los clientes de Universal SSL y a aquellos que utilizan SSL for SaaS con la opción "CA por defecto".
A partir de junio de 2024, un ciclo de vida del certificado (90 días) antes de que caduque la cadena con firma cruzada, empezaremos a migrar los certificados de Let's Encrypt que estén pendientes de renovación a una CA diferente, una que garantice la compatibilidad con los dispositivos más antiguos afectados por el cambio. Esto significa que, en el futuro, los clientes solo recibirán certificados de Let's Encrypt si solicitan explícitamente a Let's Encrypt como CA.
El cambio que está realizando Let's Encrypt es necesario. Para que podamos avanzar en la compatibilidad con nuevos estándares y protocolos, tenemos que agilizar el ecosistema de la infraestructura de clave pública (PKI). Al eliminar la cadena con firma cruzada, Let's Encrypt permitirá la compatibilidad de los dispositivos, navegadores y clientes con almacenes de confianza adaptables.
Sin embargo, hemos observado cambios como este en el pasado y, aunque impulsan la adopción de nuevos estándares, afectan de manera desproporcionada a los usuarios de regiones económicamente desfavorecidas, donde el acceso a la nueva tecnología es limitado.
Nuestra misión es ayudar a mejorar Internet, y eso significa ayudar a los usuarios de todo el mundo. Anteriormente publicamos una entrada en el blog sobre el cambio de Let's Encrypt, en la que pedíamos a los clientes que cambiaran de autoridad de certificación si esperaban verse afectados. Sin embargo, determinar el impacto del cambio es un desafío. Las tasas de error debido a la incompatibilidad del almacén de confianza se registran principalmente en el cliente, lo que reduce la visibilidad que tienen los propietarios de ese dominio. Además, aunque hoy no haya solicitudes entrantes de dispositivos incompatibles, no garantiza el acceso ininterrumpido de los usuarios en el futuro.
La canalización de certificados de Cloudflare ha evolucionado a lo largo de los años para ser resistente y flexible, lo que nos permite adaptarnos sin problemas a cambios como este sin que nuestros clientes se vean afectados.
Cómo Cloudflare ha desarrollado una sólida canalización de certificados TLS
En la actualidad, Cloudflare gestiona decenas de millones de certificados en nombre de sus clientes. Para nosotros, una canalización sólida conlleva los siguientes beneficios:
- Los clientes siempre pueden obtener un certificado TLS para su dominio.
- Los problemas relacionados con las CA no tienen ningún impacto en la capacidad de nuestros clientes para obtener un certificado.
- Se utilizan las prácticas recomendadas de seguridad y los estándares modernos.
- Optimización para la escala futura.
- Compatibilidad con una amplia gama de clientes y dispositivos.
Cada año, implementamos nuevas optimizaciones en nuestra canalización de certificados para mantener el más alto nivel de servicio. Así es como lo hacemos...
Garantizamos que los clientes siempre puedan obtener un certificado TLS para su dominio
Desde el lanzamiento de Universal SSL en 2014, Cloudflare se ha encargado de emitir y entregar un certificado TLS para cada dominio protegido por nuestra red. Puede parecer trivial, pero hay algunos pasos que se deben ejecutar correctamente para que un dominio reciba un certificado:
- Los propietarios de dominios deben completar la validación de control de dominio para cada emisión y renovación de certificado.
- La autoridad de certificación necesita verificar el token de validación de control de dominio (DCV) para emitir el certificado.
- Los registros CAA, que dictan qué CA se pueden utilizar para un dominio, se deben comprobar para garantizar que solo las partes autorizadas puedan emitir el certificado.
- La autoridad de certificación debe estar disponible para emitir el certificado.
Cada uno de estos pasos requiere la coordinación de varias partes: propietarios de dominios, CDN y autoridades de certificación. En Cloudflare, nos gusta tener el control cuando se trata del éxito de nuestra plataforma. Por eso, nos aseguramos de que cada uno de estos pasos llegue a feliz término.
Nos aseguramos de que cada emisión y renovación de certificado requiera el mínimo esfuerzo por parte de nuestros clientes. Para obtener un certificado, el propietario de un dominio tiene que completar la DCV para demostrar que realmente es el propietario del dominio. Una vez iniciada la solicitud del certificado, la CA devolverá el token DCV que el propietario del dominio deberá colocar en un registro DNS o un token HTTP. Si utilizas Cloudflare como tu proveedor de DNS, Cloudflare completa la DCV en tu nombre colocando automáticamente el token TXT devuelto por la CA en tu registro DNS. Como alternativa, si utilizas un proveedor de DNS externo, ofrecemos la opción de delegar la DCV a Cloudflare para realizar renovaciones automáticas sin la intervención del cliente.
Una vez colocados, las CA verifican los tokens DCV. Las CA llevan a cabo esta verificación desde varios ámbitos para evitar intentos de suplantación. Sin embargo, dado que estas comprobaciones se realizan desde varios países y ASN (sistemas autónomos), pueden activar una regla en el Cloudflare WAF que puede bloquear la comprobación de la DCV. Nos aseguramos de actualizar nuestro WAF y nuestro motor de seguridad para reconocer que estas solicitudes proceden de una CA y garantizar así que nunca se bloqueen y que la DCV se pueda completar con éxito.
Algunos clientes tienen preferencias de CA, debido a requisitos internos o a normativas de cumplimiento. Para evitar que una CA no autorizada emita un certificado para un dominio, el propietario del dominio puede crear un registro DNS de autorización de la autoridad de certificación (CAA), especificando qué CA pueden emitir un certificado para ese dominio. Para garantizar que los clientes siempre puedan obtener un certificado, comprobamos los registros de CAA antes de solicitar un certificado para saber qué CA debemos utilizar. Si los registros CAA bloquean todas las CA que están disponibles en la canalización de Cloudflare y el cliente no ha cargado un certificado de la CA de su elección, añadimos registros CAA en nombre de nuestros clientes para garantizar que puedan obtener un certificado emitido. Siempre que podemos, optimizamos las preferencias. De lo contrario, nuestro trabajo es evitar una interrupción asegurándonos de que siempre haya un certificado TLS disponible para el dominio, incluso si no procede de una CA preferida.
En la actualidad, Cloudflare no es una autoridad de certificación de confianza pública, por lo que dependemos de las CA que utilizamos para tener una alta disponibilidad. Sin embargo, un tiempo activo del 100 % es una expectativa poco realista. En cambio, nuestra canalización debe estar preparada en caso de que nuestras CA dejen de estar disponibles.
Garantizamos que los problemas relacionados con las CA no tengan ningún impacto en la capacidad de nuestros clientes para obtener un certificado
En Cloudflare, nos gusta pensar en el futuro, lo que significa prevenir los incidentes antes de que ocurran. No es raro que las CA dejen de estar disponibles. A veces ocurre debido a una interrupción, pero lo más común es que ocurra temporalmente durante los periodos de mantenimiento de las CA.
Nuestro trabajo es garantizar la redundancia de las CA, por lo que siempre tenemos varias preparadas para emitir un certificado, lo que garantiza una alta disponibilidad en todo momento. Si has observado que diferentes CA emiten tus certificados Universal SSL, es de forma intencionada. Distribuimos uniformemente la carga entre nuestras CA para evitar cualquier punto único de fallo. Además, monitorizamos la latencia y la tasa de error para detectar cualquier problema y cambiar automáticamente a una CA diferente que esté disponible y funcione. Puede que no lo sepas, pero una de nuestras CA se somete a 4 periodos de mantenimiento programados cada mes. Cuando esto sucede, nuestros sistemas automatizados se activan de forma eficaz, para que todo funcione sin problemas. Todo el proceso se desarrolla tan bien que ya no tenemos que localizar a nuestros equipos internos porque todo funciona, sin más.
Adopción de las prácticas recomendadas de seguridad y estándares modernos
La seguridad siempre ha sido, y seguirá siendo, la principal prioridad de Cloudflare, por lo que es fundamental mantener los más altos estándares de seguridad para proteger los datos de nuestros clientes y las claves privadas.
Durante la última década, el CA/Browser Forum ha abogado por reducir la vida útil de los certificados de 5 años a 90 días como norma del sector. Este cambio ayuda a minimizar la amenaza de una clave en riesgo. Cuando los certificados se renuevan cada 90 días, sus claves privadas siguen siendo válidas solo durante ese periodo, lo que reduce la ventana de tiempo en que un ciberdelincuente puede hacer uso del material en riesgo.
Apoyamos plenamente este cambio y hemos establecido 90 días como periodo de validez del certificado por defecto. Este cambio mejora nuestra postura de seguridad porque garantiza renovaciones regulares de las claves, y nos ha empujado a desarrollar herramientas como DCV Delegation que promueven la automatización en torno a las renovaciones frecuentes de certificados, sin la sobrecarga adicional. Esta función es lo que nos permite ofrecer certificados con periodos de validez de tan solo dos semanas, para los clientes que quieren renovar sus claves privadas con mucha frecuencia sin preocuparse de que esto provoque fallos en la renovación del certificado.
Cloudflare siempre ha estado a la vanguardia de los nuevos protocolos y estándares. No es ningún secreto que cuando apoyamos un nuevo protocolo, la adopción se dispara. Este mes añadiremos la compatibilidad ECDSA para certificados emitidos desde Google Trust Services. Con ECDSA, obtienes el mismo nivel de seguridad que RSA, pero con claves más pequeñas. Las claves más pequeñas implican certificados más pequeños y menos datos que se pasan para establecer una conexión TLS , lo que se traduce en conexiones y tiempos de carga más rápidos.
Optimización para la escala futura
En la actualidad, Cloudflare emite casi un millón de certificados al día. Con el reciente cambio hacia una vida útil más corta de los certificados, seguimos mejorando nuestra canalización para que sea más sólida. Pero incluso si nuestra canalización puede gestionar la carga significativa, aún necesitamos confiar en nuestras CA para poder escalar con nosotros. Con cada CA que integramos, nos convertimos instantáneamente en uno de sus mayores usuarios. Exigimos a nuestras autoridades de certificación un alto nivel y las impulsamos a mejorar su infraestructura para escalar. Esto no solo beneficia a los clientes de Cloudflare, sino que ayuda a Internet, ya que exige a las CA que gestionen mayores volúmenes de emisión.
Y ahora que Let's Encrypt reduce su cadena de confianza, vamos a añadir una mejora adicional a nuestra canalización, una que garantice la mejor compatibilidad de dispositivos para todos.
Compatibilidad para todos los clientes con dispositivos heredados y modernos
El próximo cambio de Let's Encrypt evitará que los dispositivos heredados realicen solicitudes a dominios o aplicaciones que estén protegidos por un certificado de Let's Encrypt. No queremos interrumpir el acceso a Internet desde ninguna parte del mundo, lo que significa que vamos a seguir ofreciendo la mejor compatibilidad de dispositivos a nuestros clientes, a pesar del cambio.
Gracias a todas las mejoras recientes, podemos reducir nuestra dependencia de Let's Encrypt sin afectar la fiabilidad o la calidad de servicio de nuestra canalización de certificados. Con un ciclo de vida de los certificados (90 días) antes del cambio, vamos a empezar a cambiar los certificados para utilizar una CA diferente, una que sea compatible con los dispositivos que se verán afectados. De este modo, mitigaremos cualquier impacto sin necesidad de que nuestros clientes tengan que intervenir. Los únicos clientes que seguirán utilizando Let's Encrypt son aquellos que hayan elegido específicamente Let's Encrypt como CA.
Próximos pasos con el cambio de Let's Encrypt
La cadena con firma cruzada de Let's Encrypt expirará el 30 de septiembre de 2024. Aunque Let's Encrypt planea dejar de emitir certificados de esta cadena el 6 de junio de 2024, Cloudflare seguirá sirviendo la cadena con firma cruzada para todos los certificados de Let's Encrypt hasta el 9 de septiembre de 2024.
Con 90 días o un ciclo de vida de certificado antes del cambio, vamos a empezar a cambiar los certificados de Let's Encrypt para que utilicen una autoridad de certificación diferente. Implementaremos el cambio en todos los productos en los que Cloudflare sea responsable de la selección de la CA, lo que significa que será automático para los clientes que utilicen Universal SSL y SSL for SaaS con la opción "CA por defecto".
Cualquier cliente que haya elegido específicamente Let's Encrypt como su CA recibirá una notificación por correo electrónico con una lista de sus certificados de Let's Encrypt e información sobre si estamos viendo o no solicitudes en esos nombres de host procedentes de dispositivos heredados.
A partir del 9 de septiembre de 2024, Cloudflare servirá todos los certificados de Let's Encrypt utilizando la cadena ISRG Root X1. Esto es lo que deberías esperar en función del producto de certificado que estés utilizando:
Universal SSL
Con Universal SSL, Cloudflare elige la CA que se utiliza para el certificado del dominio. De esta manera, podemos elegir el mejor certificado para nuestros clientes. Si utilizas Universal SSL, no tendrás que hacer nada antes del cambio. Cloudflare cambiará automáticamente tu certificado para que utilice una CA más compatible.
Advanced Certificates
Con Advanced Certificate Manager, los clientes eligen específicamente qué CA quieren utilizar. Si eligieron Let's Encrypt como la CA para un certificado, respetaremos la elección, porque los clientes pueden haber elegido esta CA en concreto debido a requisitos internos, o porque han implementado el anclaje de certificados, lo que desaconsejamos encarecidamente.
Si prevemos que un dominio que utiliza un certificado avanzado emitido por Let's Encrypt se verá afectado por el cambio, enviaremos notificaciones por correo electrónico para informar a esos clientes sobre que certificados utilizan Let's Encrypt como su CA y si esos dominios están recibiendo o no solicitudes del cliente que se verá afectado por el cambio. Los clientes serán responsables de cambiar la CA a otro proveedor, si así lo deciden.
SSL para SaaS
Con SSL for SaaS, los clientes tienen dos opciones: utilizar una CA por defecto, lo que significa que Cloudflare elegirá la autoridad emisora, o especificar qué CA utilizar.
Si dejas la elección de la CA en manos de Cloudflare, utilizaremos automáticamente una CA con mayor compatibilidad de dispositivos.
Si especificas una determinada autoridad de certificación para tus nombres de host personalizados, respetaremos esa elección. Enviaremos un correo electrónico a los proveedores y plataformas de SaaS para informarles de qué nombres de host personalizados están recibiendo solicitudes de dispositivos heredados. Los clientes serán responsables de cambiar la CA a otro proveedor, si así lo deciden.
Certificados personalizados
Si haces una integración directa con Let's Encrypt y utilizas certificados personalizados para cargar tus certificados de Let's Encrypt en Cloudflare, tus certificados se incluirán en la cadena con firma cruzada, siempre que elijas el método de paquete "compatible" o "moderno" y los cargues antes del 9 de septiembre de 2024. Después del 9 de septiembre, agruparemos todos los certificados de Let's Encrypt con la cadena ISRG Root X1. Con el método de paquete "definido por el usuario", siempre servimos la cadena que se carga en Cloudflare. Si cargas certificados de Let's Encrypt con este método, tendrás que asegurarte de que los certificados cargados después del 30 de septiembre de 2024, la fecha de caducidad de la CA, contienen la cadena de certificados correcta.
Además, si controlas los clientes que se conectan a tu aplicación, te recomendamos que actualices el almacén de confianza para incluir ISRG Root X1. Si utilizas el anclaje de certificados, elimina o actualiza tu anclaje. En general, desaconsejamos a todos los clientes que anclen sus certificados, ya que esto suele causar problemas durante las renovaciones de certificados o los cambios de CA.
Conclusión
Los estándares de Internet seguirán evolucionando y mejorando. Conforme apoyamos y adoptamos esos cambios, también debemos reconocer que es nuestra responsabilidad mantener a los usuarios en línea y el acceso a Internet en las partes del mundo donde las nuevas tecnologías no están disponibles. Con Cloudflare, siempre tienes la opción de elegir la configuración que mejor se adapte a tu aplicación.
Para obtener más información sobre este cambio, consulta nuestra documentación para desarrolladores.