Monitorización de Transparencia de Certificados de Alta Garantía

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

Este libro blanco ofrece un análisis profundo de las lecciones que aprendimos al construir Red Sift Certificates, nuestra solución principal para la monitorización de la postura PKI. Comenzamos con una visión general de cómo el mundo gestiona la confianza e introducimos conceptos y tecnologías cada vez más complejos hasta explorar las técnicas que implementamos para ayudar a nuestros clientes a alcanzar 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 la máxima seguridad en la PKI pública.

Los últimos 15 años han sido muy positivos para Internet en lo que a seguridad de la capa de transporte se refiere. Tras décadas de abandono previo, hemos presenciado un esfuerzo decidido por asegurar la protección de cifrado, un esfuerzo que continúa hoy en día. Llevó muchos años, pero la comunidad de ingeniería trabajó para actualizar el Transport Layer Protocol (TLS), modernizando su criptografía, eliminando lo innecesario, y manteniendo la compatibilidad retroactiva. Un éxito rotundo.

Y, aún así, las PKI públicas siguen siendo, en esencia, tan seguras como siempre lo han sido.

En 2011, una pequeña Autoridad de Certificación (CA) neerlandesa llamada DigiNotar fue atacada y toda su seguridad comprometida. En los días siguientes, se emitieron cientos de certificados para algunas de las propiedades más importantes del mundo. Google, Microsoft, Mozilla, Twitter... elija usted—se emitieron certificados fraudulentos para todas ellas.

Para empeorar la situación, estos certificados se utilizaron contra aproximadamente 300.000 usuarios en un ataque activo de red diseñado para comprometer el cifrado y recolectar sus secretos y contraseñas. Un ataque de tal escala no tenía precedentes; no se había visto antes ni se ha visto desde entonces.

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

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 usuarios puedan verificar para asegurar el acceso cifrado. Estas identidades se fundamentan en claves privadas de cifrado que se pueden validar usando las correspondientes claves públicas. En la práctica, agrupamos estas claves públicas en certificados que contienen toda la información necesaria para la validación. Desde la perspectiva del usuario final, los certificados son un detalle técnico que garantiza la seguridad, pero existe un complejo ecosistema oculto que asegura que los certificados aporten la seguridad requerida.

A pesar de la palabra "pública" en el nombre, las PKI no tienen por qué ser públicas. Cualquiera puede crear su propia PKI privada y decidir las reglas que desee. Sin embargo, la seguridad a escala mundial solo puede proporcionarse mediante PKI públicas construidas con reglas bien definidas y permitiendo que todos participen. La Web PKI es un ejemplo de PKI pública; está fuertemente regulada y gestionada por los principales fabricantes de navegadores y se utiliza para proteger sitios web. También existe la Internet PKI, menos definida, que a veces trabaja dentro de la Web PKI y otras fuera de ella. Para nuestros fines, la distinción entre ambas generalmente no es muy importante, pero la resaltaremos cuando sí lo sea.

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

Primero, seleccionamos un grupo de organizaciones de confianza llamadas Autoridades de Certificación (CAs). Nos aseguramos de que conocen su trabajo en materia de seguridad de red y de que tienen competencia general, y les damos instrucciones precisas sobre cómo deben ser los certificados. El requisito principal aquí es asegurarse de que los certificados digitales se emitan solo a sus legítimos propietarios, mediante un proceso llamado validación.

Aquí viene la parte complicada: realizar la validación a escala mundial no es sencillo, pues hay que crear relaciones de confianza desde cero. El enfoque dominante en la actualidad es la prueba de control de la infraestructura. En la práctica, si desea un certificado para "google.com", solo tiene que demostrar un cierto control sobre ese dominio, por ejemplo, publicando un archivo especial en su website.

Este diseño, creado por Netscape en los primeros días de Internet, propició el crecimiento explosivo de la Web porque resulta fácil de usar. Desafortunadamente, tiene dos debilidades estructurales:

• La validación se realiza a través de redes públicas sin autenticación criptográfica. Un atacante que logre atentar con éxito contra el enrutamiento de la red o DNS, o secuestrar la comunicación, puede manipular la emisión y obtener certificados fraudulentos.
• Los propietarios de dominios no pueden controlar qué certificados se emiten para sus propiedades. Es decir, se confía en que las CAs harán su trabajo correctamente. Aunque se auditan para verificar su competencia, en la práctica pueden suceder y han sucedido diversos problemas. Como ya vimos con DigiNotar, su propia seguridad puede verse comprometida. Pueden cometer errores operativos o ser víctimas de ingeniería social. O pueden ser legalmente forzadas por sus gobiernos a realizar acciones no permitidas.

Comprender estas debilidades es fundamental para poder crear estrategias que permitan detectar o prevenir ataques, y minimizar los daños si llegan a ocurrir.

Como ya hemos analizado, los certificados se emiten solo tras demostrar con éxito el control sobre la infraestructura de red correspondiente. Para los nombres de dominio, el proceso es el siguiente:

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

¿Qué podemos deducir? El proceso de validación depende de algunos componentes básicos de Internet, como la resolución DNS y el enrutamiento de direcciones IP (vía BGP), y asume que la comunicación no será secuestrada. Actualmente, ninguno de estos elementos opera de forma segura, y existen diversos ataques posibles. Por ejemplo, un ataque BGP puede redirigir el tráfico de una IP al atacante en vez de al propietario legítimo. La suplantación de DNS se puede usar para enviar el tráfico de un sitio a una IP bajo control del atacante. Un ataque activo de red contra cualquiera de los extremos (website o CA) puede causar lo mismo.

Ahora que entendemos la importancia de las CAs para la seguridad de Internet, ¿qué información tenemos sobre ellas? Los fabricantes de navegadores confían en el sistema Common CA Database (CCADB) para rastrear las CAs y sus certificados digitales con poderes especiales de emisión. Esta base de datos es pública y recientemente analicé sus datos. Esto es lo que descubrí:

• Hay 94 organizaciones CA en la base de datos confiables por al menos uno de los cuatro grandes (Apple, Google, Microsoft o Mozilla).
• De esas, 39 son de confianza para los cuatro.
• Las 94 organizaciones están repartidas en 42 países.
• El grupo reducido de 39 organizaciones, en 22 países.

¿Qué podemos concluir de estos datos? Primero, solo el número de organizaciones ya representa una gran superficie de ataque. Para preservar nuestra seguridad, todas ellas deben hacer lo correcto para mantenerse seguras y evitar errores operativos. Segundo, en un mundo con relaciones políticas complejas, tener CAs en tantos países abre posibilidades tanto teóricas como reales de abuso político.

Estas debilidades no son solo teóricas. De hecho, todas se han materializado en diferentes momentos:

• En 2011, la seguridad de DigiNotar fue totalmente comprometida 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% de todo el tráfico DNS de .cd (incluidos subdominios).
• En 2022, atacantes ejecutaron un ataque BGP contra KLAYswap, una exchange de criptomonedas coreana, y robaron 2 millones de dólares en criptomonedas.
• En 2023, se secuestró el acceso de red al servidor web de "jabber.ru", aparentemente por las fuerzas de seguridad alemanas, lo cual permitió emitir un certificado usado para descifrar todo el acceso cifrado.
• En 2024, se detectó a Salt Typhoon, un grupo de espionaje, que comprometió la conectividad de red de 60 organizaciones en 80 países.
• En 2025, se descubrió que la CA Fina emitió doce certificados para la dirección IP 1.1.1.1 (propiedad de Cloudflare) sin permiso durante 16 meses.

Estos problemas son solo una muestra representativa de lo que conocemos. He seleccionado cada ejemplo para ilustrar un vector de ataque concreto. Probablemente existan otros ataques similares que permanecen sin descubrir.

Tras el ataque a DigiNotar en 2011, surgieron muchas propuestas para mejorar la seguridad de las PKI públicas. Aquellas que requerían cambios profundos en el modelo de emisión de certificados fracasaron; las que optaron por mejoras incrementales, triunfaron, destacando la Transparencia de Certificados (CT) como una de ellas. Ayudó el hecho de que esta iniciativa partiera de Google, que podía ejercer mucho poder a través de su navegador Chrome.

