¿Tu aplicación .NET envía correos de forma impecable cuando la ejecutas manualmente, pero al dispararla desde el Programador de Tareas se rompe la negociación TLS y el Visor de Eventos muestra el temido SChannel 36882? En esta guía aprenderás a reproducir el problema, entender el trasfondo técnico y aplicar, paso a paso, todas las correcciones permanentes disponibles.
Error SChannel 36882 en contexto
SChannel es el proveedor de seguridad de Windows responsable de implementar los protocolos SSL/TLS. El identificador 36882 indica que la cadena de confianza presentada por el servidor (o, en ocasiones, por el cliente) no ha podido validarse porque falta una autoridad intermedia o raíz reconocida. El mensaje más frecuente reza “The certificate received from the server was issued by an untrusted certificate authority…”.
Por qué el mismo usuario falla al ejecutar la tarea
Aunque la tarea se configure con la misma cuenta que usas al iniciar sesión, en realidad se ejecuta en sesión 0, aislada del escritorio interactivo. Si no se fuerza la carga del perfil, el servicio Task Scheduler crea un contexto mínimo sin montar el registro de HKCU ni el almacén de certificados CurrentUser. Cuando tu aplicación .NET llama a Microsoft Identity Client (MSAL) o a la biblioteca de Exchange Online, esta delega la negociación TLS en SChannel, que busca los certificados de confianza en los almacenes cargados. Al no encontrarlos, rechaza la cadena y lanza el evento 36882.
Anatomía del fallo paso a paso
- La tarea arranca en sesión 0 sin perfil.
- El código invoca HTTPS hacia outlook.office.com.
- SChannel descarga la cadena y busca los certificados de la Autoridad de Certificación raíz (Baltimore CyberTrust Root o DigiCert Global, según la región).
- No los encuentra en
HKLM\SOFTWARE\Microsoft\SystemCertificates\Root\Certificatesni enHKLM\SOFTWARE\Microsoft\SystemCertificates\CA\Certificatesporque estaban instalados solo enCurrentUser. - Registra el evento 36882 y aborta la sesión TLS.
- MSAL muestra una excepción
System.Net.Http.HttpRequestExceptionque tu aplicación propaga o captura.
Solución integral
Forzar la carga del perfil de usuario
- Abre taskschd.msc.
- Ficha General → Marca Run whether user is logged on or not y Run with highest privileges.
- Estas opciones instruyen al servicio a cargar completamente
NTUSER.DATy, con él, los almacenesCurrentUser, solucionando la carencia de certificados intermedios.
Reubicar el certificado de la aplicación
Si tu código utiliza un certificado de cliente (por ejemplo, autenticación mutua o firma S/MIME) impórtalo en el almacén Local Machine\Personal (alias MY):
certutil -importPFX "C:\Rutas\certificado.pfx" NoExportCon certutil -store My verifica que aparezca con clave privada y el atributo Machine Keyset.
Verificar la cadena de confianza
Aun forzando el perfil, algunos entornos se quedan sin la raíz de Baltimore CyberTrust o DigiCert Global. Actualízalas manual o automáticamente:
certutil -syncWithWU
certutil -generateSSTFromWU roots.sst
certutil -addstore root roots.sstHabilitar protocolos TLS modernos
Exchange Online exige TLS 1.2 desde octubre de 2023. En versiones antiguas de Windows o .NET Framework agrega el registro:
[HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"Enabled"=dword:00000001
"DisabledByDefault"=dword:00000000Para aplicaciones .NET Framework 4.x añade:
ServicePointManager.SecurityProtocol |= SecurityProtocolType.Tls12;Registro detallado de SChannel
Actívalo solo en pruebas—genera muchos eventos:
reg add HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL /v EventLogging /t REG_DWORD /d 1 /fTras reproducir el fallo restaura el valor predeterminado 0 para evitar llenar el Visor de Eventos.
Guía rápida de comprobaciones
| Verificación | Comando / Herramienta | Resultado deseado |
|---|---|---|
| Perfil cargado | Process Explorer → col. Session ID | La tarea aparece en Session 0 con nombre de usuario correcto |
| Certificado de cliente | certutil -store My | Atributo Machine Keyset: True |
| Cadena de confianza | certutil –verify –urlfetch mail.corp.com.cer | “Certificate is valid” |
| TLS 1.2 activo | PowerShell [Net.ServicePointManager]::SecurityProtocol | Incluye Tls12 |
Alternativas y buenas prácticas
- Cuenta de servicio administrada (gMSA): Almacena certificados en
Local Machine; ideal para flujos CI/CD. - Disparador basado en evento: Útil cuando el bloqueo coincide con un backup o con GPO que reinician LSA.
- Renovación automática: Programa certutil –pulse semanalmente para refrescar expiraciones.
- Monitoring: Configura alertas en el Canal Microsoft‑Windows‑Schannel/Operational para reaccionar antes de que el envío de correo falle en producción.
Preguntas frecuentes
¿Puedo copiar los certificados de CurrentUser a LocalMachine arrastrando desde MMC?
Sí, pero evita exponer la clave privada copiando solo la cadena pública (.cer). El almacén My de equipo no debería tener claves exportables en planes de seguridad estrictos.
¿Basta con marcar “Run only when user is logged on”?
Sólo en laboratorios. En producción querrás que la tarea corra 24×7 sin sesión interactiva. Usa la combinación “Run whether user is logged on or not” + “Run with highest privileges”.
El certificado se distribuye por GPO, ¿por qué sigue faltando?
GPO instala certificados en LocalMachine, pero si tu dominio combina objetos heredados y nuevos, comprueba los permisos de lectura para NT SERVICE\TrustedInstaller y NETWORK SERVICE —en algunos hardenings se deniegan accidentalmente.
¿Cómo limpio certificados raíz obsoletos?
Ejecuta certutil -delstore root thumbprint. Después sincroniza de nuevo con Windows Update para evitar vacíos de confianza.
¿El error 36882 puede indicar un ataque MITM?
En teoría sí. Si un proxy intercepta TLS y re‑firma, presentará una raíz distinta. Pero en la práctica, cuando el fallo ocurre solo en tareas programadas, la raíz del problema suele ser la ausencia del almacén CurrentUser.
Resumen operativo
El evento SChannel 36882 al ejecutar una tarea programada surge porque el servicio Task Scheduler crea un contexto sin cargar el perfil de usuario, dejando huérfanos los certificados intermedios o de raíz que viven en CurrentUser. Las soluciones seguras son (1) forzar la carga del perfil o (2) mover la cadena de confianza y los certificados de cliente a Local Machine. Verifica también que TLS 1.2 esté habilitado y que la cadena se propague mediante GPO o certutil –syncWithWU. Aplicando estas medidas la negociación TLS con Exchange Online o cualquier otro servicio terminará con éxito y tu aplicación .NET volverá a enviar correo sin contratiempos.