SBC mTLS : authentification mutuelle TLS pour la signalisation SIP

Le TLS standard prouve que votre contrôleur de session en bordure (SBC) est bien le dispositif que son nom d’hôte prétend être. Il ne prouve rien sur le dispositif à l’autre extrémité de la connexion. Pour une frontière SIP exposée sur Internet, c’est la mauvaise moitié du problème à résoudre. N’importe qui sur l’Internet public peut ouvrir un socket TCP sur le port 5061, effectuer un handshake TLS unidirectionnel contre votre certificat, et commencer à envoyer des messages INVITE. TLS protège le canal ; il n’authentifie pas le pair.
Le TLS mutuel, généralement noté mTLS, comble cette lacune. Les deux points de terminaison présentent des certificats X.509 lors du handshake, et les deux valident le certificat reçu selon leur propre politique de confiance. Si le pair ne présente pas de certificat, ou en présente un que votre SBC ne reconnaît pas, le handshake échoue avant qu’un seul octet SIP ne soit échangé. C’est le mécanisme que la plupart des opérateurs de niveau 1 exigent sur les interconnexions, et le mécanisme qui remplace progressivement les listes d’autorisation IP comme frontière de confiance par défaut entre les pairs SIP.
Ce guide va plus loin que la définition de haut niveau. Il détaille ce qui se passe réellement lors du handshake mTLS, la différence entre un truststore et un keystore (l’un des points les plus systématiquement confondus dans les déploiements réels), les quatre modèles de confiance entre lesquels vous pouvez choisir, pourquoi la confiance entre deux pairs n’est presque jamais symétrique, comment la vérification de révocation fonctionne en pratique, et les modes de défaillance spécifiques au mTLS par rapport au TLS en général. Pour la procédure de configuration TLS et SRTP par trunk qui sous-tend tout cela, consultez le guide de configuration TLS et SRTP pour SBC.

Ce que le TLS unidirectionnel laisse ouvert

Dans un handshake TLS standard avec authentification du serveur uniquement, un seul côté prouve son identité. Lorsqu’un client SIP ouvre une connexion TLS vers votre SBC sur le port 5061, le SBC présente son certificat, le client valide ce certificat par rapport à son truststore, et le tunnel chiffré est établi. Le client n’a jamais besoin de prouver qui il est. Du point de vue du SBC, tout dispositif qui complète le handshake peut commencer à envoyer des messages SIP.
Cela fonctionne pour le web grand public, où le serveur est l’actif à protéger et le client est un navigateur dont l’identité est vérifiée plus haut dans la pile (noms d’utilisateur, mots de passe, cookies). Cela ne fonctionne pas pour une frontière SIP, où le serveur est l’actif à protéger et le client est un autre élément réseau sans humain au clavier. L’authentification SIP par digest existe, mais elle s’exécute au-dessus de la couche TLS et ne remplace pas l’authentification du dispositif hôte.
Le risque pratique est simple. Un attaquant scanne Internet, trouve votre SBC sur le port 5061, ouvre une connexion TLS et commence à sonder. Il ne peut pas déchiffrer votre trafic existant, mais il peut désormais initier des appels SIP. Que ces appels aboutissent dépend entièrement de l’authentification, des listes d’autorisation et des politiques que vous avez configurées au-dessus de TLS. Le mTLS repousse la frontière d’authentification dans le handshake lui-même, de sorte que la connexion de l’attaquant est rejetée avant même que la pile SIP ne la voie.

Comment fonctionne réellement le handshake mTLS

Le serveur demande un certificat au client, le client en fournit un, et les deux côtés valident ce qu’ils reçoivent avant que tout flux de données applicatives ne commence.

