Mejora de la gestión de certificados digitales con la integración de Service Now de CertSecure

Respuesta rápida: La integración de CertSecure Manager con ServiceNow convierte automáticamente los eventos de vencimiento de certificados en tickets de incidentes de ServiceNow enrutados por RBAC a los 90, 60, 30 y 7 días antes del vencimiento, además de en el momento del vencimiento, con una escalada de respaldo automatizada, de modo que las renovaciones de certificados se rastrean, se gestionan y se auditan en lugar de depender de que alguien vea una alerta por correo electrónico.

Un solo certificado caducado puede dejar inoperativa una aplicación de cara al cliente en cuestión de segundos, y la mayoría de los equipos de seguridad se enteran a través de una alerta de interrupción del servicio, no de un panel de control. A medida que el volumen de certificados asciende a miles por organización, el seguimiento mediante hojas de cálculo y los recordatorios manuales de renovación dejan de ser viables mucho antes de la próxima auditoría de cumplimiento.

La integración de CertSecure Manager con ServiceNow conecta los eventos del ciclo de vida de los certificados directamente con los flujos de trabajo de gestión de incidencias y tickets de ServiceNow. Cuando un certificado está próximo a caducar (a los 90, 60, 30 o 7 días) o ya ha caducado, la integración abre automáticamente una incidencia, la asigna al grupo de propietarios correcto mediante el control de acceso basado en roles y, si nadie responde, la escala a través de una cadena de reserva. El resultado: menos renovaciones no realizadas, un registro de resolución documentado para los auditores y se acabaron las interrupciones de certificados atribuidas a que «nadie vio el correo electrónico».

Esta guía explica por qué el seguimiento manual de certificados falla a gran escala, cómo está diseñada la integración con ServiceNow, el flujo de trabajo de configuración paso a paso, las métricas que se deben seguir después de la implementación y cómo esto encaja en su plan más amplio de preparación de certificados TLS de 47 días .

Ir a: Resumen ejecutivo | Puntos clave | Lista de verificación rápida | Configuración paso a paso | Matriz de propietarios y acciones | Preguntas frecuentes

Resumen Ejecutivo

El seguimiento manual de las caducidad de los certificados resulta inviable una vez que el inventario de una empresa alcanza los miles de certificados, y la situación empeora aún más a medida que el calendario del CA/Browser Forum reduce la validez máxima de los certificados TLS públicos a 47 días para marzo de 2029. La integración de CertSecure Manager con ServiceNow soluciona este problema al convertir los eventos del ciclo de vida de los certificados en tickets de incidentes de ServiceNow gestionados mediante RBAC, con escalamiento automático de respaldo. De esta forma, las renovaciones se registran y auditan en lugar de depender de que alguien detecte un correo electrónico. Esta guía abarca el flujo de trabajo de configuración, la arquitectura subyacente, una matriz de responsables y acciones para los equipos de PKI, seguridad, plataforma y cumplimiento, y las métricas que se deben seguir una vez implementado, todo ello como parte de una estrategia más amplia de descubrimiento de certificados y agilidad criptográfica.

Puntos Clave

• La integración de CertSecure Manager con ServiceNow convierte los eventos de vencimiento de certificados en tickets de incidentes enrutados por RBAC a los 90, 60, 30 y 7 días antes del vencimiento, además de en el momento del vencimiento.
• Un mecanismo de escalamiento de respaldo integrado reasigna los tickets no resueltos a un propietario de grupo específico, lo que reduce el tiempo entre el envío de una alerta y la renovación efectiva del certificado.
• Según la encuesta Trust Pulse de DigiCert de julio de 2025, el 45 % de las organizaciones informaron de tiempos de inactividad relacionados con certificados durante el último año, y el 37.5 % de estos problemas estaban específicamente vinculados a certificados caducados.
• Los equipos de PKI, seguridad, plataforma/ITSM y cumplimiento normativo son responsables cada uno de una parte distinta del flujo de trabajo, desde la estructura RBAC hasta la evidencia de auditoría.
• A medida que el calendario del Foro CA/B reduce la validez máxima de los certificados TLS a 200 días en 2026, 100 días en 2027 y 47 días en 2029, la automatización basada en tickets se vuelve necesaria en lugar de opcional.

Lista de verificación rápida: Antes de comenzar

