¿Qué es la detecciónTLS ? Una guía completa para localizar todos los certificados de tu entorno

Ese inventario nunca ha sido tan importante.La vigencia de los certificados se está reduciendohasta situarse en aproximadamente un mes y medio para 2029, el número deidentidades de máquinasno deja de aumentar y las organizaciones están iniciando el largo proceso de adaptar su infraestructura criptográfica a la criptografía poscuántica. Nada de eso es posible si primero no se puede responder a una pregunta aparentemente sencilla: ¿qué certificados tenemos realmente y dónde se encuentran?

Una breve nota sobre la terminología. En esta guía se utilizaTLSen todo momento, ya que TLS el protocolo moderno que sustituyó a las SSL anteriores SSL . Aunque técnicamente son diferentes, en el sector se siguen utilizandoSSLyTLSde forma más o menos intercambiable, por lo que verás que estos términos se tratan como sinónimos en la mayoría de las herramientas y la documentación.

Por qué es importante la detección TLS

La mayoría de las organizaciones no tienen un problema de visibilidad por descuido. Lo tienen porque los certificados se acumulan de forma silenciosa, en todas direcciones, a un ritmo más rápido del que cualquier proceso manual puede seguir. Los certificados son emitidos por más de una autoridad de certificación, se implementan tanto en entornos en la nube como locales, y los solicitan diferentes equipos, cada uno de los cuales resuelve su propio problema inmediato. Como resultado, no existe una única fuente de información fiable, y nadie puede afirmar con certeza cuántos certificados hay ni cuándo caduca el siguiente.

Este es el reto que los profesionales de la gestión de certificados describen como «falta de visibilidad». A medida que aumenta el número de certificados, también lo hace la incertidumbre. No sabes cuántos certificados gestionas ni cuántos están a punto de caducar. El descubrimiento es la respuesta a esa carencia concreta: automatiza la búsqueda en toda la empresa y crea un registro preciso de los certificados, lo que te permite evitar las costosas e potencialmente perjudiciales interrupciones del servicio que se producen al perder la pista de ellos.

Hay una serie de factores que hacen que la falta de visibilidad resulte especialmente peligrosa hoy en día:

• Certificados «en la sombra».
  Cuando una unidad de negocio obtiene un certificado al margen de los procedimientos habituales de control, el departamento de seguridad nunca tiene conocimiento de ello. Esos puntos ciegos son precisamente los certificados con mayor probabilidad de fallar de forma silenciosa o de estar mal configurados.
• Multiplicación de certificados.
  A medida que se acorta la vida útil, el mismo certificado debe renovarse con mucha más frecuencia, lo que multiplica la carga operativa y el número de ocasiones en las que se puede pasar algo por alto.
• Explosiónde identidadesde máquinas.
  Las mallas de servicios y los marcos de identidad de cargas de trabajo emiten ahora certificados en cantidades que nadie solicita y que nadie tocará jamás. Se trata de un conjunto independiente y mucho más amplio, que nace y caduca automáticamente en grandes entornos, sin haber pasado nunca por un servicio de solicitudes.
• Migración impuesta desde el exterior.
  Las transiciones criptográficas más importantes son aquellas que no se pueden programar. Sin un inventario completo basado en la cadena de confianza completa, ni siquiera se puede determinar cuáles de los certificados activos se ven afectados, y esa delimitación del alcance constituye la mayor parte de la respuesta.Falta de base para las políticas o la planificación.Sin un inventario completo, los equipos no pueden aplicar políticas, programar renovaciones ni prepararse para transiciones criptográficas como la preparación para la era poscuántica. No se puede proteger, migrar ni certificar lo que no se ve.

Esos dos últimos puntos vinculan el proceso de identificación con un horizonte a más largo plazo. El sector se está preparando para implementar criptografía resistente a los ataques cuánticos, con el fin de proteger la información y las infraestructuras frente a los ataques perpetrados por grandes ordenadores cuánticos. El primer paso en cualquier migración de este tipo es saber qué certificados se tienen y en qué tipo de criptografía se basan. El proceso de identificación constituye la base de todo el esfuerzo por lograr la agilidad criptográfica.

Dado que los certificados se basan en el estándar X.509, un buen inventario recoge los detalles estructurados que define dicho estándar, lo que hace que el registro resulte útil tanto para las operaciones como para las auditorías.

Cómo funciona la detección TLS

