Localhost certificate error

Hi there,

I have changed my inner loop from http to https development. Using servicestack I suddenly get an error when trying to authenticate from an UWP app using asp.net core 3.1 on server side. Using latest version 5.8 (ref Servicestack.HttpClient.Core)

Server Side :

.UseKestrel(options =>
options.Listen(IPAddress.Any, 443, listenOptions =>
listenOptions.UseHttps(“localhost.pfx”, “password”);

client side:

JsonHttpClient authClient = new JsonHttpClient(“https://localhost:443/”) { };

            var response = authClient.Post(new Authenticate
                provider = "credentials",
                UserName = "demo",
                Password = "password",
                UseTokenCookie = false

The error that I get shows:

Browser shows certificate is perfect.


I also managed to successfully authenticate with postman on http + https with servicestack endpoint.

Servicestack http requests works perfectly so it’s only https JsonHttpClient that gives me this problem.

So not sure if there is something special I need todo for localhost development on port 443.

Thanks in advance.

The error message suggests that the CA used to sign your certificate is invalid or likely isn’t trusted.

Is there a reason why you’re not just using the localhost ASP.NET Core trusted dev certificate?

If you’re going to use custom self-signed certs you’re going to either need to trust the custom certificates in the certificate store that each platform you’re trying to use them in uses. For this you can try importing the certificate using the same powershell scripts used to import custom grpc SSL certs.

Or you’d need to provide your own custom logic to validate whether or not the certificate should be trusted by using a custom HttpMessageHandler:

var client = new JsonHttpClient(baseUrl)
    HttpMessageHandler = new HttpClientHandler {
        UseCookies = true,
        AutomaticDecompression = DecompressionMethods.GZip | DecompressionMethods.Deflate,
        ServerCertificateCustomValidationCallback = (req,cert,chain,errors) => ...

Thanks mythz,

what a pain these local certificates. why the hell can’t MS create a solution that always works. anyone else who might be reading this. I needed to make sure localhost certificate exist in 4 places for httpclient + web browsers to be happy.

  1. certificate manager - local user - personal / certificates
  2. certificate manager - local user - trusted root / certificates
  3. certificate manager - local machine - personal / certificates
  4. certificate manager - local machine - trusted root / certificates

in my case either web browser or httpclient is not happy when any of these root spots are not filled.

I always use dotnet cli to create certificate and trust. problem with this is it only creates it in option 1 above.
I also run visual studio as admin so not sure if that is also contributing to my issues.

mythz , I see in your httpclient you use decompression, I don’t use it currently in my solution as my solution involves mainly native apps excluding web, but I have been playing with blazor wasm and ss and everything seems to work great so is that something that you can recommend to improve speed ?

1 Like

I just included it because this is the default configuration JsonHttpClient uses so if you’re going to override it, it’s a good idea to preserve the defaults (although not necessary).

There’s not really general rule for when Compression is useful, you’d need to evaluate it on a case-by-case basis, since it adds to execution time you’d want to ensure that it’s justified from the payload savings. Generally I’d recommend compressing caches (i.e. SS default behavior) as the server execution time is pre-paid & saved, but it depends on the Content Type & size which impacts how beneficial it is, e.g. it’s not beneficial for most binary formats like images & protocol buffers, but very beneficial in verbose/repetitive text formats like XML.

Thanks mythz, agree. I think I’ll rather wait for .net 5 when I can use grpc across the board. can’t wait for this magical one BCL ;))