• Instancia de CertSecure Manager implementada con acceso de administrador a la configuración del conector.
• Instancia de ServiceNow con acceso a la API y una cuenta de servicio con permisos para crear incidentes.
• Grupos RBAC definidos y asignados a los propietarios de certificados (equipos de aplicaciones, equipo de PKI, equipo de plataforma).
• Intervalos de alerta acordados (generalmente 90/60/30/7 días antes del vencimiento, más después del vencimiento)
• Responsable documentado de la gestión de casos alternativos/de escalamiento para incidencias no resueltas
• Conectividad de red entre CertSecure Manager y la instancia de ServiceNow (reglas de firewall, lista de permisos de puntos finales de API).

Tabla de requisitos previos para la acción:

Requisito previo	Propietario	Acción previa a la integración
Se ha implementado CertSecure Manager y se han configurado los conectores para todas las CA.	Equipo PKI	Confirme que la arquitectura HA esté activa y que el inventario de certificados esté completo.
Acceso a la API de ServiceNow	Equipo de plataforma/ITSM	Proporcione una cuenta de servicio y credenciales de API limitadas a la creación de incidentes.
Mapeo de grupos RBAC	Equipo de seguridad/PKI	Asignar propietarios de certificados a grupos de asignación de ServiceNow
Política de intervalos de alerta	Equipo de cumplimiento	Acordar y documentar el calendario de alertas de 90/60/30/7 días y posteriores al vencimiento.
Responsable de la escalada/sustitución	líder del equipo de PKI	Nombre al propietario del grupo que recibe tickets sin resolver después del período de reserva.

Por qué el seguimiento manual de certificados falla a gran escala

La proliferación de certificados digitales en las empresas es consecuencia directa de la creciente complejidad de los entornos de TI modernos. Servidores, dispositivos informáticos, API e identidades de usuario requieren certificados, y la cantidad de certificados emitidos en una empresa típica asciende ahora a miles. Según la encuesta Trust Pulse de DigiCert (2 de julio de 2025), el 45 % de las organizaciones experimentaron interrupciones del servicio debido a incidentes relacionados con certificados durante el último año, y el 37.5 % atribuyó específicamente las interrupciones a certificados caducados . Esta es una de las causas más evitables de interrupciones en los sistemas de TI empresariales, y persiste porque la mayoría de los equipos siguen gestionando los certificados de la misma manera que hace una década.

Como proveedores de soluciones de gestión de certificados , observamos tres patrones de fallos recurrentes cuando las organizaciones intentan gestionar esto manualmente.

Desafío 1: Seguimiento del portafolio de certificados en constante crecimiento

Actualmente, se emiten certificados digitales para todo tipo de aplicaciones, desde herramientas para desarrolladores hasta puntos de acceso para clientes, y el volumen de emisiones ha superado la capacidad de cualquier hoja de cálculo o registro manual. Además de la emisión, es necesario garantizar la validez y confiabilidad de cada certificado en todas las autoridades de certificación, entornos y ciclos de renovación. Si no se controla, esta complejidad se traduce en caducidad e interrupciones del servicio.

Desafío 2: Brecha en la previsión del vencimiento del certificado

La mayoría de los sistemas de gestión de certificados carecen de una visión en tiempo real y predictiva de las próximas fechas de vencimiento. Sin un indicador claro y automatizado, los equipos recurren al seguimiento manual y a las hojas de cálculo, lo que introduce errores humanos precisamente en el punto donde son menos tolerables. La falta de previsión, no la falta de esfuerzo, es lo que provoca las interrupciones del servicio.

Desafío 3: Ineficiencia del sistema de alerta y falta de seguimiento del ciclo de vida de los problemas

Incluso cuando existen alertas de vencimiento, suelen limitarse a una notificación sin ticket, responsable ni seguimiento del ciclo de vida. Un certificado vence, se activa una alerta y, a partir de ahí, no hay ningún mecanismo que indique si alguien la resolvió. Peor aún, normalmente no existe una alternativa cuando el primer responsable no actúa. Precisamente esa deficiencia es la que la integración de CertSecure Manager con ServiceNow se diseñó para solucionar.

¿Qué es CertSecure Manager?

CertSecure Manager es la plataforma de gestión del ciclo de vida de certificados (CLM) de Encryption Consulting, diseñada específicamente para resolver el desafío fundamental de administrar entornos PKI a gran escala. Su arquitectura de alta disponibilidad (HA) permite a los clientes de conectores integrar todas las CA públicas y privadas en una única interfaz, de modo que ninguna CA, ya sea en una configuración multinube, híbrida o público-privada, queda fuera del inventario.

