Estado do Certificado de Assinatura SAML no Entra

Certificado de Assinatura SAML do Entra Expirado: O Que Isso Significa

Quando um certificado de assinatura SAML do Entra expira, o login federado para aquela aplicação para de funcionar em todo o tenant — não por causa de um ataque, mas por uma tarefa administrativa rotineira que ninguém agendou. Toda aplicação empresarial configurada para single sign-on (SSO) federado via SAML no Microsoft Entra ID depende de um certificado de assinatura: o Entra ID usa sua chave privada para assinar criptograficamente as asserções SAML que emite, e o provedor de serviço valida essas asserções contra a chave pública correspondente. Essa é a âncora de confiança de todo o relacionamento de federação — se o certificado é inválido, a asserção não tem valor algum para o provedor de serviço, não importa quão correto seja o restante do fluxo de autenticação.

"Saúde do certificado" cobre três estados de risco distintos, mas relacionados, rastreados no catálogo de vulnerabilidades da EtcSec para Aplicações Azure:

Expirado — o período de validade do certificado já passou. Isso é uma interrupção funcional, não apenas uma fraqueza de segurança.
Expirando em breve — o certificado vai expirar dentro de 30 dias e nenhuma renovação foi preparada.
Vida longa demais — o certificado foi emitido com uma janela de validade excessivamente longa (o Entra ID usa três anos por padrão), o que amplia o raio de impacto caso o material da chave privada seja mal gerenciado em algum momento, e aumenta a chance de que quem era responsável pela rotação já tenha saído da organização, mudado de função, ou simplesmente esquecido.

Por padrão, ao configurar SSO baseado em SAML para uma aplicação de galeria ou não-galeria, o Entra ID gera automaticamente um certificado autoassinado válido por três anos (Microsoft Learn). Diferente de um segredo de aplicação com vida útil padrão curta, que força atenção frequente, um certificado SAML de três anos é fácil de configurar uma vez e nunca mais pensar nele — até expirar silenciosamente.

Quando o Entra ID atua como provedor de identidade (IdP) para uma aplicação SAML, o fluxo de login depende do estado do certificado em dois pontos:

O Entra ID assina a asserção SAML (ou a resposta) com a chave privada do certificado de assinatura ativo no service principal da aplicação empresarial.
O provedor de serviço valida essa assinatura contra o certificado público que possui em seus registros (seja carregado manualmente ou obtido dinamicamente da URL de metadados de federação da aplicação).

Se o certificado que o Entra ID usou para assinar expirou, o Entra ID não para de assinar com ele — continua usando o que quer que esteja marcado como ativo. É o provedor de serviço que rejeita a asserção assim que percebe que o certificado não está mais dentro da sua janela de validade, e essa rejeição é o que os usuários experimentam como uma falha de login (Microsoft Learn). Em outras palavras: o Entra ID não "percebe" a expiração e bloqueia o login proativamente — a falha aparece mais adiante, na aplicação, e só depois que os usuários começam a ser afetados.

Verificação de metadados e notificações por e-mail

Existem duas mitigações, dependendo das capacidades da aplicação:

Verificação de metadados de federação. Para aplicações que suportam isso, o Entra ID verifica os metadados de federação da aplicação aproximadamente 35 dias antes da expiração do certificado de assinatura; se um novo certificado estiver disponível ali, nenhuma intervenção manual ou notificação é necessária (Microsoft Learn).
Notificações por e-mail. Para tudo o mais, o Entra ID envia e-mails para os endereços de notificação configurados na aplicação empresarial 60, 30 e 7 dias antes da expiração, a partir de [email protected] — até cinco endereços, com padrão apenas para o administrador que originalmente configurou o SSO (Microsoft Learn).

Ambas as mitigações dependem de alguém tê-las configurado corretamente em primeiro lugar, e ambas costumam ser ignoradas: a verificação de metadados só funciona se a aplicação realmente suportar e consumi-la, e a lista de notificação é trivialmente deixada na caixa de entrada de um único administrador que já saiu da empresa.

⚠️

⚠️ Aviso: Se a validação de expiração de certificado estiver desativada do lado da aplicação e um novo certificado for criado antes da janela de manutenção agendada para o rollover, o Entra ID pode trocar automaticamente para esse certificado válido, mas ainda não carregado, antes do previsto — e como o provedor de serviço ainda não o recebeu, isso causa uma interrupção da aplicação em vez de uma correção silenciosa. A própria orientação da Microsoft é aguardar a janela de manutenção antes de criar o novo certificado, e manter a validação de expiração ativada no provedor de serviço desde o início (Microsoft Learn).