El objetivo de CT, como su nombre indica, es ampliar la Web PKI con sistemas que proporcionen visibilidad total sobre la emisión de certificados. Si no podemos cambiar los fundamentos de la confianza (no hay controles técnicos sobre la actividad de las CAs), al menos podemos observar lo que hacen.

Con CT, la Web PKI se extiende con logs CT que funcionan como auditores. Antes de emitir un certificado, su información esencial debe ser registrada por varios logs CT gestionados independientemente. Para cada certificado observado que está a punto de emitirse, los logs CT devuelven confirmaciones en forma de firmas digitales. En el paso final, estas firmas se incorporan en los propios certificados.

Este paso final es el que hace que el sistema funcione: al llevar todos los certificados pruebas de inclusión en los logs CT, los navegadores pueden ampliar su validación y rechazar cualquier certificado cuya inclusión no se pueda validar. Como resultado, solo pueden usarse en websites certificados registrados públicamente.

Nota: Aquí sí importa la distinción entre Web PKI e Internet PKI. Actualmente, la Transparencia de Certificados solo se ha implementado como parte de la Web PKI y los navegadores la hacen cumplir. Los certificados sin información CT siguen siendo técnicamente válidos; funcionarán para fines de Internet PKI, pero no para websites. Esto podría cambiar en el futuro.

CT es, en la práctica, obligatoria desde 2018. Chrome fue el primer navegador en exigirla, y solo esto bastó por su cuota de mercado. Después siguieron Apple, Microsoft y Mozilla. La visibilidad proporcionada por CT es de gran valor al permitir la monitorización mundial de la emisión de certificados, algo que sigue mejorándose y afinándose.

Nota: Las especificaciones técnicas que rigen la emisión de certificados las gestiona el CA/Browser Forum, un organismo del sector. Navegadores y CAs deciden cómo se realiza la validación y la emisión, aunque la relación no es simétrica: los navegadores deciden qué CAs aceptan, lo que les confiere ventaja en las conversaciones.

Como ya vimos, la Transparencia de Certificados es una herramienta muy útil para monitorización de todo el ecosistema global, pero también permite a los propietarios de dominios monitorizar la emisión de certificados relacionados con sus propiedades. Recordando lo anterior, las debilidades en el modelo de las PKI públicas permiten que terceros, maliciosos o no, emitan certificados para dominios ajenos. Con CT, cualquiera puede monitorizar los certificados para cualquier dominio.

Las organizaciones preocupadas por actividad no autorizada pueden desplegar monitores CT para inspeccionar el flujo mundial de certificados y localizar aquellos que les afectan. Esto abre dos posibilidades interesantes:

• Los propietarios pueden monitorizar sus propios certificados para comprender los puntos de emisión y detectar patrones, y ver qué CAs usan quiénes.
• Además, se pueden descubrir certificados no autorizados. En otras palabras, CT hace posible detectar certificados mal emitidos.

La Transparencia de Certificados, en su implementación actual, no ofrece visibilidad perfecta sobre la emisión mundial de certificados. Se debe a que no todos los proveedores obligan a publicar en CT según su root store policy. La situación es la siguiente:

• Apple exige CT para todos los certificados, incluyendo su navegador y cualquier código construido sobre sus bibliotecas oficiales
• Chrome de Google exige CT para todos los websites
• Edge de Microsoft, basado en Chromium, exige CT
• Firefox de Mozilla también exige CT

Dado que CT no es requisito de las Baseline Requirements y las root store policies no exigen que todas las CAs registren todo en CT, existen lagunas que pueden explotarse. Por lo tanto, técnicamente, no es obligatoria la publicación en CT. Aunque las CAs suelen grabar en CT por defecto, algunas permiten optar por no hacerlo. Además, pueden ser obligadas legalmente a publicar fuera de CT.

Obviamente, tales certificados no serán válidos para websites, pero pueden pasar validaciones en varios casos:

• Peticiones API (excepto desde plataformas Apple)
• Comunicación servidor-servidor, por ejemplo, para intercambio de correo o XMPP

