API 项目

使用 Web API 的项目应：

• 不侦听 HTTP。
• 关闭状态码为 400（错误请求）的连接并且不处理请求。

若要在 API 中禁用 HTTP 重定向，请设置 ASPNETCORE_URLS 环境变量或使用 --urls 命令行标志。 有关详细信息，请参阅 ASP.NET Core 运行时环境 和 Andrew Lock 撰写的 8 种为 ASP.NET Core 应用设置 URL 的方法。

HSTS 和 API 项目

HTTP 严格传输安全（HSTS）协议的安全方法是将 API 项目配置为仅侦听和响应 HTTPS。

HTTP 重定向到 HTTPS（CORS 预检请求中出现 ERR_INVALID_REDIRECT）

当使用 HTTP 向端点发出的请求通过 UseHttpsRedirection 方法被重定向到 HTTPS 时，重定向会因 CORS 预检请求上的 ERR_INVALID_REDIRECT 错误而失败。

API 项目可以直接拒绝 HTTP 请求，而不使用 UseHttpsRedirection 方法将请求重定向到 HTTPS。

需要 HTTPS

对于生产 ASP.NET Core Web 应用，建议使用以下方法：

• 若要将 HTTP 请求重定向到 HTTPS，请使用 HTTPS 重定向中间件（UseHttpsRedirection）。

• 若要将 HSTS 标头发送到客户端，请通过 UseHsts 方法使用 HSTS 中间件。

HTTPS 重定向中间件 （UseHttpsRedirection）

以下代码在 Program.cs 文件中调用 UseHttpsRedirection 方法：

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

上述突出显示的代码：

• 使用默认的 HttpsRedirectionOptions.RedirectStatusCode 属性，并与 Status307TemporaryRedirect 代码一起使用。
• 除非被 ASPNETCORE_HTTPS_PORT 环境变量或 IServerAddressesFeature 替代，否则使用默认 HttpsRedirectionOptions.HttpsPort 属性（传递 null）。

建议的方法是使用临时重定向，而不是永久重定向。 链接缓存会导致开发环境中的行为不稳定。 如果希望在应用处于非Development 环境中时发送永久重定向状态代码，请参阅“ 在生产部分中配置永久重定向 ”。 使用 HSTS 向客户端发出信号，即只应将安全资源请求发送到应用（仅在生产环境中）。

端口配置

中间件必须有可用的端口才能将不安全的请求重定向到 HTTPS。 如果没有可用的端口：

• 不会重定向到 HTTPS。
• 中间件记录警告 无法确定重定向的 https 端口。

使用以下任一方法指定 HTTPS 端口：

• 设置 HttpsRedirectionOptions.HttpsPort。

• 设置 https_port主机设置：

  • 在主机配置中。

  • 通过设置 ASPNETCORE_HTTPS_PORT 环境变量。

  • 通过在 appsettings.json 文件中添加顶级条目：

    {
      "https_port": 443,
      "Logging": {
        "LogLevel": {
          "Default": "Information",
          "Microsoft.AspNetCore": "Warning"
        }
      },
      "AllowedHosts": "*"
    }
    

• 使用 ASPNETCORE_URLS环境变量指示具有安全方案的端口。 该环境变量配置服务器。 中间件通过 IServerAddressesFeature 间接发现 HTTPS 端口。 此方法在反向代理部署中不起作用。

• ASP.NET Core Web 模板在 Properties/launchsettings.json 文件中为 Kestrel 和 IIS Express 设置 HTTPS URL。 本地计算机上仅使用 launchsettings.json 文件。

• 为 Kestrel 服务器或 HTTP.sys 服务器的面向公众的边缘部署配置 HTTPS URL 终结点。 该应用仅使用一个 HTTPS 端口。 中间件通过 IServerAddressesFeature 发现该端口。

边缘部署

当 Kestrel 或 HTTP.sys 用作面向公众的边缘服务器时，必须将 Kestrel 或 HTTP.sys 配置为对这两者进行侦听：

• 重定向客户端的安全端口（通常在生产环境中为 443，在开发环境中为 5001）。
• 不安全的端口（通常在生产环境中为 80，在开发环境中为 5000）。

客户端必须可访问不安全端口，以便应用接收不安全的请求并将客户端重定向到安全端口。

有关详细信息，请参阅 Kestrel终结点配置或 ASP.NET Core 中的 HTTP.sys Web 服务器实现。

部署方案

客户端和服务器之间的任何防火墙还必须打开通信端口供流量使用。

