MENU
  1. Accueil
  2. Windows
  3. Windows Server
  4. BizTalk Server 2020 et TLS 1.3 : état du support, feuille de route et alternatives

BizTalk Server 2020 et TLS 1.3 : état du support, feuille de route et alternatives

Windows Server

BizTalk Server 2020 ne prend pas en charge TLS 1.3 à la date d’octobre 2025. Voici un guide clair et actionnable pour comprendre la situation, sécuriser vos flux en TLS 1.2 durci et planifier, si nécessaire, une trajectoire vers des alternatives compatibles TLS 1.3.

Sommaire

Vue d’ensemble de la question

L’échange porte sur trois points clés : prise en charge actuelle, feuille de route et échéancier. En bref :

  • Prise en charge actuelle : BizTalk Server 2020 reconnaît TLS 1.2. TLS 1.3 n’est pas disponible.
  • Feuille de route : Microsoft n’a communiqué aucun engagement public d’ajouter TLS 1.3 à BizTalk 2020 (ou à une autre version) au moment d’écrire ces lignes.
  • Échéancier : aucun calendrier officiel publié.

État actuel en octobre 2025

BizTalk Server 2020 fonctionne sur .NET Framework 4.8 et tire parti de la pile TLS/SSL Schannel de Windows via les bibliothèques .NET/WCF. Or, .NET Framework 4.8 n’expose pas TLS 1.3. Même si l’OS sous-jacent (Windows 11 ou Windows Server 2022) implémente TLS 1.3 dans Schannel, BizTalk 2020 ne peut pas s’y connecter car l’API .NET utilisée par BizTalk ne propose pas ce protocole.

Conséquence : les scénarios HTTP(S)/WCF, REST ou SOAP de BizTalk négocient au mieux TLS 1.2 (avec suites de chiffrement modernes), dès lors que l’OS et la configuration le permettent, mais jamais TLS 1.3.

Pourquoi TLS 1.3 n’est pas exposé à BizTalk 2020

  1. Dépendance au runtime .NET Framework : BizTalk 2020 s’appuie sur .NET Framework 4.8 pour le réseau et la sécurité. Cette version ne définit pas l’énumération/les constantes permettant d’activer TLS 1.3.
  2. Écart entre l’OS et le runtime : Windows Server 2022 et Windows 11 prennent en charge TLS 1.3 au niveau Schannel. Mais l’application doit aussi cibler un runtime qui expose le protocole. Sans ce pont, BizTalk ne peut pas « monter » à TLS 1.3.
  3. WCF et connecteurs : la majorité des adaptateurs HTTP(S) de BizTalk sont bâtis sur WCF/.NET. En .NET Framework, WCF s’aligne sur les capacités du runtime (au mieux TLS 1.2).

Impacts concrets par couche

CoucheComposantRôlePrise en charge la plus élevéeRemarques
ApplicationBizTalk Server 2020Moteur d’orchestration, ports d’envoi/réceptionTLS 1.2WCF et System.Net côté .NET Framework
Runtime.NET Framework 4.8API réseau, SChannel wrapperTLS 1.2Pas d’exposition de TLS 1.3
OSWindows Server 2022 / Windows 11Schannel (TLS/SSL)TLS 1.3Disponible côté OS, non exploitable par BizTalk 2020

État des systèmes d’exploitation Windows (référence utile)

OSTLS 1.3 (Schannel)Commentaires
Windows Server 2016NonJusqu’à TLS 1.2
Windows Server 2019NonJusqu’à TLS 1.2
Windows Server 2022OuiTLS 1.3 activable au niveau OS
Windows 10 (21H2) / Windows 11Oui (Windows 11)Windows 11 apporte TLS 1.3 au niveau Schannel

Ce que cela signifie pour vos adaptateurs BizTalk

AdaptateurProtocole/TransportNégociation TLSCompatible TLS 1.3 ?Action recommandée
WCF-BasicHttp / WCF-Custom (HTTP)HTTPS (SOAP/REST)WCF/.NET → SchannelNonForcer TLS 1.2, suites modernes, désactiver TLS 1.0/1.1
WCF-WebHttpHTTPS (REST)WCF/.NET → SchannelNonIdem, vérifier sides serveur/clients
WCF-NetTcpNet.TCP (Message/Transport Security)Chiffrement via WCF/.NETNon (pas TLS 1.3)Algorithmes forts, TLS 1.2 si HTTPS utilisé
HTTP/HTTPS natifHTTPSSystem.Net → SchannelNonForcer TLS 1.2 globalement
SFTPSSHHors TLSN/ANon concerné par TLS, sécuriser SSH
FTP/FTPSFTPS (TLS)System.Net → SchannelNonImposer TLS 1.2 si FTPS