O Que Quebra Quando o Certificado Expira ou Fica Ativo por Tempo Demais

O impacto de um certificado de assinatura SAML expirado é sobre disponibilidade, não confidencialidade: o login federado para aquela aplicação falha para todos os usuários até que o certificado seja renovado e reativado em ambos os lados. Para uma aplicação SaaS de linha de negócio usada em todo o tenant, isso é uma interrupção completa causada puramente por um descuido administrativo, não por qualquer ação de atacante.

Certificados de vida longa carregam um risco diferente, mais silencioso. Uma janela de validade de três anos (ou mais) significa que:

A rotação acontece com tão pouca frequência que o processo manual — gerar, baixar, carregar no provedor de serviço, ativar, verificar, limpar o certificado antigo — permanece pouco familiar toda vez que é necessário, aumentando a chance de erro durante a rotação real.
Deriva de propriedade: o administrador que configurou o certificado pode não estar mais na organização quando a renovação for necessária.
Uma janela maior para que o material da chave privada fique exposto, caso o certificado ou sua exportação seja mal gerenciado em algum momento, sem uma renovação forçada.

A própria orientação da Microsoft para ISVs que constroem integrações SAML reconhece isso diretamente, observando que o rollover manual se torna "insustentável" em escala, à medida que os tempos de vida de certificados tendem a ficar mais curtos em todo o setor, e recomenda que aplicações suportem rollover automatizado baseado em metadados com certificados de assinatura primário/secundário, justamente para remover a fragilidade operacional de tempos de vida longos e gerenciados manualmente (Microsoft Learn).

É também por isso que essa lacuna importa do ponto de vista de cobertura: o ciclo de vida do certificado SAML é um risco distinto da higiene de permissões de aplicação. Um risco relacionado, mas diferente, na categoria Applications — registros de aplicativo com privilégios excessivos e permissões delegadas em excesso — é abordado em Registros de Aplicativo Azure: Apps com Privilégios Excessivos; a saúde do certificado é uma preocupação ortogonal, focada em disponibilidade, dentro da mesma categoria.

Detecção: Encontrando Certificados SAML Expirando e de Vida Longa

Não espere uma enxurrada de chamados de suporte para descobrir que um certificado expirou. O Entra ID expõe o estado do certificado por vários canais:

Sinal	Onde	O que observar
Status de expiração do certificado	Central de administração do Entra → Aplicativos empresariais → [App] → Single sign-on → Certificados SAML	Status, data de expiração e thumbprint de cada certificado (ativo e inativo)
`keyCredentials`, `passwordCredentials`	Objeto `servicePrincipal` do Microsoft Graph	`endDateTime` no passado ou dentro de 30 dias; múltiplas credenciais com estado ativo pouco claro
`preferredTokenSigningKeyThumbprint`	Objeto `servicePrincipal` do Microsoft Graph	Confirma com qual certificado o Entra ID está realmente assinando — verifique se corresponde ao que foi carregado no provedor de serviço
Recomendação Renovar credenciais de service principal expirando	Central de administração do Entra → Visão geral → Recomendações, ou Graph `/beta/directory/recommendations` (`servicePrincipalKeyExpiry`)	Sinaliza qualquer credencial de service principal expirando dentro de 30 dias, em todo o tenant, sem precisar checar app por app (Microsoft Learn)
Logs de auditoria	Logs de auditoria do Microsoft Entra — Serviço: Core Directory, Categoria: ApplicationManagement, Atividade: Update Application – Certificates and secrets management / Update Service principal	Credencial adicionada fora de uma janela de mudança conhecida, ou nenhuma atualização de credencial registrada à medida que a expiração se aproxima (Microsoft Learn)
Logs de login	Logs de login do Microsoft Entra, filtrados para a aplicação afetada	Um pico de logins com falha concentrado em uma aplicação é o sintoma operacional; referências de terceiros sobre troubleshooting de SAML (ex.: guia de erros SAML do Entra da SSOJet) comumente associam esse padrão de falha ao `AADSTS50008` (InvalidSamlToken) no relying party — trate o código como um sinal para checar o status do certificado, não como uma certeza, já que o mesmo código pode ter outras causas

💡

💡 Dica: Consulte keyCredentials e passwordCredentials em todos os servicePrincipal do tenant, em vez de checar aplicações uma a uma — essa é exatamente a auditoria que a própria orientação de operações de segurança da Microsoft recomenda para detectar janelas longas de expiração de credenciais antes que se tornem uma interrupção (Microsoft Learn).