如果请求是在反向代理配置中转发的，请在调用 HTTPS 重定向中间件之前使用 转发头中间件。 转发标头中间件使用 X-Forwarded-Proto 标头更新 Request.Scheme。 使用该中间件，重定向 URI 和其他安全策略可以正常工作。 如果未使用转发标头中间件，后端应用可能无法接收到正确的请求协议，并陷入重定向循环。 常见的最终用户错误消息是重定向过多。

部署到 Azure 应用服务 时，请遵循 在 Azure 应用服务 中为自定义域启用 HTTPS 中的指导。

选项

以下突出显示的代码调用 AddHttpsRedirection 方法来配置中间件选项：

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddHsts(options =>
{
    options.Preload = true;
    options.IncludeSubDomains = true;
    options.MaxAge = TimeSpan.FromDays(60);
    options.ExcludedHosts.Add("example.com");
    options.ExcludedHosts.Add("www.example.com");
});

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = Status307TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

只有需要修改 HttpsPort 或 RedirectStatusCode 时，才需要调用 AddHttpsRedirection。

上述突出显示的代码：

• 将 HttpsRedirectionOptions.RedirectStatusCode 属性设置为 Status307TemporaryRedirect 代码，即默认值。 使用 StatusCodes 类的字段进行 RedirectStatusCode 的分配。
• 将 HTTPS 端口设置为 5001。

在生产环境中配置永久性重定向

中间件默认会为所有重定向发送 Status307TemporaryRedirect 代码。 如果希望在应用处于非 Development 开发环境时发送永久性重定向状态代码，请将中间件选项配置包装在非 Development 开发环境的条件检查中。

以下代码显示 Program.cs 文件中服务的配置：

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

if (!builder.Environment.IsDevelopment())
{
    builder.Services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = Status308PermanentRedirect;
        options.HttpsPort = 443;
    });
}

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");

    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

HTTPS 重定向中间件替代方法

除了使用 HTTPS 重定向中间件（通过 UseHttpsRedirection 方法）外，还可以使用 URL 重写中间件（通过 AddRedirectToHttps 方法）。
AddRedirectToHttps 还可以设置执行重定向时的状态码和端口。 有关详细信息，请参阅 URL 重写中间件。

当应用重定向到 HTTPS 而不要求其他重定向规则时，建议使用 HTTPS 重定向中间件（UseHttpsRedirection如本文所述）。

HTTP 严格传输安全性 （HSTS） 协议

根据 OWASP，HSTS 是一种由 Web 应用程序通过响应标头声明的可选启用的安全增强机制。 当支持 HSTS 的浏览器收到此标头时：

• 该浏览器会存储防止通过 HTTP 发送任何通信的域配置。 该浏览器会强制通过 HTTPS 进行所有通信。
• 该浏览器会阻止用户使用不受信任或无效的证书。 该浏览器会禁用允许用户暂时信任此类证书的提示。

由于客户端强制实施 HSTS，因此存在一些限制：

• 客户端必须支持 HSTS。
• HSTS 需要至少一个成功的 HTTPS 请求才能建立 HSTS 策略。
• 应用程序必须检查每个 HTTP 请求，并重定向或拒绝 HTTP 请求。

ASP.NET Core 使用 UseHsts 扩展方法实现 HSTS。以下代码会在应用不处于开发环境时调用 UseHsts：

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

不建议在开发环境中使用 UseHsts，因为 HSTS 设置对浏览器而言是高度可缓存的。 默认情况下，UseHsts 不包括本地环回地址。

首次在生产环境中启用 HTTPS 时，应使用 TimeSpan 的方法，将 HstsOptions.MaxAge 的初始值设为较短的时间，从数小时到最多一天，以便必要时将 HTTPS 基础结构恢复为 HTTP。确认 HTTPS 配置能够持续稳定运行后，再增大 HSTS 的 max-age 值，通常设为一年。

以下突出显示的代码：

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddHsts(options =>
{
    options.Preload = true;
    options.IncludeSubDomains = true;
    options.MaxAge = TimeSpan.FromDays(60);
    options.ExcludedHosts.Add("example.com");
    options.ExcludedHosts.Add("www.example.com");
});

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = Status307TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

• 设置 Strict-Transport-Security 标头的预加载参数。 预加载不是 RFC 6797 HSTS 规范的一部分。 Web 浏览器支持在全新安装时预加载 HSTS 站点。 有关详细信息，请参阅 https://hstspreload.org/。
• 启用 includeSubDomain 指令，该指令会将 HSTS 策略应用于主机的子域名。 有关详细信息，请参阅 RFC 6797 HSTS 规范（第 6.1.2 节）。
• 将 max-age 标头的 Strict-Transport-Security 参数显式设置为 60 天。 如果未设置，则默认为 30 天。 有关详细信息，请参阅 max-ageRFC 6797 HSTS 规范中的指令（第 6.1.1 节）。
• 将 example.com 添加到要排除的主机列表中。

