Última actualización: 5 de enero de 2025

RESUMEN EJECUTIVO: La PKI de Internet (Public Key Infrastructure) es un ecosistema sensible y a veces frágil. Desde que Netscape diseñó el núcleo de su sistema de confianza en 1995, la comunidad internacional de la seguridad ha trabajado para comprender las amenazas y, con el tiempo, desarrollar distintas mitigaciones, mientras el mundo continuaba funcionando adaptándose a estos cambios. Red Sift ha estado muy implicada en este ámbito, explorando el estado del arte en protección de PKI y trabajando para proteger a nuestros clientes.

Este libro blanco ofrece un análisis exhaustivo de las lecciones que aprendimos durante el desarrollo de Red Sift Certificates, nuestra solución líder para la supervisión de la postura PKI. Empezamos con una visión de cómo se gestiona la confianza a nivel mundial y vamos introduciendo conceptos y tecnologías cada vez más complejas, hasta llegar a las técnicas que hemos implementado para ayudar a nuestros clientes a cumplir sus objetivos de seguridad. Finalmente, presentamos la Monitorización de Transparencia de Certificados de Alta Garantía, una técnica imprescindible para aquellas organizaciones que requieren máxima seguridad pública en PKI.

Los últimos 15 años han sido especialmente positivos para Internet en lo que respecta a la seguridad de la capa de transporte. Tras décadas de abandono, hemos asistido a un esfuerzo decidido para conseguir un cifrado robusto, esfuerzo que sigue en marcha actualmente. Fueron necesarios muchos años, pero la comunidad de ingenieros logró actualizar el Transport Layer Protocol (TLS), incorporando criptografía moderna, eliminando elementos obsoletos y manteniendo la compatibilidad hacia atrás. Un éxito rotundo.

Sin embargo, las PKI públicas siguen siendo, en esencia, tan seguras (o inseguras) como siempre lo han sido.

En 2011, una pequeña Certification Authority (CA) holandesa llamada DigiNotar fue atacada y su seguridad fue completamente comprometida. En los días siguientes, se emitieron cientos de certificados para algunas de las propiedades más conocidas del mundo: Google, Microsoft, Mozilla, Twitter... Elija cualquiera; se emitieron certificados fraudulentos para todas ellas.

Para empeorar la situación, estos certificados se usaron contra aproximadamente 300.000 usuarios en un ataque de red activo diseñado para comprometer el cifrado y obtener sus secretos y contraseñas. Un ataque de esa escala fue inédito; nunca se había visto antes ni se ha repetido desde entonces.

Lo mismo podría ocurrir hoy, porque las debilidades fundamentales de nuestro modelo de confianza siguen existiendo.

Public Key Infrastructure (PKI) se refiere al marco de tecnologías, políticas y procedimientos utilizados para gestionar identidades digitales. Por ejemplo, cada sitio web necesita una identidad digital que los consumidores puedan verificar para garantizar un acceso seguro y cifrado. Estas identidades se basan en claves privadas de cifrado que pueden verificarse usando las claves públicas correspondientes. En la práctica, incluimos estas claves públicas dentro de certificados que contienen toda la información necesaria para realizar la validación. Desde la perspectiva del usuario final, los certificados son un detalle técnico que garantiza la seguridad, pero tras bastidores existe un ecosistema complejo encargado de asegurar que estos certificados aporten la protección necesaria.

A pesar de la palabra "pública" en el nombre, una PKI no tiene por qué ser pública. Cualquiera puede crear su propia PKI privada y aplicar las reglas que desee. Sin embargo, la seguridad a escala mundial solo es posible con PKI públicas creadas bajo reglas bien definidas y abiertas a la participación de cualquiera. La Web PKI es un ejemplo de PKI pública, fuertemente regulada y gestionada por los grandes fabricantes de navegadores y usada para la protección de sitios web. También existe la Internet PKI, que está menos definida y a veces opera dentro del marco de la Web PKI y otras veces no. Para nuestros propósitos aquí, la distinción rara vez será importante, pero la destacaremos cuando lo sea.

Como ya hemos mencionado, en la superficie usamos certificados digitales para autenticar el acceso a sitios web. Esa parte es sencilla: antes de acceder al destino, el sitio web debe presentar un certificado válido y demostrar la posesión de la clave privada correspondiente. Sin embargo, el proceso para emitir certificados es mucho más complejo.

