CertSecure Manager 3.3 ya está aquí, y llega justo cuando más lo necesitas. 

CertSecure Manager 3.3 es la versión de Encryption Consulting para la gestión del ciclo de vida de los certificados, diseñada para la reducción gradual, por parte del CA/Browser Forum, de la validez máxima de los certificados TLS públicos a 47 días para 2029. Incorpora un perfil de riesgo de certificado, revocación masiva y transferencia de propiedad, renovación sin intervención manual, nuevas integraciones con CA y bóvedas, y una detección ampliada, lo que permite a los equipos de certificados operar con una frecuencia de renovación aproximadamente ocho veces mayor que la actual, sin cuellos de botella manuales.

Si has estado al tanto de las conversaciones sobre gestión de certificados durante el último año, ya sabes que el panorama está cambiando. La duración de los certificados TLS públicos, pilar fundamental del funcionamiento de la web durante más de una década, se está reduciendo drásticamente. La época de «renovarlo una vez al año y olvidarse» ha llegado oficialmente a su fin. 

CertSecure Manager v3.3 es nuestra versión adaptada a esta nueva realidad. Se trata de una serie de cambios planificados para ayudar a su equipo a sobrevivir, e idealmente a prosperar, en un mundo donde los certificados caducan cada pocas semanas en lugar de cada 13 meses. Analicemos los cambios, su impacto en sus operaciones y el motivo de su diseño.

CertSecure Manager v3.3 se ha diseñado teniendo en cuenta una realidad del sector: la duración de los certificados TLS se reducirá de 398 a 47 días en los próximos tres años, y la gestión manual de certificados no podrá seguir ese ritmo. Esta versión incluye 18 nuevas funciones y mejoras orientadas a la mayor frecuencia de renovación.

Las principales novedades incluyen un perfil de riesgo de certificado que evalúa cada certificado de su inventario, visualización completa de la cadena de confianza, revocación y transferencia de propiedad masivas, renovación automática en todos los agentes de servidor web, integraciones nativas con Google Public CA y ServiceNow, compatibilidad ampliada con Azure Key Vault, incluyendo inquilinos gubernamentales, detección de AWS e IIS CCS y una ruta de automatización ACME con Ansible. Si gestiona certificados TLS a gran escala, esta versión está diseñada para el entorno actual.

Puntos Clave

• CertSecure Manager 3.3 está diseñado para la reducción gradual de la validez de los certificados TLS del CA/Browser Forum: 200 días (marzo de 2026), 100 días (marzo de 2027) y 47 días (marzo de 2029).
• Esta versión incluye 18 funciones y mejoras, entre las que destacan un perfil de riesgo de certificados, visualización completa de la cadena de confianza, revocación masiva, transferencia masiva de propiedad, renovación sin intervención en todos los agentes del servidor web y una nueva ruta de automatización ACME de Ansible.
• La encuesta Trust Pulse de DigiCert reveló que el 45 % de las organizaciones experimentaron interrupciones del servicio relacionadas con certificados durante el último año, y el 37.5 % atribuyeron una interrupción a un certificado caducado, precisamente el tipo de fallo que esta versión está diseñada para prevenir.
• La actualización es un proceso programado y de bajo riesgo para los clientes que ya utilizan una versión reciente; los nuevos usuarios deberían comenzar ahora, ya que el hito de los 100 días se alcanza en marzo de 2027.
• Los equipos de PKI, seguridad, plataforma y cumplimiento tienen cada uno una acción distinta; la matriz de propietario/acción y la tabla de requisitos previos para la acción que se muestran a continuación detallan exactamente qué y quién.

Ir a: Resumen ejecutivo | Lista de verificación de preparación | Requisitos previos | Pasos de actualización | Tabla de requisitos previos a acciones | Antes y después | Guía de reversión | Métricas de éxito | Matriz de propietario/acción | Qué hacer a continuación | Preguntas frecuentes

Resumen ejecutivo para los equipos de PKI, seguridad, plataforma y cumplimiento normativo.

Si usted lidera alguna de estas funciones, aquí encontrará la decisión que respalda esta versión y la acción de referencia rápida correspondiente.

• Equipos PKI: Confirmar los requisitos previos, programar la actualización a la versión 3.3 y validar la puntuación del perfil de riesgo del certificado una vez que esté operativa.
• Equipos de seguridad: Utilice el nuevo Perfil de Riesgo de Certificados para detectar certificados de riesgo grave y alto antes de que provoquen un incidente.
• Equipos de plataforma/DevOps: Adopte la renovación sin intervención manual y la ruta de automatización ACME de Ansible para que la frecuencia de renovación pueda aumentar sin añadir trabajo manual.
• Equipos de cumplimiento: Utilice los informes de perfil de riesgo y los registros de transferencia masiva de propiedad como evidencia lista para auditoría de cómo se gestiona el riesgo del certificado.

Lista de verificación de preparación rápida

Utilice esta lista de verificación para determinar si realmente está listo para actualizar, y no solo si sabe que existe la nueva versión.

