.NET 4.7.2 SSLStream on Windows Server 2019 ignore proxy settings while checking CRL
Hi everybody,
on a Windows Server 2012 R2 server I have a .net 4.7.2 library using SSLStream class to connect to a SMTP server to send an e-mail. Everything was working fine till we upgraded the machine to Windows Server 2019, when the library stopped working as it was unable to check the revocation list (CRL) for the remote server certificate.
My understanding is that SSLStream.AuthenticateAsClient method uses windows crypto API to check the CRL, which is downloaded through winhttp API to reach the CRL endpoint specified in the certificate itself, through the winhttp proxy set for the server. This behaviour is embedded in the SSLStream class, and not customizable by the developer (well, you can disable CRL verification, but this is not desirable).
My analysis (with the help of procmon 🙂 ) showed that the W2019 machine is trying to reach the CRL distribution endpoint bypassing the proxy settings, that is correctly showed with ‘netsh winhttp show proxy’ command, and it tries to reach the remote endpoint directly, failing because without the proxy the host is unreachable. Further analysis showed that on W2012 right before contacting the enterprise proxy to download the CRL the system is accessing the winhttp settings in the registry (I presume to read proxy settings), while the W2019 server is looking in the user registry section for internet settings: since my application runs with a non-interactive user there’s no profile for it, thus no proxy settings.
Restoring a previous W2012 snapshot of the server fixed the issue, so it seems that W2019 introduced a different behaviour for the winhttp api, breaking somehow backward compatibility with the software.
Do any of you have experienced a similar issue or just have some info about this?
Thanks!
Hi everybody, on a Windows Server 2012 R2 server I have a .net 4.7.2 library using SSLStream class to connect to a SMTP server to send an e-mail. Everything was working fine till we upgraded the machine to Windows Server 2019, when the library stopped working as it was unable to check the revocation list (CRL) for the remote server certificate. My understanding is that SSLStream.AuthenticateAsClient method uses windows crypto API to check the CRL, which is downloaded through winhttp API to reach the CRL endpoint specified in the certificate itself, through the winhttp proxy set for the server. This behaviour is embedded in the SSLStream class, and not customizable by the developer (well, you can disable CRL verification, but this is not desirable). My analysis (with the help of procmon 🙂 ) showed that the W2019 machine is trying to reach the CRL distribution endpoint bypassing the proxy settings, that is correctly showed with ‘netsh winhttp show proxy’ command, and it tries to reach the remote endpoint directly, failing because without the proxy the host is unreachable. Further analysis showed that on W2012 right before contacting the enterprise proxy to download the CRL the system is accessing the winhttp settings in the registry (I presume to read proxy settings), while the W2019 server is looking in the user registry section for internet settings: since my application runs with a non-interactive user there’s no profile for it, thus no proxy settings. Restoring a previous W2012 snapshot of the server fixed the issue, so it seems that W2019 introduced a different behaviour for the winhttp api, breaking somehow backward compatibility with the software. Do any of you have experienced a similar issue or just have some info about this? Thanks! Read More