1. Le ClientHello ouvre la connexion et propose les versions TLS prises en charge par le client, les suites cryptographiques et les extensions. Aucun certificat n’est échangé à ce stade.
2. Le ServerHello et le certificat du serveur suivent une fois que le SBC a sélectionné une suite cryptographique, et le SBC présente sa propre chaîne de certificats à cette étape. C’est la même étape que dans un TLS unidirectionnel.
3. Un CertificateRequest est envoyé au lieu de terminer le handshake, demandant au client de présenter son propre certificat. Le message inclut une liste d’autorités de certification acceptables pour que le client sache quel certificat choisir.
4. Les messages Certificate et CertificateVerify du client reviennent ensemble : le client renvoie son certificat (et la chaîne intermédiaire) accompagné d’un message CertificateVerify contenant une signature sur la transcription du handshake, réalisée avec la clé privée correspondant au certificat. Cela prouve que le client détient réellement la clé, et non simplement une copie du certificat de quelqu’un d’autre.
5. L’étape de validation mutuelle se produit simultanément des deux côtés. Le SBC valide la chaîne du client par rapport à son truststore, vérifie la période de validité, contrôle la signature CertificateVerify et (si configuré) effectue une vérification de révocation. Le client effectue la même validation sur le certificat du SBC. Toute défaillance interrompt le handshake avec une alerte TLS.
6. Les messages Finished sont échangés des deux côtés, le canal applicatif chiffré s’ouvre, et le trafic SIP commence.

Deux implications comptent sur le plan opérationnel. Premièrement, le mTLS est bidirectionnel par construction : une erreur de configuration de l’un ou l’autre côté casse la connexion, et la surface d’erreur se situe dans la couche TLS, pas dans la couche SIP. Des outils comme une trace SIP vous diront que l’appel n’a jamais démarré ; seule une capture au niveau TLS (ou le journal d’erreurs TLS du SBC) vous dira pourquoi. Deuxièmement, chaque appel réussi sur un trunk protégé par mTLS a déjà prouvé, lors de l’étape du handshake, que le pair détient une clé privée correspondant à un certificat que votre SBC a choisi de faire confiance. C’est une affirmation bien plus forte que « l’IP source est dans la liste d’autorisation ».

Les quatre éléments d’une configuration mTLS

La plupart des confusions opérationnelles autour du mTLS proviennent de l’amalgame de concepts distincts. Il y a quatre éléments indépendants, et chacun réside dans une partie différente de la configuration du SBC.
L’identité serveur est le certificat propre du SBC et la clé privée correspondante, utilisés lorsque le SBC agit comme serveur TLS (un pair se connecte en entrant sur le port 5061). Le SAN doit inclure chaque FQDN que les pairs entrants utiliseront pour vous joindre. Pour les déploiements multi-locataires, un certificat wildcard ou multi-SAN est courant ; consultez le guide sur le SBC multi-locataire pour Teams Direct Routing pour le modèle de certificat wildcard attendu par Microsoft.
L’identité client est le certificat que le SBC présente lorsqu’il agit comme client TLS (le SBC initie une connexion TLS sortante vers un opérateur ou vers Teams). C’est souvent le même certificat que l’identité serveur sur les déploiements plus petits, et un certificat différent sur les plus grands où le trafic sortant utilise une identité dédiée. Dans les deux cas, il doit être stocké comme un certificat avec sa clé privée correspondante, et non comme un simple fichier certificat.
Le truststore détermine quelles autorités de certification (ou certificats de pairs individuels) le SBC acceptera lors de la validation d’un pair. Ceci est indépendant de votre propre identité. Un truststore contenant « toute CA publique à laquelle le système d’exploitation fait confiance » est beaucoup trop permissif pour SIP, car il autorise chaque certificat Let’s Encrypt et DigiCert sur Internet à communiquer avec vous. Un truststore SIP correct ne liste que les CA qui émettent des certificats pour vos pairs réels.
La politique par trunk lie les trois éléments précédents à des trunks SIP spécifiques.
La confusion keystore-versus-truststore mérite d’être comprise car elle produit une classe de défaillance spécifique. Si le certificat et la clé privée propres du SBC sont rangés dans le truststore au lieu du keystore, le SBC n’a aucune identité à présenter : la pile TLS échoue généralement à démarrer le listener, ou interrompt le handshake avec un handshake_failure générique (alerte 40) avant qu’aucun certificat ne soit échangé. Si le mTLS est configuré et que la CA d’un pair est rangée dans le keystore au lieu du truststore, le SBC ne fera pas confiance au certificat que ce pair présente lors de l’authentification client, et le handshake échoue avec unknown_ca (alerte 48).

Choisir un modèle de confiance