Para um passo a passo mais amplo de como estruturar uma revisão completa de segurança do Entra além dos certificados, veja Como Auditar a Segurança do Microsoft Entra ID (Azure AD): Guia Prático. Para o fortalecimento dos padrões em todo o tenant, que reduz a exposição junto com a higiene de certificados, veja Fortalecimento do Tenant Azure: Configurações Padrão Inseguras.

Remediação: Renovando Sem Downtime

A sequência de renovação documentada pela Microsoft existe especificamente para evitar uma interrupção durante a rotação — pular etapas ou executá-las fora de ordem é a forma mais comum pela qual times transformam uma renovação planejada em uma não planejada.

Passo 1 — Crie o novo certificado com antecedência

Crie o novo certificado com uma data de expiração que se sobreponha à validade restante do certificado atual, via Aplicativos empresariais → [App] → Single sign-on → Certificados SAML → Novo Certificado. Ele é salvo como Inativo — essa etapa isolada não causa nenhuma interrupção (Microsoft Learn).

Passo 2 — Carregue-o primeiro no provedor de serviço

Baixe e carregue o novo certificado no provedor de serviço, no formato de codificação especificado pelo guia de configuração de SSO da aplicação, antes de ativá-lo no Entra ID.

Passo 3 — Ative, verifique e limpe

Ative o novo certificado no Entra ID (selecione o menu … do novo certificado → Tornar certificado ativo) — isso marca automaticamente o certificado anterior como inativo. Verifique se o login funciona de ponta a ponta para a aplicação antes de considerar a rotação concluída, e então remova o certificado antigo depois de verificado, para que não possa ser reativado por engano mais tarde.

# Microsoft Graph PowerShell — inspecionar o estado atual do certificado de assinatura SAML de um service principal
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 adicionar um novo certificado de assinatura de token programaticamente, use a ação addTokenSigningCertificate do servicePrincipal no Graph, e depois defina preferredTokenSigningKeyThumbprint com o thumbprint do novo certificado para torná-lo aquele com o qual o Entra ID assina (Microsoft Learn — Configurar SSO SAML usando o Microsoft Graph).

✅ Nota: Feche a lacuna de vida longa demais ao mesmo tempo em que faz qualquer renovação. Defina a expiração do novo certificado para uma janela mais curta e deliberada, em vez de aceitar o padrão de três anos, e coloque a próxima renovação no calendário com antecedência suficiente para evitar uma nova correria.

Prevenindo a recorrência

Além do certificado em si, dois controles de baixo esforço evitam a recorrência:

Preencha o campo de endereços de e-mail de notificação em cada aplicação federada com uma lista de distribuição, não a caixa de entrada de um indivíduo — até cinco endereços são suportados, e o Entra ID envia os avisos de 60/30/7 dias para lá (Microsoft Learn).
Aja sobre a recomendação Renovar credenciais de service principal expirando na página de Visão geral da central de administração do Entra como uma checagem fixa, em todo o tenant, em vez de depender da memória por aplicação.

Para riscos de permissão de aplicativo que frequentemente convivem com configurações incorretas de certificado nas mesmas aplicações empresariais, veja OAuth Consent Phishing: Como Apps Maliciosos Contornam o Roubo de Senhas. Para os controles mais amplos de Acesso Condicional que regem como aplicações federadas podem ser acessadas, veja Falhas de Acesso Condicional no Entra ID: Quais Erros Deixam uma Exposição Real.

Como a EtcSec Detecta Isso

A auditoria Azure da EtcSec verifica o estado do certificado de assinatura SAML de cada aplicação empresarial em cada varredura do tenant. SAML_CERTIFICATE_EXPIRED sinaliza qualquer aplicação cujo certificado de assinatura ativo já expirou — um achado crítico, com impacto na disponibilidade, já que o login federado para aquela aplicação está ativamente quebrado. SAML_CERTIFICATE_EXPIRING_SOON sinaliza certificados se aproximando da expiração para que a renovação possa ser agendada em vez de apressada, e SAML_CERTIFICATE_LONG_LIFETIME sinaliza certificados emitidos com uma janela de validade excessiva, para que você possa encurtá-la na próxima rotação, em vez de reiniciar o mesmo relógio de vários anos.

ℹ️

ℹ️ Nota: A EtcSec verifica automaticamente essa vulnerabilidade em cada auditoria Azure. Execute uma auditoria gratuita para verificar a postura do certificado SAML do seu ambiente em todas as aplicações federadas.