Quando Microsoft cambia le regole sotto i piedi: la rotazione delle Root CA per Teams Direct Routing

Il contesto

Se gestisci un SBC (Session Border Controller) per collegare una PBX on-prem o un provider SIP a Microsoft Teams, sai che la connessione tra il tuo SBC e l'infrastruttura Microsoft si basa su mutual TLS (mTLS): entrambe le parti si presentano un certificato, ed entrambe devono fidarsi della catena di certificazione dell'altra.

Fino a poco tempo fa questa fiducia era una cosa abbastanza stabile, la configuri una volta, importi le CA richieste, e per anni non ci pensi più. Poi arriva un cambiamento nell'ecosistema dei browser che, indirettamente, costringe Microsoft a rifare tutta l'infrastruttura di certificazione lato SIP.

La causa a monte: Chrome decide, tutti si adeguano

Il driver reale di questa storia non è nemmeno Microsoft: è una policy di Google. A febbraio 2025 Google ha aggiornato la Chrome Root Program Policy (v1.6), deprecando l'uso della Client Authentication EKU (Extended Key Usage) nei certificati TLS server-side fidati da Chrome. Da giugno 2026 in poi, per essere riconosciuti dai principali browser, i certificati devono includere esclusivamente la Server Authentication EKU.

Il problema è che l'mTLS di Teams Direct Routing si basa storicamente su certificati "dual-use", con entrambe le EKU. Microsoft ha dovuto quindi ristrutturare la propria PKI lato SIP, spostando i certificati dei propri endpoint su una nuova catena di Root CA, principalmente DigiCert, più alcune Root Microsoft dedicate, mantenendo comunque la Client Authentication EKU sul lato SIP (che gli OS accettano nativamente anche se i browser ormai no).

Tradotto in pratica: ogni SBC collegato a Teams doveva avere in trust store sette nuove Root CA, non più solo le una o due storiche.

La timeline (e perché fa male)

Qui sta il punto che ha reso questa storia interessante da raccontare, più che semplicemente "un certificato da importare":

• Fine febbraio 2026 — deadline raccomandata per aggiornare i trust store degli SBC con le nuove Root CA.
• Fine marzo 2026 — Microsoft mette a disposizione un endpoint SIP di test dedicato (solo OPTIONS ping, niente traffico voce) per validare la connettività TLS verso la nuova catena.
• Da aprile 2026 — Microsoft comincia a implementare i cambiamenti lato server.
• 30 giugno 2026, ore 9:00 UTC — parte il test di validazione vero e proprio: la transizione dei certificati SIP verso la nuova CA avviene in modo graduale e a fasi, per area geografica, su un arco di 2-4 giorni.

Quest'ultimo punto è quello che rende il debug un incubo. Non è un cutover secco dove "prima funzionava, ora non funziona più": durante il rollout alcune connessioni verso il tuo SBC arrivano ancora con il certificato vecchio, altre con quello nuovo. Il sintomo che vedi è intermittente, chiamate che a volte si stabiliscono e a volte no, SIP OPTIONS che a tratti smettono di arrivare, ed è facile perdere ore a cercare la causa in tutt'altro posto (routing, SIP trunk, QoS) prima di guardare al trust store.

Cosa abbiamo trovato sul nostro SBC

Nel nostro caso il software SBC in produzione era fermo a una versione antecedente alla 4.12 della piattaforma, che semplicemente non aveva ancora nel proprio trust store predefinito le nuove Root CA richieste da Microsoft. Risultato: durante la finestra di rollout, una parte del traffico SIP verso Teams cominciava a fallire l'handshake TLS con errori di validazione del certificato, non un blocco totale, ma abbastanza per generare ticket di malfunzionamento intermittente sulle chiamate in ingresso/uscita per i clienti collegati a quell'SBC.

Il primo segnale, se te lo sei perso in anticipo, è quasi sempre uno di questi:

• assenza di risposta ai SIP OPTIONS da parte di Microsoft (spesso il primo sintomo di un handshake TLS fallito);
• errori espliciti di "certificate validation failed" nel trace SIP;
• nei casi più seri, disattivazione del dominio Direct Routing lato Teams admin center, perché Teams interpreta i fallimenti sostenuti di OPTIONS come un outage dell'SBC.

La soluzione (concettualmente semplice, operativamente noiosa)

La correzione in sé non è complicata: bisogna importare manualmente le sette Root CA richieste nel trust store dell'SBC, verificando che siano tutte presenti, non solo una o due, perché il certificato che Microsoft presenta durante l'handshake può ancorarsi a una qualsiasi di esse a seconda dell'endpoint che risponde.

Quello che non è banale è farlo bene su un parco SBC multi-tenant/multi-cliente:

1. Verifica preventiva, prima ancora di toccare la configurazione: controllare quali Root CA sono già presenti nel trust store rispetto alla lista pubblicata da Microsoft nella pagina Azure Certificate Authority details.
2. Import via file, non via CLI incollata a mano. Alcuni certificati DigiCert nel formato PEM contengono la stringa "quit", che su alcune CLI (tipicamente Cisco IOS) viene interpretata come comando di uscita e tronca l'import a metà. Meglio importare via SCP/TFTP o attraverso l'interfaccia grafica.
3. Validazione contro l'endpoint di test SIP OPTIONS di Microsoft, prima di fidarsi che tutto sia a posto. Una risposta 200 OK conferma che l'handshake TLS con la nuova catena funziona, senza dover aspettare il rollout reale per scoprirlo.
4. Ripetere per ogni nodo, ogni sede, ogni cliente. In un contesto MSP multi-tenant, un solo SBC dimenticato in un DC significa chiamate che cadono per un sottoinsieme di utenti e nessun errore evidente lato Teams admin center che ti indichi la causa reale.
5. Documentare la finestra di enforcement, perché il rollout a fasi geografiche significa che un test riuscito oggi non garantisce nulla su un altro SBC domani, finché l'enforcement non è completo ovunque.

La lezione infrastrutturale

Al di là del singolo incidente, la cosa che mi porto a casa è più generale: quando una piattaforma cloud terza (in questo caso i browser) cambia le regole di fiducia dei certificati, l'onda d'urto arriva a valle su sistemi che apparentemente non c'entrano nulla, un SBC per la telefonia aziendale non ha nulla a che fare con Chrome, eppure eredita il cambiamento con mesi di ritardo e zero visibilità diretta sulla causa.

La morale operativa è la solita, ma vale la pena ripeterla: tenere il firmware/versione software degli apparati di rete critici aggiornato non è vanità, è l'unico modo per non ritrovarsi tagliati fuori da un cambiamento di postura di sicurezza che arriva da tre livelli più in alto nella catena di fiducia. E quando arriva un avviso "cambiamento CA in arrivo" da un vendor cloud, vale la pena trattarlo come una deadline vera, non come una nota a piè di pagina della roadmap.

P.S.: Grazie a Gemini per il supporto nella creazione delle immagini!

Se gestisci SBC per Direct Routing, la lista aggiornata delle Root CA richieste è sempre disponibile nella pagina "Azure Certificate Authority details" di Microsoft Learn è il primo posto da controllare prima di aprire un ticket di supporto.