La detección no es una técnica única. Los programas consolidados combinan varios métodos, ya que cada uno de ellos ofrece una visión diferente del entorno y ningún enfoque por sí solo permite detectarlo todo. Los tres enfoques principales son el escaneo basado en red, la detección basada en CA y la detección basada en agentes o en la nube.

Escaneo basado en red

El escaneo de red es el método más habitual. Una herramienta de detección recorre las redes definidas, se conecta a TLS y extrae los datos de los certificados que encuentra en ellos. En la práctica, el alcance de una red se define de una de estas tres formas: mediante notación de red (CIDR), mediante direcciones IP individuales o mediante nombres de host individuales. Cada red definida se convierte en su propia tarea de detección, lo que permite a los administradores segmentar entornos de gran tamaño y optimizar el rendimiento, en lugar de escanearlo todo de una sola vez.

Existen varios controles que garantizan que el escaneo sea eficiente y seguro:

• Grupos de Orchestrator.
  Las tareas de escaneo se pueden asignar a grupos de Orchestrator en función de su ubicación, de modo que el escáner adecuado llegue a la parte correcta de la red.
• Rangos de puertos.
  Se especifican los puertos que se van a analizar, centrando el escaneo en aquellos en los que TLS están realmente a la escucha.
• Programaciones.
  Las tareas de detección se ejecutan con una periodicidad definida y abarcan todos los puntos finales incluidos en la definición de la red.
• Horario de silencio.
  Puedes definir franjas horarias en las que no se ejecutarán los análisis, lo que evita que estos se realicen en momentos delicados y optimiza aún más cuándo y cómo se ejecutan.

La ventaja del escaneo de red es que detecta los certificados que se están utilizando activamente en los terminales a los que se puede acceder. Su limitación es precisamente lo contrario: solo detecta lo que está a la escucha en una red que controlas, por lo que funciona mejor en combinación con los otros dos métodos.

Descubrimiento basado en CA

El descubrimiento basado en CA da la vuelta a la lógica. En lugar de dirigirse al punto final (las hojas de la jerarquía de la PKI), se acude al emisor, partiendo del principio de que la autoridad que ha emitido un certificado mantiene un registro oficial del mismo. Esto se divide claramente en privado y público.

En el caso de una PKI interna, se realiza una integración directa con la autoridad de certificación emisora y se enumeran los certificados que ha emitido. Con Microsoft AD CS, esto implica consultar la base de datos de la CA a través de sus interfaces de gestión o herramientas command; con EJBCA utilizar la API REST o SOAP. Se obtienen todos los certificados emitidos por la CA, junto con los metadatos de la solicitud, como el solicitante, la plantilla o el perfil utilizado y el estado de revocación. Es fundamental destacar que, dependiendo de la programación de la herramienta de detección, esta puede obtener información sobre cada certificado en el momento de su creación, antes incluso de que el certificado se implemente en ningún sitio.

En el caso de los certificados de confianza pública, el mecanismo es la Transparencia de Certificados (CT). Los navegadores exigen ahora que los certificados de confianza pública se registren en registros CT de solo adición antes de ser aceptados, por lo que al consultar los agregadores de CT (como crt.sh o Censys) o los propios registros de tus dominios, se obtienen los certificados emitidos a tu nombre por cualquier CA pública. Este es el método que detecta los certificados «en la sombra»: aquellos que un equipo ha obtenido sin informar al equipo de seguridad, implementados en una infraestructura que no se analiza, además de cualquier emisión errónea que suplante la identidad de tus dominios. Un análisis de tus propios rangos nunca los detectaría.

El punto fuerte de la búsqueda basada en CA es su fiabilidad y exhaustividad respecto a un emisor concreto, independientemente de dónde acabe el certificado. La limitación es la inversa del escaneo de red: un registro de CA indica que se ha emitido un certificado, pero no dónde se encuentra ni si está en uso. El CT solo abarca los certificados públicos, y la enumeración interna solo cubre las CA a las que se puede acceder, por lo que ambas son complementarias y no redundantes. Para cerrar el círculo, se correlacionan los datos de emisión con los de implementación.

Detección basada en agentes y en la nube