• Hemos confirmado su versión actual de CertSecure Manager y revisado las notas de la versión 3.3.
• Se identificaron los conectores de CA, las bóvedas y los agentes de servidor web que están incluidos en el alcance de esta actualización.
• Programé una ventana de mantenimiento y, para las implementaciones de alta disponibilidad, confirmé la secuencia de actualización de nodos con su equipo de consultoría de cifrado.
• Realice una copia de seguridad de la configuración actual de CertSecure Manager, la base de datos y los scripts de automatización personalizados.
• Se revisaron los criterios de puntuación del perfil de riesgo del certificado (longitud de la clave, algoritmo de firma, período de validez) para que los resultados tras la actualización no sean una sorpresa.

Requisitos previos a la implementación

• Se requiere una versión reciente y compatible de CertSecure Manager; su equipo de cuenta puede confirmar la versión base mínima para una actualización directa a la versión 3.3.
• Acceso administrativo a CertSecure Manager y a cada CA, bóveda o destino de inscripción conectado que planee incorporar a las nuevas funciones, incluidas Google Public CA, Azure Key Vault, AWS y ServiceNow.
• Se requiere una ventana de mantenimiento o de cambio, ya que la actualización implica un reinicio del servicio en los nodos del administrador y, en entornos de alta disponibilidad, actualizaciones secuenciales de los nodos.
• Una copia de seguridad actual y probada de la base de datos y la configuración de CertSecure Manager, realizada inmediatamente antes de la actualización.
• Para la ruta de automatización ACME de Ansible, se requiere un nodo de control de Ansible existente y familiaridad con un módulo de Ansible compatible con ACME, como por ejemplo: community.crypto.acme_certificate.
• Para la integración con ServiceNow, se requiere una instancia existente de ServiceNow con permisos de instalación de aplicaciones en la tienda.

Flujo de trabajo de actualización paso a paso

Este es el flujo de trabajo general para actualizar a CertSecure Manager 3.3. Su equipo de consultoría de cifrado confirmará los detalles específicos del entorno, especialmente para implementaciones de alta disponibilidad (HA).

1. Revise las notas de la versión y esta guía, y confirmar que se cumplen los requisitos previos mencionados anteriormente.
2. Notificar a los equipos afectados y programar la ventana de mantenimiento, incluyendo la orientación sobre la secuenciación de nodos HA por parte de su equipo de cuenta, si procede.
3. Realice una copia de seguridad de la configuración actual, la base de datos y cualquier script de automatización personalizado.
4. Aplicar la actualización 3.3 siguiendo la ruta específica del entorno que le proporcione su equipo de cuenta, ya sea de alta disponibilidad de nodo único o secuenciada.
5. Verifique la actualización: Confirme la versión de CertSecure Manager, confirme que la columna de puntuación del perfil de riesgo del certificado aparece en la búsqueda de inventario y certificados, y confirme que se muestran las pruebas de CA y la nueva pestaña Métricas.
6. Reactivar o ampliar la automatización: Configure los agentes del servidor web para que realicen una renovación automática, conecte las nuevas autoridades de certificación o bóvedas que planee utilizar y actualice los playbooks de Ansible al módulo ACME si opta por esa vía.
7. Confirmar la preparación para la reversión antes de cerrar la ventana de mantenimiento.
8. Supervise el primer ciclo de renovación automatizada. Después de la actualización, registre las siguientes métricas de éxito como referencia.

Ejemplo de configuración: Declaración del estado del certificado con Ansible

La ruta de automatización ACME de Ansible en la versión 3.3 le permite declarar el estado deseado de un certificado en su configuración de Ansible en lugar de emitirlo y renovarlo manualmente. El siguiente ejemplo muestra el patrón general utilizando Ansible. community.crypto.acme_certificate módulo; consulte la documentación de CertSecure Manager para conocer los parámetros de tarea exactos que necesita su entorno.

- name: Ensure TLS certificate is issued and current
  community.crypto.acme_certificate:
    account_key_src: /etc/pki/acme/account.key
    csr: /etc/pki/tls/csr/www.example.com.csr
    dest: /etc/pki/tls/certs/www.example.com.crt
    acme_directory: https://acme-v02.api.letsencrypt.org/directory
    acme_version: 2
    terms_agreed: true
    challenge: dns-01

Al ejecutar esto como parte de un playbook programado, el certificado implementado se alinea automáticamente con el estado declarado, que es el patrón que los equipos que ya utilizan Ansible a gran escala deberían extender a sus certificados administrados por CertSecure.

Tabla de requisitos previos para la acción

Requisito previo	POR QUÉ ES IMPORTANTE	Acción:	Propietario
Versión base reciente de CertSecure Manager	3.3 actualizaciones desde una versión reciente compatible; saltarse versiones puede complicar la migración.	Confirma la versión actual con tu equipo de cuentas antes de programar la cita.	Equipo PKI
Acceso de administrador a las CA y bóvedas conectadas.	Las nuevas integraciones (Google Public CA, Azure Key Vault Government, AWS, ServiceNow) requieren credenciales para su configuración.	Recopile o confirme las credenciales antes de la ventana de mantenimiento.	Equipo de PKI / Equipo de plataforma
Ventana de mantenimiento y plan de secuenciación de alta disponibilidad	La actualización incluye un reinicio del servicio y, para alta disponibilidad, actualizaciones secuenciales de los nodos.	Programe la ventana y confirme la secuencia con su equipo de cuenta.	equipo de la plataforma
Copia de seguridad previa a la actualización	Restaura el entorno si la verificación falla después de la actualización.	Realice y pruebe una copia de seguridad de la configuración, la base de datos y los scripts personalizados.	Equipo PKI
Nodo de control de Ansible (si se adopta la automatización ACME)	Necesario para ejecutar el patrón de ejemplo community.crypto.acme_certificate	Confirme las herramientas y el acceso a Ansible antes de realizar la prueba piloto.	Equipo de plataforma/DevOps
Instancia de ServiceNow (si se adopta la aplicación)	Es necesario instalar la aplicación CertSecure Certificate Management desde la tienda de ServiceNow.	Confirma los permisos de instalación de la aplicación de la tienda.	Equipo de plataforma / Equipo ITSM