CertSecure Manager también admite agentes de renovación que se integran directamente con servidores como IIS y Tomcat, y balanceadores de carga como F5, manteniendo los certificados activos y renovándolos automáticamente antes de que caduquen. Su función de detección de certificados encuentra todos los certificados en un servidor web, independientemente de la partición o ruta en la que estén instalados, y las organizaciones pueden integrar sus propias herramientas mediante las API ACME o REST para simplificar la emisión de certificados para aplicaciones internas.

¿Por qué usar ServiceNow? Descubriendo la importancia de la integración.

La integración con ServiceNow permite a las organizaciones conectadas configurar su instancia de ServiceNow para que funcione directamente con CertSecure Manager. Se basa en el control de acceso basado en roles (RBAC), lo que garantiza que la administración de certificados se asigne con precisión a las personas adecuadas. RBAC simplifica la asignación de roles y la agrupación de usuarios, permitiendo que el sistema los clasifique en capas según sus permisos y nivel de acceso, lo que mantiene la gestión de certificados organizada y auditable.

La integración ofrece cuatro beneficios concretos:

• Automatiza el seguimiento de certificados con actualizaciones en tiempo real y mínima intervención manual.
• Genera alertas y tickets automáticos con suficiente antelación (7, 30, 60, 90 días) e inmediatamente al vencimiento.
• Ejecuta un algoritmo de escalamiento alternativo cuando no se recibe una resolución a tiempo.
• Evita errores humanos e interrupciones del servicio relacionadas con la caducidad del certificado.

ServiceNow también resuelve el problema recurrente del seguimiento de certificados en todo momento. Cuando un certificado caduca, se genera un ticket que se asigna al grupo correspondiente y, posteriormente, se remite al emisor para su resolución. Esto permite gestionar todo el proceso de renovación de certificados dentro de un único sistema auditable.

Cómo la integración de ServiceNow resuelve cada desafío

Seguimiento de una cartera en constante crecimiento

ServiceNow automatiza y optimiza el ciclo de vida de los certificados sobre la base de datos centralizada de certificados de CertSecure Manager. Actúa como un orquestador dinámico, automatizando tareas rutinarias como el seguimiento de la validez y la gestión de renovaciones puntuales. Esta automatización precisa reduce la intervención manual, lo que disminuye directamente el riesgo de errores.

Cómo cerrar la brecha en la previsión de vencimiento de certificados

La integración elimina la brecha de previsión con mecanismos automatizados de seguimiento, alerta y respaldo para cada certificado. El control de acceso basado en roles (RBAC) garantiza que las responsabilidades y los roles se asignen con precisión a los usuarios agrupados correctos, y la automatización de ServiceNow envía alertas a los grupos designados y, a su vez, a los usuarios designados, mucho antes de que un certificado caduque.

Solución de problemas de ineficiencia en las alertas y seguimiento del ciclo de vida de los problemas.

ServiceNow mejora las alertas creando un incidente para cada problema de vencimiento. La integración genera tickets automáticamente con suficiente antelación, a intervalos de 7, 30, 60 y 90 días, e inmediatamente al vencimiento, de modo que cada evento queda registrado y se le da seguimiento. Un algoritmo de reserva integrado reasigna el ticket si no se recibe una respuesta a la resolución a tiempo, lo que garantiza la fiabilidad del proceso en lugar de depender de que una sola persona vea un correo electrónico.

Arquitectura en profundidad de la integración

La arquitectura de la integración se organiza en tres capas: la capa de administración , la capa de grupos de incidentes y la entidad de tickets de incidentes . La capa de administración se sitúa en la parte superior y supervisa todos los grupos administrativos, gestionando la segunda capa que se encuentra debajo. El control de acceso pasa de ser general en la capa de administración a ser específico en la entidad de tickets de incidentes.

La capa de administración gestiona la administración general del grupo. La capa de gestión de incidentes se encarga de la actividad específica del grupo, es decir, de los equipos responsables de resolver los incidentes relacionados con los certificados. La entidad de ticket de incidente contiene los detalles precisos vinculados a la fecha de vencimiento de un certificado , lo que proporciona a todo el proceso una ruta estructurada y organizada para su resolución.