Los agentes atacan el punto ciego que comparten los dos métodos anteriores: los certificados en reposo. Se instala un proceso local ligero en cada host que inspecciona el equipo desde dentro. Recorre el sistema de archivos en busca de archivos de certificados y claves (como .pem, .crt, .pfx y .jks), lee los almacenes de la plataforma, como el almacén de certificados de Windows y los almacenes de claves de Java, y analiza la configuración de los servicios para determinar qué certificado está vinculado a cada servicio. Al ejecutarse con privilegios locales, detecta lo que la red no puede ver: certificados no vinculados a ningún puerto abierto, la ubicación exacta de los archivos y su vinculación con los servicios, y el estado de la clave privada. También puede notificar la presencia de un certificado recién instalado en el momento en que aparece, en lugar de esperar a la siguiente ventana de análisis, y, dado que el mismo agente puede escribir en los almacenes de claves y reiniciar servicios, la detección y la corrección pueden integrarse en un único canal. La contrapartida es la gestión de la flota: hay que implementar y mantener agentes en numerosos sistemas operativos, y siempre habrá dispositivos y sistemas de terceros en los que no sea posible instalar uno.

El descubrimiento en la nube generaliza esta misma idea a infraestructuras que carecen de un host en el que instalar un agente. Los certificados modernos se alojan cada vez más en los servicios de los proveedores, en lugar de en servidores, por lo que se conceden a una herramienta de descubrimiento credenciales de API de solo lectura y se realiza un recuento a través de cuentas, suscripciones, proyectos y regiones. En la práctica, esto abarca los servicios de certificados y los gestores de secretos, las configuraciones de equilibradores de carga y de oyentes de CDN, las pasarelas de API, TLS de Kubernetes y la identidad de la malla de servicios. Estos certificados suelen ser efímeros, se aprovisionan automáticamente y son numerosos, y resultan prácticamente invisibles para los escáneres de red locales y para los agentes de host. El punto débil es la dispersión de la cobertura: cada cuenta y cada región supone una integración independiente, y en el momento en que alguien crea una cuenta que nadie ha incorporado al sistema, esa parte queda fuera de cobertura.

Investigación frente a seguimiento: comprender la diferencia

A menudo se mencionan en el mismo contexto los conceptos de detección y seguimiento, pero cumplen funciones diferentes, y un programa eficaz necesita ambos.

Las tareas de detección buscan nuevos certificados. Acceden a todos los terminales de una red definida e incorporan a tu inventario los certificados que antes se desconocían. Las tareas de supervisión, por el contrario, solo analizan los certificados existentes que se han marcado para su seguimiento y envían alertas en función de un umbral de caducidad configurado. En otras palabras, la detección encuentra; la supervisión vigila.

Así es como encajan entre sí:

• Discovery elabora el inventario.
  Responde a la pregunta: «¿Qué tenemos y dónde está?».
• La supervisión garantiza el buen estado del inventario.
  Responde a la pregunta: «¿Qué está a punto de caducar o de incumplir la política?».
• Ambos se ejecutan de forma continua.
  Discovery debe ejecutarse según una programación periódica para detectar rápidamente los nuevos certificados, mientras que la supervisión se ejecuta en paralelo para generar alertas antes de que caduque alguno.

Una práctica recomendable es hacer que la función de detección incorpore automáticamente los certificados recién detectados al sistema de supervisión, de modo que no haya ningún certificado en el inventario que no esté bajo supervisión. De este modo, en el momento en que se detecta un certificado, ya se inicia el plazo para las alertas de caducidad.

Los riesgos de no encontrar tus certificados

La necesidad del descubrimiento se hace evidente cuando se analiza lo que puede salir mal sin él. Cada riesgo se corresponde con una laguna que el descubrimiento está diseñado para subsanar.

Interrupciones inesperadas debidas a certificados caducados

Los certificados que caducan son el enemigo del tiempo de actividad. Basta con que se pase por alto una sola caducidad para desencadenar una oleada de fallos: una aplicación deja de responder, un servicio dependiente da error y la interrupción se convierte en un tiempo de inactividad que afecta a los clientes. Estas interrupciones son especialmente frustrantes porque se pueden evitar por completo. El certificado no falló; simplemente se olvidó. La función de detección elimina la categoría de «olvidados» al garantizar que se conozca cada certificado y, mediante la supervisión, se realice un seguimiento de su fecha de renovación mucho antes de que se convierta en un problema.

Vulnerabilidades de seguridad e incumplimientos normativos

Los certificados no detectados suelen ser los que están peor mantenidos. Pueden basarse en versiones de protocolo obsoletas o en algoritmos débiles, estar vinculados a puntos de confianza que ya no controlas o contener configuraciones que incumplen silenciosamente las políticas. Al no haber nadie que los supervise, se convierten en los puntos débiles que busca un atacante. En concreto, TLS más antiguas SSL TLS (TLS .TLS y 1.1) deberían desactivarse en favor del TLS moderno TLS TLS .3), pero solo puedes imponerlo si sabes dónde se encuentran las configuraciones obsoletas.