Une fois que vous avez décidé d’exiger l’authentification client, vous devez prendre une décision distincte concernant les autorités qui émettent les certificats que vous accepterez. Il existe quatre options pratiques, et la bonne dépend de l’identité du pair et du degré de contrôle que vous avez sur sa PKI.

Le modèle le plus susceptible de produire des surprises est l’approche large avec racine de CA publique. Mettre « DigiCert Global Root G2 » dans votre truststore signifie que le SBC acceptera tout certificat émis par DigiCert pour n’importe quel sujet, y compris des acteurs non intentionnels. La défense consiste à superposer la validation FQDN à la validation CA : même si le certificat remonte à une racine de confiance, le rejeter sauf si le SAN correspond au FQDN avec lequel le trunk est censé communiquer.

Le problème de la confiance asymétrique : l’exemple Microsoft Teams

La confiance entre deux pairs en mTLS est rarement symétrique, et la documentation ne le dit presque jamais explicitement. Votre SBC fait confiance aux certificats émis par un ensemble spécifique de CA ; le pair fait confiance aux certificats émis par un ensemble différent (généralement chevauchant mais pas identique). Les deux listes comptent, les deux peuvent être incorrectes indépendamment, et une connexion ne fonctionne que lorsque les deux listes acceptent le certificat que l’autre côté présente.
L’une de ces implémentations gagnant en popularité est Microsoft Teams Direct Routing. Le truststore de Microsoft côté Teams accepte les certificats provenant d’une liste publiée de CA publiques (la liste est mise à jour périodiquement, le plus récemment pour le renouvellement de la CA racine de juin 2026). Votre SBC, de son côté, doit faire confiance à la CA qui signe les certificats propres de Microsoft sur l’interface Teams (actuellement DigiCert Global Root G2, bientôt aussi Microsoft RSA Root Certificate Authority 2017). Si vous ne mettez à jour que le côté SBC ou uniquement le côté Teams, le trunk tombe en panne. Si vous oubliez complètement la nouvelle racine Microsoft, l’établissement des appels ne sera plus possible. La confiance asymétrique est la raison pour laquelle le changement de certificat Teams est annoncé des mois à l’avance.
La discipline opérationnelle qui gère bien cette situation consiste à penser la confiance mTLS par direction plutôt que par trunk. Pour chaque direction (entrant depuis le pair, sortant vers le pair), conservez un registre des CA auxquelles le SBC fait confiance, des CA auxquelles le pair fait confiance, de la date de renouvellement de ces CA, et de la personne responsable de vous informer. Une fois cela en place, l’incident « le handshake TLS a cessé de fonctionner cette nuit, sans changement de configuration » devient un ticket de routine plutôt qu’une panne.

Révocation : CRL, OCSP et le choix du soft-fail

La période de validité d’un certificat vous indique quand il expire naturellement. Elle ne vous dit pas si la CA l’a révoqué prématurément en raison d’une compromission, d’une résiliation de contrat ou d’un renouvellement de clé. La révocation est appliquée via l’un des deux mécanismes.
CRL (Certificate Revocation List) est un fichier signé publié par la CA listant le numéro de série de chaque certificat révoqué. Les CRL sont simples et fiables, mais elles peuvent devenir volumineuses et leur fraîcheur dépend de l’intervalle d’interrogation.
OCSP (Online Certificate Status Protocol) est une requête en temps réel que le SBC envoie au répondeur OCSP de la CA demandant spécifiquement « ce certificat est-il encore valide ? ». La réponse est signée et de courte durée. L’OCSP stapling permet au pair de récupérer sa propre réponse OCSP à l’avance et de l’inclure dans le handshake TLS, de sorte que le SBC n’a pas besoin d’effectuer sa propre requête. Le stapling est le modèle le plus propre lorsque le pair le prend en charge.
La décision qui compte plus que CRL versus OCSP est la politique soft-fail versus hard-fail. Si le répondeur OCSP est injoignable ou si le point de distribution CRL expire, acceptez-vous la connexion (soft-fail) ou la rejetez-vous (hard-fail) ? Le hard-fail est plus sécurisé, car un attaquant réseau ne peut pas bloquer les vérifications de révocation pour maintenir un certificat compromis en vie. Le soft-fail est plus disponible, car une panne côté CA ne fait pas tomber votre service vocal avec elle. La plupart des interconnexions d’opérateurs fonctionnent en soft-fail ; les déploiements haute sécurité et les flux de signature STIR/SHAKEN fonctionnent en hard-fail. Quel que soit votre choix, faites-le délibérément, et surveillez les échecs de vérification de révocation afin qu’un soft-fail silencieux ne masque pas un vrai problème.

