Salud del certificado de firma SAML en Microsoft Entra

Certificado de firma SAML Entra expirado: qué significa

Cuando un certificado de firma SAML Entra está expirado, el inicio de sesión federado para esa aplicación se rompe en todo el tenant — no por un ataque, sino por una tarea administrativa rutinaria que nadie programó. Toda aplicación empresarial configurada para el inicio de sesión único (SSO) federado mediante SAML en Microsoft Entra ID depende de un certificado de firma: Entra ID usa su clave privada para firmar criptográficamente las aserciones SAML que emite, y el proveedor de servicios valida esas aserciones con la clave pública correspondiente. Este es el ancla de confianza de toda la relación de federación — si el certificado no es válido, la aserción no vale nada para el proveedor de servicios, sin importar lo correcto que sea el resto del flujo de autenticación.

La "salud del certificado" cubre tres estados de riesgo distintos pero relacionados, seguidos en el catálogo de vulnerabilidades de EtcSec para aplicaciones de Azure:

Expirado — el período de validez del certificado ya ha pasado. Esto es una interrupción funcional, no solo una debilidad de seguridad.
Por expirar pronto — el certificado expirará en los próximos 30 días y no se ha preparado ninguna renovación.
Vida útil larga — el certificado se emitió con una ventana de validez excesivamente larga (Entra ID usa tres años por defecto), lo que amplía el radio de impacto si la clave privada llega a manejarse mal y aumenta la probabilidad de que quien era responsable de la rotación ya haya dejado la organización, cambiado de rol, o simplemente lo haya olvidado.

Por defecto, al configurar el SSO basado en SAML para una aplicación de la galería o fuera de ella, Entra ID genera automáticamente un certificado autofirmado válido por tres años (Microsoft Learn). A diferencia de un secreto de aplicación con una vida útil corta por defecto que obliga a prestarle atención con frecuencia, un certificado SAML de tres años es fácil de configurar una vez y no volver a pensar en él — hasta que expira silenciosamente.

Cómo sustenta el certificado el inicio de sesión federado

Cuando Entra ID actúa como proveedor de identidad (IdP) para una aplicación SAML, el flujo de inicio de sesión depende del estado del certificado en dos momentos:

Entra ID firma la aserción SAML (o la respuesta) con la clave privada del certificado de firma activo en el principal de servicio de la aplicación empresarial.
El proveedor de servicios valida esa firma contra el certificado público que tiene registrado (subido manualmente o recuperado dinámicamente desde la URL de metadatos de federación de la aplicación).

Si el certificado que Entra ID usó para firmar ha expirado, Entra ID no deja de firmar con él — sigue usando el certificado que esté marcado como activo. Es el proveedor de servicios quien rechaza la aserción en cuanto detecta que el certificado ya no está dentro de su ventana de validez, y ese rechazo es lo que los usuarios experimentan como un fallo de inicio de sesión (Microsoft Learn). En otras palabras: Entra ID no "detecta" la expiración ni bloquea el inicio de sesión de forma proactiva — el fallo aparece más adelante en el flujo, en la aplicación, y solo después de que los usuarios empiecen a encontrárselo.

Sondeo de metadatos y notificaciones por correo

Existen dos mitigaciones según las capacidades de la aplicación:

Sondeo de metadatos de federación. Para las aplicaciones que lo soportan, Entra ID comprueba los metadatos de federación de la aplicación aproximadamente 35 días antes de que expire el certificado de firma; si hay un certificado nuevo disponible ahí, no se necesita intervención manual ni notificación (Microsoft Learn).
Notificaciones por correo. Para todo lo demás, Entra ID envía un correo a las direcciones de notificación configuradas en la aplicación empresarial 60, 30 y 7 días antes de la expiración, desde [email protected] — hasta cinco direcciones, y por defecto solo el administrador que configuró originalmente el SSO (Microsoft Learn).

Ambas mitigaciones dependen de que alguien las haya configurado correctamente de antemano, y ambas se omiten con frecuencia: el sondeo de metadatos solo funciona si la aplicación realmente lo soporta y lo consume, y la lista de notificación se queda fácilmente reducida al buzón de un único administrador que ya se ha marchado.

⚠️

⚠️ Advertencia: Si la validación de expiración del certificado está desactivada en el lado de la aplicación y se crea un certificado nuevo antes de la ventana de mantenimiento programada para el cambio, Entra ID puede pasar automáticamente a ese certificado válido pero aún no subido, antes de lo previsto — y como el proveedor de servicios todavía no lo ha recibido, esto provoca una interrupción de la aplicación en lugar de una corrección silenciosa. La recomendación de Microsoft es esperar a la ventana de mantenimiento antes de crear el nuevo certificado, y mantener activada la validación de expiración en el proveedor de servicios (Microsoft Learn).