Primero, seleccionamos un grupo de organizaciones de confianza que llamamos Certification Authorities (CA). Nos aseguramos de que cuenten con conocimientos en seguridad de redes y competencia general, y les proporcionamos instrucciones precisas sobre el formato de los certificados. El principal requisito es garantizar que los certificados digitales se emitan solo a sus legítimos dueños, mediante el proceso conocido como validación.

Aquí viene la parte complicada: realizar la validación a escala mundial no es fácil, porque hay que generar relaciones de confianza desde cero. El enfoque dominante hoy en día es la prueba de control de infraestructura. En la práctica, esto significa que, si quieres un certificado para "google.com", solo tienes que demostrar cierto nivel de control sobre ese dominio, por ejemplo, publicando un archivo especial en su sitio web.

Este diseño, creado por Netscape en los inicios de Internet, permitió el crecimiento explosivo de la Web, porque es accesible para cualquiera. Lamentablemente, conlleva dos debilidades inherentes:

• La validación se realiza a través de redes públicas sin autenticación criptográfica. Un adversario que consiga atacar el enrutamiento de la red o el DNS, o que intercepte la comunicación, podrá manipular el proceso y obtener certificados fraudulentos.
• Los propietarios de los dominios no tienen control sobre qué certificados se emiten sobre sus propiedades. Es decir, las CA son de confianza para hacer su trabajo correctamente. Aunque las auditamos para certificar su competencia, en la práctica ocurren y han ocurrido infinidad de fallos. Como vimos con DigiNotar, pueden romper su propia seguridad. Pueden cometer errores operacionales o ser víctimas de ingeniería social. O pueden ser obligadas legalmente por sus gobiernos a hacer cosas no permitidas.

Comprender estas debilidades es clave para diseñar estrategias de detección, prevención y mitigación en caso de ataques reales.

Como ya se explicó, los certificados solo se emiten tras una demostración satisfactoria de control sobre la parte relevante de la infraestructura de red. Para los nombres de dominio, el proceso suele ser el siguiente:

1. Se solicita un certificado para example.com a una CA
2. La CA genera un número aleatorio largo y lo envía de vuelta
3. El solicitante publica el número aleatorio en el sitio web example.com en texto plano
4. La CA verifica que dicho número puede observarse a través de HTTP
5. La CA emite el certificado

¿Qué deducimos de esto? El proceso de validación depende de elementos básicos de Internet, como la resolución DNS, el enrutamiento de IP mediante el protocolo BGP y la suposición de que la comunicación no será interceptada. Hoy en día, ninguno de estos elementos es completamente seguro y existen múltiples ataques posibles contra ellos. Por ejemplo, un ataque BGP puede redirigir el tráfico de una IP al atacante en vez de a su propietario legítimo. La suplantación de DNS puede redirigir el tráfico web a una IP controlada por el atacante. Un ataque activo contra cualquiera de los extremos (el sitio o la CA) logra el mismo efecto.

Ya que comprendemos la importancia de las CA para la seguridad de Internet, ¿qué sabemos de ellas? Los fabricantes de navegadores confían en el sistema Common CA Database (CCADB) para hacer seguimiento de las CA y sus certificados digitales con poderes especiales para emitir certificados de usuario final. Esta base de datos es pública y, recientemente, la he consultado. Esto es lo que descubrí:

• Hay 94 organizaciones CA en la base de datos, en las que confía al menos uno de los cuatro grandes fabricantes (Apple, Google, Microsoft o Mozilla).
• De esas, 39 organizaciones gozan de la confianza de los cuatro fabricantes.
• Las 94 organizaciones se distribuyen en 42 países.
• El grupo reducido de 39 organizaciones está en 22 países.

¿Qué se puede concluir? En primer lugar, el mero número de organizaciones supone una superficie de ataque considerable. Para que nuestra seguridad se mantenga, todas deben actuar correctamente y evitar errores operativos. En segundo lugar, en un mundo de complejas relaciones políticas, tener CA en tantos países crea posibilidades teóricas y prácticas de abusos políticos.

Estas debilidades no son meramente teóricas. De hecho, todas ellas se han explotado en diferentes momentos:

• En 2011 se comprometió por completo la seguridad de DigiNotar CA y se emitieron cientos de certificados fraudulentos.
• En 2021, se descubrió que el dominio de nivel superior .cd tenía un servidor de nombres mal configurado, lo que permitió a un investigador redirigir el 50% del tráfico DNS de .cd (subdominios incluidos).
• En 2022, unos atacantes ejecutaron un ataque BGP contra KLAYswap, una casa de cambio de criptomonedas de Corea, y robaron 2 millones de dólares en criptodivisas.
• En 2023, el acceso de red al servidor web "jabber.ru" fue secuestrado, presuntamente por las autoridades en Alemania, lo que permitió emitir un certificado usado posteriormente para descifrar todos los accesos cifrados.
• En 2024 se descubrieron actividades del grupo de espionaje Salt Typhoon, con indicios de compromiso de la conectividad de red de 60 organizaciones en 80 países.
• En 2025 se descubrió que la CA Fina había emitido doce certificados para la dirección IP 1.1.1.1 (propiedad de Cloudflare) sin permiso, durante 16 meses.

Estos incidentes son solo una muestra representativa de lo que conocemos. Cada ejemplo ilustra un vector de ataque diferente. Es probable que existan otros ataques similares aún no descubiertos.

Tras el ataque a DigiNotar en 2011, surgieron numerosas propuestas para mejorar la seguridad de las PKI públicas. Las que buscaban cambios sustanciales en los procesos de emisión de certificados no prosperaron. Las orientadas a mejoras incrementales sí, y Certificate Transparency (CT) fue una de ellas. Ayudó mucho el hecho de que esta iniciativa surgiera en Google, gracias al poder de su navegador Chrome.

El objetivo de CT, como su nombre indica, es ampliar la Web PKI con sistemas que ofrezcan visibilidad total sobre la emisión de certificados. Si no podemos cambiar cómo funciona la confianza en esencia (sin controles técnicos sobre el trabajo de las CA), al menos nos centramos en poder observar lo que hacen.

Con CT, la Web PKI se amplía con logs de CT, que ejercen de auditores. Antes de emitir un certificado, su información clave debe registrarse en varios logs CT gestionados de manera independiente. Para cada certificado a emitir, los logs devuelven confirmaciones en forma de firmas digitales. Finalmente, estas firmas se integran en el propio certificado.

El último paso es el que hace que el sistema funcione: ahora todos los certificados llevan pruebas de inclusión en los logs CT, por lo que los navegadores pueden alargar su validación y rechazar cualquier certificado cuya inclusión no pueda comprobarse. Como resultado, solo se pueden usar en sitios web certificados registrados públicamente.

Nota: Aquí es donde la distinción entre Web PKI e Internet PKI sí importa. Certificate Transparency solo se ha implementado como parte de Web PKI y la hacen cumplir los navegadores. Los certificados sin información CT son válidos y funcionales para propósitos de Internet PKI, pero no para sitios web. Esto puede cambiar en el futuro.

CT es prácticamente obligatorio desde 2018. Chrome fue el primer navegador en exigirlo, y solo eso bastó por su dominio de mercado. Apple, Microsoft y Mozilla siguieron el mismo camino. La visibilidad que CT ha proporcionado ha sido de enorme valor, pues permite la monitorización mundial masiva de la emisión de certificados, habilitando mejoras y ajustes continuos que aún siguen en curso.

Nota: Las especificaciones técnicas que regulan la emisión de certificados las gestiona el CA/Browser Forum. Navegadores y CA deciden de forma conjunta cómo validar y emitir certificados. Pero la relación no es simétrica: los navegadores eligen en quién confían, lo que les otorga ventaja en la negociación.

Como ya hemos visto, Certificate Transparency es una herramienta muy útil para la monitorización global del ecosistema, pero también permite a los propietarios de dominios vigilar qué certificados se emiten sobre sus propiedades. Como recordamos, las debilidades del modelo PKI público permiten que terceros, maliciosos o no, emitan certificados sobre dominios que no les pertenecen. Gracias a CT, cualquiera puede monitorizar certificados para cualquier nombre de dominio.

Las organizaciones preocupadas por actividades no autorizadas pueden desplegar monitores CT que examinen el flujo global de certificados y encuentren los relacionados con ellas. Esto habilita dos posibilidades especialmente interesantes:

• El propietario de un dominio puede monitorizar sus propios certificados para entender los patrones y centros de emisión, así como saber qué CA usan diferentes partes.
• Además, es posible descubrir certificados no autorizados. Es decir, CT permite detectar certificados mal emitidos.

El sistema Certificate Transparency, tal y como está implementado hoy, no proporciona visibilidad perfecta sobre todas las emisiones de certificados en el mundo. Esto se debe a que no todos los proveedores exigen su publicación en CT como parte de su root store policy. Actualmente, la situación es así:

• Apple exige CT para todos los certificados, incluido su navegador y cualquier software basado en sus bibliotecas oficiales
• Chrome de Google exige CT para todos los sitios web
• El Edge de Microsoft, basado en Chromium, también exige CT
• Firefox de Mozilla también exige CT

Puesto que CT no es requisito en los Baseline Requirements y las root store policies no exigen a todas las CA registrar todo en CT, existen huecos explotables. Por tanto, técnicamente, no es obligatorio publicar todo en CT. Aunque las CA suelen enviar todo a CT por defecto, algunas ofrecen posibilidad de exclusión voluntaria y, además, pueden verse forzadas legalmente a emitir fuera de CT.

Obviamente, dichos certificados no serán válidos para sitios web, pero podrían pasar la validación en muchos otros casos:

• Solicitudes API (salvo desde las plataformas de Apple)
• Comunicaciones entre servidores, por ejemplo para correo electrónico o XMPP

Esperamos que en el futuro el alcance de CT se amplíe hasta incluir todos los certificados públicos. De momento, ten en cuenta estas limitaciones y actualiza tus modelos de amenazas según corresponda.

Certification Authority Authorization (CAA) es un estándar que permite a los propietarios de dominios controlar la emisión de certificados para sus propiedades. Las políticas CAA se almacenan en el sistema DNS, usando el registro de recurso CAA. Incluye varias funciones:

• Controlar qué CA pueden emitir
• Controles separados para emisión de certificados estándar, comodines, así como certificados de correo y BIMI
• Posibilidad de definir políticas detalladas a nivel de cada CA
• Distribución de información de contacto en caso de problemas

Considera la siguiente configuración de ejemplo:

example.com.  CAA     0 issue "letsencrypt.org"
example.com.  CAA     0 issuewild "digicert.com"
example.com.  CAA     0 issuewild "sectigo.com"
example.com.  CAA     0 issuemail ";"
example.com.  CAA     0 issuevmc ";"
example.com.  CAA     0 iodef "pki@example.com"

CAA es un control que se aplica justo antes de emitir un certificado. No se aplica con un control técnico fuerte, pero es obligatorio para todas las CA según los Baseline Requirements. Cualquier emisión que no respete la configuración CAA del propietario se considera una mal emisión.

La capacidad esencial de CAA es limitar qué CA pueden emitir y para qué tipos de certificados. Si un dominio no tiene política CAA, cualquier CA y tipo de certificado está permitido. Si existe al menos una directiva para algún tipo (por ejemplo, "issue" para certificados estándar o "issuemail" para S/MIME), solo las CA listadas podrán emitir. Si se detecta un solo punto y coma, no está permitido emitir ningún certificado.

Vamos a desglosar la configuración del ejemplo anterior:

• Let's Encrypt puede emitir certificados estándar
• DigiCert y Sectigo pueden emitir certificados comodín
• No está permitida la emisión de certificados S/MIME ni BIMI
• La dirección "pki@example.com" puede usarse para avisos de problemas

Las etiquetas "issue" e "issuewild" funcionan de forma conjunta. Si solo existe "issue", se permite la emisión de certificados estándar y comodines. Si está presente "issuewild", esta restringe en exclusiva la emisión de certificados comodín.

CAA es flexible en cuanto a su ubicación. Esto permite que cada dominio tenga una configuración diferente. Además, si un subdominio carece de configuración CAA, se recurre y utiliza la configuración CAA del dominio padre, si existe.

En la sección anterior analizamos los mecanismos para restringir la emisión de certificados. ¿En qué beneficia esto exactamente? Es una medida muy valiosa porque reduce la superficie de ataque. Recordemos las debilidades del modelo PKI público: existen muchas CA con capacidad para emitir certificados para tus dominios y todas ellas deben acertar siempre en sus prácticas.

