BizTalk Server 2020 y TLS 1.3: estado, alternativas y guía de implantación

¿BizTalk Server 2020 soporta TLS 1.3? La respuesta corta es no: hoy sólo ofrece soporte oficial para TLS 1.2. En esta guía verás el estado actual, el impacto en tus integraciones y cómo implementar, desde ya, arquitecturas puente con TLS 1.3 sin tocar tus aplicaciones.

Índice

Resumen de la pregunta y respuesta breve

Pregunta: ¿BizTalk Server 2020 admite TLS 1.3? Si no, ¿piensan añadirlo y cuándo?

Estado actual: BizTalk Server 2020 admite oficialmente TLS 1.2. No existe soporte nativo anunciado para TLS 1.3 ni fechas públicas confirmadas.
Implicación práctica: Si un partner o cliente exige TLS 1.3 extremo a extremo, BizTalk 2020 no puede hablarlo directamente.

Lo esencial en una mirada

Aspecto	Situación con BizTalk 2020	Qué hacer hoy
Versión TLS soportada	TLS 1.2 (soporte oficial)	Endurecer TLS 1.2 y usar terminación/puente TLS 1.3 al borde
Exposición externa HTTPS	Puede quedar en TLS 1.2	Poner un reverse proxy/balanceador que hable TLS 1.3 externo y TLS 1.2 interno
Consumo de APIs TLS 1.3	No conecta directo	Usar proxy TLS saliente con inspección/bridging que negocie 1.3 con el destino
mTLS con certificados de cliente	Soportado en TLS 1.2	Propagar el certificado al backend mediante bridging o cabeceras seguras del proxy
Cumplimiento y auditoría	Dependiente de SO, .NET e IIS	Actualizar CUs/parches, deshabilitar TLS 1.0/1.1, limitar cipher suites fuertes

Contexto: TLS 1.2 vs TLS 1.3 y por qué te importa

TLS 1.3 elimina handshakes innecesarios y cipher suites débiles, integra PFS de forma obligatoria y acelera la negociación. Aun así, muchas plataformas empresariales siguen en TLS 1.2 por dependencias con .NET Framework, librerías y adaptadores. BizTalk 2020 —basado en .NET Framework e IIS— funciona perfectamente con TLS 1.2 endurecido, pero no negocia TLS 1.3 por sí mismo. Si el sistema operativo soporta TLS 1.3, eso no implica que BizTalk lo herede automáticamente en toda la cadena de transporte. La solución práctica es introducir un elemento intermedio que traduzca entre mundos 1.3 y 1.2, manteniendo la seguridad y el rendimiento.

Estrategia recomendada: terminación o puente TLS 1.3 delante de BizTalk

Coloca un componente perimetral que acepte conexiones TLS 1.3 desde clientes externos y que a su vez se conecte a BizTalk usando TLS 1.2. Este patrón se conoce como TLS termination o TLS bridging y es el más común en entornos con requisitos modernos de cifrado.

Arquitectura de referencia

Cliente (TLS 1.3)  ⇄  Reverse Proxy / LB (terminación 1.3)  ⇄  BizTalk/IIS (TLS 1.2)

Perímetro: NGINX, HAProxy, F5 BIG-IP, Apache, Azure Application Gateway o Azure Front Door.
Interior: IIS con los Receive Locations HTTP/HTTPS de BizTalk, o servicios WCF expuestos por adaptadores WCF-*.
mTLS: El perimetral valida el certificado de cliente en la cara 1.3 y lo reexpone al backend ya sea mediante bridging TLS o a través de cabeceras firmadas/variables de entorno que BizTalk/IIS pueda consumir.

Opciones de plataforma para el perimetral