Rotation des certificats sans couper les appels

Chaque certificat expire un jour. Le problème de la rotation est plus difficile pour le mTLS que pour le TLS unidirectionnel, car les deux pairs doivent se coordonner : lorsque vous remplacez votre certificat client, chaque pair qui a épinglé votre ancien certificat doit ajouter le nouveau à son truststore avant que vous ne basculiez, et lorsqu’un pair effectue une rotation, vous devez ajouter le nouveau certificat avant qu’il ne bascule. Oubliez l’une ou l’autre étape et le trunk devient silencieux.
Le modèle propre est la fenêtre de double confiance. Pendant au moins 30 jours avant une rotation, l’ancien et le nouveau certificat (ou l’ancienne et la nouvelle CA émettrice) sont tous deux reconnus des deux côtés. Le pair présente le nouveau certificat dès qu’il est provisionné ; le SBC l’accepte car la nouvelle CA est déjà dans le truststore. Une fois que chaque pair a confirmé qu’il présente le nouveau certificat, l’ancien certificat est retiré du truststore. Cela évite tout moment de bascule totale.
Pour les certificats présentés par le SBC, le même modèle s’applique en sens inverse. Provisionnez le nouveau certificat à côté de l’ancien, basculez chaque trunk vers le nouveau certificat pendant une fenêtre de faible trafic, surveillez les échecs de handshake des pairs qui n’ont pas mis à jour leur truststore, et ne retirez l’ancien certificat qu’après que chaque trunk a basculé proprement. Certains SBC (ProSBC inclus) permettent de préparer un nouveau certificat et de l’associer à un trunk sans redémarrage du service, de sorte que la rotation se fait au niveau de la connexion plutôt que du processus.
La rigueur calendaire compte plus que le mécanisme. Suivez les dates d’expiration par certificat, alertez à 90, 60 et 30 jours, et traitez tout certificat à moins de 14 jours de l’expiration comme un incident actif. Le nombre d’incidents d’échec de handshake TLS qui se révèlent être « nous avons oublié que le certificat expirait aujourd’hui » est désespérément élevé.

Modes de défaillance spécifiques au mTLS

La plupart des guides de dépannage TLS couvrent les échecs de handshake de manière générique. Les défaillances listées ci-dessous sont celles qui surviennent spécifiquement parce que le mTLS exige un accord des deux côtés, et elles diffèrent des erreurs TLS standard.
Une alerte « no certificate available » signifie que l’identité client du pair est manquante ou illisible. Sur un déploiement neuf, cela signifie généralement que le certificat a été téléchargé sans la clé privée correspondante, ou que les permissions du fichier de clé privée empêchent le processus du SBC de le lire. Le journal TLS du pair montrera le CertificateRequest arrivant et un message Certificate vide renvoyé.
Une alerte « unknown CA » couvre le cas où le certificat présenté par le pair remonte à une CA que le SBC ne reconnaît pas. La correction consiste presque toujours à ajouter l’intermédiaire ou la racine manquante au truststore, et non à affaiblir la politique de validation. Si vous ne reconnaissez pas la CA émettrice, ne lui faites pas confiance.
Une alerte « certificate verify failed » signifie que la signature CertificateVerify ne correspondait pas à la clé publique du certificat. C’est plus rare et survient généralement parce que le pair présente un certificat dont il ne détient pas réellement la clé privée (souvent parce que quelqu’un a copié un fichier certificat entre des hôtes mais pas sa clé). Traitez-le comme un événement de sécurité, pas comme une dérive de configuration.
Un mismatch FQDN malgré une chaîne valide signifie que la chaîne est validée et le certificat n’est pas expiré, mais le SAN n’inclut pas le FQDN que votre SBC contacte. C’est le mode de défaillance qui prouve que vous vérifiez le SAN, ce qui est correct. Le pair a besoin d’un certificat avec le bon SAN, pas d’un truststore plus large de votre côté.
Le symptôme classique « ça marchait hier, cassé aujourd’hui, aucun changement de configuration » remonte presque toujours à un certificat expiré, une CRL que le SBC n’a pas pu actualiser, ou une racine de CA que le SBC reconnaissait et qui a été retirée du truststore du pair (le cas Microsoft Teams est l’exemple canonique). Vérifiez les dates d’expiration et l’accessibilité des sources de révocation avant toute autre chose.
Un handshake réussi dans un seul sens se produit lorsque le certificat du SBC est reconnu par le pair, mais que le SBC rejette le certificat du pair. Le trunk fonctionne dans une direction et échoue dans l’autre. C’est la défaillance de confiance asymétrique de la section précédente, et elle signifie presque toujours une CA manquante d’un côté.