Antes y después: El cambio en el flujo de trabajo operativo

Task	Antes (Enfoque manual)	Después (con CertSecure Manager 3.3)
Ejecución de renovación	Reemisión y redistribución manual de cada certificado, con seguimiento en hojas de cálculo o recordatorios de calendario.	El proceso de renovación sin intervención humana abarca desde la inscripción en CA hasta la entrega, instalación y recarga del servicio.
Visibilidad del riesgo	Scripts de detección ad hoc y revisión manual de hojas de cálculo para encontrar claves débiles o certificados de larga duración.	El perfil de riesgo del certificado evalúa automáticamente cada certificado; filtre a Grave en segundos.
Revocación masiva o limpieza	Los certificados se revocan y reasignan uno por uno.	La revocación masiva y la transferencia masiva de propiedad gestionan muchos certificados en una sola operación.
Solución de problemas de la cadena	Localice manualmente los intermediarios que falten en los portales de CA.	Visualización completa de la cadena de confianza y descarga de la cadena desde la vista de detalles del certificado.
CA y salud de la infraestructura	Se descubrió solo después de fallos en la inscripción o una interrupción del servicio.	El ping de CA y la pestaña Métricas muestran el estado de CA y del agente de automatización de forma proactiva.

Guía de reversión

Dado que la actualización incluye una migración de la configuración y de la base de datos, planifique la reversión antes de comenzar, no después de que algo salga mal.

• Mantenga la copia de seguridad, la configuración, la base de datos y los scripts personalizados previos a la actualización accesibles y probados para su restauración, no solo capturados.
• Para implementaciones de alta disponibilidad, confirme con su equipo de cuenta qué secuencia de nodos permite una reversión segura a la versión anterior en caso de que falle la verificación.
• Evite habilitar nuevas rutas de automatización, como el módulo ACME de Ansible o nuevos conectores CA, hasta que haya confirmado que la actualización principal es estable, para que una reversión no tenga que deshacer también la nueva automatización.
• Si la verificación falla después de la actualización, restaure la copia de seguridad anterior a la actualización y póngase en contacto con su equipo de consultoría de cifrado antes de volver a intentarlo.

Errores comunes y cómo evitarlos

• Omitir la copia de seguridad previa a la actualización: La forma más común en que una actualización difícil se convierte en irrecuperable es realizando siempre una copia de seguridad de la configuración, la base de datos y los scripts personalizados.
• Actualización de nodos HA fuera de secuencia: Aplicar la secuencia proporcionada por el equipo de cuentas en lugar de actualizar los nodos en un orden arbitrario.
• Suponiendo que la automatización existente se mantenga sin cambios: Es posible que sea necesario volver a conectar algunos agentes y conectores de CA en la nueva interfaz de usuario, incluso si las credenciales no han cambiado; confírmelo en lugar de darlo por sentado.
• Ignorando los resultados del nuevo perfil de riesgo del certificado: Un aumento repentino en los certificados de riesgo grave o alto justo después de una actualización generalmente refleja certificados que ya tenían claves o algoritmos débiles, no un error; investigue antes de descartarlo.
• No probar primero la ruta ACME de Ansible en un entorno que no sea de producción: Validar una nueva ruta de automatización en un conjunto pequeño y representativo de certificados antes de integrarla en la renovación de producción.

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

• Porcentaje de certificados clasificados como Seguros o de Bajo Riesgo frente a los clasificados como de Alto Riesgo o Grave según el Perfil de Riesgo del Certificado, con seguimiento mensual.
• Porcentaje de renovaciones completadas mediante automatización sin intervención manual frente a la intervención manual, ya que esa proporción determina si se puede mantener el ritmo de 47 días.
• Ahora es posible revocar y reasignar la propiedad de un lote definido de certificados de forma masiva, en comparación con el proceso anterior de uno por uno.
• Número de incidencias o incidencias relacionadas con certificados por trimestre, en comparación con la línea base anterior a la actualización.
• Tiempo transcurrido desde una votación de la CA o un cambio de política hasta la visibilidad completa del inventario de certificados afectados, utilizando el ping de la CA y el descubrimiento ampliado en la versión 3.3.

Matriz de propietarios y acciones por equipo