Esperamos que en el futuro el alcance de CT se amplíe a todos los certificados públicos. Hasta entonces, tenga en cuenta sus limitaciones y actualice su modelo de amenazas en consecuencia.

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 de Nombres de Dominio (DNS) usando el registro de recurso CAA. Se soportan varias funciones:

• Controlar qué CAs pueden emitir
• Controles divididos para emisión de certificados estándar, comodín, así como certificados de correo y BIMI
• Capacidad para comunicar políticas granulares por cada CA
• Distribución de información de contacto ante incidencias

Considere 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 la emisión del certificado. No se refuerza con un control fuerte, pero todas las CAs están obligadas a usarlo según las Baseline Requirements. Cualquier emisión que no respete la configuración CAA del propietario se considera mal emitida.

La capacidad esencial de CAA es restringir qué CAs pueden emitir qué tipos de certificados. Si no hay política CAA en un dominio, se permite cualquier CA y cualquier tipo de certificado. Si existe al menos una directiva para un tipo (por ejemplo, "issue" para certificados estándar o "issuemail" para S/MIME), solo las CAs listadas pueden emitir. Si se observa un solo punto y coma, no se permite ningún tipo de emisión.

Desglosemos la anterior configuración de ejemplo:

• Let's Encrypt puede emitir certificados estándar
• DigiCert y Sectigo pueden emitir certificados comodín
• Nadie puede emitir certificados S/MIME ni BIMI
• La dirección "pki@example.com" puede emplearse para comunicar problemas

Las etiquetas "issue" e "issuewild" funcionan en conjunto. Si solo se usa "issue", pueden emitirse certificados estándar y comodín. Si se usa "issuewild", controla exclusivamente la emisión de certificados comodín.

CAA es flexible en cuanto a ubicación; cada dominio puede tener su propia configuración. Además, si no se observa CAA en un subdominio, la configuración del dominio padre se aplica si existe.

En la sección anterior se explicó la mecánica de restricción de CAs; pero ¿cómo ayuda esto en la práctica? Este control es esencial porque reduce la superficie de ataque. Como vimos, existen muchas debilidades en la organización de PKI pública. En especial, muchas CAs pueden emitir certificados para sus dominios, y todas deben actuar correctamente siempre.

En la práctica, la mayoría de organizaciones trabajan con unas pocas CAs, lo que convierte al resto en un riesgo potencial. Al usar CAA, ese riesgo se minimiza.

La aproximación básica recomendada es:

1. Construir una lista integral de dominios existentes
2. Usar CT para inventariar todos los certificados públicos
3. Monitorizar CT durante un tiempo y registrar las CAs observadas
4. Configurar CAA restringiendo la emisión a las pocas CAs necesarias

Este método sencillo permite minimizar el riesgo PKI con bajas probabilidades de afectar negativamente la emisión de certificados actual. La configuración CAA deseada debe aplicarse en todos los registros de dominio. Según el nivel de seguridad buscado, puede usar la misma lista de CAs para todos los dominios o restringir por dominio.

Nota: El DNS se usa habitualmente para delegar controles limitados a terceros, por ejemplo, al ofrecer un servicio gestionado en su propio dominio. Esto suele hacerse con el registro CNAME. Configurar una política CAA en el dominio principal no debería romper la emisión, incluso si terceros quieren usar una CA no listada. Esto se debe a que CNAME delega todos los aspectos de DNS, incluyendo CAA. El único detalle es que los terceros deben ser conscientes de CAA y establecer su propia política CAA adaptada a ellos.

El estándar CAA básico es un buen punto de partida, pero no basta para quienes deben proteger dominios de alto valor. Una "laguna" es que CAA restringe qué CAs pueden emitir, pero no impide que terceros usen esas CAs para obtener certificados. Esto se complica porque prácticamente todo el mundo utiliza Let's Encrypt, gracias a certificados gratuitos y automatización. La barrera para utilizar Let's Encrypt es muy baja.

Aquí entran las extensiones ACME CAA. ACME significa Automatic Certificate Management Environment; el estándar para emisión automática de certificados popularizado por Let's Encrypt desde 2015 y ahora adoptado por todas las CAs. RFC 8657 estandariza dos funciones adicionales en el cruce entre ACME y CAA:

• Restringir desde qué cuentas de cliente se puede emitir
• Restringir qué métodos de validación ACME pueden usarse

Al momento de escribir, RFC 8657 no es obligatorio, pero se espera su adopción en un futuro cercano. Actualmente, Let's Encrypt es la única CA que lo soporta oficialmente. Lo interesante es que, a diferencia de CAA básico, no es necesario que todos los CAs lo soporten, solo aquellos con los que usted trabaja. Si tiene dudas, consulte con su CA: algunos ofrecen funciones propietarias equivalentes.

Con RFC 8657, es posible permitir la emisión para un dominio desde cierta CA, pero de forma que ningún otro cliente de esa misma CA pueda emitir para ese dominio. Así sería, usando Let's Encrypt:

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

Mientras siga activa esa configuración, solo la cuenta "1726001367" podrá obtener certificados de Let's Encrypt para "example.com". Si hace falta la emisión desde varias cuentas, pueden configurarse varias etiquetas CAA, cada una permitiendo una cuenta distinta.

La otra función de RFC 8657 es que permite restringir qué métodos de validación puede usar ACME antes de emitir un certificado. ACME ofrece varios métodos y el cliente normalmente escoge el que prefiera al solicitar un certificado. El método más frecuente es la prueba de propiedad, que requiere responder a un reto de la CA publicando algo en el website deseado.

Esta aproximación suele ser cómoda, pues permite a cualquier servidor comunicarse directamente con una CA y obtener un certificado propio. Sin embargo, desde un enfoque de seguridad, permitir a servidores conseguir sus propios certificados puede no ser ideal: quien controle un servidor puede obtener certificados para cualquier dominio apuntando allí.

Existe, por ejemplo, la explotación por misconfiguración de DNS colgante, que ocurre cuando se dan de baja servidores pero los registros DNS siguen activos. Si las IP proceden de servicios en la nube, cualquiera que obtenga esas IP puede obtener certificados para dicho dominio. Hay otros vectores similares en DNS.

Una organización que quiera evitar este problema puede centralizar la emisión de certificados y usar la validación ACME basada en DNS. Pero para que funcione, debe asegurarse de que solo ese método esté habilitado. Así sería con RFC 8657:

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

                                  dns-01"

Con esta configuración, la emisión solo podrá aprobarse cambiando la configuración DNS del dominio solicitado.

Los dos métodos de restricción en RFC 8657 imponen controles similares pero con diferencias clave que pueden influir en cuál usar.

• La restricción por método de validación no requiere autenticar la solicitud. Si la emisión se limita a un método como "dns-01", solo pueden satisfacer la CAA quienes controlen su DNS (o la parte relevante). Esto reduce la superficie de ataque, aunque la solicitud en sí no se autentica y puede explotarse una mala configuración DNS.
• La restricción por cuenta exige autenticación fuerte. Cuando la emisión se restringe a una cuenta cliente específica, se impone autenticación fuerte de la solicitud antes de cualquier validación. En ACME, por ejemplo, las cuentas se protegen por criptografía de clave pública. Lo primero que hace un cliente ACME es crear una identidad criptográfica, usada para cada emisión. Si hay restricción por cuenta, la autenticación ocurre como primer paso porque el cliente debe demostrar ser la cuenta especificada en la configuración CAA.

Nota: En junio de 2025, el CA/Browser Forum aprobó el Ballot SC-085v2 que exige validar DNSSEC al consultar CAA y DCV (domain control validation). Estos cambios serán obligatorios a partir de marzo de 2026. Tras esa fecha, los dominios con DNSSEC serán inmunes a cualquier spoofing DNS.

Las extensiones RFC 8657 permiten desplegar controles mucho más estrictos sobre la emisión de certificados, pero hacerlo requiere tiempo y recursos para reorganizar la emisión de forma compatible y segura. No suele ser útil aplicar esta técnica a todos los dominios de la organización, pues no resulta coste-eficiente. Pero sí compensa proteger así un pequeño grupo de propiedades valiosas. Para el resto, basta con restringir la emisión a unas pocas CAs.

Para sus dominios más valiosos, proponga la siguiente estrategia:

1. Elija dos o tres CAs competentes. Necesita al menos dos para evitar puntos únicos de fallo. Para propiedades importantes, recomiendo siempre tener al menos un certificado válido de respaldo, por si falla el principal. Como mínimo, las CAs elegidas deben soportar RFC 8567 o tener prestaciones equivalentes.
2. Implemente una configuración CAA estricta en el dominio principal, limitando la emisión solo a las CAs elegidas y—clave—solo a cuentas específicas con esas CAs. Así se activa una validación criptográfica robusta.
3. Supervise su configuración DNS para: a) garantizar que no existen problemas de DNS colgante y b) conocer si hay delegaciones a terceros vía CNAME (quienes pueden usar políticas CAA propias).

Como hemos visto, la Transparencia de Certificados ha revolucionado la monitorización de las actividades de las autoridades de certificación. Aun así, la monitorización enfrenta retos:

• Aún es posible publicar certificados públicos fuera de CT, como se explicó anteriormente.
• La monitorización CT no está aún generalizada. Aunque es obligatoria desde hace años, la mayoría de organizaciones sigue sin dedicar suficientes recursos a monitorizar la emisión de sus propios certificados.
• Distinguir señales legítimas de ruido es difícil. Los certificados suelen carecer de información suficiente para diferenciar una emisión regular de una fraudulenta por terceros. Esto requiere herramientas avanzadas que la mayoría de las organizaciones aún desconocen.

A pesar de que en este documento exploramos el estado del arte, reconocemos que muchas organizaciones no requieren la máxima seguridad. Incluso quienes sí la necesitan, a menudo no la requieren en todo su patrimonio de dominios o websites.

Aconsejamos dividir su parque de dominios en tres grupos, según su perfil de riesgo:

• Muy bajo riesgo: incluya aquí todos los dominios inactivos o aparcados. Según el tamaño de la organización, puede tener desde unos pocos hasta cientos de ellos. Salvo que disponga de excelente automatización DNS, probablemente no compense mejorar la seguridad de este grupo.
• Bajo riesgo: aquí se incluyen dominios con websites o aplicaciones activas. Este debería ser el grupo por defecto. Para estos, lo ideal es una política CAA sencilla que limite la emisión a las pocas CAs con las que negocia, como se trató antes. Estas propiedades son poco propensas a ataques, por lo que CAA servirá para reforzar su política de selección de CA.
• Alto riesgo: agrupe aquí los dominios más propensos a ataques; webs y aplicaciones que manejan dinero, asuntos gubernamentales, comunicaciones o susceptibles de sufrir ataques de red activos. Proteja este grupo con todas las medidas técnicas posibles.

La monitorización CT de alta garantía es una aproximación que permite monitorizar con gran certeza el flujo de certificados publicados en Certificate Transparency y distinguir certificados bajo su control de aquellos bajo control de terceros no autorizados.

En concepto, la estrategia es simple y se basa en validar lo que sabe que es legítimo, considerando todo lo demás como sospechoso:

1. Mantenga un inventario de certificados bajo su control
2. Monitorice Certificate Transparency para detectar certificados que no estén en su inventario

Eso es todo. Dos pasos; pero el primero puede requerir esfuerzo para implementarse en la práctica, según su entorno. Recuerde que este trabajo solo se realiza para propiedades de alto riesgo, no en todo el parque.

• Si utiliza una herramienta de Gestión del Ciclo de Vida de Certificados (CLM) o ACME con una CA comercial, seguramente incluyen un inventario integrado. No debería ser difícil extraer sus certificados, aunque necesitará programar con sus APIs.
• Si usa ACME con una CA gratuita (como Let's Encrypt), puede que no haya inventario integrado. En ese caso, necesitará un mecanismo para recolectar los certificados emitidos y trasladarlos a un mismo lugar. Será más fácil si todo se emite desde un mismo servidor, pero no imposible con varios.

En la práctica, lo más probable es que deba mantener una base de datos separada para sus propios certificados. La emisión centralizada es poco común en la realidad, especialmente a gran escala. Siempre hay situaciones especiales, incluidos casos donde aspectos de su PKI pública se delegan a terceros. La solución integral deberá juntar diversas fuentes de datos para obtener una visión completa.