Certificato di firma SAML Entra scaduto: perché il login federato smette di funzionare

Certificato di firma SAML Entra scaduto: cosa significa

Quando un certificato di firma SAML Entra è scaduto, il login federato per quell'applicazione smette di funzionare in tutto il tenant — non a causa di un attacco, ma per un'attività amministrativa di routine che nessuno ha pianificato. Ogni applicazione aziendale configurata per il single sign-on (SSO) federato tramite SAML in Microsoft Entra ID si basa su un certificato di firma: Entra ID usa la propria chiave privata per firmare crittograficamente le asserzioni SAML che emette, e il service provider convalida quelle asserzioni con la chiave pubblica corrispondente. È l'ancora di fiducia dell'intera relazione di federazione — se il certificato non è valido, l'asserzione non ha alcun valore per il service provider, indipendentemente da quanto sia corretto il resto del flusso di autenticazione.

La "salute del certificato" copre tre stati di rischio distinti ma correlati, monitorati nel catalogo delle vulnerabilità EtcSec per le applicazioni Azure:

• Scaduto — il periodo di validità del certificato è già trascorso. È un'interruzione funzionale, non solo una debolezza di sicurezza.
• In scadenza a breve — il certificato scadrà entro 30 giorni e non è stato predisposto alcun rinnovo.
• Validità troppo lunga — il certificato è stato emesso con una finestra di validità eccessivamente lunga (Entra ID applica di default tre anni), il che amplia il raggio d'impatto se la chiave privata viene a un certo punto gestita in modo scorretto, e aumenta la probabilità che chi era responsabile della rotazione abbia nel frattempo lasciato l'organizzazione, cambiato ruolo, o semplicemente dimenticato.

Per impostazione predefinita, quando configuri l'SSO basato su SAML per un'applicazione della galleria o non della galleria, Entra ID genera automaticamente un certificato autofirmato valido tre anni (Microsoft Learn). A differenza di un secret applicativo con una breve durata predefinita che impone attenzione frequente, un certificato SAML di tre anni è facile da configurare una volta e non pensarci più — finché non scade silenziosamente.

Come il certificato sostiene il login federato

Quando Entra ID agisce da identity provider (IdP) per un'applicazione SAML, il flusso di accesso dipende dallo stato del certificato in due momenti:

1. Entra ID firma l'asserzione SAML (o la risposta) con la chiave privata del certificato di firma attivo sul service principal dell'applicazione aziendale.
2. Il service provider convalida quella firma rispetto al certificato pubblico che ha registrato (caricato manualmente o recuperato dinamicamente dall'URL dei metadati di federazione dell'applicazione).

Se il certificato usato da Entra ID per firmare è scaduto, Entra ID non smette di firmare con esso — continua a usare qualunque certificato sia contrassegnato come attivo. È il service provider a rifiutare l'asserzione non appena rileva che il certificato non è più entro la propria finestra di validità, e quel rifiuto è ciò che gli utenti vivono come un accesso fallito (Microsoft Learn). In altre parole: Entra ID non "si accorge" della scadenza e non blocca l'accesso in modo proattivo — il fallimento emerge a valle, a livello dell'applicazione, e solo dopo che gli utenti hanno iniziato a incontrarlo.

Polling dei metadati e notifiche via e-mail

Esistono due mitigazioni a seconda delle capacità dell'applicazione:

• Polling dei metadati di federazione. Per le applicazioni che lo supportano, Entra ID controlla i metadati di federazione dell'applicazione circa 35 giorni prima della scadenza del certificato di firma; se lì è disponibile un nuovo certificato, non è necessario alcun intervento manuale né notifica (Microsoft Learn).
• Notifiche via e-mail. Per tutto il resto, Entra ID invia un'e-mail agli indirizzi di notifica configurati sull'applicazione aziendale 60, 30 e 7 giorni prima della scadenza, da [email protected] — fino a cinque indirizzi, per impostazione predefinita solo l'amministratore che ha configurato originariamente lo SSO (Microsoft Learn).

Entrambe le mitigazioni dipendono dal fatto che qualcuno le abbia configurate correttamente in anticipo, ed entrambe vengono comunemente trascurate: il polling dei metadati funziona solo se l'applicazione lo supporta e lo utilizza realmente, e l'elenco di notifica viene banalmente lasciato alla casella di posta di un singolo amministratore ormai andato via.

Cosa si rompe quando il certificato scade o resta attivo troppo a lungo

L'impatto di un certificato di firma SAML scaduto riguarda la disponibilità, non la riservatezza: il login federato per quell'applicazione fallisce per tutti gli utenti finché il certificato non viene rinnovato e riattivato su entrambi i lati. Per un'applicazione SaaS aziendale usata in tutto il tenant, si tratta di un'interruzione completa causata unicamente da una svista amministrativa, non da un'azione di un attaccante.

I certificati a lunga durata comportano un rischio diverso, più silenzioso. Una finestra di validità di tre anni (o più) significa che:

• La rotazione avviene abbastanza raramente da rendere il processo manuale — generare, scaricare, caricare sul SP, attivare, verificare, ripulire il vecchio certificato — poco familiare ogni volta che serve, aumentando la probabilità di un errore durante la rotazione stessa.
• Deriva della responsabilità: l'amministratore che l'ha configurato potrebbe non essere più nell'organizzazione al momento del rinnovo.
• Una finestra più lunga di esposizione della chiave privata se il certificato o la sua esportazione vengono a un certo punto gestiti in modo scorretto, senza un rinnovo forzato.

