Lo que no aparece en tu inventario es justo lo que termina deteniendo tu operación.
La mayoría de las organizaciones cree que tiene control sobre sus certificados digitales. Hasta que alguien pide explicarlos.
Cuántos certificados activos tienes hoy.
Cuáles están por expirar.
Qué servicios dependen de ellos.
Qué certificados viven fuera de la CA principal
Cuáles fueron emitidos por terceros.
Cuáles siguen vivos a nombre de alguien que ya no está.
Ahí es donde aparece el verdadero problema.
No es la PKI. Es la falta de visibilidad sobre ella.
Porque en casi todas las organizaciones los certificados crecen más rápido que el inventario que intenta seguirles el paso. Cada integración suma los suyos. Cada proveedor, los suyos.
Cada ambiente nuevo agrega otra capa. Y cada equipo implementa a su manera, en momentos distintos y desde lugares distintos.
Con el tiempo dejan de ser una operación visible. Se dispersan — entre consolas, entre equipos, entre autoridades certificadoras, entre servicios que nadie revisa hasta que algo falla.
La mayoría de los inventarios está incompleto
Muchas organizaciones sí tienen un inventario de certificados. El problema es que casi siempre cubre solo lo que pasó por el proceso formal.
No cubre:
Certificados que emitió directamente un equipo de desarrollo
Certificados que montó un proveedor externo
Certificados instalados durante una migración
Certificados que viven en servicios olvidados
Ni los que nacieron en ambientes que crecieron fuera del proceso central
Y esa diferencia importa más de lo que parece. Porque inventario y visibilidad no son lo mismo.
El inventario muestra lo que alguien registró. La visibilidad muestra lo que realmente existe
Los puntos ciegos aparecen de formas muy distintas
En unas organizaciones el problema vive en certificados repartidos entre varias CAs sin una vista central. En otras, en certificados públicos que TI nunca llega a monitorear de cerca.
A veces están en:
APIs internas
Balanceadores y gateways
Servicios heredados
O integraciones que nadie ha tocado en años
También es común toparse con certificados a nombre de personas que ya no trabajan en la empresa.
El certificado sigue funcionando. Hasta que deja de hacerlo.
Y cuando deja de funcionar, la investigación empieza desde cero:
Dónde está
Quién lo emitió
Cuándo vence
Qué depende de él
Y quién debería responder por él
Un certificado que es de todos no es de nadie
Cuando uno falla, la primera pregunta casi nunca es técnica. Es otra: ¿de quién era esto?
Lo emitió alguien que ya no está. Lo renovaba un equipo que cambió de prioridades. Vivía en un servicio que pasó de un área a otra en la última reorganización. Sobre el papel, alguien era responsable. En la práctica, nadie lo estaba mirando.
La responsabilidad difusa es invisibilidad con otro nombre.
No es un problema de mala gente. Es que nadie puede hacerse cargo de lo que no aparece en ningún lado con nombre y dueño.
La fragmentación casi nunca se ve… hasta que impacta operación
Rara vez la sientes mientras todo funciona, porque la fragmentación no se anuncia: no manda alertas, no aparece en reportes ejecutivos, no abre tickets. Solo se acumula.
Hasta que:
Un certificado expira
Un servicio deja de responder
Una integración falla
Una auditoría pide evidencia
O un área descubre que dependía de un certificado que nadie estaba mirando
Y entonces llega la auditoría
Hay un momento en que la falta de visibilidad deja de ser un riesgo abstracto y se vuelve una fecha en el calendario: la auditoría.
Te piden algo que suena simple. Qué certificados tienes, dónde están, quién los emitió, cuándo vencen y cómo demuestras que los controlas. Y empieza la carrera: exportar de una consola, pedir capturas a otro equipo, cruzar hojas de cálculo que nadie sabe si están al día.
Lo que debería tomar minutos termina tomando días.
Y el resultado no es control. Es una foto armada a las prisas que demuestra esfuerzo, no gobierno.
Control demostrable, no de palabra.
Y el margen para no verlos se está achicando
Hasta hace poco, un certificado público podía vivir hasta 398 días. Lo emitías y te olvidabas de él casi un año. Eso ya cambió.
El CA/Browser Forum —donde Apple, Google, Mozilla y Microsoft fijan las reglas del navegador— votó reducir la vigencia de los certificados TLS públicos por etapas. Desde el 15 de marzo de 2026 el máximo es de 200 días. En 2027 baja a 100. En 2029, a 47. Y no es un plan a futuro: ya está en vigor.
De renovar una vez al año a renovar casi cada mes.
Más vigencia corta significa más renovaciones. Y más renovaciones sobre un inventario que no ves completo significan más oportunidades de que un certificado olvidado venza y tire un servicio. El cambio no crea el problema de visibilidad. Lo multiplica.
Lo difícil no es renovar más seguido. Lo difícil es saber qué tienes que renovar.
Quien hoy tiene su inventario claro va a cruzar este cambio sin drama. Quien no, va a descubrir sus puntos ciegos de la peor forma: cuando empiecen a vencer, uno tras otro.
El verdadero reto ya no es emitir certificados
Es entender dónde están de verdad: cuáles siguen activos, cuáles están por expirar, qué servicios dependen de ellos, cuáles viven fuera del proceso central, cuáles se reparten entre distintas CAs. Y cuáles podrían volverse un incidente operativo sin que nadie lo vea venir.
Ese es el cambio que muchas organizaciones apenas empiezan a enfrentar.
No es un problema de emisión. Es un problema de observabilidad.
Porque la mayoría de las interrupciones por certificados no empiezan con un ataque sofisticado. Empiezan con algo mucho más simple:
Un certificado que llevaba años funcionando fuera del radar.
Nada de esto se resuelve emitiendo más certificados. Se resuelve viéndolos completos — antes de que uno se vuelva el problema.
Y lo que hoy vive fuera del radar se puede traer a una sola vista. Verlo con tus propios certificados toma una demo corta.