Esta estructura está diseñada para alinearse con los flujos de trabajo que probablemente su organización ya utiliza. Las políticas administrativas existentes se integran perfectamente con las diferentes capas, por lo que la integración refuerza su proceso actual en lugar de reemplazarlo.

Así es como funciona la asignación de tickets para un certificado próximo a caducar: cuando se genera un ticket, se asigna al grupo emisor responsable de dicho certificado. Este grupo es el propietario del ticket y de su renovación. Los tickets se generan con suficiente antelación, a los 7, 30, 60 y 90 días antes de la fecha de caducidad, y de nuevo inmediatamente después si el problema no se resolvió a tiempo.

La política del ciclo de vida de los tickets es sencilla: primero se asigna al emisor del certificado o a la entidad designada. Una vez renovado el certificado y resuelto el problema, el ticket se cierra. Si permanece sin resolverse tras un plazo determinado, se reasigna automáticamente al responsable del grupo, quien a su vez lo asigna a la persona que pueda cerrarlo. Este flujo de trabajo estructurado y ágil evita que los incidentes de renovación de certificados caduquen sin previo aviso junto con el certificado.

Paso a paso: Configuración de CertSecure Manager e integración con ServiceNow

La configuración que se describe a continuación presupone que CertSecure Manager ya está implementado y que su inventario de certificados está completo. Las capturas de pantalla que se muestran a continuación deben reflejar las versiones actuales de la consola de administración de CertSecure Manager y de la instancia de ServiceNow en el momento de la configuración.

1. Habilitar la cuenta de servicio de ServiceNow: En ServiceNow, cree un usuario de integración dedicado con acceso a la API limitado a la creación de incidentes y a la lectura/escritura de grupos de asignación. Evite reutilizar una cuenta de administrador personal; esta es la cuenta con la que CertSecure Manager se autenticará. Captura de pantalla: Pantalla de creación de usuario de ServiceNow con el rol "Acceso solo a servicios web" asignado.
2. Mapa de grupos RBAC: En la consola de administración de CertSecure Manager, defina la capa de administración y, a continuación, cree grupos de incidentes que reflejen su estructura de propiedad de certificados existente (equipos de aplicaciones, equipo de PKI, equipo de plataforma). Captura de pantalla: Panel de configuración RBAC de CertSecure Manager que muestra la jerarquía de grupos.
3. Configure el conector de ServiceNow: Introduzca la URL de la instancia de ServiceNow, las credenciales de la cuenta de servicio y la tabla de destino (normalmente la tabla de incidentes) en la configuración de integraciones de CertSecure Manager. Captura de pantalla: Página de configuración de integración de CertSecure Manager con los campos de ServiceNow completados.
4. Establecer intervalos de alerta: Defina el calendario de alertas previas al vencimiento, generalmente de 90, 60, 30 y 7 días, además de una alerta posterior al vencimiento. Cada intervalo debe corresponder a un nivel de prioridad de ticket en ServiceNow. Captura de pantalla: pantalla de configuración del intervalo de alerta.
5. Configure la cadena de reserva/escalamiento: Establezca el plazo tras el cual un ticket sin resolver se reasigna al propietario del grupo, e indique explícitamente el nombre de dicho propietario. Captura de pantalla: Generador de reglas de escalamiento que muestra la ventana de reasignación y el propietario objetivo.
6. Ejecuta un certificado de prueba a través del proceso: Utilice un certificado con una fecha de vencimiento próxima en un entorno que no sea de producción para confirmar que un ticket se crea, asigna y escala correctamente de principio a fin.
7. Validar los datos del ticket con respecto al registro del certificado: Confirme que el ticket incluya el CN/SAN del certificado, la CA emisora, la fecha de vencimiento y la aplicación propietaria, para que quienes respondan no tengan que buscar esta información por separado.
8. Ponga en marcha el sistema y supervise el primer ciclo completo de alertas: Antes de confiar plenamente en este sistema, observe atentamente los primeros lotes de alertas de 90 y 30 días para confirmar que los grupos de asignación y los tiempos de escalamiento funcionan según lo configurado.

Referencia de configuración de ejemplo (los valores variarán según la instancia de ServiceNow):

Integration endpoint: https://<instance>.service-now.com/api/now/table/incident
Auth type: OAuth 2.0 (service account)
Alert intervals (days before expiry): 90, 60, 30, 7
Post-expiry alert: immediate
Fallback escalation window: 48 hours
Escalation target: PKI team lead (group owner)

Antes y después: Comparación del flujo de trabajo operativo

