Errores Schannel 36871 y 36874 en TLS Windows Server 2022/2019: causas y solución definitiva

Administradores de Windows Server 2022 y 2019 reportan miles de eventos Schannel 36871 y 36874. El origen casi siempre es una desalineación entre protocolos, suites de cifrado o certificados. Esta guía exhaustiva explica las causas y detalla un procedimiento paso a paso para eliminarlos definitivamente.

Qué es Schannel y por qué genera eventos 36871 y 36874

Schannel (Secure Channel) es la implementación nativa de TLS/SSL de Windows. Todo proceso que intente abrir un canal seguro—desde IIS y SQL Server hasta un proceso .NET de línea de comandos—depende de Schannel para negociar versión del protocolo y conjunto de cifrado. Cuando la negociación falla, el controlador de eventos registra errores:

• 36871 – “A fatal error occurred while creating a TLS client credential. Internal error state 10013/10010”.
• 36874 – “A TLS 1.2 connection request was received but none of the cipher suites supported by the client are supported by the server”.

Ambos eventos indican que el cliente y el servidor no comparten al menos una combinación compatible de versión TLS + cipher suite + certificado válido.

Anatomía del problema

Para cada intento de conexión TLS intervienen tres componentes:

1. Versión del protocolo (TLS 1.0–1.3). Windows Server 2022 admite de forma nativa TLS 1.3, pero solo si está habilitado por directiva. Muchos entornos aún negocian TLS 1.2 de forma predeterminada.
2. Cipher suite, p. ej. TLSECDHERSAWITHAES256GCM_SHA384. Los clientes heredados suelen ofrecer suites antiguas ya inhabilitadas por la directiva de seguridad del servidor.
3. Certificado: cadena de confianza, uso de clave (EKU) y longitud de clave RSA/EC. Un certificado inválido o con clave de 1024 bits forzará la denegación.

Síntomas habituales que delatan desajustes

• Peticiones HTTPS que tardan varios segundos y terminan en error “ERRSSLVERSIONORCIPHER_MISMATCH”.
• Servicios .NET en segundo plano que dejan de enviar datos al exterior tras un parche mensual.
• Backup agents antiguos que fallan al notificar a la consola central.
• Solo aparecen eventos Schannel en el servidor, no en el cliente.

Estados de error internos frecuentes

Internal State	Significado	Acción recomendada
10010	Suite ofrecida obsoleta o bloqueada por directiva	Habilitar suite moderna compatible o actualizar cliente
10013	Algoritmo de firma o hash prohibido (SHA‑1, RC4)	Reemplazar certificado o deshabilitar algoritmos débiles
10053	Cadena de certificados incompleta	Importar certificado intermedio
1205	Protocolo no admitido o negociado (SSL 3.0/TLS 1.0)	Forzar TLS 1.2+ en ambas partes

Paso a paso: solución integral

Actualizar sistema y reiniciar

Aplique la actualización acumulativa más reciente de Windows. Microsoft publica correcciones mensuales que amplían la lista de suites predeterminadas y refinan el comportamiento de Schannel.

Alinear y priorizar cipher suites

1. Ejecute en el servidor: Get-TlsCipherSuite | Select-Object Name,Exchange,Hash | Sort-Object Name.
2. Con una herramienta visual (IIS Crypto o Política de grupo) mueva suites modernas (ECDHERSAWITHAES256GCMSHA384, ECDHEECDSAWITHAES128GCMSHA256) al principio.
3. Aplique la directiva SSL Cipher Suite Order y reinicie.

Validar certificados

Abrir certlm.msc → Personal. Confirme:

• Cadena completa hasta una Autoridad de certificación de confianza.
• Clave RSA ≥ 2048 bits o curva ECC P‑256.
• EKU “Server Authentication”.
• Nombre común o SAN que coincida con el FQDN usado por los clientes.

Renueve certificados que no cumplan estos requisitos.

Forzar TLS 1.2 y cifrado fuerte en .NET Framework

.NET 4.x y 3.5 usan la configuración del sistema salvo que una aplicación fije una versión específica. Añada o verifique las siguientes DWORD = 1 (32 y 64 bits):

HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SystemDefaultTlsVersions  
HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SchUseStrongCrypto  
HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319\SystemDefaultTlsVersions  
HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319\SchUseStrongCrypto