También hay una dimensión normativa. Los marcos normativos que regulan los datos en tránsito exigen que se aplique y se gestione el cifrado. Por ejemplo,

• El requisito 4 de la norma PCI DSS se refiere al cifrado de la transmisión de los datos de los titulares de tarjetas,
• las disposiciones sobre seguridad en la transmisión de la Norma de Seguridad de la HIPAA se refieren a la información sanitaria protegida en tránsito, y
• El artículo 32 del RGPD exige el cifrado como parte de la seguridad del tratamiento.

Un certificado no gestionado o mal configurado puede hacer que no cumplas con cualquiera de estos requisitos, y no podrás demostrar el cumplimiento normativo de certificados que ni siquiera puedes enumerar.

Incapacidad para prepararse para las transiciones criptográficas

Hay dos tendencias que ya están transformando la gestión de certificados: el paso a períodos de validez mucho más cortos y la migración final a la criptografía poscuántica. Ambas requieren que sepas con qué cuentas. No se puede planificar una migración a algoritmos resistentes a la criptografía cuántica si no se sabe qué certificados utilizan qué tipo de criptografía, y tampoco se puede adaptarse a los plazos de validez más cortos si no se conoce el conjunto completo de certificados que necesitan una renovación más rápida. La identificación, junto con un inventario exhaustivo, es el requisito previo para una gestión del ciclo de vida de los certificados que garantice su seguridad desde la emisión hasta su caducidad.

Qué hay que tener en cuenta a la hora de elegir una herramienta de detección TLS

No todas las herramientas de detección son iguales. Utiliza la lista de verificación que figura a continuación para evaluar cualquier solución en función de las exigencias de un entorno de certificados moderno y de alta velocidad.

• Análisis exhaustivo.
  La herramienta debe permitir la detección basada en red, basada en CA y nativa de la nube. Cualquier método por sí solo deja puntos ciegos, por lo que lo primero que hay que comprobar es la amplitud de la cobertura.
• Detalle por certificado.
  Encontrar un certificado es solo el principio; pero el valor reside en los atributos que lo acompañan. Busca la resolución completa de la cadena, el conjunto completo de nombres alternativos del sujeto, las fechas de validez, el tipo y tamaño de la clave, así como el algoritmo de la clave del sujeto y el algoritmo de firma utilizados por el emisor. Esa distinción entre dos algoritmos es importante para la agilidad criptográfica, ya que la solidez de la autenticación de un certificado depende de la firma más débil de su cadena.
• Programación automática.
  Discovery debería ejecutarse según horarios recurrentes sin intervención manual, con controles como las horas de silencio para gestionar los horarios.
• Inventario centralizado.
  Un único repositorio debería agrupar todos los certificados detectados, independientemente de cómo se hayan encontrado, de modo que haya un único lugar desde el que realizar búsquedas y generar informes.
• Alertas de caducidad.
  Las notificaciones configurables deben activarse cuando los certificados se acerquen a sus plazos de caducidad.
• Integración con la gestión del ciclo de vida.
  El proceso de detección debería integrarse directamente en los flujos de trabajo de renovación, asignación y revocación, en lugar de constituir un informe independiente.
• Escalabilidad.
  La posibilidad de dividir redes de gran tamaño en zonas de análisis, mediante el uso de grupos de orquestadores, permite mantener un rendimiento gestionable a medida que crece el entorno.
• Informes y cumplimiento normativo.
  La herramienta debería generar informes listos para auditoría y, a ser posible, almacenar un historial por momentos concretos, de modo que se puedan responder preguntas retrospectivas, como por ejemplo qué certificados estaban activos durante un periodo determinado.

Cuanto más detallado sea el registro por certificado, más posibilidades tendrá el inventario posteriormente, y la gestión también será más exhaustiva y detallada. Atributos como el estado de la clave privada (dónde se encuentra la clave y si es exportable), los enlaces de implementación (todos los lugares en los que está instalado un certificado, no solo uno) y la procedencia de la emisión (qué CA, qué plantilla, qué solicitante) son los que convierten una lista plana en algo a partir de lo cual se puede auditar y realizar migraciones. Escatimar en profundidad en el momento de la recopilación limita silenciosamente lo que el inventario podrá soportar en fases posteriores.

El impacto de la reducción de la vigencia de los certificados en el proceso de descubrimiento

