Proxy problems with DotNet API requests (CRL)
Recently we faced an interesting support case with one of our addon customers migrating to Business Central v17. On the customers site, the REST Api calls of our server-side DotNet component constantly kept running into TLS/SSL errors. Since a non-transparent proxy is used in the customer environment it was obvious where the problem had its origin. However, in the setup of our addon we took the proxy into account, which was also confirmed in the network traffic log in WireShark. Our API calls were routed cleanly through the proxy, but they were always accompanied by queries that ran into errors… with some strange external IPs that had nothing in common with our API.
Our dotnet component internally uses the well-known OpenSource library RestSharp for these API calls. So, it didn’t take too much magic to setup the proxy… we thought…
Then why do they keep crashing?
We finally found what we were looking for in the so-called CRL requests. In this case, a revocation list is retrieved from the certificate authority of the external SSL certificate. Compromised certificates end up on this list and thus provide a little more security by denying them. And exactly this external CRL call was not routed via the proxy. However, we were able to clearly identify the microsoft.dynamics.nav.server.exe as the triggering process using ProcMon from the SysInternals suite.
From the beginning it was not our component that ignored the proxy, but the downstream certificate check by the NAV/BC service.
How to fix this?
After some research and building up a test-environment with my colleagues it turned out that setting the Inet-proxy settings for the service-user did the trick. You could achieve this via registry or alternatively logging in as the service-user and setting up via GUI.
It was interesting that Winhttp settings weren’t used at all, although we have suspected that CryptoApi is used to check the revocation list here which relies on the latter… It had to be the classic WinInet-Settings as it is the fallback setting! This means it might not be enough to just set the proxy-settings in your component if you’re sitting behind a non-transparent proxy. Other system-related and external calls may be triggered, on which you have no influence in your component directly.
Jens Fritzsche
... is a technical consultant and developer at Comsol Unternehmenslösungen AG in Kronberg/Taunus. Major tasks are the architecture and implementation of complex, usually cross-system applications in and around Microsoft Dynamics 365 Business Central.