Qué se rompe cuando el certificado expira o se queda demasiado tiempo

El impacto de un certificado de firma SAML expirado es de disponibilidad, no de confidencialidad: el inicio de sesión federado para esa aplicación falla para todos los usuarios hasta que el certificado se renueva y se reactiva en ambos lados. Para una aplicación SaaS de negocio usada en todo el tenant, eso es una interrupción total provocada únicamente por un descuido administrativo, no por la acción de un atacante.

Los certificados de vida útil larga conllevan un riesgo distinto, más silencioso. Una ventana de validez de tres años (o más) significa:

La rotación ocurre con la suficiente poca frecuencia como para que el proceso manual — generar, descargar, subir al SP, activar, verificar, limpiar el certificado antiguo — resulte poco familiar cada vez que se necesita, aumentando la probabilidad de un error durante la rotación en sí.
Deriva de propiedad: el administrador que lo configuró puede haber dejado de estar en la organización cuando llega el momento de renovar.
Una ventana más larga de exposición del material de la clave privada si el certificado o su exportación llegan a manejarse mal, sin una renovación forzada.

Las propias recomendaciones de Microsoft para los ISV que construyen integraciones SAML reconocen esto directamente, señalando que la rotación manual se vuelve "insostenible" a gran escala a medida que las vidas útiles de los certificados tienden a acortarse en todo el sector, y recomiendan que las aplicaciones soporten la rotación automatizada basada en metadatos con certificados de firma primario/secundario, precisamente para eliminar la fragilidad operativa de las vidas útiles largas y gestionadas manualmente (Microsoft Learn).

Por eso esta brecha también importa desde el punto de vista de la cobertura: el ciclo de vida de los certificados SAML es un riesgo distinto de la higiene de permisos de las aplicaciones. Un riesgo relacionado pero diferente dentro de la categoría Applications — los registros de aplicaciones con permisos delegados excesivos — se cubre en Azure App Registrations: aplicaciones sobreprivilegiadas del tenant; la salud de los certificados es una preocupación ortogonal, centrada en la disponibilidad, dentro de la misma categoría.

Detección: encontrar certificados SAML por expirar y con vida útil demasiado larga

No esperes a una avalancha de tickets de soporte para descubrir que un certificado ha expirado. Entra ID expone el estado de los certificados a través de varios canales:

Señal	Dónde	Qué buscar
Estado de expiración del certificado	Centro de administración de Entra → Enterprise apps → [App] → Single sign-on → SAML Certificates	Estado, fecha de expiración y huella digital de cada certificado (activo e inactivo)
`keyCredentials`, `passwordCredentials`	Objeto `servicePrincipal` de Microsoft Graph	`endDateTime` en el pasado o dentro de los próximos 30 días; varias credenciales con un estado activo poco claro
`preferredTokenSigningKeyThumbprint`	Objeto `servicePrincipal` de Microsoft Graph	Confirma con qué certificado está firmando realmente Entra ID — verificar que coincide con el subido al proveedor de servicios
Recomendación Renew expiring service principal credentials	Centro de administración de Entra → Overview → Recommendations, o Graph `/beta/directory/recommendations` (`servicePrincipalKeyExpiry`)	Señala cualquier credencial de principal de servicio que expire en 30 días, en todo el tenant, sin tener que comprobar aplicación por aplicación (Microsoft Learn)
Registros de auditoría	Registros de auditoría de Microsoft Entra — Service: Core Directory, Category: ApplicationManagement, Activity: Update Application – Certificates and secrets management / Update Service principal	Credencial añadida fuera de una ventana de cambio conocida, o ninguna actualización de credencial registrada al acercarse la expiración (Microsoft Learn)
Registros de inicio de sesión	Registros de inicio de sesión de Microsoft Entra, filtrados por la aplicación afectada	Un pico de inicios de sesión fallidos concentrado en una sola aplicación es el síntoma operativo; referencias de terceros sobre resolución de problemas SAML (por ejemplo, la guía de errores SAML de Entra de SSOJet) suelen asociar este fallo con el código `AADSTS50008` (InvalidSamlToken) en la relying party — hay que tratarlo como una señal para revisar el estado del certificado, no como una certeza, ya que el mismo código puede tener otras causas

💡

💡 Consejo: Consulta keyCredentials y passwordCredentials en todos los servicePrincipal del tenant en lugar de revisar las aplicaciones una por una — es exactamente la auditoría que recomienda la propia guía de operaciones de seguridad de Microsoft para detectar ventanas largas de expiración de credenciales antes de que se conviertan en una interrupción (Microsoft Learn).