Equipo	Medioambiental	Acción clave
Equipo PKI	Es propietario de la actualización en sí y del inventario de certificados del que depende.	Confirme los requisitos previos, programe la actualización y valide la puntuación del perfil de riesgo del certificado después de la actualización.
Equipo de seguridad	Es responsable de interpretar los resultados del perfil de riesgo y de confirmar que no haya interrupciones en el flujo de trabajo que dependan del certificado.	Revise los certificados de riesgo grave y alto dentro del primer ciclo de renovación y confirme que los manuales de revocación masiva estén actualizados.
Equipo de plataforma/DevOps	Posee automatización de cableado, incluyendo Ansible ACME, agentes de cero intervención y CI/CD, en el entorno actualizado.	Valide el ejemplo de Ansible ACME con un conjunto de certificados que no sea de producción antes de su implementación en producción.
Equipo de Cumplimiento/Auditoría	Posee evidencia de que el riesgo y la propiedad del certificado se rastrean y están actualizados.	Utilice los informes de perfil de riesgo y los registros de transferencia de propiedad masiva como evidencia lista para auditoría en cada ciclo.

Qué hacer a continuación

• Equipos PKI: Confirma los requisitos previos y programa la actualización a la versión 3.3 para este trimestre, si aún no lo has hecho.
• Equipos de seguridad: Se prevé revisar los resultados del perfil de riesgo del certificado durante la primera semana posterior a la actualización.
• Equipos de plataforma: Pruebe la ruta de automatización ACME de Ansible en un conjunto de certificados que no sea de producción antes de adoptarla de forma generalizada.
• Equipos de cumplimiento: Confirme que su próxima auditoría puede mostrar el perfil de riesgo y los registros de transferencia de propiedad como evidencia.

El turno de 47 días

El 11 de abril de 2025, el CA/Browser Forum, el organismo del sector que establece las normas que siguen los principales navegadores y autoridades de certificación, aprobó la propuesta SC-081v3, presentada originalmente por Apple y respaldada por Sectigo, Google Chrome y Mozilla. La votación se aprobó por 29 votos a favor y 0 en contra, con cinco abstenciones. Los cuatro principales proveedores de navegadores (Apple, Google, Microsoft y Mozilla) votaron a favor, junto con 25 autoridades de certificación , entre ellas DigiCert, Sectigo, GlobalSign, GoDaddy y Amazon. Cinco autoridades de certificación se abstuvieron, alegando preocupaciones sobre la preparación operativa.

La votación reduce gradualmente la duración de los certificados TLS, pasando del máximo actual de 398 días a tan solo 47 días para 2029. El calendario es el siguiente: 

• Marzo 15, 2026: La duración máxima de los certificados TLS se reduce a 200 días, al igual que la reutilización de la validación de control de dominio.
• Marzo 15, 2027: La vida útil máxima se reduce a 100 días, y la reutilización de DCV también se reduce a 100 días.
• Marzo 15, 2029: La vida útil máxima se reduce a 47 días, y el período de reutilización del DCV se reduce a tan solo 10 días.

Ya hemos superado el primer hito. El límite de 200 días está vigente en este momento. 

¿Por qué específicamente 47? Equivale a un mes de 31 días, más la mitad de un mes de 30 días, más un día de margen. Suficiente para mantener una frecuencia de renovación mensual razonable sin que sea tan ajustado que los operadores no tengan margen de maniobra.

Qué significa esto realmente para tu equipo.

Las matemáticas son lo que quita el sueño a la gente. Una organización que gestiona 1,000 certificados tendrá que realizar aproximadamente 7,766 renovaciones al año con el modelo de 47 días. Eso equivale a unas 21 renovaciones diarias, un aumento de ocho veces con respecto a la frecuencia actual. 

Según la encuesta Trust Pulse de DigiCert, publicada el 2 de julio de 2025, el 45 % de las organizaciones experimentaron interrupciones del servicio relacionadas con certificados durante el último año, y el 37.5 % atribuyeron una interrupción específicamente a un certificado caducado. Un aumento de ocho veces en la frecuencia de renovación multiplica las probabilidades de que se produzca ese mismo fallo, a menos que la renovación esté automatizada de principio a fin.

El calendario que justifica este aumento de ocho veces proviene de la propuesta SC-081v3 del Foro CA/Browser , aprobada el 11 de abril de 2025: las fases máximas de validez de los certificados TLS públicos pasan de los 398 días actuales a 200 días en marzo de 2026, 100 días en marzo de 2027 y 47 días en marzo de 2029.

Hojas de cálculo, recordatorios de calendario, «Bob se encarga de eso». Nada de esto es escalable. El Foro CA/Browser no ha disimulado esto: la incomodidad es deliberada, porque el consenso de la industria es que la automatización ya no es opcional para la seguridad de internet. Los certificados TLS de 47 días son la forma en que este mensaje deja de ser opcional.

Existen tres razones reales que explican este acortamiento. 

• Limitación del radio de explosión: Si llave privada Si el sistema se ve comprometido, un certificado de 398 días le da al atacante más de un año de uso indebido. Un certificado de 47 días les da, como máximo, unas semanas.
• Solución para el problema de la revocación: La papeleta incluye un largo argumento de que el sistema de revocación de certificados utiliza CRL y OCSP No es fiable, ya que los navegadores suelen ignorar estas funciones. Los plazos de validez cortos son un mecanismo más honesto que la revocación que en realidad no se produce.
• Agilidad criptográfica para la era cuántica: Una menor duración de los datos dificulta las tácticas de "capturar ahora, descifrar después" para los adversarios, y acelera la transición a nuevos algoritmos criptográficos cuando sea necesario. NIST finalizó sus primeros estándares post-cuánticos (ML-KEM, ML-DSA, SLH-DSA) en 2024 y públicos CA ya están realizando pruebas piloto de emisión. Migración fuera RSA y ECDSA Ya no es algo lejano. Un conjunto de certificados que se renuevan cada seis semanas se adapta más rápido que uno que se renueva cada trece meses.