Bonnes pratiques immédiates : durcir TLS 1.2

En attendant une éventuelle prise en charge de TLS 1.3, la stratégie pragmatique consiste à durcir TLS 1.2 de bout en bout :

  1. Désactiver TLS 1.0 et TLS 1.1 (client et serveur) sur toutes les machines de la ferme BizTalk et du SQL associé.
  2. Activer TLS 1.2 et suites de chiffrement modernes (ECDHE + AES-GCM, SHA-256/384), en ordonnant les suites côté serveur.
  3. Forcer .NET à utiliser des chiffres forts (SchUseStrongCrypto) et, si du code personnalisé est utilisé, imposer explicitement Tls12.
  4. Installer les derniers Cumulative Updates (CU) de BizTalk 2020 et les correctifs de sécurité mensuels de Windows/SQL Server.
  5. Vérifier les dépendances externes : partenaires, reverse proxies, API en face doivent eux aussi accepter TLS 1.2 moderne.

Modèle de script PowerShell (désactiver TLS 1.0/1.1, activer TLS 1.2)

# À exécuter en PowerShell élevé. Redémarrage requis.
$base = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols"

# Helper

function Enable-TlsVersion {
param([string]$Version, [bool]$Enable)
$paths = @("$base$Version\Client", "$base$Version\Server")
foreach ($p in $paths) {
New-Item -Path $p -Force | Out-Null
if ($Enable) {
New-ItemProperty -Path $p -Name "Enabled" -PropertyType "DWord" -Value 1 -Force | Out-Null
New-ItemProperty -Path $p -Name "DisabledByDefault" -PropertyType "DWord" -Value 0 -Force | Out-Null
} else {
New-ItemProperty -Path $p -Name "Enabled" -PropertyType "DWord" -Value 0 -Force | Out-Null
New-ItemProperty -Path $p -Name "DisabledByDefault" -PropertyType "DWord" -Value 1 -Force | Out-Null
}
}
}

# Désactiver TLS 1.0 et 1.1

Enable-TlsVersion -Version "TLS 1.0" -Enable:$false
Enable-TlsVersion -Version "TLS 1.1" -Enable:$false

# Activer TLS 1.2

Enable-TlsVersion -Version "TLS 1.2" -Enable:$true

Write-Host "Configuration appliquée. Pensez à redémarrer le serveur."

Forcer des chiffres forts côté .NET (.NET Framework)

Sur toutes les machines BizTalk (x64 et, si pertinent, x86), appliquez SchUseStrongCrypto pour .NET Framework :

# .NET Framework 4.x
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -PropertyType DWord -Value 1 -Force | Out-Null
New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -PropertyType DWord -Value 1 -Force | Out-Null

# .NET Framework 2.0/3.5 (si des composants hérités existent)

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft.NETFramework\v2.0.50727" -Name "SchUseStrongCrypto" -PropertyType DWord -Value 1 -Force | Out-Null
New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft.NETFramework\v2.0.50727" -Name "SchUseStrongCrypto" -PropertyType DWord -Value 1 -Force | Out-Null

Exemple pour du code personnalisé (pipeline, composant, helper)

Si vous avez du code .NET dans des composants personnalisés, imposez TLS 1.2 explicitement :

System.Net.ServicePointManager.SecurityProtocol =
    System.Net.SecurityProtocolType.Tls12; // .NET Framework : impose TLS 1.2

Ordre des suites de chiffrement

Définissez un ordre de suites côté serveur privilégiant ECDHE + AES-GCM (256/128) avec SHA-384/256. Utilisez la stratégie de groupe « SSL Cipher Suite Order » pour Windows Server. Évitez CBC et RC4. Contrôlez également les suites côté client si vos machines initient des connexions sortantes.

Journalisation et diagnostic Schannel

Pour diagnostiquer les négociations TLS, activez la journalisation Schannel :

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" `
  -Name "EventLogging" -PropertyType DWord -Value 1 -Force | Out-Null

