2

I have a .NET Core 3 web service that consumes a third-party WCF service. The service is hosted on a server that's using a private root certificate which I need to trust, but only if it's valid otherwise (not expired and has valid signatures).

I am using Azure App Services. Azure does not support custom certificate authorities in their lower-tier service plans. The Isolated plan supports it, but it is 5x more expensive and would be overkill for the single purpose of trusting a root certificate.

I was looking for workarounds. There are solutions for HttpClient using HttpClientHandler.ServerCertificateCustomValidationCallback. However, the WCF reference does not use HttpClient; it uses an autogenerated client code based on ClientBase.

Then there are some older solutions for completely disabling certificate validation in .NET using System.Net.ServicePointManager.ServerCertificateValidationCallback but that is not supported in .NET Core. And even if it was, I don't want to completely disable the validation; I want it to still validate everything, except that it should trust the specific root certificate.

Is there any way to feed the trusted root certificate into a ClientBase-based client, or to intercept its validation mechanism but without introducing serious security holes? I wouldn't want to start blindly accepting any random certificate.

JustAMartin
  • 13,165
  • 18
  • 99
  • 183
  • You may take a look at this link:[configure TLS mutual authentication](https://learn.microsoft.com/en-us/azure/app-service/app-service-web-configure-tls-mutual-auth). – Jiayao Sep 02 '21 at 06:54
  • @Jiayao That is for client certificates. In my case, the client certificate is working fine, but the server certificate is not being accepted because of missing trust. – JustAMartin Sep 02 '21 at 06:56
  • Maybe you can add the x509 certificate authentication in server-side. – Jiayao Sep 30 '21 at 03:19
  • @Jiayao The server does not belong to me. It belongs to another third-party organization. And the problem is not with x509 certificate, it's with their HTTPS certificate - they have a privately generated certificate that .Net does not trust. – JustAMartin Sep 30 '21 at 15:11

0 Answers0