En la práctica, la mayoría de organizaciones solo usa un puñado de CA, dejando a las demás como un riesgo. Al usar CAA, se reduce ese riesgo al mínimo.

El enfoque recomendado básico sería el siguiente:

1. Crear un inventario completo de nombres de dominio propios
2. Usar CT para construir el inventario de todos los certificados públicos
3. Monitorizar CT durante un tiempo para identificar las CA realmente utilizadas
4. Implantar una política CAA que permita emisión únicamente a ese reducido grupo de CA observadas

Este procedimiento sencillo permite minimizar el riesgo del ecosistema PKI sin romper las prácticas actuales de emisión. La configuración deseada de CAA debe establecerse en cada registro de dominio. Según el nivel de seguridad buscado, puede usarse la misma lista para todos los dominios, o bien restringir solo a las CA utilizadas por dominio.

Nota: El DNS se usa habitualmente para delegar control limitado a terceros, por ejemplo para ofertar servicios gestionados en tu propio dominio. Esto suele realizarse mediante el registro CNAME. Establecer una política CAA en el dominio principal no debería impedir la emisión, incluso si los terceros desean usar una CA no contemplada en tu lista. Esto es porque CNAME delega todos los aspectos del DNS, incluida la configuración CAA. El único requisito es que los terceros estén al tanto de CAA y establezcan su propia configuración de CAA que se adapte a sus necesidades.  

El estándar CAA básico es un buen punto de partida, pero resulta insuficiente para organizaciones que necesitan proteger activos de alto valor. Una "brecha" relevante es que CAA restringe qué CA pueden emitir, pero no puede impedir que una tercera parte use esas mismas CA permitidas para obtener certificados. Esto se agrava porque prácticamente todas las organizaciones usan Let's Encrypt para obtener certificados gratis y de manera automatizada. Así, la barrera de entrada para usar Let's Encrypt es muy baja.

Aquí surgen las extensiones ACME CAA. ACME (por Automatic Certificate Management Environment) es el estándar para emisión automatizada de certificados, popularizado por Let's Encrypt desde 2015 y ahora adoptado por todas las CA. La RFC 8657 estandariza dos funciones extra que se sitúan entre ACME y CAA:

• Restringir la emisión a cuentas concretas de clientes CA
• Restringir los métodos de validación ACME que pueden emplearse

En el momento de escribir esto, RFC 8657 no es obligatoria, pero se espera que sea adoptada en un futuro cercano. Actualmente, Let's Encrypt es la única CA que la admite oficialmente. La naturaleza de estas extensiones es que, a diferencia del CAA base, no necesitan ser compatibles con todas las CA para ser útiles, sino solo con las CA con las que tienes relaciones comerciales. Si tienes dudas, consulta con tu CA. Algunas cuentan con funcionalidades propietarias que pueden usarse con un efecto similar.

Con RFC 8657, es posible permitir la emisión de un nombre de dominio por parte de una CA, pero de modo que ningún otro cliente de esa misma CA pueda emitir para el mismo nombre. Así se vería este proceso al trabajar con Let's Encrypt:

example.com.  CAA  0  issue "letsencrypt.org;
                             accounturi=https://acme-v02.api.
                             letsencrypt.org/acme/acct/1726001367"

Mientras el fragmento de configuración anterior esté activo, solo la cuenta "1726001367" podrá obtener certificados de Let's Encrypt para el dominio "example.com". Si se necesita emisión desde varias cuentas, pueden configurarse varias etiquetas CAA, cada una permitiendo una cuenta de cliente diferente.

Otra funcionalidad de RFC 8657 es que permite restringir qué métodos de validación puede utilizar ACME antes de emitir un certificado. ACME ofrece una variedad de métodos y normalmente los clientes pueden elegir el que prefieran al solicitar un certificado. El método de validación más popular es la prueba de propiedad, que requiere que se publique en el sitio web una respuesta al desafío de la CA para el cual se solicita el certificado.

Este enfoque suele ser conveniente, ya que permite que cualquier servidor se comunique directamente con una CA y obtenga certificados para sí mismo. Sin embargo, en materia de seguridad, permitir que los propios servidores consigan sus certificados no suele ser lo ideal; quien controle un servidor podrá obtener certificados para cualquier dominio que apunte a él.