Consultez ensuite le journal « Système » (Source : Schannel) et le journal « Applications et services > Microsoft > Windows > Schannel » pour les détails de négociation (échecs, versions, suites).

Tests de conformité TLS 1.2

Testez qu’un endpoint distant accepte bien TLS 1.2 :

# Forcer TLS 1.2 dans la session PowerShell
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
# Appel de test (code 200 attendu sur un endpoint HTTPS valide)
(Invoke-WebRequest -Uri "https://votre-api.exemple" -UseBasicParsing).StatusCode

Pour des ports spécifiques, vous pouvez aussi vérifier la connectivité :

Test-NetConnection -ComputerName "votre-api.exemple" -Port 443

Feuille de route : ce que l’on sait

  • Pas d’annonce officielle publiée sur l’ajout de TLS 1.3 à BizTalk 2020.
  • Aucune date communiquée pour une version qui exposerait TLS 1.3 via .NET Framework ou une évolution de BizTalk.
  • Recommandation : surveillez les annonces Microsoft (Blog produit, TechCommunity, Microsoft Learn, feuilles de route Integration Services) pour détecter tout changement.

Alternatives et contournements lorsque TLS 1.3 est exigé

Front TLS 1.3 avec terminaison/bridge

Si des partenaires exigent TLS 1.3 côté frontal, mettez en place un proxy/reverse proxy qui termine en TLS 1.3 à l’edge puis relaie vers BizTalk en TLS 1.2 en interne :

  • Azure API Management (APIM) en mode passerelle : expose TLS 1.3 aux consommateurs, applique des politiques (throttling, transformation), relaie en TLS 1.2 vers BizTalk.
  • Azure Application Gateway ou un NGFW/ADC on‑prem (F5, NGINX Plus, etc.) configurés pour TLS 1.3 côté client.
  • Azure Front Door ou CDN en edge global pour décharger TLS et filtrer.

Veillez à :

  • segmenter le trafic (DMZ → LAN),
  • journaliser les handshakes TLS à l’edge,
  • aligner les suites/chiffres internes en TLS 1.2 durci,
  • tester la latence et la capacité (MTLS, certificats client, rotation).

Azure Integration Services

Si l’exigence TLS 1.3 est non négociable pour des flux Internet, envisagez une évolution progressive vers une architecture basée sur Azure Integration Services :

  • Logic Apps (Standard/Consumption) pour les orchestrations et déclencheurs HTTP(s).
  • API Management en façade pour exposer des API sécurisées en TLS 1.3, appliquer du MTLS et des politiques.
  • Service Bus pour la messagerie asynchrone.
  • Event Grid pour la distribution d’événements.

Un pattern fréquent consiste à exposer des API en TLS 1.3 via APIM/Logic Apps, puis à communiquer avec BizTalk interne (le temps de la transition) via des files (Service Bus) ou via un relais sécurisé.

Sécurité : TLS 1.2 « durci » reste robuste

Dans de nombreux contextes conformes (PCI DSS, exigences clients), TLS 1.2 avec ECDHE + AES‑GCM reste acceptable et robuste. L’essentiel est de :

  • désactiver fermement TLS 1.0/1.1 et les suites faibles,
  • imposer des suites ECDHE + AES‑GCM,
  • rotations et clés RSA 2048+ ou ECDSA P‑256/P‑384,
  • renforcer la validation de certificats (OCSP, CRL),
  • monitorer la dérive de configuration.

Procédure opérationnelle recommandée (playbook)

  1. Inventorier les endpoints HTTPS (ports, noms DNS, clients/serveurs, MTLS).
  2. Appliquer les clés Registre et GPO (désactivation TLS 1.0/1.1, activation TLS 1.2, ordre des suites).
  3. Forcer .NET via SchUseStrongCrypto et, le cas échéant, dans le code personnalisé.
  4. Mettre à jour BizTalk 2020 (dernier CU), Windows Server, SQL Server et drivers.
  5. Tester avec des scripts PowerShell et des outils d’audit TLS (externe/interne).
  6. Surveiller les journaux Schannel et les métriques (erreurs de handshake, pénalités de performance).
  7. Négocier avec les partenaires les exigences TLS (MTLS, versions, suites) et consigner par contrat.
  8. Prévoir une option B (front TLS 1.3 via APIM/ADC) si des flux imposent TLS 1.3 court terme.

FAQ