CertSecure Manager 3.3 se diseñó teniendo en cuenta estas tres realidades. Así es como se refleja esto en la versión.

Detecta el riesgo antes de que te detecte.

Si va a renovar certificados ocho veces más a menudo, necesita un panel de control que le indique qué certificados presentan problemas antes de que se conviertan en incidentes. Tres cambios en la versión 3.3 trabajan en conjunto para brindarle esa funcionalidad. 

Perfil de riesgo del certificado 

 Ahora, cada certificado de su inventario se califica automáticamente según un perfil de riesgo, y la calificación se muestra como una columna en los listados de su inventario y como un filtro en la búsqueda de certificados. La calificación analiza tres indicadores que históricamente han sido la causa de la mayoría de los problemas en la gestión de certificados:

• Longitud de la clave: Se señalan las claves RSA débiles, las curvas ECDSA obsoletas y cualquier cosa que esté por debajo de los estándares actuales de la industria.
• Algoritmo de firma: Sacando a la luz los sistemas SHA1 que aún resisten, los hashes débiles y cualquier cosa que no sobreviva a la próxima ola de desuso.
• Periodo de validez: Es más importante ahora que nunca, a medida que la industria avanza en la escala de 398 a 200 a 100 a 47 días.

Los certificados se clasifican en cuatro niveles: Seguro, Bajo Riesgo, Alto Riesgo y Grave. Al filtrar, ordenar y generar informes sobre estos niveles, puede preguntar «muéstrame todos los certificados Graves en producción» y obtener una respuesta en segundos, en lugar de tener que ejecutar un script de descubrimiento y crear una tabla dinámica en Excel. Además, le proporciona la información necesaria cuando un auditor le pregunte cómo gestiona el riesgo criptográfico.

Visualización de la cadena de confianza del certificado 

Cuando falla el protocolo de enlace TLS, la causa suele ser algún problema menor relacionado con la cadena de certificados: un certificado intermedio faltante, una cadena en el orden incorrecto o una raíz obsoleta. CertSecure ahora visualiza la cadena de confianza completa para cada certificado administrado, directamente desde la vista de detalles del certificado.

Los certificados raíz e intermedios son accesibles directamente en la pantalla, y cada elemento de la cadena es clicable, lo que permite acceder a los metadatos sin salir de ella. Para certificados de terceros, el sistema admite la creación y descarga de la cadena completa, evitando así la necesidad de buscar certificados intermedios en diferentes portales de CA al implementarlos en un nuevo entorno.

Métricas del sistema y de ping de CA

Dos funciones que a menudo se pasan por alto completan la información sobre la visibilidad. Una nueva función de comprobación de estado de las CA en la página de administración de CA permite supervisar si cada CA conectada es accesible y funciona correctamente. Esto resulta útil tanto para diagnosticar inscripciones fallidas como para detectar de forma proactiva las interrupciones de las CA antes de que las detecten los usuarios.

La nueva pestaña Métricas en Configuración le ofrece monitorización en tiempo real de la CPU, el disco y la RAM para cada componente de CertSecure: agentes de automatización, conectores de CA y nodos de administración. Puede añadir o eliminar máquinas de la vista para centrarse en lo que realmente importa para su entorno. Cuando la automatización es la base de su estrategia de renovación, es fundamental que dicha base funcione correctamente. 

Sobrevive al ritmo de renovación con operaciones a granel.

Dos funciones muy solicitadas llegan en la versión 3.3, y juntas probablemente representarán el mayor avance en productividad desde el primer día para la mayoría de los equipos. 

Revocación masiva

Ahora puedes revocar varios certificados a la vez en una sola operación. Si alguna vez has vivido una situación similar, te resultará evidente su utilidad. 

• Eventos clave que comprometen la seguridad: Si un HSM Si el almacén de claves se ve comprometido, debe revocarlo de forma rápida y completa, no un certificado a la vez.
• Eventos de desconfianza en California: Si se elimina una CA del almacén raíz (sucede, pregúntenle a cualquiera que haya vivido la experiencia de DigiNotar, Symantec o cualquiera de los ejemplos más recientes), es necesario eliminar los certificados afectados de inmediato.
• Limpieza rutinaria: Certificados de prueba obsoletos, servicios retirados, entornos antiguos. Revoquémoslos en masa y sigamos adelante.

Transferencia de propiedad masiva

Los registros de propiedad de certificados cambian constantemente. La gente se va, los equipos se reorganizan y las aplicaciones se reasignan. En la versión 3.3, puedes transferir la propiedad de varios certificados a la vez. Esta función parece insignificante hasta que pasas dos días revisando los registros de certificados individualmente para actualizar el correo electrónico del propietario después de una reorganización. 

Ambas características ya resultaban útiles en un mundo de 398 días. En un mundo de 47 días, son imprescindibles. 