Una forma de explotar este tipo de disposición es mediante una mala configuración de DNS pendiente. Para que un nombre de dominio funcione, es necesario realizar cambios de configuración en dos lugares. Primero, en el DNS, donde los registros A y AAAA se usan para añadir direcciones IPv4 e IPv6, respectivamente. Después, se debe configurar un servidor en esas mismas direcciones IP para proporcionar respuestas. Un problema de DNS pendiente se crea cuando un servidor se da de baja pero sus entradas de DNS permanecen. Imagina que las direcciones IP provinieran de un servicio en la nube, algo muy común. Ahora, cualquier persona a quien se le asignen esas IP puede obtener certificados para el dominio con DNS pendiente. Este es solo un ejemplo; existen otros vectores de ataque en el DNS que pueden tener el mismo efecto.

Una organización que quiera prevenir este tipo de problemas puede optar por centralizar la emisión de sus certificados y emplear la opción de validación de ACME basada en DNS. Sin embargo, para que esto funcione, deben asegurarse de que todos los demás métodos de validación estén deshabilitados. Así se vería esto usando RFC 8657:

example.com.    CAA    0    issue "letsencrypt.org;
                                   validationmethods=

                                  dns-01"

Con esta configuración, la emisión de certificados solo podrá aprobarse realizando cambios en la configuración DNS del dominio en el que se solicitan los certificados.

Los dos métodos de restricción especificados en RFC 8657 permiten limitaciones en cierta forma similares, pero existen diferencias clave entre ellos que pueden influir en cuál usar y en qué momento.

• La restricción por método de validación no requiere autenticación de la solicitud. Cuando la emisión se restringe a un método como "dns-01", solo quienes controlan tu DNS (o partes relevantes del mismo) pueden cumplir con la configuración CAA. Esto reduce la superficie de ataque, pero la solicitud de emisión en este caso aún no está autenticada. Por ejemplo, aún sería posible explotar una mala configuración de DNS.
• La restricción por cuenta exige autenticación fuerte. Cuando la emisión se restringe a una cuenta de cliente específica, esto obliga a una autenticación fuerte de la solicitud de emisión antes de cualquier validación. En ACME, por ejemplo, las cuentas se aseguran mediante criptografía de clave pública. La primera actividad de un cliente ACME es crear una identidad criptográfica única, que se usa posteriormente para cada emisión. Cuando la restricción por cuenta está en vigor, la autenticación de la solicitud es el primer paso en la interacción con ACME, pues el cliente tiene que demostrar su asociación con la cuenta especificada en la configuración CAA.

Nota: En junio de 2025, el CA/Browser Forum votó la adopción del Ballot SC-085v2, que añade el requisito de validar DNSSEC al realizar consultas CAA y DCV (validación de control de dominio). Estos cambios serán obligatorios para todas las CA a partir de marzo de 2026. Después de ese momento, los dominios con DNSSEC no serán susceptibles a ninguna forma de suplantación DNS. 

Las extensiones definidas en RFC 8657 nos permiten aplicar controles de seguridad más estrictos para la emisión de certificados, pero hacerlo no es gratuito. Se necesita tiempo y recursos para reestructurar y organizar la emisión de manera compatible y que al mismo tiempo proporcione mejor seguridad. Normalmente, no resulta útil aplicar este enfoque a todos los dominios que posee una organización, ya que no resulta coste-efectivo. Sin embargo, puede emplearse para un pequeño número de activos de alto valor. Para el resto, la opción más sencilla de limitar la emisión a unas pocas CA sería suficiente.

Para tus activos de alto valor, considera el siguiente enfoque:

1. Escoge dos o tres CA competentes con las que trabajar. Necesitas al menos dos para evitar un punto único de fallo. Para activos de alto valor, normalmente recomiendo tener al menos un certificado de respaldo válido por si ocurre algún problema con el certificado principal. Como mínimo, las CA seleccionadas deben soportar RFC 8567 o tener funcionalidades propietarias equivalentes.
2. Despliega una configuración CAA estricta en el dominio principal, que restrinja la emisión solo a las CA seleccionadas y—lo más importante—solo a las cuentas específicas dentro de esas CA. Esta configuración permitirá una validación criptográfica sólida.
3. Monitorea tu configuración DNS para a) asegurarte de que no existan problemas de DNS pendientes y b) saber si existen delegaciones a terceros por medio de CNAMEs (que pueden tener su propia configuración CAA sobrescribiendo la tuya).