Paso	Antes de la integración (manual)	Después de la integración (automatizada)
Seguimiento de vencimientos	Recordatorios en hojas de cálculo o calendario, revisados ​​periódicamente.	Supervisión continua y automatizada dentro de CertSecure Manager
Alertando	Enviar por correo electrónico a una lista de distribución, sin garantía de propiedad.	El ticket se creó automáticamente y se asignó al grupo de propietarios correcto mediante RBAC.
Escalada	Ninguno; depende de que alguien vea el correo electrónico.	Reasignación automática de reserva después de un período definido
Registro de auditoría	Dispersos en hilos de correo electrónico y hojas de cálculo.	Registro del ciclo de vida de un único ticket dentro de ServiceNow
Visibilidad de la resolución	Se desconoce hasta que se produzca un apagón.	Seguimiento desde la creación del ticket hasta su cierre.

Guía de reversión y errores comunes

Si es necesario revertir la integración, primero desactive el conector de ServiceNow en la configuración de integración de CertSecure Manager; esto evita que se generen nuevos tickets sin eliminar los existentes. Mantenga las asignaciones de grupos RBAC para que, al volver a habilitar la integración, no sea necesario reconfigurar la propiedad desde cero. Finalmente, revoque el token de API de la cuenta de servicio de ServiceNow, tras confirmar que ningún ticket en curso depende de él para las actualizaciones.

Errores comunes durante la configuración:

• Tickets creados pero no asignados: Normalmente significa que la asignación de grupos RBAC no se completó antes de que se habilitara el conector.
• No se generó ningún ticket: Compruebe que el token de API de la cuenta de servicio no haya caducado y que la URL de la instancia de ServiceNow sea correcta.
• Boletos duplicados para el mismo certificado: Normalmente se debe a la superposición de las reglas de intervalos de alerta; confirme que cada intervalo se corresponde con un estado de ticket distinto.
• La escalada nunca se activa: Confirme que tanto la ventana de reserva como el objetivo de escalamiento estén configurados; en algunas configuraciones de ServiceNow, la falta de un objetivo desactiva silenciosamente el escalamiento.

Métricas de éxito a seguir tras la implementación

Realice un seguimiento de estas métricas durante al menos un trimestre completo después de la puesta en marcha para confirmar que la integración está proporcionando la reducción prevista en el esfuerzo manual y el riesgo de interrupciones:

• Número de incidencias relacionadas con certificados creadas frente a resueltas dentro del plazo establecido en el SLA.
• Porcentaje de incidencias resueltas antes de que se active el plazo de escalamiento/recuperación.
• Reducción del seguimiento manual de certificados (se eliminaron las entradas en hojas de cálculo).
• Recuento de interrupciones relacionadas con certificados, trimestre tras trimestre, en comparación con la línea base previa a la integración.
• Tiempo promedio desde la alerta hasta la resolución del ticket, según el intervalo de alerta (90/60/30/7 días)

Las organizaciones que utilizan el paquete completo de automatización de CertSecure Manager, que incluye los agentes de renovación y la integración con ServiceNow, suelen reportar reducciones en el tiempo de renovación y una disminución significativa en la cantidad de solicitudes de certificados abiertas manualmente durante los dos primeros trimestres posteriores a la implementación. Si realiza un seguimiento de sus propias cifras, regístrelas trimestralmente para poder mostrar la tendencia en su próxima revisión de cumplimiento o auditoría.

Cómo se relaciona esto con la preparación para la certificación TLS en 47 días

La necesidad de un seguimiento automatizado de certificados se fortalece cada año con el avance del calendario de reducción de validez del CA/Browser Forum. Según el anuncio de Sectigo del 11 de abril de 2025, la votación aprobada por el CA/B Forum reduce gradualmente la validez máxima de los certificados TLS públicos de 398 días a 200 días a partir del 15 de marzo de 2026, a 100 días a partir del 15 de marzo de 2027 y a 47 días a partir del 15 de marzo de 2029. Cada paso reduce el plazo de renovación y aumenta la frecuencia con la que cada certificado de su inventario requiere atención.

Un proceso de seguimiento manual o semiautomatizado que resultaba simplemente inconveniente con una validez de 398 días se vuelve insostenible a los 47 días, cuando una empresa mediana podría estar renovando certificados de forma casi continua. El seguimiento del ciclo de vida basado en tickets, los intervalos de alerta y la escalada de respaldo de la integración de ServiceNow constituyen precisamente la capa de automatización que requiere la preparación de certificados a los 47 días : convierte la necesidad de renovar pronto un certificado en un ticket rastreado, asignado y auditable en cada ocasión.