Le stesse indicazioni di Microsoft rivolte agli ISV che costruiscono integrazioni SAML riconoscono direttamente questo problema, notando che il rollover manuale diventa "insostenibile" su larga scala man mano che le durate dei certificati tendono ad accorciarsi in tutto il settore, e raccomandano che le applicazioni supportino il rollover automatizzato basato sui metadati con certificati di firma primario/secondario, proprio per eliminare la fragilità operativa delle durate lunghe e gestite manualmente (Microsoft Learn).

Questo è anche il motivo per cui questa lacuna conta dal punto di vista della copertura: il ciclo di vita dei certificati SAML è un rischio distinto dall'igiene dei permessi applicativi. Un rischio correlato ma diverso della categoria Applications — le app registration con permessi delegati eccessivi — è trattato in Azure App Registrations: applicazioni con privilegi eccessivi nel tenant; la salute dei certificati è una preoccupazione ortogonale, incentrata sulla disponibilità, all'interno della stessa categoria.

Rilevamento: individuare certificati SAML in scadenza e a lunga durata

Non aspettare un'ondata di ticket all'help desk per scoprire che un certificato è scaduto. Entra ID espone lo stato dei certificati attraverso diversi canali:

Per una panoramica più ampia su come strutturare una revisione completa della sicurezza di Entra al di là dei soli certificati, vedi Come auditare la sicurezza di Microsoft Entra ID. Per un hardening delle impostazioni predefinite a livello di tenant che riduce l'esposizione insieme all'igiene dei certificati, vedi Azure Tenant Hardening: correggere le impostazioni predefinite non sicure.

Rimedio: rinnovare senza interruzioni

La sequenza di rinnovo documentata da Microsoft esiste specificamente per evitare un'interruzione durante la rotazione — saltare passaggi o eseguirli nell'ordine sbagliato è il modo più comune in cui i team trasformano un rinnovo pianificato in un incidente non pianificato.

Passo 1 — Creare in anticipo il nuovo certificato

Crea il nuovo certificato con una data di scadenza che si sovrapponga alla validità residua del certificato attuale, da Enterprise apps → [App] → Single sign-on → SAML Certificates → New Certificate. Viene salvato come Inactive — questo passaggio da solo non causa alcuna interruzione (Microsoft Learn).

Passo 2 — Caricarlo prima presso il service provider

Scarica e carica il nuovo certificato presso il service provider, nel formato di codifica specificato dalla guida di configurazione SSO dell'applicazione, prima di attivarlo in Entra ID.

Passo 3 — Attivare, verificare e ripulire

Attiva il nuovo certificato in Entra ID (menu … del nuovo certificato → Make certificate active) — questo contrassegna automaticamente il certificato precedente come inattivo. Verifica che il login funzioni end-to-end per l'applicazione prima di considerare completata la rotazione, quindi rimuovi il vecchio certificato una volta verificato, in modo che non possa essere riattivato per errore in seguito.

# Microsoft Graph PowerShell — verificare lo stato attuale del certificato di firma SAML di un 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

Per aggiungere un nuovo certificato di firma del token in modo programmatico, usa l'azione Graph servicePrincipal addTokenSigningCertificate, quindi imposta preferredTokenSigningKeyThumbprint sul thumbprint del nuovo certificato per renderlo quello con cui Entra ID firma (Microsoft Learn — Configure SAML SSO using Microsoft Graph).

✅ Nota: Chiudi il divario di validità troppo lunga contestualmente a ogni rinnovo. Imposta la scadenza del nuovo certificato su una finestra più breve e deliberata invece di accettare i tre anni predefiniti, e metti il prossimo rinnovo in calendario con sufficiente anticipo per evitare una nuova corsa contro il tempo.

Prevenire il ripetersi

Oltre al certificato in sé, due controlli a basso sforzo prevengono il ripetersi del problema:

• Popola il campo indirizzi e-mail di notifica di ogni applicazione federata con una mailing list, non con la casella di posta di un singolo individuo — sono supportati fino a cinque indirizzi, ed Entra ID vi invia gli avvisi a 60/30/7 giorni (Microsoft Learn).
• Tratta la raccomandazione Renew expiring service principal credentials nella pagina Overview del centro di amministrazione Entra come un controllo permanente a livello di tenant, invece di affidarti alla memoria applicazione per applicazione.

Per i rischi legati ai permessi applicativi che spesso coesistono con una configurazione errata dei certificati sulle stesse applicazioni aziendali, vedi OAuth Consent Phishing: come le app malevole aggirano il furto di password. Per i controlli di accesso condizionale più ampi che regolano come si possa raggiungere le applicazioni federate, vedi Lacune nell'accesso condizionale di Entra ID.

Come EtcSec rileva questo problema

L'audit Azure di EtcSec verifica lo stato del certificato di firma SAML di ogni applicazione aziendale a ogni scansione del tenant. SAML_CERTIFICATE_EXPIRED segnala qualsiasi applicazione il cui certificato di firma attivo sia già scaduto — un riscontro critico che incide sulla disponibilità, poiché il login federato per quell'applicazione è attivamente non funzionante. SAML_CERTIFICATE_EXPIRING_SOON segnala i certificati in avvicinamento alla scadenza in modo che il rinnovo possa essere pianificato anziché affrettato, e SAML_CERTIFICATE_LONG_LIFETIME segnala i certificati emessi con una finestra di validità eccessiva, così da poterla accorciare alla prossima rotazione invece di reimpostare lo stesso orologio pluriennale.