Como ya hemos visto, Certificate Transparency ha sido revolucionaria para nuestra capacidad de monitorear la actividad de las autoridades de certificación. Sin embargo, el monitoreo presenta ciertos desafíos:

• Todavía es posible publicar certificados públicos fuera de CT, como se mencionó en una sección anterior de este documento.
• El monitoreo CT aún no está generalizado. A pesar de que es obligatorio desde hace varios años, la mayoría de las organizaciones todavía no destinan los recursos necesarios para monitorear la emisión de certificados en sus propios activos.
• Es difícil distinguir entre información relevante y ruido. Los certificados a menudo no contienen suficiente información como para ayudar a distinguir la emisión legítima de los certificados obtenidos fraudulentamente por terceros. Lograrlo requiere herramientas de monitoreo avanzadas, y la mayoría de organizaciones aún no las conocen.

Aunque nuestro objetivo en este documento es explorar el arte de lo posible, reconocemos que muchas organizaciones no necesitan seguridad de última generación. Incluso aquellas que sí lo requieren, a menudo no necesitan lo mejor en seguridad para todo su conjunto de dominios y sitios web.

Aconsejamos dividir tu conjunto de dominios en tres grupos según su riesgo:

• Riesgo muy bajo; coloca aquí cualquier dominio aparcado o sin uso. Dependiendo del tamaño de tu organización, puedes tener solo algunos, pero podrían ser cientos. Salvo que la automatización de tu configuración DNS sea excelente de forma general, probablemente no valga la pena invertir tiempo en mejorar la seguridad de este grupo. 
• Riesgo bajo; agrupa aquí los dominios en los que realmente tienes sitios web o aplicaciones. Esta debe ser tu opción por defecto. Para este grupo deberías desplegar una configuración CAA sencilla que limite la emisión a un pequeño número de CA con las que deseas trabajar, como ya se trató anteriormente. Es poco probable que estos activos sufran ataques, por lo que el CAA servirá mayormente para reforzar tu política de selección de CA.
• Riesgo alto; agrupa aquí tus activos más críticos—todo aquello que creas que podría estar realmente expuesto a ataques. Sitios web y aplicaciones relacionados con dinero, organismos gubernamentales, comunicaciones y cualquier cosa susceptible a ataques activos en la red. Querrás proteger este grupo empleando todas las medidas técnicas a tu disposición.

La monitorización CT de alta garantía es un enfoque donde puedes supervisar con gran certeza el flujo de certificados publicados por Certificate Transparency y distinguir los certificados bajo tu control de los que están bajo control de terceros no autorizados.

En concepto, el enfoque es sencillo y se basa en validar lo que se sabe que es bueno; todo lo demás solo puede ser indebido:

1. Mantén un inventario de los certificados que sabes que están bajo tu control
2. Monitorea Certificate Transparency para buscar certificados que no conozcas previamente

Eso es todo. Solo dos pasos, pero el primero puede requerir bastante trabajo en la práctica, dependiendo de tu infraestructura. Recuerda que esto solo lo harás para tus activos de alto riesgo, no para todos los dominios.

• Si usas una herramienta de gestión del ciclo de vida de certificados (CLM) o ACME con una CA comercial, probablemente incluirán un inventario de certificados integrado. No debería ser difícil extraer tus certificados, pero deberás programar contra sus API para obtenerlos.
• Si usas ACME con una CA gratuita (por ejemplo Let's Encrypt), puede que no tengas un inventario de certificados con el que integrarte. En este caso, necesitarás algún mecanismo para recolectar los certificados emitidos y transportarlos a un lugar central. Esto será más sencillo si todos tus certificados se emiten desde el mismo servidor, pero no debería suponer demasiada dificultad incluso con varios servidores.

En la práctica, lo más probable es que debas mantener una base de datos separada donde almacenes tus propios certificados. Esto se debe a que la emisión centralizada es muy poco común en la vida real, sobre todo a escala. Siempre hay situaciones especiales, incluidas aquellas en las que partes de tu PKI pública están delegadas a terceros. La solución completa necesitará integrar varias fuentes de datos para obtener una visión integral.