Blazor server and ASPNET Identity: going through FW only works when certificate has the same DNS name as the site in the subject alternative name

We're seeing a weird behavior on an existing Blazor Server web app which uses ASP.NET Identity for managing is users (this app wasn't developed by our dev team and we don't have access to the team that developed it). Now, before getting into the issue we're having, let me start by trying to resume our production setup:

• We have a FW which receives all the requests for our hosted sites (ex.: xxx.something.com) and redirects them to the appropriate server
• The FW is configured to do SSL offloading, ie, it has the widlcard certificate used for https (TLS)
• After receiving a request, the FW ends up redirecting the request to the server through its internal IP address. This call is generally done through TLS (https) and all the servers have certificates generated by our internal CA issuer with their subject alternative names correctly setup (typically, the SNA will contain at least the DNS name of the machine and its IP address). This works flawlessly in all other sites we have. For instance, a request for the https://site.something.com gets redirected to https://internalIP and we have HTTPS all the way from the browser to the server.

Now, the problem: after applying this default to this Blazor Server app, the app won't handle the authentication cookie properly and the user ends up getting redirected to the default entry page after logging in instead of being redirected to the secure area of the app. On the browser (dev tools), I can see that the authentication cookie was generated but whenever the user tries to access the secure area of the app, the cookie is sent but it's as if it doesn't exist (or isn't considered valid by the framework?).

Now, here's the weird part: if we replace the internal certificate used for TLS on the web server that only has its SAN set to its hostname and IP address with a new one which has its SAN set to its hostname, subdomain name (ie, the name of the site that's being called) and IP address, everything works out properly.

In fact, we have tried the following:

1. start by using the default certificate which has the SAN set to the hostname (ex: DNS=server1) and IP address (ex.: IP=10.50.100.200)
2. navigate to the app and perform login
3. the authentication succeeds, but the user is "redirected" to the default main page
4. without closing the browser or logging out, replace the internal server's certificate used in step 1 with a new one that has the site as an extra DNS value (ex.: DNS=server1;DNS=mysite.something.com)
5. going back to the browser on the client PC and refreshing it (F5) produces the expected result, ie, we can see the private area instead of getting the default main page (yep, no logging out or window close, just a simple refresh which seems to confirm that the authentication cookie that was generated in the initial log in is ok)

Now, does someone have a logical explanation for what's going on here? I haven't developed any blazor server or signalr app, but I've developed some aspnet core apps (mvc, web api and even blazor wasm), but I don't recall having seen anything on the docs that explains this behavior.

what's the relation between the certificate SAN and aspnet authentication? I really don't think there is, but how can this behavior be explained (ie, authentication cookies seem to be processed only when the server's certificate has the site name on its SAN)? Is this behavior signalr related?

As I've said, we have this setup for traditional asp.net mvc apps and everything works properly. Any ideas on what's going on? any thoughts on how to debug this?

btw, the is being hosted on IIS and I'm under the impression that the client is using polling to communicate with the server side.

Thanks.

So, after going through the app's code, we've managed to see what was going (thanks to dotpeek). In the end, the Blazor server app ended up calling a controller method (hosted on the same site) for getting info about the current logged in user (don't know why the developer didn't simply call one of the identity classes directly instead of wrapping that in a web service call) and that's where things went downhill.

HttpClient was being used for that call and since it performs certificate validation by default during tls calls and the server's certificate had its san set only to the machine name and IP (no site name specified), the call didn't go through and the request processing got "aborted" which ended up returning a 200 ok with the default page instead of the 302 for the private area of the site.