La place du mTLS dans une défense en profondeur

Le mTLS authentifie la connexion. Il ne traite pas, à lui seul, la plupart des autres menaces à la frontière SIP. Une posture de sécurité SBC complète traite le mTLS comme l’une de plusieurs couches.
Au-dessus du mTLS, le SBC doit toujours contrôler le comportement au niveau SIP : limites de débit sur les INVITE, REGISTER et OPTIONS, mise en liste de blocage dynamique pour les sources qui dépassent les seuils, et protection contre les messages malformés. Un pair qui complète le mTLS avec succès puis vous inonde d’INVITE est authentifié, mais reste abusif.
À côté du mTLS, le chemin média nécessite son propre chiffrement. Le mTLS protège la signalisation SIP. Les flux média RTP circulent sur UDP et sont protégés par SRTP, avec des clés échangées soit en SDES (à l’intérieur de la signalisation protégée par TLS) soit via DTLS-SRTP (handshake sur le chemin média lui-même). Ne chiffrer que la signalisation est une erreur courante ; les clés SDES circulent dans la signalisation, donc une signalisation non chiffrée compromet aussi le SRTP.
En dessous du mTLS, les contrôles réseau restent importants. Les listes d’autorisation IP sont plus faibles que l’authentification cryptographique, mais elles réduisent le bruit de fond en éloignant le trafic Internet aléatoire de la pile TLS. La combinaison « l’IP doit être autorisée et le certificat doit être reconnu » est considérablement plus forte que l’une ou l’autre seule, et les deux échouent en mode fermé.

Surveillance et alertes spécifiques au mTLS

La surveillance SIP générique vous indique quand les appels échouent. La surveillance adaptée au mTLS vous indique pourquoi un trunk protégé par TLS a échoué avant même que l’appel ne soit tenté, et vous donne un avertissement précoce avant l’expiration du prochain certificat.
Quatre signaux méritent des alertes spécifiques. Le premier est l’expiration du certificat du pair par trunk, exprimée en jours restants. C’est le seul moyen de repérer un pair sur le point de renouveler un certificat sans vous prévenir, et cela doit être mesuré en lisant le certificat que le pair présente réellement, et non en se fiant à la documentation contractuelle. Le deuxième est le taux d’échec de handshake par pair, ventilé par raison d’alerte TLS. Un pic soudain d’alertes « unknown CA » provenant d’un pair signifie presque toujours qu’il a effectué une rotation de sa CA sans coordination. Le troisième est le taux d’échec de vérification de révocation, distinct du taux d’échec de handshake. Une politique soft-fail masquera les pannes CRL/OCSP dans les handshakes réussis, de sorte que le taux d’échec est le seul moyen de les voir. Le quatrième est le nombre de jours avant expiration de votre propre certificat, avec des alertes à 90, 60, 30 et 14 jours. Renouveler à l’avance est simple ; renouveler à expiration moins un jour est un incident affectant les appels.
Pour les fournisseurs de services exploitant cela à grande échelle, le Monitoring as a Service peut intégrer les signaux d’expiration de certificat, d’échec de handshake et d’échec de révocation dans le même tableau de bord que les métriques de qualité d’appel, avec des alertes par e-mail, Slack ou Teams. Le faire correctement en interne est aussi faisable si vous vous engagez à inspecter les certificats par trunk plutôt que par serveur.