Automatización que abarca las plataformas que la mayoría de las herramientas olvidan.

La automatización solo funciona si funciona en todas partes, y tradicionalmente, las herramientas de automatización han sido muy eficaces contra objetivos sencillos y muy débiles contra los más complejos. CertSecure 3.3 soluciona algunas de las deficiencias más solicitadas.

Automatización de renovaciones para Citrix NetScaler, JBoss EAP y Wildfly.

La automatización integral de la renovación de certificados ahora se extiende a Citrix NetScaler, JBoss EAP y Wildfly. Fundamentalmente, la automatización gestiona la recuperación de la cadena de certificados como parte del flujo de renovación, de modo que el agente obtiene los certificados intermedios correctos y los inserta en el almacén de claves o la configuración adecuados, sin que los usuarios tengan que descargar los paquetes de la cadena por separado e integrarlos manualmente. Este último detalle es más importante de lo que parece: una configuración incorrecta de la cadena es una de las causas más comunes de fallos en las implementaciones. 

Renovación sin intervención manual en todos los agentes de servidor web.

Todos los agentes de renovación de servidores web de CertSecure ahora admiten la renovación automática. Esto significa que la renovación de un certificado puede realizarse sin intervención humana, desde la inscripción en la CA hasta la entrega, instalación y reinicio del servicio. Este es el único modelo sostenible cuando se renueva cada seis o siete semanas.

Gestión del estado deseado de Ansible con el módulo ACME

Para entornos que prefieren la infraestructura como código, la versión 3.3 introduce una nueva ruta de automatización mediante el módulo ACME de Ansible . Se declara el estado deseado de los certificados en la configuración de Ansible, y el sistema se encarga de obtener y renovar los certificados TLS de cualquier CA compatible con ACME, manteniendo el estado desplegado real alineado con el declarado. Es el modelo ideal para equipos que ya utilizan Ansible a gran escala.

Conozca los certificados dondequiera que se encuentren.

CertSecure 3.3 amplía el universo de CA, bóvedas y sistemas que puede administrar de forma nativa.

Integración de Google Public CA

Google Public CA ahora es una CA integrada de primera clase. La gestión completa del ciclo de vida (emisión, renovación, revocación, inventario) funciona con Google Public CA igual que con sus otras CA. Para las organizaciones que utilizan los servicios de GCP o que desean una opción adicional de CA pública, esto elimina una importante brecha de integración.

La aplicación ServiceNow ya está disponible en la tienda.

La aplicación CertSecure Certificate Management para ServiceNow ya está disponible en la tienda oficial de ServiceNow. Esto es mucho más importante de lo que parece: la mayoría de los flujos de trabajo de certificados empresariales ya se gestionan mediante tickets de ITSM. La integración permite a los usuarios solicitar, registrar, generar y descargar certificados desde su flujo de trabajo de ServiceNow existente, en lugar de tener que aprender a usar un nuevo portal. Menos complicaciones, procesamiento más rápido y menos tickets pendientes porque alguien no sabía qué herramienta usar.

Azure Key Vault: Inquilinos gubernamentales y carga con un solo clic

La compatibilidad con Azure Key Vault se ha ampliado en dos direcciones importantes.

• Los inquilinos del gobierno ahora reciben apoyo, Con control de acceso basado en roles (RBAC) completo para la carga de certificados. Esto es fundamental para los clientes del sector público y regulado que operan en Azure Government. 
• Carga con un solo clic Permite insertar certificados en Azure Key Vault, ya sea en el momento de la inscripción o para cualquier certificado ya inscrito. Lo que antes requería varios pasos manuales, ahora se realiza con un solo botón. 

DigiCert: Periodos de validez personalizados

Los clientes de DigiCert ahora pueden especificar un período de validez personalizado al registrarse. Un pequeño cambio, solicitado con frecuencia y particularmente relevante a medida que la industria reduce gradualmente la vida útil de las licencias. La decisión de "adaptar la renovación a la ventana de implementación" se está volviendo más compleja.  

Descubrimiento sin búsqueda manual

No se puede gestionar lo que no se encuentra. CertSecure 3.3 introduce dos mejoras importantes. 

• Descubrimiento en la nube de AWS Ahora está habilitado. Los certificados que se encuentran en AWS, incluidos ACMLos sistemas de gestión de identidades y accesos (IAM) y los balanceadores de carga se pueden incorporar automáticamente al inventario de CertSecure en lugar de realizar un seguimiento por separado. 
• Descubrimiento de tiendas IIS CCS Ahora es compatible. Para entornos con gran cantidad de Windows que utilizan el Almacén Centralizado de Certificados de IIS, los certificados en los recursos compartidos de CCS ahora se pueden inventariar de forma nativa. 

Una vez que los certificados se encuentran en el inventario, los certificados de terceros aparecen en su propio contenedor visible en Inventario → CertSecure, y se pueden filtrar mediante el filtro Tipo de certificado. Puede realizar las mismas operaciones que con los certificados gestionados internamente: descargar, ver la cadena, enviar por correo electrónico y cambiar de contenedor. Esto resuelve una de las deficiencias recurrentes en la gestión de certificados. En concreto, el problema de «tenemos algunos certificados de CA externas y los gestionamos en una hoja de cálculo aparte». 