La razón principal por la que el proceso de descubrimiento está pasando de ser un proyecto periódico a una práctica continua es la decisión del sector de acortar la vigencia de los certificados. El CA/Browser Forum ha aprobado una reducción gradual, mediante la votación SC-081v3, que reduce progresivamente la validez máxima a lo largo de varios años, hasta alcanzar aproximadamente un mes y medio (47 días) a principios de 2029. Según el resumen del calendario elaborado por DigiCert, los hitos intermedios fijan la validez máxima en 200 días a principios de 2026 y en 100 días a principios de 2027, antes de la fase final.

Las cifras operativas son implacables. Un certificado que antes requería atención aproximadamente una vez al año tendrá que renovarse varias veces al año. Si multiplicamos eso por todo el parque informático, la carga resulta evidente:

• El seguimiento manual deja de ser escalable.
  Con estos plazos, las hojas de cálculo y los recordatorios del calendario ya no dan abasto. El seguimiento y la renovación manuales no solo son ineficaces a estas alturas, sino que suponen un riesgo.
• La detección debe ser continua.
  Una auditoría puntual queda obsoleta casi de inmediato, dado que los certificados caducan con tanta rapidez. La detección debe realizarse de forma automatizada y periódica para que el inventario nunca se aleje demasiado de la realidad.
• Invertir desde el principio da sus frutos.
  Las organizaciones que implanten ahora el descubrimiento automatizado superarán sin problemas cada hito de ciclo de vida más corto, mientras que aquellas que esperen percibirán cada reducción como una nueva situación de emergencia.

Las duraciones más cortas no alteran la esencia del proceso de detección. Lo que sí cambian es la frecuencia con la que debe ejecutarse, y descartan la posibilidad de hacerlo manualmente.

Cómo Keyfactor ayudarte Keyfactor

Keyfactor diseñado precisamente para resolver los retos de detección descritos anteriormente. Su función SSL analiza las redes definidas para localizar todos TLS e importar los datos de los certificados a un inventario centralizado, lo que te proporciona un registro preciso que los procesos manuales no pueden mantener.

El flujo de trabajo se corresponde directamente con los criterios de evaluación mencionados anteriormente:

• Detección flexible y segmentada.
  Agilesecejecuta tareas de detección organizadas por red, que pueden segmentarse para optimizar el rendimiento, asignarse a grupos de orquestadores por ubicación, programarse en intervalos flexibles y ajustarse teniendo en cuenta las horas de silencio.
• Inscripción automática en la supervisión.
  Los certificados detectados mediante el proceso de detección pueden añadirse automáticamente a la supervisión, con alertas de caducidad configurables, de modo que ningún elemento entre en el inventario sin estar supervisado.
• Automatización del ciclo de viday mucho más.
  Keyfactor Command se integra con AgileSec, unificando el inventario, la automatización del ciclo de vida y la generación de informes de cumplimiento, de modo que la búsqueda de un certificado conduce directamente a su renovación, aprovisionamiento y revocación.
• Prepárate para lo que está por venir.
  La plataforma facilita la preparación para ciclos de vida más cortos y transiciones poscuánticas gracias a su agilidad criptográfica, proporcionándote la base de inventario y automatización que requieren esos cambios.

La amplia gama Keyfactor, que incluye la detección e inventario de certificados criptográficos y la automatización del ciclo de vida de los certificados, está diseñada para que la detección no sea una tarea aislada, sino la primera fase de un programa completo de gestión de certificados.

Principales conclusiones

• La detección TLS es el proceso que consiste en localizar automáticamente todos los certificados del entorno y registrar sus datos clave.
• Sin un proceso de detección, las organizaciones se enfrentan a interrupciones evitables, brechas de seguridad e incumplimientos normativos.
• La detección y la supervisión son complementarias: la detección identifica nuevos certificados, mientras que la supervisión realiza un seguimiento de los ya conocidos hasta su caducidad.
• El escaneo de redes, la detección basada en CA y la detección mediante agente o en la nube abarcan cada uno una parte diferente del entorno, por lo que los programas más eficaces combinan las tres opciones.
• El cambio hacia ciclos de vida de aproximadamente 47 días para 2029 hace que la detección continua y automatizada sea esencial, y no opcional.
• Una herramienta de detección eficaz ofrece un análisis exhaustivo, información detallada de cada certificado, programación automatizada, inventario centralizado e integración con la gestión del ciclo de vida.
• Keyfactor soluciones integrales de detección, supervisión y automatización del ciclo de vida de los certificados en una única plataforma.