UseHsts 不包括以下环回主机：

• localhost：IPv4环回地址。
• 127.0.0.1：IPv4环回地址。
• [::1]：IPv6 环回地址。

在创建项目时选择不启用 HTTPS/HSTS

在某些后端服务方案中，在网络面向公众的边缘处理连接安全性时，不需要在每个节点上配置连接安全性。 从 Visual Studio 中的模板或 dotnet new 命令生成的 Web 应用启用 HTTPS 重定向和 HSTS。 对于不需要这些方案的部署，可以在从模板创建应用时选择退出 HTTPS/HSTS。

若要退出 HTTPS/HSTS：

dotnet new webapp --no-https

信任 ASP.NET Core HTTPS 开发证书

.NET SDK 包括 HTTPS 开发证书。 该证书是作为首次运行体验的一部分安装的。 例如，该 dotnet --info 命令生成以下输出的变体：

ASP.NET Core
------------
Successfully installed the ASP.NET Core HTTPS Development Certificate.
To trust the certificate run 'dotnet dev-certs https --trust' (Windows and macOS only).
For establishing trust on other platforms refer to the platform specific documentation.
For more information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054.

安装 .NET SDK 会将 ASP.NET Core HTTPS 开发证书安装到本地用户证书存储。 证书已安装，但不受信任。 要信任该证书，请执行一次性步骤来运行 dotnet dev-certs 工具：

dotnet dev-certs https --trust

下面的命令提供有关 dotnet dev-certs 工具的帮助：

dotnet dev-certs https --help

为 Docker 设置开发证书

若要为 Docker 配置开发证书，请参阅 GitHub dotnet/aspnetcore.docs issue #6199 – 如何在开发中使用 Docker 时设置开发证书。

Linux 专用注意事项

Linux 发行版在将证书标记为受信任的方式上存在很大差异。

该工具 dotnet dev-certs 有望广泛适用，但官方支持仅适用于 Ubuntu 和 Fedora。 支持专门旨在确保对基于 Firefox 和 Chromium 的浏览器（Microsoft Edge、Chrome 和 Chromium）的信任。

依赖项

• 若要建立 OpenSSL 信任，该 openssl 工具必须位于路径上。
• 若要建立浏览器信任（例如在 Microsoft Edge 或 Firefox 中），certutil 工具必须位于路径上。

OpenSSL 信任

当信任 ASP.NET Core开发证书时，证书将导出到当前用户的主目录中的文件夹。 若要让 OpenSSL（和使用它的客户端）选取此文件夹，需要设置 SSL_CERT_DIR 环境变量。 你可以在单个会话中通过运行类似 export SSL_CERT_DIR=$HOME/.aspnet/dev-certs/trust:/usr/lib/ssl/certs 的命令来设置该变量（传递 --verbose 时，确切值会显示在输出中），或者将其添加到你的（因发行版和 shell 而异的）配置文件中（例如 .profile）。

要让 curl 等工具信任开发证书，需要采用上述方法。也可以在每次调用 curl 时使用 --cacert 或 --capath 指定证书文件或目录。参数校正：原文此处写作 -CAfile、-CApath；curl 官方参数为 --cacert、--capath。

如果 OpenSSL 信任进入错误状态（例如，如果 dotnet dev-certs https --clean 无法删除它），则可以使用 c_rehash 工具经常解决这种情况。

覆盖默认配置

如果使用另一个浏览器及其自己的网络安全服务（NSS）存储区，则可以使用 DOTNET_DEV_CERTS_NSSDB_PATHS 环境变量来指定 NSS 目录的冒号分隔列表（例如包含 cert9.db的目录）。 然后，可以将开发证书位置添加到变量中的列表中。

如果将希望 OpenSSL 信任的证书存储在特定目录中，则可以使用 DOTNET_DEV_CERTS_OPENSSL_CERTIFICATE_DIRECTORY 环境变量来指示证书位置。

使用 sudo

与其他平台上一样，开发证书是针对每个用户单独存储和信任的。

如果以其他用户身份运行dotnet dev-certs（例如使用 sudo），则该特定用户（例如 root）会信任开发证书。

在 Linux 上使用 linux-dev-certs 信任 HTTPS 证书

linux-dev-certs 是一种开源、社区支持的 .NET 全局工具，可快捷地在 Linux 上创建和信任开发证书。 Microsoft 不维护或支持该工具。

以下命令安装该工具并创建受信任的开发证书：