La función de informes también incorpora un nuevo filtro de plantillas en los informes de inventario y caducidad, lo que permite segmentar el inventario por plantilla de certificado. Esto resulta útil en entornos con muchas plantillas que cumplen diferentes funciones, donde la pregunta clave es: "¿Cuántos certificados de plantilla de mi servidor web caducan en 30 días?". 

Y si alguna vez has dedicado diez minutos a buscar una sección específica en las páginas de documentación, ahora la documentación de la interfaz de usuario incluye una función de búsqueda integrada. 

Momentos de inscripción más fluidos

Un par de cambios pequeños pero realmente útiles. 

Descarga de PFX con carga de clave privada para la inscripción mediante CSR. Al inscribirte mediante CSR , ahora puedes cargar tu clave privada durante el proceso de inscripción y CertSecure generará un archivo PFX descargable. Para los destinos que requieren PFX (y aún hay muchos), esto evita tener que ejecutar openssl en tu ordenador.

Se ha solucionado un problema con la entrega de certificados DigiCert por correo electrónico en un caso excepcional conocido, y se han corregido algunos errores adicionales en el proceso de inscripción. También se ha corregido el comportamiento de la opción "ignorar plantilla".

Que Viene Próximamente?

Una breve nota sobre hacia dónde nos dirigimos, porque el trabajo no termina con este lanzamiento.

La automatización cada vez más profunda es el tema principal. A medida que los certificados de 100 días se conviertan en el estándar en marzo de 2027, añadiremos más destinos de implementación y patrones de orquestación más sofisticados. Si hay alguna plataforma en su infraestructura que aún no automatizamos, háganoslo saber. Sus comentarios nos ayudarán a definir la hoja de ruta.

La preparación para la criptografía postcuántica es el segundo aspecto clave. El perfil de riesgo, la renovación automática y la base de orquestación de la versión 3.3 facilitan una futura migración a PQC . Al poder renovar automáticamente toda una flota, el cambio de algoritmos se convierte en una simple modificación de configuración, en lugar de un proyecto que se extiende por varios trimestres. Las capacidades explícitas de PQC están en desarrollo, y compartiremos más información en futuras versiones a medida que el ecosistema de CA públicas estandarice sus prácticas de emisión de PQC.

La misma base de automatización se extiende más allá de los certificados TLS. Nuestra plataforma CBOM Secure realiza la misma detección de certificados en todo su entorno criptográfico, y nuestra guía CBOM: De inventario a inteligencia explica cómo convertir ese inventario en un programa continuo. Dado que la automatización de certificados en CertSecure Manager 3.3 es independiente de la CA, la base de renovación automática que usted crea ahora también le brinda la agilidad criptográfica necesaria para cambiar de algoritmos más adelante sin un proyecto de varios trimestres. Nuestra hoja de ruta de preparación para PQC de 9 fases y el Centro de Excelencia de PQC pueden ayudarle a planificar esa transición junto con esta actualización.

La expansión de Discovery es la tercera novedad. AWS Cloud Discovery e IIS CCS se suman a la lista de herramientas de Discovery en la versión 3.3, pero aún quedan más almacenes de certificados en la nube y locales por cubrir. Estamos trabajando en ello.

Cómo actualizar

CertSecure Manager v3.3 ya está disponible. Si ya utiliza una versión reciente, la actualización es sencilla. Su equipo de consultoría de cifrado le guiará a través de las consideraciones específicas de su entorno y la secuencia de implementación para entornos de alta disponibilidad. 

Si aún no utiliza CertSecure Manager , es importante considerar el momento oportuno. El cambio de certificados de 200 días a certificados de 100 días se implementará en marzo de 2027, en menos de un año. Las organizaciones que esperen hasta que los certificados de 47 días sean obligatorios en 2029 para comenzar a automatizar sus procesos se enfrentarán a graves problemas. Las organizaciones que establezcan una base de automatización sólida ahora, durante las fases de 200 y 100 días, llegarán a 2029 con una infraestructura ya operativa.

Si alguna de las funciones mencionadas anteriormente le parece que resuelve un problema con el que ha estado conviviendo, póngase en contacto con el equipo de Consultoría de Cifrado para que realicen un análisis detallado de su entorno.

Y, como siempre, gracias a todos los clientes que abrieron una incidencia, hicieron preguntas difíciles o insistieron en que la solución alternativa existente no era aceptable. Gran parte de lo que incluye la versión 3.3 se debe a ustedes.

Lecturas relacionadas de Encryption Consulting

• Automatización de la validación DNS con CertSecure Manager: DCV persistente y conectores DNS Cubre la automatización de la validación del dominio dentro del mismo ciclo de renovación de 47 días.
• CBOM: Del inventario a la inteligencia Este tema aborda la transformación del descubrimiento criptográfico en un programa continuo que va más allá de los certificados.
• Centro de Excelencia PQC Este documento explica cómo planificar la migración post-cuántica junto con esta base de automatización de certificados.

Preguntas frecuentes

¿Cuál es la principal conclusión de que CertSecure Manager 3.3 ya está aquí y llega justo cuando más lo necesitas?

