Cloudflare lleva años apoyándose en 16 CA públicas asociadas sin haber emitido nunca por sí mismo un certificado de confianza pública. Ahora pretende convertirse en una, y lo interesante es el diseño: certificados clásicos y Merkle Tree Certificates bajo una sola CA, con contención de fallos incorporada desde el principio.
Un consumidor de certificados se convierte en emisor #
La mayoría de las empresas de infraestructura se quedan en un solo lado de la relación con los certificados. Los solicitan, los instalan y se quejan cuando una CA sufre un incidente. Cloudflare ha estado firmemente del lado del consumo. Según su propio relato, nunca ha emitido por sí mismo un solo certificado de confianza pública.
Eso está a punto de cambiar, o al menos Cloudflare dice que esa es su intención. La empresa anuncia su intención de convertirse en una autoridad de certificación pública. El anuncio es cuidadoso sobre el punto en que están hoy las cosas, y este artículo debe serlo también. Cloudflare todavía no emite certificados. Todo lo relativo al comportamiento del servicio, desde su interfaz ACME hasta sus reglas de renovación y su compatibilidad con Merkle Tree Certificates, es una declaración de planes y no la descripción de un sistema en funcionamiento.
Lo que da credibilidad al anuncio no es la ambición sino el trabajo previo ya visible. Cloudflare ha solicitado su inclusión en los programas raíz de Chrome, Apple, Microsoft y Mozilla. Dice que está avanzando en el proceso de solicitud y aprobación con cada uno de los programas de claves raíz centrales de la web, y señala que estos procesos se desarrollan en público. Cualquiera puede, en principio, seguir si la solicitud prospera.
Por qué Cloudflare está en posición de plantear la cuestión #
El argumento de Cloudflare para crear una CA parte de su posición como cliente. Está por delante de más del 20 por ciento del tráfico mundial de solicitudes de Internet. Termina TLS para millones de dominios y depende de millones de certificados al año. Proporciona paquetes de certificados a sus clientes a través de Universal SSL, y también consume certificados de muchas CA distintas para operar sus propios sistemas y operaciones internas.
Para mantener los servicios de sus clientes, Cloudflare obtiene esos certificados a través de varias CA, con rutas principales y de respaldo para que los servicios sigan funcionando ante caídas de una CA y eventos de revocación. La red de CA públicas asociadas en la que se ha apoyado durante muchos años suma 16.
El mecanismo de respaldo merece una mirada más detenida porque muestra cómo piensa Cloudflare sobre los fallos. Cada certificado de Universal SSL ya se entrega con un certificado de respaldo, protegido con una clave distinta y emitido por otra autoridad. Si el principal llega a ser revocado o comprometido, el de respaldo está listo para desplegarse automáticamente. Es una cobertura frente al fallo de una sola CA, construida desde el lado del cliente de la relación.
También es una cobertura con techo. Solo se puede diversificar entre las CA que existen, y la fuente sostiene que la oferta de CA capaces es más escasa de lo que parece.
El problema de la concentración #
Las cifras detrás de ese argumento son llamativas. Let's Encrypt emite del orden de diez millones de certificados al día. Da servicio a más de 500 millones de sitios y superó los cuatro mil millones de certificados activos en 2025. Son cifras de una sola CA gratuita, y describen una web cuyo cifrado se apoya en gran medida en una sola organización.
La fuente extrae la conclusión obvia, con una salvedad apropiada: si la autoridad de certificación gratuita dominante pasara una mala semana, gran parte de la web no tendría una alternativa gratuita y automatizada comparable lista para asumir la carga. Es una afirmación sobre una hipótesis, y Cloudflare la presenta como tal. No sostiene que esa semana haya ocurrido ni que vaya a llegar.
Aun así, la lógica es fácil de seguir. Una CA gratuita y automatizada solo es una opción de resiliencia si existe antes de la emergencia. La propuesta de Cloudflare es que puede ofrecer una segunda a escala. Yo diría que es la razón comercial y técnica más sólida del anuncio, y no depende de ninguna de las partes más especulativas del plan. Una web con una CA gratuita dominante y poco más es una web con un punto único de fallo, sea cual sea la calidad de las operaciones de esa CA.
| Dimensión | CA gratuita y automatizada tradicional (Let's Encrypt) | CA pública propuesta por Cloudflare |
|---|---|---|
| Estrategia de ancla de confianza | ISRG Root X1 / X2 (raíces propias creadas desde 2015) | Raíz de GlobalSign adquirida (de confianza desde 2012) + nueva raíz |
| Protocolo de emisión | ACME estándar (RFC 8555) | ACME con aplicación obligatoria de ARI (RFC 9773) |
| Paradigma de revocación | CRL / OCSP + sustitución masiva de emergencia en los suscriptores | Adelanto coordinado de la renovación mediante endpoints ARI |
| Vía poscuántica | Firmas X.509 híbridas en evaluación | Merkle Tree Certificates (MTC) nativos que conviven con X.509 clásico |
| Escala y carga inicial | ~10 M de certificados al día en más de 500 M de sitios | Validación Customer Zero en más del 20 % del tráfico web mundial |
Comprar una raíz en lugar de esperarla #
La decisión más práctica del anuncio tiene que ver con la raíz. Cloudflare dice haber firmado un acuerdo definitivo para adquirir a GlobalSign una raíz establecida y de amplia confianza. La fuente da la razón directamente: una raíz completamente nueva no resulta útil de forma amplia durante años. La raíz existente de GlobalSign, en cambio, goza de confianza en navegadores, sistemas operativos y dispositivos desde 2012.
La confianza en una raíz avanza despacio porque está instalada en los dispositivos, y los dispositivos se actualizan despacio. Una raíz nueva puede ser aceptada por todos los programas y aun así no validarse en un teléfono antiguo o en un sistema embebido. Adquirir una raíz que ya está en el terreno desde 2012 evita esa espera, al menos tal como lo plantea la fuente.
Cloudflare no abandona del todo la vía de una raíz nueva. También presentará una raíz nueva para su inclusión en los programas de claves raíz, que describe como pensada para hacia dónde se dirige el ecosistema, incluidos programas que empiezan a limitar la antigüedad que puede tener una raíz de confianza. Ese último detalle recuerda que la antigüedad corta en ambos sentidos. La antigüedad de una raíz de confianza es una ventaja para la cobertura de dispositivos, y algunos programas avanzan hacia límites sobre la antigüedad de las raíces de confianza. Gestionar a la vez una raíz adquirida y una nueva solicitud parece una respuesta a esa tensión, aunque la fuente no explica el razonamiento en esos términos.
Un servicio ACME primero, con condiciones #
La adopción es el punto en el que muchos anuncios de CA se vuelven vagos. Cloudflare es concreto. Su CA pública será ACME primero, es decir, hablará el protocolo Automated Certificate Management Environment que ya usa la automatización existente. La afirmación es que quien ya apunte a una CA gratuita existente puede pasarse a la CA de Cloudflare cambiando una URL de directorio, sin herramientas nuevas y sin rehacer la arquitectura. Es un plan, no una ruta de migración probada, y hay que leerlo así. Pero un cambio de configuración de una línea es el objetivo adecuado, porque el coste de migrar es lo que mantiene a la gente en una opción por defecto.
La trampa es un requisito que la mayoría de los usuarios de ACME no han tenido que cumplir. Cloudflare solo emitirá a clientes compatibles con ACME Renewal Information, o ARI, estandarizado en el RFC 9773. Los suscriptores deben mantener una automatización que consulte el endpoint de renovación de Cloudflare, actúe según las ventanas de renovación que Cloudflare publica e identifique el certificado que sustituye.
Es una postura firme, y creo que es la correcta. También plantea una pregunta legítima sobre la adopción: una CA que solo atiende a clientes compatibles con ARI es más restringida que una que atiende a cualquiera con una biblioteca ACME. La fuente no dice cuántos clientes quedan excluidos hoy, así que no voy a adivinarlo. Lo que sí dice es por qué Cloudflare quiere esa restricción.
Revocar sin romper sitios #
Cloudflare afirma haber observado ciertas cosas en los últimos 16 años, y una de esas observaciones guía este diseño. Ha visto autoridades de certificación atrapadas entre una revocación oportuna y mantener en línea los sitios de sus suscriptores.
Esa tensión es real para cualquier CA. Revocar un certificado rápidamente protege al público, pero puede tumbar todos los sitios que dependen de ese certificado si el suscriptor no puede sustituirlo con suficiente rapidez. Una CA atrapada en medio o revoca tarde o rompe a sus clientes.
ARI es la respuesta de Cloudflare. Cuando haya que retirar certificados, Cloudflare dice que puede adelantar las ventanas de renovación de los certificados afectados. Como los suscriptores están obligados a consultar el endpoint de renovación y a actuar según las ventanas publicadas, la CA puede llevarlos hacia la sustitución antes de que llegue una revocación tajante. Este mecanismo se describe como una capacidad que Cloudflare pretende tener, no como una que haya demostrado como CA. Aun así, la lógica se sostiene: la obligación de consultar existe para que esta palanca funcione.
El mismo razonamiento aparece en un objetivo de diseño más amplio. Cloudflare pretende construir una autoridad de certificación cuya fiabilidad no dependa solo de evitar errores sino, como en el resto de los productos de Cloudflare, de fallar en pequeño y limitar el impacto de cada problema. Evitar errores es necesario para una CA, y ninguna CA puede prometerlo a la perfección. Diseñar para que un error quede contenido es la postura de ingeniería más honesta.
Transparencia más allá de la auditoría #
A las CA públicas se las juzga normalmente por sus auditorías. La fuente es tajante sobre sus límites: las auditorías son puntuales y te dicen que una CA aprobó. No te dicen lo que hace la CA un martes cualquiera después.
La respuesta de Cloudflare es decir que publicará compilaciones reproducibles del software que firma los certificados. Se presenta como un compromiso, no como un entregable terminado. Las compilaciones reproducibles permiten a terceros comprobar que el binario que se ejecuta en la ruta de firma corresponde al código fuente publicado, lo que es una propiedad continua, algo que un informe de auditoría no es. Que resulte suficiente dependerá de lo que Cloudflare publique realmente y de que otros lo comprueben.
La segunda mitad del anuncio: Merkle Tree Certificates #
El material poscuántico es donde el anuncio mira más lejos. Cloudflare anuncia su plan de ser una de las primeras CA en servir certificados poscuánticos, y prevé emitir sus primeros Merkle Tree Certificates en el primer trimestre de 2027. Otro pasaje de la fuente dice que los primeros MTC se esperan a principios de 2027. Ambos son planes.
La fuente describe los MTC como una forma nueva y mucho más compacta de entregar certificados de confianza pública. Esa formulación es una descripción, y la fuente no aporta mediciones en los pasajes con los que trabajo, así que no puedo decir cuánto más compactos son. Cloudflare dice que ha estado impulsando en el IETF la propuesta basada en estándares para los MTC. También informa de que Chrome designó a principios de este año los MTC como la vía preferida para la autenticación poscuántica. Ese es un hecho demostrado, y es importante, porque la preferencia declarada de un fabricante de navegadores es lo que convierte una propuesta en algo con lo que una CA puede planificar.
Cloudflare no espera una transición repentina. Prevé que gran parte de Internet siga dependiendo de los certificados clásicos y de la WebPKI existente durante muchos años más. A lo largo de ese periodo, espera que los MTC ganen una cuota de emisión en crecimiento constante. Son expectativas, y la fuente las presenta como tales.
Una CA, un ciclo de vida #
La decisión de arquitectura que se deriva de esto es la que me parece más convincente. La nueva CA está diseñada para albergar certificados clásicos y Merkle Tree Certificates bajo una sola CA, con un solo ciclo de vida y un solo conjunto de garantías. Los clientes pueden adoptarla al ritmo que les convenga y ayudar a la web a hacer la travesía sin un corte brusco.
La alternativa son dos CA paralelas, dos conjuntos de procedimientos y una migración forzada en algún momento. Un corte brusco es la forma más arriesgada de cambiar un ecosistema de certificados, y el objetivo declarado de la fuente es evitarlo. La formulación es prudente, y con razón: es una intención de diseño para una CA que todavía no emite.
También encaja con el cuadro de incentivos. Cloudflare dice esperar que el número de certificados de los que depende cada año siga creciendo a medida que disminuyan los periodos máximos de validez, aumente la actividad agéntica y los certificados poscuánticos se generalicen. Más certificados, emitidos con más frecuencia, abogan por la automatización y por una CA que trate la renovación como una operación de primer orden. Un sistema construido en torno a ARI y a un solo ciclo de vida es una respuesta razonable a esa expectativa, aunque la expectativa en sí sea una previsión y no una medición.
Customer Zero #
¿Cómo se prueba una CA antes de que el público confíe en ella? La respuesta de Cloudflare es ser su propio primer cliente. Será el Customer Zero de la nueva CA y de sus certificados, tanto WebPKI como MTC. El propósito declarado es garantizar que todos los aspectos de los nuevos sistemas y procesos cumplan los elevados estándares internos de Cloudflare, y que la infraestructura de la CA se ponga a prueba a la escala de Cloudflare.
Dadas las cifras anteriores, es una carga interna exigente: millones de certificados al año, en una empresa que está por delante de más del 20 por ciento del tráfico mundial de solicitudes. Las afirmaciones no pueden decirnos si los primeros años de operación irán bien. Lo que sí muestran es un orden de operaciones sensato. La empresa empieza como usuaria intensiva de lo que está construyendo, con un historial de aprovisionamiento con varias CA, rutas de respaldo y 16 CA asociadas detrás.
Conviene decir con claridad lo que falta. Nada en la fuente recoge volúmenes de emisión, tasas de error, latencia de validación ni historial de incidentes de la propia CA de Cloudflare, porque ese historial todavía no existe. El anuncio es una declaración de intenciones respaldada por solicitudes, un acuerdo de adquisición y un diseño. No es una trayectoria.
Qué vigilar #
Tres cosas decidirán si esto es una aportación significativa a la WebPKI o simplemente un anuncio interesante.
La primera son los programas raíz. Cloudflare ha presentado solicitudes a Chrome, Apple, Microsoft y Mozilla, y los procesos son públicos. Seguirlos es la forma más directa de ver hasta dónde ha llegado el plan, y ninguna de las afirmaciones me permite predecir el resultado.
La segunda es el requisito de ARI. Una CA que exige compatibilidad con el RFC 9773 apuesta a que la automatización de la renovación puede impulsarse en toda su base de suscriptores. Si la apuesta sale bien, Cloudflare podrá adelantar las ventanas de renovación cuando haya que retirar certificados, que es la respuesta declarada al dilema de la revocación que ha observado. Si sale mal, la adopción será más lenta de lo que sugiere el relato de la migración en una línea.
La tercera es el primer trimestre de 2027. Es cuando Cloudflare prevé sus primeros Merkle Tree Certificates. La pregunta abierta es con qué rapidez crecerá realmente la cuota en crecimiento constante que espera, dada su propia opinión de que gran parte de Internet seguirá con certificados clásicos durante muchos años más. La empresa ha dicho que la travesía no debería requerir un corte brusco. El primer trimestre de 2027 será la primera ocasión de ver si una CA que alberga ambos tipos de certificado puede hacerlo realidad.
Qué significa por sector #
La aparición de una autoridad de certificación pública automatizada y de gran volumen procedente de un proveedor de infraestructura en el borde modifica el riesgo operativo y la planificación de PKI en varios ámbitos técnicos.
Infraestructura en la nube y redes en el borde #
Operar una CA pública a escala de borde reduce la dependencia externa de API de verificación y CRL de terceros. Al combinar la terminación en el borde mediante proxy inverso con renovaciones automatizadas ACME ARI, los proveedores de infraestructura pueden aislar a sus clientes de las caídas de autoridades de certificación ascendentes.
PKI empresarial y equipos DevOps #
Las organizaciones que dependen de Let's Encrypt para sus endpoints públicos obtienen una alternativa automatizada y creíble. Sin embargo, la aplicación obligatoria del RFC 9773 (ARI) implica que los equipos deben auditar sus clientes ACME (Certbot, Lego, Caddy, Traefik) para asegurarse de que la compatibilidad con ARI está activa antes de cambiar de endpoint de directorio.
Fabricantes de navegadores y gobernanza de raíces #
Los programas raíz (Chrome, Mozilla, Apple, Microsoft) se enfrentan a un ecosistema creciente de CA automatizadas de gran volumen. El enfoque de doble raíz (adquirir una raíz heredada de 2012 mientras se presenta una raíz moderna) sortea unas políticas de navegador que restringen cada vez más la vida útil de los certificados raíz, al tiempo que mantiene la compatibilidad con dispositivos antiguos.
Conclusión #
El paso de Cloudflare para convertirse en una autoridad de certificación pública aborda una vulnerabilidad estructural real de la WebPKI moderna: la concentración extrema en la emisión gratuita y automatizada de certificados. Al combinar una raíz establecida de GlobalSign, una automatización estricta de la renovación con ARI y un puente hacia los Merkle Tree Certificates poscuánticos, el diseño apunta a la resiliencia operativa y no al mero aprovisionamiento de certificados. El éxito dependerá de las aprobaciones de los programas raíz y de la rapidez con que las herramientas cliente adopten los estándares ARI antes del despliegue de 2027.
Preguntas frecuentes #
¿Puedo cambiar hoy mismo mi cliente ACME a la CA de Cloudflare?
Todavía no. Cloudflare ha anunciado su intención, ha firmado el acuerdo de adquisición de la raíz y ha presentado solicitudes a los principales programas raíz. La emisión pública está prevista tras las aprobaciones de los programas raíz.
¿Qué es ACME Renewal Information (ARI) y por qué importa?
ARI (RFC 9773) es una extensión del protocolo ACME que permite a las autoridades de certificación indicar a los suscriptores cuándo debe renovarse un certificado. Así las CA pueden coordinar con fluidez renovaciones anticipadas antes de revocaciones planificadas y evitar caídas de sitios.
¿En qué se diferencian los Merkle Tree Certificates (MTC) de los certificados X.509 estándar?
Los MTC sustituyen las firmas criptográficas individuales tradicionales por pruebas de inclusión Merkle ancladas en un registro verificable públicamente. Esto reduce de forma notable el tamaño de los certificados y la sobrecarga de transmisión, lo que los convierte en un candidato preferente para la autenticación TLS poscuántica.
Referencias #
- Cloudflare, (2026). Construir una autoridad de certificación para todo Internet ⧉. Blog de Cloudflare.
- IETF, (2024). RFC 9773: Automated Certificate Management Environment (ACME) Renewal Information (ARI) ⧉. IETF.
- IETF, (2025). Merkle Tree Certificates para TLS ⧉. IETF.
- Chrome Root Program, (2026). Política y consideraciones sobre la autenticación poscuántica ⧉. Chromium Projects.
Última revisión .
Última revisión .
Republicar este artículo
Copiar formato para Medium
# Cloudflare quiere ser CA ante la concentración de las CA gratuitas — Sebastien Rousseau > Originally published at [https://sebastienrousseau.com/es/2026-09-20-cloudflare-quiere-ser-ca-ante-concentracion/](https://sebastienrousseau.com/es/2026-09-20-cloudflare-quiere-ser-ca-ante-concentracion/) Cloudflare quiere ser una autoridad de certificación pública: solicitud a los programas raíz, compra de una raíz de GlobalSign, ARI obligatorio y certificados Merkle. Read the full article on sebastienrousseau.com: https://sebastienrousseau.com/es/2026-09-20-cloudflare-quiere-ser-ca-ante-concentracion/
Copiar formato para Mastodon
Cloudflare quiere ser CA ante la concentración de las CA gratuitas — Sebastien Rousseau Cloudflare quiere ser una autoridad de certificación pública: solicitud a los programas raíz, compra de una raíz de GlobalSign, ARI obligatorio y certificados Merkle. https://sebastienrousseau.com/es/2026-09-20-cloudflare-quiere-ser-ca-ante-concentracion/
Copiar formateado para LinkedIn
Cloudflare quiere ser CA ante la concentración de las CA gratuitas — Sebastien Rousseau Cloudflare quiere ser una autoridad de certificación pública: solicitud a los programas raíz, compra de una raíz de GlobalSign, ARI obligatorio y certificados Merkle. Estos son los puntos estratégicos clave: - Un consumidor de certificados se convierte en emisor. La mayoría de las empresas de infraestructura se quedan en un solo lado de la relación con los certificados. - Por qué Cloudflare está en posición de plantear la cuestión. El argumento de Cloudflare para crear una CA parte de su posición como cliente. - El problema de la concentración. Las cifras detrás de ese argumento son llamativas. - Comprar una raíz en lugar de esperarla. La decisión más práctica del anuncio tiene que ver con la raíz. ¿Cuál es el enfoque de su organización ante los desafíos descritos en este artículo? → https://sebastienrousseau.com/es/2026-09-20-cloudflare-quiere-ser-ca-ante-concentracion/ #Cloudflare #AutoridadDeCertificación #CaPública #Webpki #Let'sEncrypt Sebastien Rousseau | CC-BY-4.0
Citar este artículo
Cloudflare quiere ser CA ante la concentración de las CA gratuitas — Sebastien Rousseau
Cloudflare quiere ser una autoridad de certificación pública: solicitud a los programas raíz, compra de una raíz de GlobalSign, ARI obligatorio y certificados Merkle.
BibTeX
@online{rousseau2026cloudflare,
author = {Rousseau, Sebastien},
title = {{Cloudflare quiere ser CA ante la concentración de las CA gratuitas — Sebastien Rousseau}},
year = {2026},
url = {https://sebastienrousseau.com/es/2026-09-20-cloudflare-quiere-ser-ca-ante-concentracion/},
urldate = {2026}
}RIS
TY - GEN AU - Rousseau, Sebastien TI - Cloudflare quiere ser CA ante la concentración de las CA gratuitas — Sebastien Rousseau PY - 2026 UR - https://sebastienrousseau.com/es/2026-09-20-cloudflare-quiere-ser-ca-ante-concentracion/ ER -
Vancouver
Rousseau S. Cloudflare quiere ser CA ante la concentración de las CA gratuitas — Sebastien Rousseau. sebastienrousseau.com. 2026 Sep 20. Available from: https://sebastienrousseau.com/es/2026-09-20-cloudflare-quiere-ser-ca-ante-concentracion/
Chicago
Rousseau, Sebastien. "Cloudflare quiere ser CA ante la concentración de las CA gratuitas — Sebastien Rousseau." sebastienrousseau.com. September 20, 2026. https://sebastienrousseau.com/es/2026-09-20-cloudflare-quiere-ser-ca-ante-concentracion/.
APA
Rousseau, S. (2026, September 20). Cloudflare quiere ser CA ante la concentración de las CA gratuitas — Sebastien Rousseau. sebastienrousseau.com. https://sebastienrousseau.com/es/2026-09-20-cloudflare-quiere-ser-ca-ante-concentracion/
Volver a publicar este artículo
Cloudflare quiere ser CA ante la concentración de las CA gratuitas — Sebastien Rousseau
Cloudflare quiere ser una autoridad de certificación pública: solicitud a los programas raíz, compra de una raíz de GlobalSign, ARI obligatorio y certificados Merkle.
Este artículo se publica bajo Creative Commons Attribution 4.0 International. La republicación requiere atribución a la URL canónica.
Cloudflare quiere ser CA ante la concentración de las CA gratuitas — Sebastien Rousseau Cloudflare quiere ser una autoridad de certificación pública: solicitud a los programas raíz, compra de una raíz de GlobalSign, ARI obligatorio y certificados Merkle. Originally published at https://sebastienrousseau.com/es/2026-09-20-cloudflare-quiere-ser-ca-ante-concentracion/ by Sebastien Rousseau. Licensed under CC-BY-4.0.