Deshabilitar protocolos inseguros con cautela

Eliminar SSL 2.0, SSL 3.0 y TLS 1.0/1.1 refuerza el entorno y cumple PCI‑DSS 4.0. Sin embargo, primero confirme que:

• No existen impresoras, firmware, dispositivos IoT o SDK Java 6/7 que dependan de TLS 1.0.
• Los sistemas operativos cliente (Windows 7 SP1, Server 2008 R2) ya tienen TLS 1.2 activado o migrarán.

Solo entonces establezca Enabled = 0 y DisabledByDefault = 1 en las claves de protocolo correspondientes.

Interpretar Schannel con registro detallado

1. Establezca DWORD EventLogging = 1 en HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL.
2. Reinicie el servidor o el proceso para que empiece a registrar eventos 11 (Handshake) enriquecidos.
3. Opcional: capture tráfico con Wireshark filtrando tcp.port==443 y analice el Client Hello y Server Hello.
4. Busque la suite elegida por el cliente; si no figura en la lista del servidor, 36874 será inminente.

Secuencia de corrección recomendada

1. Aplicar todos los parches de Windows y reiniciar.
2. Reordenar listas de cipher suites otorgando prioridad a ECDHE+AES‑GCM.
3. Renovar o instalar un certificado válido con clave de 2048 bits o ECC.
4. Agregar claves SchUseStrongCrypto y SystemDefaultTlsVersions para .NET.
5. Deshabilitar TLS 1.0/1.1 solo cuando todos los clientes soporten TLS 1.2 o 1.3.
6. Monitorizar el Visor de eventos. Si 36871/36874 persisten, habilitar registro avanzado y aislar el proceso o agente culpable.

Preguntas frecuentes (FAQ)

¿Eliminar TLS 1.0 rompe SMB v1?

No. SMB v1 y v2 no dependen de TLS. El cambio sólo impacta protocolos que usan Schannel: HTTPS, LDAP sobre TLS, RDP (CredSSP), etc.

¿Puedo habilitar TLS 1.3 en Windows Server 2022?

Sí. A partir de la Build 20348.1103 (KB5016691) tiene soporte preliminar. Habilite la función “TLS 1.3” en Configuración → Red e Internet → Configuración avanzada o vía PowerShell: Enable-TlsCipherSuite -Name TLSAES256GCMSHA384 -Position 0. Aun así, muchos navegadores de clientes negociarán TLS 1.2 hasta que detecten compatibilidad total.

¿Los eventos 36871/36874 afectan al rendimiento?

Indirectamente. Cada intento fallido provoca renegociaciones y reinicios de handshake que incrementan la latencia perceptible y el consumo de CPU. Además, saturan el Visor de eventos, complicando el análisis de otros problemas.

¿Cómo determino qué proceso genera el error?

1. Active los contadores “TLS Handshake Failures/sec” en el Monitor de rendimiento.
2. Supervise ID de proceso (PID) con Resource Monitor y correlación temporal.
3. Use ProcMon con filtro Operation = SchannelInitializeSecurityContext.

Buenas prácticas a largo plazo

• Automatice auditorías trimestrales de cipher suites con scripts PowerShell.
• Instituya renovaciones automáticas de certificados mediante ACME/Win‑ACME.
• Use plantillas de GPO dedicadas para TLS en lugar de editar el registro manualmente.
• Documente cada cambio y mantenga un snapshot de exportación de la directiva SSL Cipher Suite Order.

Conclusión

Los eventos Schannel 36871 y 36874 son un síntoma, no la causa. Una vez que el servidor y los clientes comparten versión TLS, cipher suites modernos y certificados válidos, el registro vuelve a la normalidad y las comunicaciones se benefician de cifrado fuerte, menor latencia y cumplimiento normativo. Siguiendo las medidas descritas—desde la actualización sistemática hasta el ajuste fino de cipher suites—podrá erradicar definitivamente estos errores en Windows Server 2022 y 2019, asegurar la compatibilidad futura con TLS 1.3 y mantener el entorno listo para nuevas exigencias de seguridad.

Resultado esperado: tras alinear protocolos, suites y certificados, desaparecen los eventos 36871 y 36874 y todas las conexiones TLS se establecen con TLS 1.2 o 1.3 y cifrado de grado empresarial.