CertSecure Manager 3.3 está diseñado para la reducción gradual, por parte del CA/Browser Forum, de la validez máxima de los certificados TLS públicos a 47 días para 2029. Esta versión añade un perfil de riesgo de certificado, revocación masiva y transferencia de propiedad, renovación automática en todos los agentes de servidor web y una ruta de automatización ACME de Ansible, de modo que los equipos de certificados puedan operar con una frecuencia de renovación aproximadamente ocho veces mayor que la actual, sin cuellos de botella manuales.

¿Por qué es importante esto para la gestión del ciclo de vida de los certificados empresariales?

La encuesta Trust Pulse de DigiCert reveló que el 45 % de las organizaciones experimentaron interrupciones del servicio relacionadas con certificados durante el último año, y el 37.5 % atribuyó una interrupción específicamente a un certificado caducado. Dado que la frecuencia de renovación aumenta aproximadamente ocho veces con el plazo de 47 días, cada paso manual en ese proceso se convierte en una oportunidad más frecuente para que se produzca la misma interrupción, que es precisamente lo que la automatización sin intervención manual está diseñada para eliminar.

¿Qué equipos son responsables de poner en práctica estas directrices?

Los equipos de PKI se encargan de programar la actualización y validar posteriormente los resultados del perfil de riesgo del certificado. Los equipos de seguridad se encargan de revisar los certificados de riesgo alto y grave y de confirmar que los manuales de revocación masiva estén actualizados. Los equipos de plataforma y DevOps se encargan de integrar la renovación automática y la automatización ACME de Ansible. Los equipos de cumplimiento se encargan de utilizar el perfil de riesgo y los registros de transferencia de propiedad como evidencia para auditorías.

¿Qué riesgos aumentan si este tema se aborda manualmente?

El seguimiento manual de certificados, con aproximadamente 21 renovaciones diarias (el volumen que alcanza un inventario de 1,000 certificados con un ciclo de 47 días), aumenta considerablemente la probabilidad de que se produzcan renovaciones omitidas y las consiguientes interrupciones del servicio. Los procesos manuales también dificultan la detección de claves débiles, algoritmos obsoletos y largos periodos de validez antes de que intervenga un auditor o se produzca un incidente, que es precisamente lo que el Perfil de Riesgo de Certificados está diseñado para revelar automáticamente.

¿Cómo reduce la automatización el riesgo de interrupción de los certificados?

La renovación automática gestiona un certificado desde su registro en la CA hasta su entrega, instalación y recarga del servicio, sin que se produzcan errores ni retrasos. Al combinar esto con el Perfil de Riesgo del Certificado, los certificados débiles o próximos a caducar se identifican automáticamente, en lugar de detectarse cuando falla un servicio que ya utiliza dicho certificado.

¿Qué métricas deberían monitorizar los equipos tras la implementación?

Realice un seguimiento del porcentaje de certificados clasificados como Seguros o de Bajo Riesgo frente a los de Alto Riesgo o Graves, la proporción de renovaciones completadas mediante automatización sin intervención manual frente a la intervención manual, el tiempo necesario para revocar y reasignar la propiedad de forma masiva para un lote definido, y los tickets de interrupción relacionados con certificados por trimestre en comparación con su línea base anterior a la actualización.

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

La propuesta SC-081v3 del Foro CA/Browser, aprobada el 11 de abril de 2025, reduce gradualmente la validez máxima de los certificados TLS públicos de 398 días a 200 días en marzo de 2026, 100 días en marzo de 2027 y 47 días en marzo de 2029, lo que representa un aumento de aproximadamente ocho veces en la frecuencia de renovación. La renovación automática, las operaciones masivas y la evaluación de riesgos de CertSecure Manager 3.3 están diseñadas específicamente para absorber este aumento sin necesidad de contratar más personal.

¿Cómo debe gestionarse esto en entornos PKI híbridos o multinube?

Aplique la misma puntuación de perfil de riesgo de certificado, renovación automática y detección de forma consistente en todos los entornos de CA, nube y locales, en lugar de automatizar uno y dejar otro en manual. Las funciones de detección en la nube de AWS, detección en el almacén CCS de IIS, compatibilidad con Azure Key Vault e integración nativa con la CA pública de Google de CertSecure Manager 3.3 están diseñadas para centralizar precisamente estos entornos mixtos en un único inventario.

¿Qué requisitos previos son necesarios antes de la implementación?

Para actualizar, necesita una versión reciente y compatible de CertSecure Manager, acceso administrativo a cada CA y bóveda conectada que planee incorporar a las nuevas funciones, una ventana de mantenimiento programada con la secuencia de nodos confirmada para implementaciones de alta disponibilidad y una copia de seguridad probada de su configuración y base de datos actuales realizada inmediatamente antes de la actualización.

¿Qué capturas de pantalla o ejemplos de configuración se deben incluir?

La columna Perfil de riesgo del certificado en Inventario y búsqueda de certificados, la visualización de la cadena de confianza en la vista de detalles de un certificado, el nuevo estado de ping en la página de Administración de CA y la vista de CPU, disco y RAM en la pestaña Métricas son las cuatro vistas de la interfaz de usuario que conviene capturar para las guías de implementación interna. Para la configuración, el ejemplo de automatización ACME de Ansible en esta guía muestra el patrón para declarar el estado del certificado como código.