dotnet tool update -g linux-dev-certs
dotnet linux-dev-certs install

有关详细信息或要报告问题，请参阅 linux-dev-certs GitHub 存储库。

信任 SUSE Linux Enterprise Server （SLES） 和 openSUSE 上的证书

dotnet dev-certs https --trust 在 SLES 上不受官方支持。 使用以下步骤导出开发证书，并将其信任在基于 Chromium 的浏览器、Firefox 和命令行工具中。 原文说明，这些步骤已在 SLES 15 SP7 和 openSUSE Leap 15.6 上验证。

安装依赖项

用于 certutil 管理浏览器证书存储的工具由 mozilla-nss-tools 包提供：

sudo zypper install mozilla-nss-tools openssl

导出开发证书

将 ${CertificateDirectory} 替换为源代码存储库外部的目录，例如 $HOME/.aspnet/https：

mkdir -p ${CertificateDirectory}
dotnet dev-certs https -ep ${CertificateDirectory}/aspnetcore.crt --format PEM --no-password

信任基于 Chromium 的浏览器（Microsoft Edge、Chrome、Chromium） 中的证书

certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n aspnetcore -i ${CertificateDirectory}/aspnetcore.crt

如果 $HOME/.pki/nssdb 尚不存在，请先使用 certutil -d sql:$HOME/.pki/nssdb -N --empty-password 创建它。 导入后重启浏览器。

信任 Firefox 中的证书

将 ${UserProfile} 替换为你的 Firefox 配置文件目录的名称（请参见 Firefox 中的 about:profiles）：

certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -A -t "C,," -n aspnetcore -i ${CertificateDirectory}/aspnetcore.crt

信任 curl 和其他 OpenSSL 客户端中的证书

显式传递导出的证书：

curl --cacert ${CertificateDirectory}/aspnetcore.crt https://localhost:5001

或者，指向 SSL_CERT_DIR 包含 OpenSSL 信任中所述证书的目录。

删除开发证书

certutil -d sql:$HOME/.pki/nssdb -D -n aspnetcore
certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -D -n aspnetcore
rm ${CertificateDirectory}/aspnetcore.crt
dotnet dev-certs https --clean

信任 Red Hat Enterprise Linux 上的证书（RHEL）

dotnet dev-certs https --trust RHEL 上不受正式支持。 以下步骤反映了针对 RHEL 包名称改编的 SLES 说明。

安装依赖项

用于 certutil 管理浏览器证书存储的工具由 nss-tools 包提供：

sudo dnf install nss-tools openssl

导出开发证书

将 ${CertificateDirectory} 替换为源代码存储库外部的目录，例如 $HOME/.aspnet/https：

mkdir -p ${CertificateDirectory}
dotnet dev-certs https -ep ${CertificateDirectory}/aspnetcore.crt --format PEM --no-password

信任基于 Chromium 的浏览器（Microsoft Edge、Chrome、Chromium） 中的证书

certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n aspnetcore -i ${CertificateDirectory}/aspnetcore.crt

如果 $HOME/.pki/nssdb 尚不存在，请先使用 certutil -d sql:$HOME/.pki/nssdb -N --empty-password 创建它。 导入后重启浏览器。

信任 Firefox 中的证书

将 ${UserProfile} 替换为你的 Firefox 配置文件目录的名称（请参见 Firefox 中的 about:profiles）：

certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -A -t "C,," -n aspnetcore -i ${CertificateDirectory}/aspnetcore.crt

信任 curl 和其他 OpenSSL 客户端中的证书

显式传递导出的证书：

curl --cacert ${CertificateDirectory}/aspnetcore.crt https://localhost:5001

或者，创建 OpenSSL 哈希证书目录，并将 SSL_CERT_DIR 指向该目录：

mkdir -p ${CertificateDirectory}/certs
cp ${CertificateDirectory}/aspnetcore.crt ${CertificateDirectory}/certs/
openssl rehash ${CertificateDirectory}/certs
export SSL_CERT_DIR=${CertificateDirectory}/certs

删除开发证书

certutil -d sql:$HOME/.pki/nssdb -D -n aspnetcore
certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -D -n aspnetcore
rm ${CertificateDirectory}/aspnetcore.crt
dotnet dev-certs https --clean

排查证书问题（证书不受信任）

有时，当 ASP.NET Core HTTPS 开发证书安装且受信任时，浏览器会警告证书不受信任。 以下部分提供有关解决此问题的帮助。

ASP.NET Core HTTPS 开发证书由 Kestrel 使用。