Cómo gestionar esto en entornos PKI híbridos o multinube

En entornos PKI híbridos o multinube, el mismo desafío de inventario de certificados se multiplica entre las CA de proveedores de nube, las CA locales y las CA públicas de terceros. La arquitectura de alta disponibilidad de CertSecure Manager está diseñada para integrarlas todas en un único inventario, independientemente de dónde se encuentre una CA determinada, por lo que la integración con ServiceNow no requiere una configuración independiente por nube o por tipo de CA. Defina los grupos RBAC según la propiedad de la aplicación o del equipo, no según la CA que emitió el certificado, de modo que un ticket se dirija al propietario correcto, independientemente de si el certificado proviene de una CA interna de Microsoft, una CA pública o una CA nativa de la nube.

Los equipos que operan en entornos híbridos también deberían conectar esta integración con su proceso de descubrimiento de CBOM Secure . Una lista de materiales criptográficos proporciona el inventario completo de certificados y activos criptográficos en entornos locales y en la nube; la integración con ServiceNow convierte los eventos del ciclo de vida de ese inventario en tickets asignados y con seguimiento. De esta forma, se resuelven ambos aspectos del problema: saber qué existe y garantizar que alguien actúe sobre ello antes de que caduque.

Matriz de propietarios y acciones por equipo

Equipo	Medioambiental	Medidas posteriores al lanzamiento
Equipo PKI	Es responsable de las integraciones de CA, la estructura del grupo RBAC y la política de escalamiento.	Revise los intervalos de alerta y la programación de la recuperación ante desastres trimestralmente.
Equipo de seguridad	Posee la postura general de riesgo de los certificados y la prevención de interrupciones.	Realizar un seguimiento de las métricas de interrupción y resolución de incidentes en comparación con la línea base.
Equipo de plataforma/ITSM	Es responsable de la instancia de ServiceNow y del estado de la integración de la API.	Supervisar el tiempo de actividad del conector y la rotación de credenciales de la cuenta de servicio.
Equipo de cumplimiento	Posee evidencia de auditoría para la gobernanza del ciclo de vida de los certificados.	Consulte el historial de incidencias como prueba para DORA, PCI DSS o auditorías internas.

Qué hacer a continuación

Si estás evaluando esta integración, el camino más rápido a seguir es el siguiente:

1. Equipos de seguridad y de infraestructura de clave pública (PKI): Confirme que su inventario de certificados esté completo antes de configurar las alertas; un inventario incompleto genera una falsa sensación de seguridad, en lugar de reducir las interrupciones del servicio.
2. Equipos de plataforma: Primero, configure la cuenta de servicio de ServiceNow y confirme la conectividad de la API en un entorno que no sea de producción.
3. Equipos de cumplimiento: Defina qué intervalos de alerta y registros de escalamiento deben conservarse como evidencia de auditoría antes de la puesta en marcha.
4. Todos los equipos: Es necesario acordar conjuntamente la estructura del grupo RBAC, ya que la falta de alineación en la propiedad es la causa más común de tickets sin asignar después del lanzamiento.

Conclusión

La integración de CertSecure Manager con ServiceNow transforma la monitorización y gestión de certificados, pasando de un proceso reactivo y manual a uno estructurado y auditable. La arquitectura de tres capas, desde el control administrativo hasta el ticket de incidente individual, mantiene el flujo de trabajo alineado con la forma en que su organización ya asigna la responsabilidad, mientras que las alertas automatizadas y la escalada de respaldo solucionan los problemas que provocan las interrupciones relacionadas con los certificados.

A medida que los periodos de validez de los certificados se reducen a 47 días según el calendario del CA/B Forum, este tipo de automatización deja de ser una opción deseable y se convierte en la única manera realista de mantener bajo control una cartera de certificados en constante crecimiento. Combinada con las capacidades de detección e inventario de CBOM Secure y una estrategia más amplia de preparación para PQC , la integración con ServiceNow proporciona a los equipos de PKI, seguridad, plataforma y cumplimiento una única fuente de información compartida para cada evento del ciclo de vida del certificado.

