Blazor 服务器和 ASPNET Identity：仅当证书与主题备用名称中的站点具有相同的 DNS 名称时，通过 FW 才有效

Question

我们在现有 Blazor Server Web 应用程序上看到了奇怪的行为，该应用程序使用 ASP.NET Identity 来管理用户（该应用程序不是由我们的开发团队开发的，我们无权访问开发它的团队） 。现在，在讨论我们遇到的问题之前，让我首先尝试恢复我们的生产设置：

• 我们有一个防火墙，它接收我们托管站点的所有请求（例如：xxx.something.com）并将它们重定向到适当的服务器
• 固件配置为执行 SSL 卸载，即它具有用于 https (TLS) 的 widlcard 证书
• FW收到请求后，最终通过其内部IP地址将请求重定向到服务器。此调用通常通过 TLS (https) 完成，并且所有服务器都具有由我们的内部 CA 颁发者生成的证书以及正确设置的主题备用名称（通常，SNA 将至少包含计算机的 DNS 名称及其 IP 地址）。这在我们拥有的所有其他网站上都可以完美运行。例如，对 https://site.something.com 的请求会被重定向到 https://internalIP，并且从浏览器到服务器我们一直使用 HTTPS。

现在的问题是：将此默认设置应用于此 Blazor Server 应用程序后，该应用程序将无法正确处理身份验证 cookie，并且用户最终在登录后被重定向到默认入口页面，而不是被重定向到安全区域该应用程序。在浏览器（开发工具）上，我可以看到生成了身份验证 cookie，但每当用户尝试访问应用程序的安全区域时，都会发送 cookie，但就好像它不存在（或不被视为框架有效吗？）。

现在，这是奇怪的部分：如果我们将仅将 SAN 设置为其主机名和 IP 地址的 Web 服务器上用于 TLS 的内部证书替换为将 SAN 设置为其主机名、子域名（即，正在调用的站点的名称）和 IP 地址，一切正常。

事实上，我们做了以下尝试：

1. 首先使用将 SAN 设置为主机名（例如：DNS=server1）和 IP 地址（例如：IP=10.50.100.200）的默认证书
2. 导航到应用程序并执行登录
3. 身份验证成功，但用户被“重定向”到默认主页
4. 在不关闭浏览器或注销的情况下，将步骤 1 中使用的内部服务器证书替换为将站点作为额外 DNS 值的新证书（例如：DNS=server1;DNS=mysite.something.com）
5. 返回客户端PC上的浏览器并刷新它（F5）会产生预期的结果，即我们可以看到私人区域而不是获得默认的主页（是的，没有注销或窗口关闭，只需简单的刷新这似乎证实了初始登录时生成的身份验证 cookie 是可以的）

现在，有人对这里发生的事情有一个合乎逻辑的解释吗？我还没有开发任何 blazor 服务器或 signalr 应用程序，但我开发了一些 aspnet 核心应用程序（mvc、web api 甚至 blazor wasm），但我不记得在文档中看到过任何解释此行为的内容。

证书SAN和aspnet认证有什么关系？我真的不认为有，但是如何解释这种行为（即，身份验证 cookie 似乎仅当服务器的证书在其 SAN 上具有站点名称时才被处理）？此行为信号器相关吗？

正如我所说，我们为传统的 ASP.NET MVC 应用程序进行了此设置，并且一切正常。对发生的事情有什么想法吗？关于如何调试这个有什么想法吗？

顺便说一句，它托管在 IIS 上，我的印象是客户端正在使用轮询与服务器端进行通信。

谢谢。

Answer 1

因此，在检查了应用程序的代码之后，我们已经成功地了解了发生了什么（感谢 dotpeek）。最后，Blazor 服务器应用程序最终调用一个控制器方法（托管在同一站点上）来获取有关当前登录用户的信息（不知道为什么开发人员不简单地直接调用其中一个身份类）将其包装在 Web 服务调用中），这就是事情开始走下坡路的地方。

HttpClient 用于该调用，并且由于它在 tls 调用期间默认执行证书验证，并且服务器的证书的 san 仅设置为计算机名称和 IP（未指定站点名称），因此调用没有通过，并且请求处理“中止”，最终返回默认页面的 200 ok，而不是网站私有区域的 302。