Cas d’usage au-delà de Microsoft Teams

Teams Direct Routing est le cas d’usage qui a mis le mTLS sur le radar de la plupart des opérateurs de SBC, mais ce n’est pas le seul et ne devrait pas être le seul que votre architecture considère.
Les interconnexions d’opérateurs sont de plus en plus construites sur le mTLS plutôt que sur des listes d’autorisation IP. Les opérateurs de niveau 1 publient des exigences de peering avec mTLS obligatoire depuis plusieurs années ; les opérateurs de niveau intermédiaire ont commencé à suivre. L’avantage pour les deux côtés est qu’un trunk lié à un certificat survit à une renumérotation IP avec un changement de configuration plutôt qu’une revue de sécurité.
Les déploiements BYOC de centres de contact (Genesys, Five9, NICE, Talkdesk sur les propres trunks SIP d’un opérateur) utilisent le mTLS pour authentifier le SBC auprès de la plateforme CCaaS sans dépendre d’une infrastructure IP partagée. Le modèle CPaaS et BYOC est fonctionnellement similaire à Teams Direct Routing, sans les exigences spécifiques à Microsoft.
La fédération SIP B2B entre deux entreprises, ou entre une entreprise et une plateforme UCaaS, est un cas naturel pour le mTLS car les deux côtés ont une identité connue et un FQDN stable. C’est là que le pinning ou une CA privée tend à mieux fonctionner qu’une CA publique, car le certificat n’est visible par personne en dehors de la relation.
Les déploiements MSP multi-locataires utilisent le mTLS plus un certificat wildcard pour authentifier le trafic de chaque locataire client sur un SBC partagé. La discipline de confiance asymétrique compte le plus ici, car la défaillance du certificat d’un locataire ne doit pas affecter les autres.
Les secteurs réglementés (santé, services financiers, gouvernement) traitent le mTLS comme un prérequis plutôt qu’une fonctionnalité, souvent couplé avec un hard-fail de révocation, des CA privées et du certificate pinning pour les connexions les plus sensibles. Les cadres de conformité mandatent rarement le mTLS par son nom, mais les contrôles qu’ils exigent (authentification mutuelle, garde des clés, application de la révocation) y reviennent en pratique.

mTLS sur ProSBC

ProSBC gère les quatre éléments de configuration (identité serveur, identité client, truststore, politique par trunk) via sa gestion standard des certificats et la configuration des Network Access Points (NAP). Les paramètres pertinents se trouvent aux côtés de la configuration TLS par trunk couverte dans le guide de configuration TLS et SRTP pour SBC, cette section se concentre donc sur ce qui est spécifique au mTLS plutôt que de reprendre la configuration TLS par trunk.
Le truststore peut contenir n’importe quelle combinaison de CA publiques, CA privées et certificats de pairs épinglés, avec une sélection par trunk des entrées valides pour chaque NAP. Cela évite le mode de défaillance « faire confiance à toute CA publique » en permettant à différents trunks d’accepter différentes autorités. Par exemple, des CA racines et une CA interne privée peuvent coexister sur le même SBC sans que l’une n’affaiblisse l’autre.
Chaque NAP porte sa propre politique TLS avec les quatre réglages standard (pas de TLS, TLS sans authentification client, TLS avec authentification client optionnelle, TLS avec authentification client obligatoire), de sorte que le même SBC peut servir une interconnexion d’opérateur en mTLS strict, une fenêtre de migration en mTLS optionnel et un trunk ancien en TLS unidirectionnel, simultanément. La politique par NAP permet aussi d’appliquer des politiques de révocation différentes par trunk si nécessaire.
Pour les fournisseurs de services et MSP sans personnel PKI dédié, le service managé ProSBC inclut le support du cycle de vie des certificats dans le cadre de la couverture d’ingénierie de niveau 3, ce qui libère l’opérateur de la charge de coordination des rotations. Pour les déploiements auto-hébergés, la licence ProSBC Lab suffit pour valider une configuration mTLS de bout en bout contre un tenant Teams de test ou un opérateur sandbox avant le déploiement en production.

Foire aux questions