Search code examples
c#.netssldotnet-httpclient

HttpClient and server certificate validation

In my .Net 6.0 application I'm using HttpClient to connect to a remote API service which is secured with SSL/TLS. The server where my application is hosted is running in the on-prem Windows Server 2016 environment where all the outgoing traffic needs to be whitelisted on the external firewall device. I'm explicitly allowing outgoing connection to the remote API endpoint address, but I don't allow traffic to any other address.

I'm using the default behavior of the HttpClient, which means I have not provided a custom implementation for the ServerCertificateValidationCallback property.

To my surprise the connections to the remote endpoint works flawlessly, which is something that I didn't expect as I have not whitelisted traffic neither to CRL nor OCSP endpoints of the remote API's SSL certificate authority. The certificate that they are using is regular commercial certificate. I also verified with telnet that I'm unable to connect to CRL and/or OCSP endpoints from the machine where my code is running,

I was under the impression that HttpClient before establishing the connection to the remote endpoint validates the server certificate to check if:

  • It is not expired
  • It is issued by an entity whose certificate is listed in machine's Trusted Root Certificate Authorities certificate store
  • It's CN matches with the domain name
  • It has not been revoked via OCSP and/or CLR

Given my experiment the latter is clearly not the case. Can anyone point me to a documentation which explains what is being taken under consideration by HttpClient when deeming connection to the remote endpoint secure?

Solution

  • HttpClient with the default configuration will not check against remote endpoint's CA CRL/OCSP endpoints whether the certificate has been revoked.

    If one wants the validation to happen, one needs to explicitly specify HttpClientHandler.CheckCertificateRevocationList = true

    The performance considerations of this setting needs to be carefully evaluated as it may cause additional delay when establishing the connection with the remote endpoint.

    Thanks @Evk for pointing me in the correct direction