BizTalk 2020 pourrait-il « hériter » de TLS 1.3 si j’active TLS 1.3 dans Windows Server 2022 ?

Non. L’OS peut supporter TLS 1.3, mais BizTalk 2020 s’appuie sur .NET Framework 4.8, qui n’expose pas ce protocole aux applications.

Le chiffrement côté Net.TCP m’épargne‑t‑il la contrainte TLS 1.3 ?

Net.TCP n’utilise pas TLS de la même manière qu’HTTPS. Les flux HTTPS restent limités à TLS 1.2 avec BizTalk 2020. Pour Net.TCP, conservez des algorithmes forts et mettez à jour.

Est‑ce risqué de rester en TLS 1.2 ?

Avec des suites modernes et une configuration rigoureuse, TLS 1.2 reste considéré comme sûr dans la plupart des cadres normatifs. Les faiblesses documentées concernent surtout des suites anciennes (CBC, RC4) et des configurations laxistes.

Existe‑t‑il un paramètre magique BizTalk pour activer TLS 1.3 ?

Non. Il ne s’agit pas d’un simple commutateur : il faudrait un runtime compatible (API .NET) et un support explicite côté produit BizTalk.

Exemples de configuration côté serveur (récapitulatif)

ObjetClés/ActionsValeur/Conseil
Désactivation TLS 1.0/1.1Registre Schannel (Client/Server)Enabled=0, DisabledByDefault=1
Activation TLS 1.2Registre Schannel (Client/Server)Enabled=1, DisabledByDefault=0
.NET chiffrement fortSchUseStrongCryptoDWORD=1 pour v4.0.30319 + v2.0.50727
Suites côté serveurStratégie « SSL Cipher Suite Order »Privilégier ECDHE + AES‑GCM, SHA‑384/256
Journalisation SchannelEventLoggingDWORD=1 pour diagnostiquer
CU BizTalk 2020MaintenanceAppliquer le dernier CU disponible

Plan de transition si TLS 1.3 devient obligatoire

  1. Phase 0 : cadrer l’exigence (qui demande TLS 1.3 ? sur quels endpoints ? MTLS ?).
  2. Phase 1 : implémenter un front TLS 1.3 (APIM/Application Gateway/ADC) et relayer en TLS 1.2 interne.
  3. Phase 2 : déporter progressivement les flux Internet vers Logic Apps + APIM si l’exigence est structurelle.
  4. Phase 3 : consolider la gouvernance (certificats, rotation, politique de suites, scanners de conformité).
  5. Phase 4 : surveiller les annonces Microsoft et re‑considérer BizTalk si une version ultérieure expose TLS 1.3.

Conclusion

À la date d’octobre 2025, TLS 1.3 n’est pas disponible dans BizTalk Server 2020, et aucun planning officiel n’est communiqué pour l’ajouter. La bonne démarche consiste à sécuriser la plateforme en TLS 1.2 durci (désactivation TLS 1.0/1.1, suites modernes, CU/patching), contrôler la conformité via des tests et journaux Schannel, et préparer un contournement (front TLS 1.3 ou migration sélective vers Azure Integration Services) si une exigence externe impose TLS 1.3 à court terme.

Annexe : checklist rapide

  • Désactiver TLS 1.0/1.1 (client+serveur) sur tous les nœuds BizTalk et SQL.
  • Activer/forcer TLS 1.2, ordonner les suites (ECDHE + AES‑GCM en priorité).
  • Appliquer SchUseStrongCrypto pour .NET Framework (x64/x86).
  • Mettre à jour BizTalk (dernier CU), Windows, SQL, pilotes.
  • Vérifier les partenaires (contrats : versions/suites, MTLS, SLO).
  • Instrumenter : journaux Schannel, métriques de handshake, alertes.
  • Préparer un front TLS 1.3 si nécessaire (APIM/ADC).
  • Surveiller les annonces officielles Microsoft.

Résumé exécutif

Ce qui est sûr : BizTalk 2020 = TLS 1.2 uniquement. Ce qui n’est pas annoncé : intégration de TLS 1.3 et sa date. Ce qu’il faut faire : durcir TLS 1.2, patcher, tester, et prévoir un bridge TLS 1.3 en périphérie ou une transition vers Azure Integration Services si l’exigence persiste.

Windows Server
sécurité Windows Server 2022 TLS 1.2 TLS 1.3 BizTalk Server 2020 .NET Framework 4.8
Sommaire