Plataforma	Rol	Notas de capacidad
NGINX	Reverse proxy L7	Soporta TLS 1.3 con OpenSSL 1.1.1+; mTLS; HTTP/2; cabeceras personalizadas; proxyssl* para backend TLS 1.2
HAProxy	Proxy L4/L7	Offloading TLS 1.3, reuso de sesiones, SNI, mTLS, verificación de backend TLS 1.2
F5 BIG-IP	ADC	Perfiles cliente/servidor SSL separados para 1.3 y 1.2; iRules para pasar DN del cliente
Apache HTTPD	Reverse proxy	`modssl` y `modproxy` con TLS 1.3 externo y `ProxyPass` a backend 1.2
Azure Application Gateway	WAF/LB	Políticas SSL; listener con TLS 1.3; HTTP settings para backend TLS 1.2; opción de reescritura de cabeceras
Azure Front Door	Perímetro global	Terminación TLS 1.3 en el borde, origin group hacia App Gateway o IIS en 1.2

Diseño de red y DNS

Ubicación: Despliega el proxy en DMZ o frente a Internet, con reglas de firewall que permitan sólo los puertos necesarios hacia BizTalk/IIS.
Certificados: Usa un certificado público para el listener 1.3 y, si requieres mTLS, una CA de confianza para validar clientes. En el backend, usa certificados internos confiables por el proxy.
SNI y FQDN: Habilita SNI para el frontend y usa FQDN de backend coherentes con el certificado de IIS, evitando desajustes de nombre.

Ejemplo de configuración con NGINX

Este ejemplo acepta TLS 1.3 en el frontend, exige mTLS y se conecta al backend en TLS 1.2 preservando el nombre del servidor:

server {
  listen              443 ssl http2;
  server_name         api.midominio.com;

ssl\_protocols       TLSv1.3;
ssl\_certificate     /etc/nginx/certs/fullchain.pem;
ssl\certificate\key /etc/nginx/certs/privkey.pem;

mTLS en el frente 1.3

ssl\client\certificate /etc/nginx/certs/ca-clients.pem;
ssl\verify\client       on;

Opcional: exponer el DN del cliente al backend de forma controlada

proxy\set\header X-Client-Cert-Subject \$ssl\client\s\_dn;
proxy\set\header X-Client-Cert-Verify  \$ssl\client\verify;

location / {
proxy\_pass                  [https://biztalk-backend](https://biztalk-backend);
proxy\http\version          1.1;
proxy\set\header            Host \$host;
proxy\set\header            X-Forwarded-Proto https;
proxy\read\timeout          120s;```
# TLS 1.2 al backend
proxy_ssl_server_name       on;
proxy_ssl_name              backend.midominio.local;
proxy_ssl_protocols         TLSv1.2;
proxy_ssl_ciphers           ECDHE-ECDSA-AES256-GCM-SHA384:
                            ECDHE-RSA-AES256-GCM-SHA384:
                            ECDHE-ECDSA-AES128-GCM-SHA256:
                            ECDHE-RSA-AES128-GCM-SHA256;
proxy_ssl_verify            on;
proxy_ssl_trusted_certificate /etc/nginx/certs/ca-interna.pem;
```
}
}

upstream biztalk-backend {
server 10.10.20.30:443; # IIS/BizTalk
}

Ejemplo de configuración con HAProxy

global
  ssl-default-bind-options ssl-min-ver TLSv1.3
  ssl-default-bind-ciphersuites TLSAES256GCMSHA384:TLSAES128GCMSHA256

defaults
mode http
option  httplog
timeout connect 10s
timeout client  120s
timeout server  120s

frontend fe\_https
bind :443 ssl crt /etc/haproxy/certs/api.pem ca-file /etc/haproxy/certs/ca-clients.pem verify required
http-request set-header X-Client-Cert-Subject %\[ssl\c\s\_dn]
http-request set-header X-Client-Cert-Verify  %\[ssl\c\verify]
default\backend be\biztalk

backend be\_biztalk
server iis 10.10.20.30:443 ssl verify required sni str(backend.midominio.local) 
ca-file /etc/haproxy/certs/ca-interna.pem force-tlsv12 
ciphers ECDHE+AESGCM:!aNULL:!MD5

Proxy TLS saliente cuando BizTalk consume APIs sólo-TLS 1.3

Algunos proveedores ya bloquean TLS 1.2 en sus APIs. Si BizTalk debe consumir esas APIs, utiliza un componente que termine TLS 1.2 por el lado de BizTalk y levante una nueva sesión TLS 1.3 hacia el proveedor. Esto requiere inspección SSL controlada (no meramente un túnel CONNECT), por lo que deberás:

Instalar una CA corporativa en los servidores BizTalk para confiar en el certificado generado por el proxy saliente.
Apuntar los adaptadores de envío (WCF-WebHttp, WCF-Custom, etc.) al hostname del proxy o a un DNS interno que resuelva al proxy.
Permitir que el proxy valide estrictamente el certificado real del proveedor al negociar TLS 1.3.

Herramientas típicas para este patrón incluyen HAProxy/NGINX en modo forward con inspección TLS, F5 SSL Orchestrator o soluciones de seguridad perimetral que ofrezcan SSL/TLS interception. Evita los forward proxies que sólo hacen CONNECT sin terminar TLS, porque no cambian la versión negociada: BizTalk seguiría hablando 1.2 con el destino final.

Endurecimiento de TLS 1.2 en BizTalk e infraestructura

Si te quedas en TLS 1.2 en el interior —lo más habitual—, asegúrate de que está endurecido tanto en el sistema operativo como en .NET e IIS:

Deshabilitar TLS 1.0 y 1.1 por registro

Aplica en todos los nodos BizTalk, IIS y SSO. Requiere reinicio.

Windows Registry Editor Version 5.00

; Deshabilita TLS 1.0 (Cliente y Servidor)
\[HKEY\LOCAL\MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
"Enabled"=dword:00000000
"DisabledByDefault"=dword:00000001
\[HKEY\LOCAL\MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
"Enabled"=dword:00000000
"DisabledByDefault"=dword:00000001

; Deshabilita TLS 1.1 (Cliente y Servidor)
\[HKEY\LOCAL\MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
"Enabled"=dword:00000000
"DisabledByDefault"=dword:00000001
\[HKEY\LOCAL\MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"Enabled"=dword:00000000
"DisabledByDefault"=dword:00000001

; Asegura TLS 1.2 habilitado
\[HKEY\LOCAL\MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"Enabled"=dword:00000001
"DisabledByDefault"=dword:00000000
\[HKEY\LOCAL\MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"Enabled"=dword:00000001
"DisabledByDefault"=dword:00000000

Habilitar criptografía fuerte en .NET

Para que las aplicaciones .NET de BizTalk utilicen algoritmos fuertes y dejen que el sistema operativo elija TLS 1.2 de forma predeterminada:

Windows Registry Editor Version 5.00

; Clave x64
\[HKEY\LOCAL\MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
"SystemDefaultTlsVersions"=dword:00000001

; Clave Wow6432Node
\[HKEY\LOCAL\MACHINE\SOFTWARE\WOW6432Node\Microsoft.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
"SystemDefaultTlsVersions"=dword:00000001

Además, revisa tu código .NET personalizado para evitar líneas como ServicePointManager.SecurityProtocol = Tls12 o, peor, Tls|Tls11|Tls12, que pueden tener efectos no deseados. Lo ideal es dejar que el sistema tome la mejor versión habilitada.

Limitar cipher suites fuertes en Windows

Ajusta el orden y el conjunto de cipher suites de TLS 1.2 a un perfil moderno (por ejemplo, ECDHE con AES-GCM). Un conjunto conservador:

TLSECDHEECDSAWITHAES256GCM_SHA384,
TLSECDHERSAWITHAES256GCM_SHA384,
TLSECDHEECDSAWITHAES128GCM_SHA256,
TLSECDHERSAWITHAES128GCM_SHA256

Valida en preproducción que todos los adaptadores y endpoints siguen funcionando tras aplicar el endurecimiento.

Impacto por adaptador de BizTalk

Adaptador	Transporte	Notas TLS
WCF-WebHttp / WCF-BasicHttp / WCF-Custom	HTTP/HTTPS	Trabaja con TLS 1.2 endurecido; sin TLS 1.3 nativo
HTTP / SOAP	HTTP/HTTPS	Igual que WCF; revisar bindings y certificados
FTP	FTP/FTPS	FTPS usa TLS 1.2; confirmar modo explícito/implícito
SFTP	SSH	No usa TLS; no afectado por 1.3/1.2
SB-Messaging / MQSeries	Dependiente del cliente	Validar versión TLS del SDK subyacente

Comprobaciones y validación

Antes de pasar a producción, verifica con herramientas de línea de comandos y pruebas end-to-end.

Pruebas de cliente con OpenSSL

# Verifica que el frente hable TLS 1.3
openssl sclient -connect api.midominio.com:443 -tls13 -servername api.midominio.com

Verifica que el backend hable TLS 1.2

openssl s\client -connect backend.midominio.local:443 -tls1\2 -servername backend.midominio.local

Comprueba la línea Protocol, el cipher negociado y el certificado presentado. Si usas mTLS, añade -cert y -key con un certificado de cliente válido para el listener 1.3.

Validación funcional

Ejecuta mensajes de extremo a extremo y monitorea event logs, tracking de BizTalk y métricas del proxy.
Verifica latencia de handshake y throughput bajo carga; TLS 1.3 debe reducir el tiempo de establecimiento en el exterior.
Confirma que se propaga correctamente la identidad del cliente si usas mTLS (DN, SAN, huella).

Consideraciones para mTLS y cabeceras seguras

Al hacer offloading del mTLS en el borde, el backend ya no ve el certificado del cliente directamente. Soluciones:

TLS bridging con reautenticación: Valida el cliente en el proxy y vuelve a exigir un certificado en el salto interno (menos común, añade complejidad).
Cabeceras firmadas: El proxy inserta X-Client-Cert-Subject, X-Client-Cert-Thumbprint o X-Client-Cert con el PEM del cliente. En IIS, crea handlers o módulos para leerlas y autorizar. Protege estas cabeceras en el proxy para que sólo él pueda establecerlas.

Estrategias de despliegue en Azure

Con Application Gateway

Define un listener HTTPS con política SSL que admita TLS 1.3.
Configura un backend pool con los nodos IIS/BizTalk.
En HTTP settings, activa la opción HTTPS con verificación del certificado y fuerza TLS 1.2.
Habilita reescritura de cabeceras si necesitas propagar DN del cliente.

Con Front Door

Activa TLS 1.3 en el dominio del borde.
Usa Application Gateway como origin para mantener control del salto a TLS 1.2 interno.
Configura health probes y reglas de ruta para canary/blue-green.

Matriz de decisión rápida

Requisito	Patrón recomendado	Comentarios
Exponer APIs públicas sólo en TLS 1.3	Reverse proxy con terminación 1.3	Sencillo, auditable, escalable horizontalmente
Consumo de APIs externas sólo 1.3	Proxy saliente con inspección TLS	Requiere CA corporativa; valida pinning del proveedor
mTLS extremo a extremo	Bridging + propagación de identidad	Usa cabeceras firmadas o doble mTLS si es viable
Compatibilidad amplia de clientes	1.3 externo + 1.2 interno	Mantiene compatibilidad sin tocar BizTalk

Prácticas operativas y de mantenimiento

Actualizaciones: Mantén Windows, .NET Framework, IIS y BizTalk en sus CUs y parches más recientes.
Observabilidad: Expone métricas de handshake, renegociaciones, errores de certificado y tasas de acierto de caché TLS en el proxy.
Rotación de certificados: Automatiza la renovación de certificados en el borde e interior (ACME si procede) y prueba con antelación la cadena de confianza.
Escalabilidad: Habilita HTTP/2 en el frontend 1.3 para multiplexación; usa keep-alive y pools de conexiones hacia IIS para evitar costos de handshake repetidos.
Pruebas de regresión: Incluye pruebas de interoperabilidad TLS en el pipeline de despliegue (versiones, ciphers, SNI, ALPN).

Riesgos y antipatrón a evitar

Confiar en que el SO “magicamente” actualiza BizTalk a 1.3: No ocurre. Valida siempre extremo a extremo.
Proxies que sólo tunelizan CONNECT: No cambian la versión TLS; no solucionan el requisito de 1.3.
Perder la identidad del cliente en mTLS: Diseña desde el inicio cómo propagar DN/huella y protégelo contra suplantación.
Ciphers demasiado restrictivos sin pruebas: Pueden romper adaptadores o handlers legacy. Haz pruebas y canary.

Checklist de implementación

Selecciona la plataforma de proxy adecuada y define topología (DMZ, subredes, NSG/firewall).
Instala certificados públicos para el frontend y de CA interna para validar backend.
Configura TLS 1.3 en frontend y TLS 1.2 con ciphers fuertes en backend.
Si hay mTLS, implementa validación del cliente y propagación de identidad.
Endurece TLS 1.2 en Windows/.NET/IIS de BizTalk; deshabilita TLS 1.0/1.1.
Ejecuta pruebas openssl s_client, smoke tests funcionales y de carga.
Implementa monitoreo y alertas de fallos de handshake y expiración de certificados.
Planifica rollbacks y despliegues progresivos.

Preguntas frecuentes

¿BizTalk 2020 obtendrá TLS 1.3 vía parches? No hay fechas públicas confirmadas. Planifica tu arquitectura asumiendo TLS 1.2 interno durante el ciclo de vida de la plataforma.

¿Qué pasa con SFTP? SFTP usa SSH, no TLS; los cambios aquí no aplican.

¿AS2/EDI sobre HTTPS? Funciona bien en TLS 1.2. Para requisitos de 1.3 en Internet, aplica el patrón de terminación en el borde.

¿Puedo activar TLS 1.3 en Windows y “listo”? No. Aunque el sistema lo soporte, BizTalk y sus adaptadores no negocian 1.3 de forma nativa. Valida siempre en preproducción.

Conclusión

BizTalk Server 2020 sigue siendo plenamente operativo y seguro bajo TLS 1.2 endurecido. Cuando el negocio exige TLS 1.3 —ya sea para exposición de APIs o consumo de servicios externos— la solución realista y de bajo riesgo es terminar o puentear TLS 1.3 en el borde y mantener TLS 1.2 hacia BizTalk. Con una configuración cuidada de certificados, ciphers y monitoreo, obtendrás compatibilidad, cumplimiento y rendimiento sin reescribir tus integraciones.

Nota: BizTalk 2020 se basa en .NET Framework e IIS. Aunque el sistema operativo pueda soportar TLS 1.3, eso no garantiza compatibilidad extremo a extremo en BizTalk; valida siempre en preproducción.

Comandos útiles y atajos

# Detecta versiones TLS negociadas (cliente → servidor)
openssl sclient -connect host:443 -tls13 -servername host
openssl sclient -connect host:443 -tls12 -servername host

Comprueba cabeceras insertadas por el proxy

curl -vk [https://api.midominio.com/echo](https://api.midominio.com/echo)

Verifica ciphers soportados por un servicio (OpenSSL)

openssl ciphers -v 'ECDHE+AESGCM:@STRENGTH'

Resumen de acciones si necesitas TLS 1.3 hoy

Implementa un reverse proxy o balanceador que negocie TLS 1.3 externo y TLS 1.2 interno.
Para salidas a APIs sólo 1.3, usa un proxy con inspección TLS que termine 1.2 del lado BizTalk y levante 1.3 hacia el proveedor.
Endurece TLS 1.2 en BizTalk: deshabilita 1.0/1.1, aplica ciphers fuertes, actualiza CUs/parches.
Ejecuta pruebas con openssl s_client y pruebas funcionales end-to-end, y monitorea en producción.