Szenario
Bei einem Kunden hatten wir folgendes Szenario:
- Windows Server.
- .NET-8-Konsolenanwendung, die REST-Web-API-Aufrufe an andere Server im LAN macht.
- Aufgabenplanung, um die Konsolenanwendung regelmäßig aufzurufen.
In der Aufgabenplanung haben wir nicht direkt die .NET-Konsolenanwendung aufgerufen, sondern eine CMD-Batch-Datei, und diese ruft dann wiederum die .NET-Konsolenanwendung auf.
Also z. B.:
CD /d %~dp0\..
@REM Proxy kann nicht direkt gesetzt werden, deshalb via CMD
SETX ALL_PROXY "192.149.248.31:8080"
SETX NO_PROXY "my.other.server.lan"
dotnet "D:\MyApp\MyApp.dll" some-parameter
Diese Konstellation mit der CMD-Datei, die die Aufgabenplanung regelmäßig aufruft, gab es bereits seit Jahren, lief problemlos.
Neu dazu gekomme ist jetzt, dass wir die Proxy-Einstellungen mitgeben müssen, weil wir seit kurzem eben die REST-Web-API auf einem anderen Server aufrufen müssen aus der .NET-Konsolenanwendung heraus.
Fehler
Wir konnten dann beobachten, dass die Anwendung zwar korrekt gestartet wurde durch die Aufgabenplanung, aber die Proxy-Einstellungen, die wir über die SETX-Befehle in der CMD-Datei gesetzt haben, nicht bei der Anwendung ankamen.
Es kamen diverse Fehlermeldungen à la:
System.Net.Http.HttpRequestException
The SSL connection could not be established, see inner exception.
at System.Net.Http.ConnectHelper.EstablishSslConnectionAsync(SslClientAuthenticationOptions sslOptions, HttpRequestMessage request, Boolean async, Stream stream, CancellationToken cancellationToken)
…
Und der Inner-Exception:
System.Security.Authentication.AuthenticationException
The remote certificate is invalid because of errors in the certificate chain: UntrustedRoot
at System.Net.Security.SslStream.CompleteHandshake(SslAuthenticationOptions sslAuthenticationOptions)
Lösung
Mein Kollege M. kam dann zufällig, vermutlich auch aus Verzweiflung, auf die Idee, die in der Aufgabenplanung hinterlegte Aufgabe, die es bereits seit mehreren Jahren dort gab, und die ja, wie oben erwähnt, bisher fehlerfrei funktioniert hat, einfach zu löschen und exakt genauso nochmals neu anzulegen.
Und siehe da: Auf einmal hat alles wieder funktioniert 
Die Proxy-Einstellungen wurden jetzt korrekt an die .NET-Konsolenanwendung weitergegeben, und der Aufruf der REST-Web-API lief erfolgreich durch.
Ursachenforschung
Uns ist nicht klar, was die genaue Ursache war.
Der in der Aufgabe hinterlegte „Dienst“-Benutzer war vorher und nachher genau derselbe, auch alles andere war gleich.
Werden wir vermutlich nie erfahren, aber zumindest läuft es jetzt (hoffentlich dauerhaft) wieder, und eventuell hilft dieser Eintrag hier irgendjemandem mal, der/die in derselben Lage ist.
Ich habe auch noch ChatGPT-4o gefragt, er hat dann diese Vorschläge gemacht.