CertSecure Manager ofrece un conjunto integral de funciones para la gestión del ciclo de vida: detección, inventario, emisión, implementación, renovación, revocación e informes, respaldadas por alertas inteligentes, automatización e implementación automática de servidores. Explore el Centro de Excelencia de PQC para descubrir cómo la automatización de certificados se integra en su estrategia de criptoagilidad.

¿Cuál es la principal ventaja de mejorar la gestión de certificados digitales con la integración de CertSecure en ServiceNow? La integración de CertSecure Manager con ServiceNow convierte automáticamente los eventos de vencimiento de certificados en tickets de incidentes asignados y con seguimiento, mediante la asignación basada en RBAC y la escalada de respaldo, lo que reduce la brecha entre el envío de una alerta y la renovación real del certificado.

¿Por qué es importante esto para la gestión del ciclo de vida de los certificados empresariales? Actualmente, las empresas gestionan miles de certificados en múltiples autoridades de certificación y entornos en la nube. Sin un seguimiento automatizado basado en tickets, las caducidad de los certificados se pasan por alto hasta que provocan una interrupción del servicio, y no existe un registro de auditoría que indique quién fue el responsable ni cuándo se resolvió el problema.

¿Qué equipos son responsables de implementar estas directrices? Los equipos de PKI son responsables de la estructura RBAC y las integraciones de CA, los equipos de seguridad son responsables de las métricas de prevención de interrupciones, los equipos de plataforma/ITSM son responsables del conector de ServiceNow y del estado de la API, y los equipos de cumplimiento utilizan el historial de incidencias resultante como evidencia de auditoría.

¿Qué riesgos aumentan si este tema se gestiona manualmente? El seguimiento manual aumenta el riesgo de renovaciones no realizadas, rutas de resolución no documentadas e interrupciones del servicio; según la encuesta Trust Pulse de DigiCert de julio de 2025, el 45 % de las organizaciones reportaron tiempo de inactividad relacionado con certificados en el último año, y el 37.5 % de ese tiempo de inactividad estuvo vinculado específicamente a certificados vencidos.

¿Cómo reduce la automatización el riesgo de interrupción de certificados? La automatización reemplaza el seguimiento manual mediante hojas de cálculo con una monitorización continua, genera automáticamente incidencias a intervalos definidos (7, 30, 60, 90 días y al vencimiento), las asigna al responsable correcto mediante RBAC y las escala automáticamente si nadie responde a tiempo.

¿Qué métricas deben monitorear los equipos después de la implementación? Monitorear el volumen de tickets en comparación con la tasa de resolución de SLA, el porcentaje de tickets resueltos antes de que se activen las escaladas, la reducción en los certificados monitoreados manualmente, el recuento de interrupciones trimestre tras trimestre y el tiempo promedio desde la alerta hasta la resolución según el intervalo de alerta.

¿Cómo se relaciona esto con la preparación para la certificación TLS de 47 días? El calendario aprobado por el Foro CA/B reduce la validez máxima de los certificados TLS públicos de 398 días a 200 días en marzo de 2026, a 100 días en marzo de 2027 y a 47 días en marzo de 2029. La automatización basada en tickets es lo que hace que el seguimiento de las renovaciones con esa frecuencia sea operativamente viable.

¿Cómo se debe gestionar esto en entornos PKI híbridos o multinube? Defina los grupos RBAC según la propiedad de la aplicación o del equipo, en lugar de según la CA emisora, ya que la arquitectura de alta disponibilidad de CertSecure Manager ya unifica las CA públicas, privadas, en la nube y locales en un único inventario. Al combinar esto con la capacidad de descubrimiento de CBOM Secure, se extiende el mismo seguimiento a todo el entorno híbrido.

¿Qué requisitos previos se necesitan antes de la implementación? Necesita una instancia de CertSecure Manager implementada con un inventario de certificados completo, una cuenta de servicio de ServiceNow con acceso a la API de creación de incidentes, grupos RBAC definidos y asignados a los propietarios de los certificados, una política de intervalo de alerta acordada y un propietario de escalamiento/conmutación designado.

¿Qué capturas de pantalla o ejemplos de configuración se deben incluir? Documente la pantalla de creación de la cuenta de servicio de ServiceNow, el panel de configuración RBAC de CertSecure Manager, la página de configuración de integración con los campos de ServiceNow completados, la pantalla de configuración del intervalo de alerta y el generador de reglas de escalamiento, capturados de sus versiones actuales de CertSecure Manager y ServiceNow en el momento de la configuración.