若要修复 IIS Express 证书，请参阅 Stack Overflow 问题 #20036984/answer #20048613 – 如何还原缺少的 IIS Express SSL 证书？

所有平台 – 证书不受信任

对于所有平台，请尝试通过以下步骤解决不受信任的证书问题：

1. 运行以下命令：

   dotnet dev-certs https --clean
   dotnet dev-certs https --trust
   

2. 关闭任何打开的浏览器实例，并在新的浏览器窗口中打开该应用。

   浏览器缓存存储证书是否受信任。 关闭/打开的过程有助于刷新证书的浏览器缓存设置。

这些 dotnet dev-certs https 命令通常会解决大多数浏览器信任问题。
dotnet dev-certs https --clean如果命令失败，并且浏览器仍然不信任证书，请尝试以下部分中特定于平台的建议。

Docker – 证书不受信任

如果使用 Docker，请尝试通过以下步骤解决此问题：

1. 删除 C:\Users{USER}\AppData\Roaming\ASP.NET\Https 文件夹。

2. 清理解决方案。 删除 bin 和 obj 文件夹。

3. 重启开发工具。 例如，Visual Studio 或 Visual Studio Code。

Windows – 证书不受信任

如果正在使用Windows，请完成以下故障排除步骤：

1. 检查证书存储中的证书。 在两个文件夹中查找具有 localhost 友好名称的 ASP.NET Core HTTPS development certificate 证书：

   • 当前用户 > 个人 > 证书
   • 当前用户 > 受信任的根证书颁发机构 > 证书

2. 从“个人”和“受信任的根证书颁发机构”存储中删除上述 ASP.NET Core HTTPS 开发证书。

   重要

   请勿删除 IIS Express localhost 证书。

3. 运行以下命令：

   dotnet dev-certs https --clean
   dotnet dev-certs https --trust
   

4. 关闭任何打开的浏览器实例，并在新的浏览器窗口中打开该应用。

OS X – 证书不受信任

如果使用的是 OS X，请尝试通过以下步骤解决此问题：

1. 打开 KeyChain 访问，然后选择系统密钥链。

2. 检查是否存在 localhost 证书。

3. 确认证书在图标上显示加号（+）符号，指示证书对所有用户都受信任。

4. 从系统密钥链中删除证书。

5. 运行以下命令：

   dotnet dev-certs https --clean
   dotnet dev-certs https --trust
   

6. 关闭任何打开的浏览器实例，并在新的浏览器窗口中打开该应用。

有关排查 Visual Studio 证书相关问题的更多信息，请参阅GitHub dotnet/aspnetcore 问题 #16892) – 使用 IIS Express 时出现 HTTPS 错误。

Linux – 证书不受信任

如果运行的是 Linux，请按照以下步骤对不受信任的证书进行故障排除：

1. 确认正在调查的证书是计划供 Kestrel 服务器使用的用户 HTTPS 开发证书。

2. 在以下位置检查当前用户默认的 HTTPS 开发人员 Kestrel 证书：

   ls -la ~/.dotnet/corefx/cryptography/x509stores/my
   

   HTTPS 开发人员 Kestrel 证书文件是 SHA1 指纹。 使用 dotnet dev-certs https --clean 命令删除文件时，会根据需要使用不同的指纹重新生成该文件。

3. 运行以下命令验证导出的证书的指纹是否匹配：

   openssl x509 -noout -fingerprint -sha1 -inform pem -in /usr/local/share/ca-certificates/aspnet/https.crt
   

   如果证书指纹不匹配，请调查以下条件：

   • 检查证书是否为旧证书。

   • 检查该证书是否为根用户的已导出开发证书。

     • 如果是，请导出证书。

4. 检查以下文件夹中的根用户证书：

   ls -la /root/.dotnet/corefx/cryptography/x509stores/my
   

将 IIS Express SSL 证书与 Visual Studio 一起使用

若要解决 IIS Express 证书问题，请在Visual Studio安装程序中选择 Repair。 有关详细信息，请参阅 GitHub dotnet/aspnetcore 问题 #16892） – HTTPS 错误，使用 IIS Express。

组策略可防止信任自签名证书

在某些情况下，组策略可以防止自签名证书受信任。 有关更多信息，请参阅 GitHub dotnet/aspnetcore Issue #21173 – 信任 HTTPS 开发证书时出错。

相关内容

• 配置 ASP.NET Core 以使用代理服务器和负载均衡器
• 使用 Nginx 在 Linux 上托管 ASP.NET Core：HTTPS 配置
• 在 IIS 7 或更高版本上设置 SSL
• 为 Kestrel Web 服务器配置终结点
• OWASP HSTS 浏览器支持