Para un recorrido más amplio sobre cómo estructurar una revisión de seguridad de Entra completa más allá de los certificados, consulta Cómo auditar la seguridad de Microsoft Entra ID. Para el endurecimiento de configuraciones por defecto en todo el tenant que reduce la exposición junto con la higiene de certificados, consulta Endurecimiento del tenant de Azure: corrige configuraciones por defecto inseguras.

Remediación: renovar sin caídas

La secuencia de renovación documentada por Microsoft existe específicamente para evitar una interrupción durante la rotación — saltarse pasos o hacerlos en el orden incorrecto es la forma más habitual en que los equipos convierten una renovación planificada en un incidente no planificado.

Paso 1 — Crear el certificado nuevo con antelación

Crea el certificado nuevo con una fecha de expiración que se superponga con la validez restante del certificado actual, desde Enterprise apps → [App] → Single sign-on → SAML Certificates → New Certificate. Se guarda como Inactive — este paso por sí solo no causa ninguna interrupción (Microsoft Learn).

Paso 2 — Subirlo primero al proveedor de servicios

Descarga y sube el certificado nuevo al proveedor de servicios, en el formato de codificación que especifique la guía de configuración de SSO de la aplicación, antes de activarlo en Entra ID.

Paso 3 — Activar, verificar y limpiar

Activa el certificado nuevo en Entra ID (menú … del certificado nuevo → Make certificate active) — esto marca automáticamente el certificado anterior como inactivo. Verifica que el inicio de sesión funciona de extremo a extremo para la aplicación antes de dar por terminada la rotación, y luego elimina el certificado antiguo una vez verificado, para que no pueda reactivarse por error más adelante.

# Microsoft Graph PowerShell — inspeccionar el estado actual del certificado de firma SAML de un principal de servicio
Connect-MgGraph -Scopes "Application.Read.All"
Get-MgServicePrincipal -ServicePrincipalId "<service-principal-object-id>" `
    -Property "keyCredentials,preferredTokenSigningKeyThumbprint" |
    Select-Object -ExpandProperty KeyCredentials |
    Select-Object DisplayName, Usage, StartDateTime, EndDateTime

Para añadir un nuevo certificado de firma de token de forma programática, usa la acción de Graph servicePrincipal addTokenSigningCertificate, y luego establece preferredTokenSigningKeyThumbprint con la huella digital del nuevo certificado para que sea con el que firma Entra ID (Microsoft Learn — Configure SAML SSO using Microsoft Graph).

✅ Nota: Cierra la brecha de vida útil larga al mismo tiempo que cualquier renovación. Fija la expiración del certificado nuevo en una ventana más corta y deliberada en lugar de aceptar los tres años por defecto, y programa la próxima renovación con suficiente antelación para evitar otra carrera contrarreloj.

Prevenir que se repita

Más allá del certificado en sí, dos controles de bajo esfuerzo evitan que esto se repita:

Rellena el campo de direcciones de correo de notificación de cada aplicación federada con una lista de distribución, no con el buzón de una persona — se admiten hasta cinco direcciones, y Entra ID envía ahí los avisos de 60/30/7 días (Microsoft Learn).
Trata la recomendación Renew expiring service principal credentials de la página Overview del centro de administración de Entra como una comprobación permanente en todo el tenant, en lugar de depender de la memoria aplicación por aplicación.

Para los riesgos de permisos de aplicaciones que a menudo conviven con una mala configuración de certificados en las mismas aplicaciones empresariales, consulta OAuth Consent Phishing: cómo las aplicaciones maliciosas evitan el robo de contraseñas. Para los controles de acceso condicional más amplios que rigen cómo se puede llegar a las aplicaciones federadas, consulta Brechas de acceso condicional en Entra ID.

Cómo lo detecta EtcSec

La auditoría de Azure de EtcSec comprueba el estado del certificado de firma SAML de cada aplicación empresarial en cada escaneo del tenant. SAML_CERTIFICATE_EXPIRED marca cualquier aplicación cuyo certificado de firma activo ya haya expirado — un hallazgo crítico que afecta a la disponibilidad, ya que el inicio de sesión federado para esa aplicación está activamente roto. SAML_CERTIFICATE_EXPIRING_SOON marca los certificados que se acercan a su expiración para que la renovación pueda planificarse en lugar de hacerse con prisas, y SAML_CERTIFICATE_LONG_LIFETIME marca los certificados emitidos con una ventana de validez excesiva, para poder acortarla en la próxima rotación en lugar de reiniciar el mismo reloj plurianual.

ℹ️

ℹ️ Nota: EtcSec comprueba automáticamente esta vulnerabilidad en cada auditoría de Azure. Ejecuta una auditoría gratuita para verificar la postura de tus certificados SAML en todas tus aplicaciones federadas.