Принудительное применение HTTPS в ASP.NET Core

Проекты API

Проекты, использующие веб-API, должны:

• Не использовать HTTP для прослушивания.
• Закройте подключение с кодом состояния 400 (недопустимый запрос) и не обслуживайте запрос.

Чтобы отключить перенаправление HTTP в API, задайте ASPNETCORE_URLS переменную среды или используйте флаг командной --urls строки. Дополнительные сведения см. в средах выполнения ASP.NET Core и 8 способах задания URL-адресов для приложения ASP.NET Core от Эндрю Лока.

Проекты HSTS и API

Безопасный подход к протоколу безопасности транспорта HTTP (HSTS) заключается в настройке проектов API только для прослушивания и реагирования по протоколу HTTPS.

HTTP-перенаправление на HTTPS (ERR_INVALID_REDIRECT в предварительном запросе CORS)

Когда запрос к эндпоинту по HTTP перенаправляется на HTTPS с методом UseHttpsRedirection, перенаправление завершается ошибкой ERR_INVALID_REDIRECT в CORS preflight-запросе.

Проекты API могут отклонять HTTP-запросы, а не использовать UseHttpsRedirection метод для перенаправления запросов на HTTPS.

Требовать HTTPS

Для рабочих ASP.NET Core веб-приложений рекомендуется использовать следующий подход:

• Чтобы перенаправить HTTP-запросы на HTTPS, используйте компонент middleware перенаправления HTTPS (UseHttpsRedirection).

• Чтобы отправлять заголовки HSTS клиентам, используйте ПО промежуточной обработки HSTS через метод UseHsts.

UseHttpsRedirection

Следующий код вызывает UseHttpsRedirection метод в файле Program.cs :

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.
• Использует свойство по умолчанию HttpsRedirectionOptions.HttpsPort (передавая значение null), если только оно не переопределено переменной среды ASPNETCORE_HTTPS_PORT или IServerAddressesFeature.

Рекомендуемый подход — использовать временные перенаправления, а не постоянные перенаправления. Кэширование ссылок может привести к нестабильной работе в средах разработки. Если вы предпочитаете отправлять код состояния постоянного перенаправления, если приложение находится в нерабочей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. Переменная среды настраивает сервер. ПО промежуточного слоя косвенно обнаруживает порт HTTPS через IServerAddressesFeature. Этот подход не работает в развертывании обратного прокси-сервера.

• Веб-шаблоны ASP.NET Core задают URL-адрес HTTPS в файле Properties/launchsettings.json для Kestrel и IIS Express. Файл launchsettings.json используется только на локальном компьютере.

• Настройте конечную точку HTTPS URL для публичного пограничного Kestrel развертывания сервера или сервера HTTP.sys. Приложение использует только один порт HTTPS. ПО промежуточного слоя обнаруживает порт через IServerAddressesFeature.

Пограничные развертывания

Если Kestrel или HTTP.sys используется в качестве общедоступного пограничного сервера, то необходимо настроить Kestrel или HTTP.sys для прослушивания обоих:

• Безопасный порт, в котором клиент перенаправляется (обычно 443 в рабочей среде и 5001 в разработке).
• Небезопасный порт (обычно 80 в производственной среде и 5000 в среде разработки).

Небезопасный порт должен быть доступен клиентом для получения небезопасного запроса и перенаправления клиента на безопасный порт.

Дополнительные сведения см. в разделе Kestrel о конфигурации конечной точки или реализации веб-сервера HTTP.sys в ASP.NET Core.

Сценарии развертывания

Любой брандмауэр между клиентом и сервером также должен иметь порты связи, открытые для трафика.

Если запросы перенаправляются в конфигурации обратного прокси-сервера, используйте ПО промежуточного слоя заголовков пересылки перед вызовом промежуточного ПО для перенаправления HTTPS. ПО промежуточного слоя Forwarded Headers обновляет Request.Scheme, используя заголовок X-Forwarded-Proto. Промежуточное ПО обеспечивает корректную работу URI перенаправления и других политик безопасности. Если ПО промежуточной обработки перенаправленных заголовков не используется, внутреннее приложение может не получить правильную схему запроса и попасть в цикл перенаправлений. Распространённое сообщение об ошибке для конечного пользователя: «Слишком много перенаправлений».

При развертывании в Служба приложений Azure следуйте инструкциям в Enable HTTPS для личного домена в Служба приложений Azure.

Options

В приведённом ниже выделенном коде вызывается метод 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();

Вызов AddHttpsRedirection необходим только для изменения значений HttpsPort или RedirectStatusCode.

Предыдущий выделенный код:

• Задает свойству HttpsRedirectionOptions.RedirectStatusCodeStatus307TemporaryRedirect код, который является значением по умолчанию. Используйте поля 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 Redirection Middleware (UseHttpsRedirection), как описано в этой статье.

Протокол строгой транспортной безопасности HTTP (HSTS)

Согласно OWASP, HSTS — это дополнительный механизм повышения безопасности, задаваемый веб-приложением с помощью заголовка ответа. Когда браузер, поддерживающий HSTS, получает этот заголовок:

• Браузер сохраняет конфигурацию для домена, который предотвращает отправку сообщений по протоколу HTTP. Браузер принудительно выполняет обмен данными по протоколу HTTPS.
• Браузер запрещает пользователю использовать недоверенные или недопустимые сертификаты. Браузер отключает запросы, позволяющие пользователю временно доверять такому сертификату.

Так как клиент применяет HSTS, существуют некоторые ограничения:

• Клиент должен поддерживать HSTS.
• Для установки политики HSTS требуется по крайней мере один успешный HTTPS-запрос.
• Приложение должно проверить каждый HTTP-запрос и перенаправить или отклонить HTTP-запрос.

ASP.NET Core реализует HSTS с помощью UseHsts метода расширения. Следующий код вызывается 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 внедряется впервые, задайте свойству HstsOptions.MaxAge небольшое начальное значение, используя один из методов TimeSpan. Установите значение в диапазоне от нескольких часов до не более чем одного дня, если потребуется откатить инфраструктуру с 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. Веб-браузеры поддерживают предварительную загрузку сайтов 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, включают перенаправление HTTPS и HSTS. Для развертываний, которые не требуют этих сценариев, вы можете отказаться от HTTPS/HSTS при создании приложения из шаблона.

Чтобы отказаться от HTTPS/HSTS, выполните приведенные действия.

dotnet new webapp --no-https

Доверять сертификату разработки ASP.NET Core HTTPS

Пакет SDK для .NET включает сертификат разработки 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.

Установка пакета SDK для .NET устанавливает сертификат разработки 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).

Dependencies

• Чтобы установить доверие OpenSSL, утилита openssl должна быть в пути поиска.
• Чтобы настроить доверие браузера (например, в Microsoft Edge или Firefox), инструмент certutil должен находиться в PATH.

Доверие OpenSSL

Если сертификат разработки ASP.NET Core является доверенным, сертификат экспортируется в папку в домашнем каталоге текущего пользователя. Чтобы OpenSSL (и клиенты, которые его используют) могли работать с этой папкой, необходимо задать переменную среды SSL_CERT_DIR. Вы можете задать переменную в рамках одного сеанса, выполнив команду вида export SSL_CERT_DIR=$HOME/.aspnet/dev-certs/trust:/usr/lib/ssl/certs (точное значение выводится при передаче --verbose), либо добавив её в ваш файл конфигурации, зависящий от дистрибутива и оболочки (например, .profile).

Этот подход необходим, чтобы такие инструменты, как curl, доверяли сертификату разработчика. Кроме того, можно передать -CAfile или -CApath в каждый отдельный curl вызов.

Если хранилище доверенных сертификатов OpenSSL оказывается в некорректном состоянии (например, если dotnet dev-certs https --clean не удается его удалить), эту проблему часто можно решить с помощью средства c_rehash.

Overrides

Если вы используете другой браузер с собственным хранилищем служб безопасности сети (NSS), можно использовать DOTNET_DEV_CERTS_NSSDB_PATHS переменную среды, чтобы указать список каталогов NSS с разделителями двоеточия (например, каталог, содержащий cert9.db). Затем вы можете добавить расположение сертификата разработки в список в переменной.

Если вы храните сертификаты, которые нужно, чтобы OpenSSL доверял определенному каталогу, можно использовать DOTNET_DEV_CERTS_OPENSSL_CERTIFICATE_DIRECTORY переменную среды для указания расположения сертификата.

Использование sudo

Как и на других платформах, сертификаты разработки хранятся и надежны отдельно для каждого пользователя.

Если вы запускаете dotnet dev-certs в качестве другого пользователя (например, с помощью sudo), то этот конкретный пользователь (например root) доверяет сертификату разработки.

Доверять сертификату HTTPS в Linux с помощью инструмента linux-dev-certs

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 Linux)

Если ваша конфигурация включает SUSE Linux Enterprise Server, см. обсуждение GitHub dotnet/aspnetcore.docs #28292 - Доверие к сертификату HTTPS в SLES.

Устранение неполадок с сертификатом (сертификат не доверенный)

Иногда, когда сертификат разработки ASP.NET Core для HTTPS установлен и добавлен в доверенные, браузер предупреждает, что сертификат не является доверенным. В следующих разделах приведена справка по устранению этой проблемы.

Сертификат разработки ASP.NET Core HTTPS используется компонентом Kestrel.

Чтобы восстановить сертификат IIS Express, см. вопрос Stack Overflow №20036984 / ответ №20048613 - Как восстановить отсутствующий SSL-сертификат IIS Express?

Все платформы — сертификат не доверенный

Для всех платформ попробуйте устранить проблемы с недоверенным сертификатом, выполнив следующие действия.

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. Удалите все сертификаты как из раздела «Личное», так и из раздела «Доверенные корневые центры сертификации».

   Important

   Не удаляйте сертификат IIS Express localhost.

3. Выполните следующие команды:

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

4. Закройте все открытые экземпляры браузера и откройте приложение в новом окне браузера.

OS X — сертификат, не доверенный

Если вы работаете с OS X, попробуйте устранить проблему, выполнив следующие действия:

1. Откройте keyChain Access и выберите цепочку ключей системы.

2. Проверьте наличие сертификата localhost.

3. Подтвердите, что сертификат отображает значок плюса (+) на значке, который указывает, что сертификат является доверенным для всех пользователей.

4. Удалите сертификат из цепочки ключей системы.

5. Выполните следующие команды:

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

6. Закройте все открытые экземпляры браузера и откройте приложение в новом окне браузера.

Дополнительные сведения об устранении неполадок с сертификатами в Visual Studio см. в проблеме GitHub dotnet/aspnetcore #16892) - Ошибка HTTPS при использовании IIS Express.

Linux — сертификат не доверенный

Если вы используете Linux, выполните следующие действия, чтобы устранить неполадки с недоверенным сертификатом:

1. Убедитесь, что сертификат, который вы изучаете, — это сертификат разработчика HTTPS, который планируется использовать сервером Kestrel .

2. Проверьте сертификат разработчика Kestrel HTTPS по умолчанию для текущего пользователя в следующем расположении:

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

   Файл сертификата разработчика Kestrel HTTPS — это отпечаток 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
   

SSL-сертификат IIS Express, используемый в Visual Studio

Чтобы устранить проблемы с сертификатом IIS Express, выберите Repair в установщике Visual Studio. Дополнительные сведения см. в проблеме GitHub dotnet/aspnetcore #16892) - Ошибка HTTPS при использовании IIS Express.

Групповая политика запрещает доверять самозаверенным сертификатам

В некоторых случаях групповая политика может препятствовать доверию к самоподписанным сертификатам. Дополнительные сведения см. в GitHub dotnet/aspnetcore issue #21173 - Error trusting HTTPS developer certificate.

Связанный контент

• Настройка ASP.NET Core для работы с прокси-серверами и подсистемами балансировки нагрузки
• Размещение ASP.NET Core на Linux с Nginx: настройка HTTPS
• Настройка SSL в IIS 7 или более поздней версии
• Настройка конечных точек для Kestrel веб-сервера
• Поддержка браузера OWASP HSTS

Перенаправление HTTP на HTTPS вызывает ошибку ERR_INVALID_REDIRECT в предварительном запросе CORS.

Запросы к конечной точке по протоколу HTTP, которые перенаправляются на HTTPS с использованием UseHttpsRedirection, завершаются ошибкой ERR_INVALID_REDIRECT в предварительном запросе CORS.

Проекты API могут отклонять HTTP-запросы, а не использовать UseHttpsRedirection для перенаправления запросов на HTTPS.

Требовать HTTPS

Рекомендуется использовать рабочие веб-приложения ASP.NET Core:

• Промежуточное программное обеспечение для перенаправления HTTPS (UseHttpsRedirection) для перенаправления HTTP-запросов на HTTPS.
• Посредник HSTS (UseHsts) для отправки клиентам заголовков протокола HTTP Strict Transport Security.

UseHttpsRedirection

Следующий код вызывает UseHttpsRedirection в файле Program.cs:

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).
• Использует значение по умолчанию HttpsRedirectionOptions.HttpsPort (null), если не переопределено переменной среды ASPNETCORE_HTTPS_PORT или IServerAddressesFeature.

Рекомендуется использовать временные перенаправления, а не постоянные перенаправления. Кэширование ссылок может привести к нестабильной работе в средах разработки. Если вы предпочитаете отправлять код состояния постоянного перенаправления, если приложение находится в нерабочей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. Переменная среды настраивает сервер. ПО промежуточного слоя косвенно обнаруживает порт HTTPS через IServerAddressesFeature. Этот подход не работает в развертывании обратного прокси-сервера.

• Веб-шаблоны ASP.NET Core настраивают HTTPS URL в Properties/launchsettings.json для Kestrel и IIS Express. launchsettings.json используется только на локальном компьютере.

• Настройте конечную точку HTTPS URL для публичного пограничного Kestrel развертывания сервера или сервера HTTP.sys. Приложение использует только один порт HTTPS. ПО промежуточного слоя обнаруживает порт через IServerAddressesFeature.

Пограничные развертывания

Если Kestrel или HTTP.sys используется в качестве общедоступного пограничного сервера, то необходимо настроить Kestrel или HTTP.sys для прослушивания обоих:

• Безопасный порт, в котором клиент перенаправляется (обычно 443 в рабочей среде и 5001 в разработке).
• Небезопасный порт (обычно 80 в производственной среде и 5000 в среде разработки).

Небезопасный порт должен быть доступен клиентом, чтобы приложение получило небезопасный запрос и перенаправляет клиента на безопасный порт.

Дополнительные сведения см. в разделе Kestrel о конфигурации конечной точки или реализации веб-сервера HTTP.sys в ASP.NET Core.

Сценарии развертывания

Любой брандмауэр между клиентом и сервером также должен иметь порты связи, открытые для трафика.

Если запросы перенаправляются в конфигурации обратного прокси-сервера, используйте ПО промежуточного слоя заголовков пересылки перед вызовом промежуточного ПО для перенаправления HTTPS. Промежуточное программное обеспечение для перенаправленных заголовков обновляет Request.Scheme с помощью заголовка X-Forwarded-Proto. Промежуточное ПО обеспечивает корректную работу URI перенаправления и других политик безопасности. Если промежуточное ПО для перенаправленных заголовков не используется, серверное приложение может не получить правильную схему и в конечном итоге оказаться в цикле перенаправления. Обычное сообщение об ошибке конечного пользователя заключается в том, что произошло слишком много перенаправлений.

При развертывании в службе приложений Azure следуйте инструкциям в руководстве по привязке существующего пользовательского SSL-сертификата к веб-приложениям Azure.

Options

Следующий выделенный вызов кода 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();

Вызов AddHttpsRedirection необходим только для изменения значений HttpsPort или RedirectStatusCode.

Предыдущий выделенный код:

• Задает 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 является использование Промежуточного ПО для переписывания URL-адресов. AddRedirectToHttps также может задать код состояния и порт при выполнении перенаправления. Дополнительные сведения см. в перезаписи URL с помощью промежуточного программного обеспечения.

При перенаправлении на HTTPS без требования к дополнительным правилам перенаправления рекомендуется использовать ПО промежуточного слоя перенаправления HTTPS(UseHttpsRedirection), описанное в этой статье.

Протокол строгой транспортной безопасности HTTP (HSTS)

Согласно OWASP, HTTP Strict Transport Security (HSTS) — это опция безопасности, которая может быть включена веб-приложением с помощью заголовка ответа. Когда браузер, поддерживающий HSTS, получает этот заголовок:

• Браузер сохраняет конфигурацию для домена, который предотвращает отправку сообщений по протоколу HTTP. Браузер принудительно выполняет обмен данными по протоколу HTTPS.
• Браузер запрещает пользователю использовать недоверенные или недопустимые сертификаты. Браузер отключает запросы, позволяющие пользователю временно доверять такому сертификату.

Так как HSTS применяется клиентом, он имеет некоторые ограничения:

• Клиент должен поддерживать HSTS.
• Для установки политики HSTS требуется по крайней мере один успешный HTTPS-запрос.
• Приложение должно проверить каждый HTTP-запрос и перенаправить или отклонить HTTP-запрос.

ASP.NET Core реализует HSTS с помощью UseHsts метода расширения. Следующий код вызывается 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 в первый раз, установите начальное значение HstsOptions.MaxAge на небольшой уровень, используя один из методов TimeSpan. Установите время от нескольких часов до одного дня в случае, если потребуется вернуть инфраструктуру 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 HSTS, но поддерживается веб-браузерами для предварительной загрузки сайтов HSTS на свежей установке. Дополнительные сведения см. в разделе https://hstspreload.org/.
• Включает параметр includeSubDomain, который применяет политику HSTS к поддоменам хоста.
• Явно устанавливает параметр max-age заголовка Strict-Transport-Security на 60 дней. Если значение не задано, значение по умолчанию — 30 дней. Дополнительные сведения см. в директиве max-age.
• Добавляет example.com в список узлов, которые нужно исключить.

UseHsts исключает следующие узлы для обратной связи:

• localhost : IPv4-адрес обратного соединения.
• 127.0.0.1 : IPv4-адрес обратного соединения.
• [::1] : адрес обратной связи IPv6.

Отказ от HTTPS/HSTS при создании проекта

В некоторых сценариях серверной службы, где безопасность подключения обрабатывается на общедоступном крае сети, настройка безопасности подключения на каждом узле не требуется. Веб-приложения, созданные из шаблонов в Visual Studio или с помощью команды dotnet new, включают перенаправление HTTPS и HSTS. Для развертываний, которые не требуют этих сценариев, вы можете отказаться от HTTPS/HSTS при создании приложения из шаблона.

Чтобы отказаться от HTTPS/HSTS, выполните приведенные действия.

dotnet new webapp --no-https

Доверять сертификату разработки ASP.NET Core HTTPS в Windows и macOS

В браузере Firefox см. следующий раздел.

Пакет SDK для .NET Core включает сертификат разработки 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.

При установке пакета SDK для .NET Core в локальное хранилище сертификатов пользователя устанавливается сертификат разработки HTTPS ASP.NET Core. Сертификат установлен, но он не является доверенным. Чтобы доверять сертификату, выполните однократный шаг для запуска dotnet dev-certs средства:

dotnet dev-certs https --trust

Следующая команда отображает справку по инструменту dotnet dev-certs.

dotnet dev-certs https --help

Доверяйте сертификату безопасности HTTPS в Firefox, чтобы предотвратить ошибку SEC_ERROR_INADEQUATE_KEY_USAGE

Браузер Firefox использует собственное хранилище сертификатов, поэтому не доверяет сертификатам IIS Express или Kestrel разработчика.

Существует два подхода к принятию сертификата HTTPS в Firefox: создание файла политики или настройка через браузер Firefox. При настройке с помощью браузера создается файл политики, поэтому два подхода эквивалентны.

Создание файла политики для доверия к сертификату HTTPS с помощью Firefox

Создайте файл политики (policies.jsonпо адресу:

• Виндовс: %PROGRAMFILES%\Mozilla Firefox\distribution\
• Macos: Firefox.app/Contents/Resources/distribution
• Linux: См. Как доверять сертификату в Firefox на Linux в этой статье.

Добавьте следующий код JSON в файл политики Firefox:

{
  "policies": {
    "Certificates": {
      "ImportEnterpriseRoots": true
    }
  }
}

Файл политики заставляет Firefox доверять сертификатам из хранилища доверенных сертификатов Windows. В следующем разделе представлен альтернативный подход к созданию предыдущего файла политики с помощью браузера Firefox.

Настройка доверия сертификата HTTPS с помощью браузера Firefox

Настройте security.enterprise_roots.enabled = true, следуя следующим инструкциям.

1. Введите about:config в браузере FireFox.
2. Нажмите кнопку "Принять риск" и "Продолжить ", если вы принимаете риск.
3. Выберите "Показать все"
4. Задайте значение security.enterprise_roots.enabled = true.
5. Выход и перезапуск Firefox

Дополнительные сведения см. в разделе "Настройка центров сертификации" в Firefox и mozilla/policy-templates/README-файле.

Настройка сертификата разработчика для Docker

Также см. эту проблему в GitHub.

Доверять сертификату HTTPS в Linux

Установка доверия зависит от конкретного дистрибутива и браузера. В следующих разделах приведены инструкции для некоторых популярных дистрибутивов и браузеров Chromium (Edge и Chrome) и Firefox.

Ubuntu доверяет сертификату для обмена данными между службами

Следующие инструкции не работают для некоторых версий Ubuntu, таких как 20.04. Дополнительные сведения см. в статье о проблеме GitHub dotnet/AspNetCore.Docs #23686.

1. Установите OpenSSL 1.1.1h или более поздней версии. Инструкции по обновлению OpenSSL см. в дистрибутиве.

2. Выполните следующие команды:

   dotnet dev-certs https
   sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM
   sudo update-ca-certificates
   

Предыдущие команды:

• Убедитесь, что создается сертификат разработчика текущего пользователя.
• Экспортирует сертификат с повышенными разрешениями, необходимыми для ca-certificates папки, с помощью среды текущего пользователя.
• Удаление -E флага экспортирует корневой сертификат пользователя, создав его при необходимости. Каждый созданный сертификат имеет другой отпечаток. При запуске от имени пользователя root sudo и -E не требуются.

Путь в предыдущей команде предназначен для Ubuntu. Для других дистрибутивов выберите соответствующий путь или используйте путь для центров сертификации (ЦС).

Доверие к сертификату HTTPS в Linux с помощью Edge или Chrome

cat <<EOF | sudo tee /usr/lib/firefox/distribution/policies.json
{
    "policies": {
        "Certificates": {
            "Install": [
                "/usr/local/share/ca-certificates/aspnet/https.crt"
            ]
        }
    }
}
EOF

dnf install nss-tools

cd ${ProjectDirectory}
dotnet dev-certs https -ep ${ProjectDirectory}/${CertificateName}.crt --format PEM

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

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

alias curl="curl --cacert ${ProjectDirectory}/${CertificateName}.crt"

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

Доверять сертификату с помощью Fedora 34

See:

• Комментарий GitHub
• Fedora: использование общих системных сертификатов
• Настройте среду разработки .NET в Fedora.

Доверяйте сертификату в других дистрибутивах

Также см. эту проблему в GitHub.

Доверять сертификату HTTPS из подсистема Windows для Linux

Следующие инструкции не работают для некоторых дистрибутивов Linux, таких как Ubuntu 20.04. Дополнительные сведения см. в статье о проблеме GitHub dotnet/AspNetCore.Docs #23686.

Подсистема Windows для Linux (WSL) создает самозаверяющий сертификат разработки HTTPS, который по умолчанию не является доверенным в Windows. Самый простой способ доверия Windows к сертификату WSL — настроить WSL для использования того же сертификата, что и Windows:

• В Windows экспортируйте сертификат разработчика в файл:

  dotnet dev-certs https -ep https.pfx -p $CREDENTIAL_PLACEHOLDER$ --trust
  

  Где $CREDENTIAL_PLACEHOLDER$ находится пароль.

• В окне WSL импортируйте экспортированный сертификат в экземпляр WSL.

  dotnet dev-certs https --clean --import <<path-to-pfx>> --password $CREDENTIAL_PLACEHOLDER$
  

Описанный подход — это однократная операция для каждого сертификата и каждой WSL-дистрибуции. Проще, чем экспортировать сертификат снова и снова. Если вы обновляете или повторно создаете сертификат в Windows, вам может потребоваться снова выполнить приведенные выше команды.

Устранение неполадок с сертификатами, таких как ненадежный сертификат

В этом разделе содержатся сведения о том, что сертификат разработки ASP.NET Core HTTPS установлен и доверен, но у вас по-прежнему есть предупреждения браузера о том, что сертификат не является доверенным. Сертификат разработки ASP.NET Core HTTPS используется компонентом Kestrel.

Чтобы восстановить сертификат IIS Express, ознакомьтесь с этой проблемой Stackoverflow .

Все платформы — сертификат не доверенный

Выполните следующие команды:

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

Закройте все открытые экземпляры браузера. Откройте новое окно браузера для приложения. Доверие сертификатов кэшируется браузерами.

dotnet dev-certs https --clean Сбой

Приведенные выше команды решают большинство проблем доверия браузера. Если браузер по-прежнему не доверяет сертификату, следуйте приведенным ниже предложениям для конкретной платформы.

Docker — сертификат не доверенный

• Удалите папку C:\Users{USER}\AppData\Roaming\ASP.NET\Https .
• Очистите решение. Удалите папки bin и obj.
• Перезапустите средство разработки. Например, Visual Studio или Visual Studio Code.

Windows — сертификат не доверенный

• Проверьте сертификаты в хранилище сертификатов. Должен быть localhost сертификат с удобочитаемым именем ASP.NET Core HTTPS development certificate как под Current User > Personal > Certificates, так и под Current User > Trusted root certification authorities > Certificates
• Удалите все найденные сертификаты как из личных, так и доверенных корневых удостоверяющих центров. Не удаляйте сертификат IIS Express localhost.
• Выполните следующие команды:

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

Закройте все открытые экземпляры браузера. Откройте новое окно браузера для приложения.

OS X — сертификат, не доверенный

• Откройте доступ к цепочке ключей.
• Выберите цепочку ключей системы.
• Проверьте наличие сертификата localhost.
• Убедитесь, что он содержит + символ на значке, чтобы указать, что он является доверенным для всех пользователей.
• Удалите сертификат из цепочки ключей системы.
• Выполните следующие команды:

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

Закройте все открытые экземпляры браузера. Откройте новое окно браузера для приложения.

Сведения об устранении неполадок с сертификатами в Visual Studio см. в статье об ошибке HTTPS с помощью IIS Express (dotnet/AspNetCore #16892).

Сертификат Linux не является доверенным

Убедитесь, что сертификат, настроенный для доверия, является сертификатом разработчика HTTPS, который будет использоваться сервером Kestrel .

Проверьте сертификат разработчика Kestrel HTTPS по умолчанию для текущего пользователя в следующем расположении:

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

Файл сертификата разработчика Kestrel HTTPS — это отпечаток SHA1. Когда файл удаляется с помощью dotnet dev-certs https --clean, он воссоздается по мере необходимости с другим отпечатком. Проверьте, совпадает ли отпечаток экспортированного сертификата с помощью следующей команды:

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

Если сертификат не соответствует, он может быть одним из следующих вариантов:

• Старый сертификат.
• Экспортирован сертификат разработчика для корневого пользователя. В этом случае экспортируйте сертификат.

Сертификат корневого пользователя можно проверить по адресу:

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

SSL-сертификат IIS Express, используемый в Visual Studio

Чтобы устранить проблемы с сертификатом IIS Express, выберите "Восстановить " в установщике Visual Studio. Дополнительные сведения см. здесь на GitHub.

Групповая политика не позволяет доверять самозаверенным сертификатам.

В некоторых случаях групповая политика может предотвратить доверие самозаверяемых сертификатов. Дополнительные сведения см. здесь на GitHub.

Дополнительные сведения

• Настройка ASP.NET Core для работы с прокси-серверами и подсистемами балансировки нагрузки
• Размещение ASP.NET Core на Linux с Nginx: настройка HTTPS
• Настройка SSL на IIS
• Настройка конечных точек для Kestrel веб-сервера
• Поддержка браузера OWASP HSTS

Требовать HTTPS

Рекомендуется использовать рабочие веб-приложения ASP.NET Core:

• Промежуточное программное обеспечение для перенаправления HTTPS (UseHttpsRedirection) для перенаправления HTTP-запросов на HTTPS.
• Посредник HSTS (UseHsts) для отправки клиентам заголовков протокола HTTP Strict Transport Security.

UseHttpsRedirection

В следующем коде выполняется вызов UseHttpsRedirection в классе Startup.

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    else
    {
        app.UseExceptionHandler("/Error");
        // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
        app.UseHsts();
    }

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

    app.UseRouting();

    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapRazorPages();
    });
}

Предыдущий выделенный код:

• Использует значение по умолчанию HttpsRedirectionOptions.RedirectStatusCode (Status307TemporaryRedirect).
• Использует значение по умолчанию HttpsRedirectionOptions.HttpsPort (null), если не переопределено переменной среды ASPNETCORE_HTTPS_PORT или IServerAddressesFeature.

Рекомендуется использовать временные перенаправления, а не постоянные перенаправления. Кэширование ссылок может привести к нестабильной работе в средах разработки. Если вы предпочитаете отправлять код состояния постоянного перенаправления, если приложение находится в нерабочейDevelopment среде, см. раздел «Настройка постоянных перенаправлений в рабочей среде». Мы рекомендуем использовать HSTS для сигнала клиентам о том, что в приложение должны отправляться только безопасные запросы ресурсов (только в рабочей среде).

Конфигурация порта

Порт должен быть доступен для промежуточного слоя для перенаправления небезопасного запроса на HTTPS. Если порт недоступен:

• Перенаправление на HTTPS не происходит.
• ПО промежуточного слоя записывает предупреждение "Не удалось определить порт https для перенаправления".

Укажите порт HTTPS с помощью любого из следующих подходов:

• Задайте HttpsRedirectionOptions.HttpsPort.

• https_port Задайте настройку узла:

  • В конфигурации узла.

  • Настроив переменную среды ASPNETCORE_HTTPS_PORT.

  • Добавив запись верхнего уровня в appsettings.json:

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

• Укажите порт с безопасной схемой с помощью переменной среды ASPNETCORE_URLS. Переменная среды настраивает сервер. ПО промежуточного слоя косвенно обнаруживает порт HTTPS через IServerAddressesFeature. Этот подход не работает в развертывании обратного прокси-сервера.

• В разработке задайте URL-адрес HTTPS в launchsettings.json. Включите ПРОТОКОЛ HTTPS при использовании IIS Express.

• Настройте конечную точку HTTPS URL для публичного пограничного Kestrel развертывания сервера или сервера HTTP.sys. Приложение использует только один порт HTTPS. ПО промежуточного слоя обнаруживает порт через IServerAddressesFeature.

Пограничные развертывания

Когда используется Kestrel или HTTP.sys в качестве сервера на внешнем контуре, Kestrel или HTTP.sys необходимо настроить для прослушивания обоих параметров:

• Безопасный порт, в котором клиент перенаправляется (обычно 443 в рабочей среде и 5001 в разработке).
• Небезопасный порт (обычно 80 в производственной среде и 5000 в среде разработки).

Небезопасный порт должен быть доступен клиентом, чтобы приложение получило небезопасный запрос и перенаправляет клиента на безопасный порт.

Дополнительные сведения см. в разделе Kestrel о конфигурации конечной точки или реализации веб-сервера HTTP.sys в ASP.NET Core.

Сценарии развертывания

Любой брандмауэр между клиентом и сервером также должен иметь порты связи, открытые для трафика.

Если запросы перенаправляются в конфигурации обратного прокси-сервера, используйте ПО промежуточного слоя заголовков пересылки перед вызовом промежуточного ПО для перенаправления HTTPS. Промежуточное программное обеспечение для перенаправленных заголовков обновляет Request.Scheme с помощью заголовка X-Forwarded-Proto. Промежуточное ПО обеспечивает корректную работу URI перенаправления и других политик безопасности. Если промежуточное ПО для перенаправленных заголовков не используется, серверное приложение может не получить правильную схему и в конечном итоге оказаться в цикле перенаправления. Обычное сообщение об ошибке конечного пользователя заключается в том, что произошло слишком много перенаправлений.

При развертывании в службе приложений Azure следуйте инструкциям в руководстве по привязке существующего пользовательского SSL-сертификата к веб-приложениям Azure.

Options

Следующий выделенный вызов кода AddHttpsRedirection для настройки параметров посреднического ПО:

public void ConfigureServices(IServiceCollection services)
{
    services.AddRazorPages();

    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");
    });

    services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = (int) HttpStatusCode.TemporaryRedirect;
        options.HttpsPort = 5001;
    });
}

Вызов AddHttpsRedirection необходим только для изменения значений HttpsPort или RedirectStatusCode.

Предыдущий выделенный код:

• Задает HttpsRedirectionOptions.RedirectStatusCode равным Status307TemporaryRedirect, который является значением по умолчанию. Используйте поля StatusCodes класса для назначений к RedirectStatusCode.
• Задает для порта HTTPS значение 5001.

Настройка постоянных перенаправлений в рабочей среде

По умолчанию промежуточное ПО отправляет Status307TemporaryRedirect при всех перенаправлениях. Если вы предпочитаете отправлять код состояния постоянного перенаправления, когда приложение находится в среде, отличной от Development, оберните настройку параметров промежуточного программного обеспечения в условную проверку на среду, отличную от Development.

При настройке служб в Startup.cs:

public void ConfigureServices(IServiceCollection services)
{
    // IWebHostEnvironment (stored in _env) is injected into the Startup class.
    if (!_env.IsDevelopment())
    {
        services.AddHttpsRedirection(options =>
        {
            options.RedirectStatusCode = (int) HttpStatusCode.PermanentRedirect;
            options.HttpsPort = 443;
        });
    }
}

Альтернативный подход к перенаправлению HTTPS с использованием промежуточного программного обеспечения.

Альтернативой использованию Промежуточного ПО для перенаправления HTTPS является использование Промежуточного ПО для переписывания URL-адресов. AddRedirectToHttps также может задать код состояния и порт при выполнении перенаправления. Дополнительные сведения см. в перезаписи URL с помощью промежуточного программного обеспечения.

При перенаправлении на HTTPS без требования к дополнительным правилам перенаправления рекомендуется использовать ПО промежуточного слоя перенаправления HTTPS(UseHttpsRedirection), описанное в этой статье.

Протокол строгой транспортной безопасности HTTP (HSTS)

Согласно OWASP, HTTP Strict Transport Security (HSTS) — это опция безопасности, которая может быть включена веб-приложением с помощью заголовка ответа. Когда браузер, поддерживающий HSTS, получает этот заголовок:

• Браузер сохраняет конфигурацию для домена, который предотвращает отправку сообщений по протоколу HTTP. Браузер принудительно выполняет обмен данными по протоколу HTTPS.
• Браузер запрещает пользователю использовать недоверенные или недопустимые сертификаты. Браузер отключает запросы, позволяющие пользователю временно доверять такому сертификату.

Так как HSTS применяется клиентом, он имеет некоторые ограничения:

• Клиент должен поддерживать HSTS.
• Для установки политики HSTS требуется по крайней мере один успешный HTTPS-запрос.
• Приложение должно проверить каждый HTTP-запрос и перенаправить или отклонить HTTP-запрос.

ASP.NET Core реализует HSTS с помощью UseHsts метода расширения. Следующий код вызывается UseHsts, когда приложение не в режиме разработки:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    else
    {
        app.UseExceptionHandler("/Error");
        // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
        app.UseHsts();
    }

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

    app.UseRouting();

    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapRazorPages();
    });
}

UseHsts не рекомендуется на этапе разработки, так как параметры HSTS сильно кэшируются браузерами. По умолчанию UseHsts исключает локальный адрес обратной связи.

Для рабочих сред, реализующих протокол HTTPS в первый раз, установите начальное значение HstsOptions.MaxAge на небольшой уровень, используя один из методов TimeSpan. Установите время от нескольких часов до одного дня в случае, если потребуется вернуть инфраструктуру HTTPS на HTTP. После того как вы уверены в устойчивости конфигурации HTTPS, увеличьте значение HSTS max-age ; обычно используемое значение составляет один год.

Следующий код:

public void ConfigureServices(IServiceCollection services)
{
    services.AddRazorPages();

    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");
    });

    services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = (int) HttpStatusCode.TemporaryRedirect;
        options.HttpsPort = 5001;
    });
}

• Задает параметр предварительной загрузки заголовка Strict-Transport-Security . Предварительная загрузка не является частью спецификации RFC HSTS, но поддерживается веб-браузерами для предварительной загрузки сайтов HSTS на свежей установке. Дополнительные сведения см. в разделе https://hstspreload.org/.
• Включает параметр includeSubDomain, который применяет политику HSTS к поддоменам хоста.
• Явно устанавливает параметр max-age заголовка Strict-Transport-Security на 60 дней. Если значение не задано, значение по умолчанию — 30 дней. Дополнительные сведения см. в директиве max-age.
• Добавляет example.com в список узлов, которые нужно исключить.

UseHsts исключает следующие узлы для обратной связи:

• localhost : IPv4-адрес обратного соединения.
• 127.0.0.1 : IPv4-адрес обратного соединения.
• [::1] : адрес обратной связи IPv6.

Отказ от HTTPS/HSTS при создании проекта

В некоторых сценариях серверной службы, где безопасность подключения обрабатывается на общедоступном крае сети, настройка безопасности подключения на каждом узле не требуется. Веб-приложения, созданные из шаблонов в Visual Studio или с помощью команды dotnet new, включают перенаправление HTTPS и HSTS. Для развертываний, которые не требуют этих сценариев, вы можете отказаться от HTTPS/HSTS при создании приложения из шаблона.

Чтобы отказаться от HTTPS/HSTS, выполните приведенные действия.

dotnet new webapp --no-https

Доверять сертификату разработки ASP.NET Core HTTPS в Windows и macOS

В браузере Firefox см. следующий раздел.

Пакет SDK для .NET Core включает сертификат разработки HTTPS. Сертификат устанавливается при первом использовании. Например, при первом запуске dotnet new webapp создается вариант следующих выходных данных:

Installed an ASP.NET Core HTTPS development certificate.
To trust the certificate, run 'dotnet dev-certs https --trust'
Learn about HTTPS: https://aka.ms/dotnet-https

При установке пакета SDK для .NET Core в локальное хранилище сертификатов пользователя устанавливается сертификат разработки HTTPS ASP.NET Core. Сертификат установлен, но он не является доверенным. Чтобы доверять сертификату, выполните однократный шаг для запуска dotnet dev-certs средства:

dotnet dev-certs https --trust

Следующая команда отображает справку по инструменту dotnet dev-certs.

dotnet dev-certs https --help

Доверяйте сертификату безопасности HTTPS в Firefox, чтобы предотвратить ошибку SEC_ERROR_INADEQUATE_KEY_USAGE

Браузер Firefox использует собственное хранилище сертификатов, поэтому не доверяет сертификатам IIS Express или Kestrel разработчика.

Существует два подхода к принятию сертификата HTTPS в Firefox: создание файла политики или настройка через браузер Firefox. При настройке с помощью браузера создается файл политики, поэтому два подхода эквивалентны.

Создание файла политики для доверия к сертификату HTTPS с помощью Firefox

Создайте файл политики (policies.jsonпо адресу:

• Виндовс: %PROGRAMFILES%\Mozilla Firefox\distribution\
• Macos: Firefox.app/Contents/Resources/distribution
• Linux: См. раздел доверие сертификату в браузере Firefox на Linux далее в этой статье.

Добавьте следующий код JSON в файл политики Firefox:

{
  "policies": {
    "Certificates": {
      "ImportEnterpriseRoots": true
    }
  }
}

Файл политики заставляет Firefox доверять сертификатам из хранилища доверенных сертификатов Windows. В следующем разделе представлен альтернативный подход к созданию предыдущего файла политики с помощью браузера Firefox.

Настройка доверия сертификата HTTPS с помощью браузера Firefox

Настройте security.enterprise_roots.enabled = true, следуя следующим инструкциям.

1. Введите about:config в браузере FireFox.
2. Нажмите кнопку "Принять риск" и "Продолжить ", если вы принимаете риск.
3. Выберите "Показать все".
4. Задайте security.enterprise_roots.enabled = true.
5. Выход и перезапуск Firefox.

Дополнительные сведения см. в разделе "Настройка центров сертификации" в Firefox и mozilla/policy-templates/README-файле.

Настройка сертификата разработчика для Docker

Также см. эту проблему в GitHub.

Доверять сертификату HTTPS в Linux

Установка доверия зависит от конкретного дистрибутива и браузера. В следующих разделах приведены инструкции для некоторых популярных дистрибутивов и браузеров Chromium (Edge и Chrome) и Firefox.

Ubuntu доверяет сертификату для обмена данными между службами

1. Установите OpenSSL 1.1.1h или более поздней версии. Инструкции по обновлению OpenSSL см. в дистрибутиве.

2. Выполните следующие команды:

   dotnet dev-certs https
   sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM
   sudo update-ca-certificates
   

Предыдущие команды:

• Убедитесь, что создается сертификат разработчика текущего пользователя.
• Экспортируйте сертификат с повышенными правами, необходимыми для ca-certificates папки, с помощью среды текущего пользователя.
• -E Удалите флаг для экспорта корневого сертификата пользователя, создав его при необходимости. Каждый созданный сертификат имеет другой отпечаток. При запуске от имени пользователя root sudo и -E не требуются.

Путь в предыдущей команде предназначен для Ubuntu. Для других дистрибутивов выберите соответствующий путь или используйте путь для центров сертификации (ЦС).

Доверие к сертификату HTTPS в Linux с помощью Edge или Chrome

Для браузеров chromium в Linux:

• Установите libnss3-tools для вашей дистрибуции.

• Создайте или убедитесь, что папка $HOME/.pki/nssdb существует на компьютере.

• Экспортируйте сертификат со следующей командой:

  dotnet dev-certs https
  sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM
  

  Путь в предыдущей команде предназначен для Ubuntu. Для других дистрибутивов выберите соответствующий путь или используйте путь для центров сертификации (ЦС).

• Выполните следующие команды:

  certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n localhost -i /usr/local/share/ca-certificates/aspnet/https.crt
  

• Закройте и перезапустите браузер.

Доверие к сертификату с помощью Firefox в Linux

• Экспортируйте сертификат со следующей командой:

  dotnet dev-certs https
  sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM
  

  Путь в предыдущей команде предназначен для Ubuntu. Для других дистрибутивов выберите соответствующий путь или используйте путь для центров сертификации (ЦС).

• Создайте JSON-файл /usr/lib/firefox/distribution/policies.json со следующим содержимым:

cat <<EOF | sudo tee /usr/lib/firefox/distribution/policies.json
{
    "policies": {
        "Certificates": {
            "Install": [
                "/usr/local/share/ca-certificates/aspnet/https.crt"
            ]
        }
    }
}
EOF

Дополнительную информацию о конфигурировании доверия к сертификату HTTPS с помощью браузера Firefox см. в разделе Настройка доверия сертификата HTTPS с помощью браузера Firefox этой статьи, чтобы альтернативным способом настроить файл политики через браузер.

Доверять сертификату с помощью Fedora 34

Firefox на Fedora

echo 'pref("general.config.filename", "firefox.cfg");
pref("general.config.obscure_value", 0);' > ./autoconfig.js

echo '//Enable policies.json
lockPref("browser.policies.perUserDir", false);' > firefox.cfg

echo "{
    \"policies\": {
        \"Certificates\": {
            \"Install\": [
                \"aspnetcore-localhost-https.crt\"
            ]
        }
    }
}" > policies.json

dotnet dev-certs https -ep localhost.crt --format PEM

sudo mv autoconfig.js /usr/lib64/firefox/
sudo mv firefox.cfg /usr/lib64/firefox/
sudo mv policies.json /usr/lib64/firefox/distribution/
mkdir -p ~/.mozilla/certificates
cp localhost.crt ~/.mozilla/certificates/aspnetcore-localhost-https.crt
rm localhost.crt

Настройка доверия для dotnet-to-dotnet в Fedora

sudo cp localhost.crt /etc/pki/tls/certs/localhost.pem
sudo update-ca-trust
rm localhost.crt

См. этот комментарий GitHub для получения дополнительной информации.

Доверяйте сертификату в других дистрибутивах

Также см. эту проблему в GitHub.

Доверять сертификату HTTPS из подсистема Windows для Linux

Подсистема Windows для Linux (WSL) создает самозаверяющий сертификат разработки HTTPS. Чтобы настроить хранилище сертификатов Windows для доверия к сертификату WSL:

• Экспорт сертификата разработчика в файл в Windows:

  dotnet dev-certs https -ep C:\<<path-to-folder>>\aspnetcore.pfx -p $CREDENTIAL_PLACEHOLDER$
  

  Где $CREDENTIAL_PLACEHOLDER$ находится пароль.

• В окне WSL импортируйте экспортированный сертификат в экземпляр WSL.

  dotnet dev-certs https --clean --import /mnt/c/<<path-to-folder>>/aspnetcore.pfx -p $CREDENTIAL_PLACEHOLDER$
  

Описанный подход — это однократная операция для каждого сертификата и каждой WSL-дистрибуции. Проще, чем экспортировать сертификат снова и снова. Если вы обновляете или повторно создаете сертификат в Windows, вам может потребоваться снова выполнить приведенные выше команды.

Устранение неполадок с сертификатами, таких как ненадежный сертификат

В этом разделе содержатся сведения о том, что сертификат разработки ASP.NET Core HTTPS установлен и доверен, но у вас по-прежнему есть предупреждения браузера о том, что сертификат не является доверенным. Сертификат разработки ASP.NET Core HTTPS используется компонентом Kestrel.

Чтобы восстановить сертификат IIS Express, ознакомьтесь с этой проблемой Stackoverflow .

Все платформы — сертификат не доверенный

Выполните следующие команды:

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

Закройте все открытые экземпляры браузера. Откройте новое окно браузера в приложении. Доверие сертификатов кэшируется браузерами.

dotnet dev-certs https --clean выдает ошибку

Приведенные выше команды решают большинство проблем доверия браузера. Если браузер по-прежнему не доверяет сертификату, следуйте приведенным ниже предложениям для конкретной платформы.

Docker — сертификат не доверенный

• Удалите папку C:\Users{USER}\AppData\Roaming\ASP.NET\Https .
• Очистите решение. Удалите папки bin и obj.
• Перезапустите средство разработки. Например, Visual Studio, Visual Studio Code или Visual Studio для Mac.

Windows — сертификат не доверенный

• Проверьте сертификаты в хранилище сертификатов. Должен быть localhost сертификат с удобочитаемым именем ASP.NET Core HTTPS development certificate как под Current User > Personal > Certificates, так и под Current User > Trusted root certification authorities > Certificates
• Удалите все найденные сертификаты как из личных, так и доверенных корневых удостоверяющих центров. Не удаляйте сертификат IIS Express localhost.
• Выполните следующие команды:

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

Закройте все открытые экземпляры браузера. Откройте новое окно браузера в приложении. Доверие сертификатов кэшируется браузерами.

OS X — сертификат, не доверенный

• Откройте доступ к цепочке ключей.
• Выберите цепочку ключей системы.
• Проверьте наличие сертификата localhost.
• Убедитесь, что он содержит + символ на значке, чтобы указать, что он является доверенным для всех пользователей.
• Удалите сертификат из цепочки ключей системы.
• Выполните следующие команды:

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

Закройте все открытые экземпляры браузера. Откройте новое окно браузера в приложении. Доверие сертификатов кэшируется браузерами.

Сведения об устранении неполадок с сертификатами в Visual Studio см. в статье об ошибке HTTPS с помощью IIS Express (dotnet/AspNetCore #16892).

Сертификат Linux не является доверенным

Убедитесь, что сертификат, настроенный для доверия, является сертификатом разработчика HTTPS, который будет использоваться сервером Kestrel .

Проверьте сертификат разработчика Kestrel HTTPS по умолчанию для текущего пользователя в следующем расположении:

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

Файл сертификата разработчика Kestrel HTTPS — это отпечаток SHA1. Когда файл удаляется с помощью dotnet dev-certs https --clean, он воссоздается по мере необходимости с другим отпечатком. Проверьте, совпадает ли отпечаток экспортированного сертификата с помощью следующей команды:

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

Если сертификат не соответствует, он может быть одним из следующих вариантов:

• Старый сертификат.
• Экспортирован сертификат разработчика для корневого пользователя. В этом случае экспортируйте сертификат.

Сертификат корневого пользователя можно проверить по адресу:

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

SSL-сертификат IIS Express, используемый в Visual Studio

Чтобы устранить проблемы с сертификатом IIS Express, выберите "Восстановить " в установщике Visual Studio. Дополнительные сведения см. здесь на GitHub.

Дополнительные сведения

• Настройка ASP.NET Core для работы с прокси-серверами и подсистемами балансировки нагрузки
• Размещение ASP.NET Core на Linux с Nginx: настройка HTTPS
• Настройка SSL на IIS
• Поддержка браузера OWASP HSTS
• dotnet dev-certs

Перенаправление HTTP на HTTPS вызывает ошибку ERR_INVALID_REDIRECT в предварительном запросе CORS.

Запросы к конечной точке по протоколу HTTP, которые перенаправляются на HTTPS с использованием UseHttpsRedirection, завершаются ошибкой ERR_INVALID_REDIRECT в предварительном запросе CORS.

Проекты API могут отклонять HTTP-запросы, а не использовать UseHttpsRedirection для перенаправления запросов на HTTPS.

Требовать HTTPS

Рекомендуется использовать рабочие веб-приложения ASP.NET Core:

• Промежуточное программное обеспечение для перенаправления HTTPS (UseHttpsRedirection) для перенаправления HTTP-запросов на HTTPS.
• Посредник HSTS (UseHsts) для отправки клиентам заголовков протокола HTTP Strict Transport Security.

UseHttpsRedirection

Следующий код вызывает UseHttpsRedirection в файле Program.cs:

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).
• Использует значение по умолчанию HttpsRedirectionOptions.HttpsPort (null), если не переопределено переменной среды ASPNETCORE_HTTPS_PORT или IServerAddressesFeature.

Рекомендуется использовать временные перенаправления, а не постоянные перенаправления. Кэширование ссылок может привести к нестабильной работе в средах разработки. Если вы предпочитаете отправлять код состояния постоянного перенаправления, если приложение находится в нерабочей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. Переменная среды настраивает сервер. ПО промежуточного слоя косвенно обнаруживает порт HTTPS через IServerAddressesFeature. Этот подход не работает в развертывании обратного прокси-сервера.

• Веб-шаблоны ASP.NET Core настраивают HTTPS URL в Properties/launchsettings.json для Kestrel и IIS Express. launchsettings.json используется только на локальном компьютере.

• Настройте конечную точку HTTPS URL для публичного пограничного Kestrel развертывания сервера или сервера HTTP.sys. Приложение использует только один порт HTTPS. ПО промежуточного слоя обнаруживает порт через IServerAddressesFeature.

Пограничные развертывания

Если Kestrel или HTTP.sys используется в качестве общедоступного пограничного сервера, то необходимо настроить Kestrel или HTTP.sys для прослушивания обоих:

• Безопасный порт, в котором клиент перенаправляется (обычно 443 в рабочей среде и 5001 в разработке).
• Небезопасный порт (обычно 80 в производственной среде и 5000 в среде разработки).

Небезопасный порт должен быть доступен клиентом, чтобы приложение получило небезопасный запрос и перенаправляет клиента на безопасный порт.

Дополнительные сведения см. в разделе Kestrel о конфигурации конечной точки или реализации веб-сервера HTTP.sys в ASP.NET Core.

Сценарии развертывания

Любой брандмауэр между клиентом и сервером также должен иметь порты связи, открытые для трафика.

Если запросы перенаправляются в конфигурации обратного прокси-сервера, используйте ПО промежуточного слоя заголовков пересылки перед вызовом промежуточного ПО для перенаправления HTTPS. Промежуточное программное обеспечение для перенаправленных заголовков обновляет Request.Scheme с помощью заголовка X-Forwarded-Proto. Промежуточное ПО обеспечивает корректную работу URI перенаправления и других политик безопасности. Если промежуточное ПО для перенаправленных заголовков не используется, серверное приложение может не получить правильную схему и в конечном итоге оказаться в цикле перенаправления. Обычное сообщение об ошибке конечного пользователя заключается в том, что произошло слишком много перенаправлений.

При развертывании в службе приложений Azure следуйте инструкциям в руководстве по привязке существующего пользовательского SSL-сертификата к веб-приложениям Azure.

Options

Следующий выделенный вызов кода 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();

Вызов AddHttpsRedirection необходим только для изменения значений HttpsPort или RedirectStatusCode.

Предыдущий выделенный код:

• Задает 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 является использование Промежуточного ПО для переписывания URL-адресов. AddRedirectToHttps также может задать код состояния и порт при выполнении перенаправления. Дополнительные сведения см. в перезаписи URL с помощью промежуточного программного обеспечения.

При перенаправлении на HTTPS без требования к дополнительным правилам перенаправления рекомендуется использовать ПО промежуточного слоя перенаправления HTTPS(UseHttpsRedirection), описанное в этой статье.

Протокол строгой транспортной безопасности HTTP (HSTS)

Согласно OWASP, HTTP Strict Transport Security (HSTS) — это опция безопасности, которая может быть включена веб-приложением с помощью заголовка ответа. Когда браузер, поддерживающий HSTS, получает этот заголовок:

• Браузер сохраняет конфигурацию для домена, который предотвращает отправку сообщений по протоколу HTTP. Браузер принудительно выполняет обмен данными по протоколу HTTPS.
• Браузер запрещает пользователю использовать недоверенные или недопустимые сертификаты. Браузер отключает запросы, позволяющие пользователю временно доверять такому сертификату.

Так как HSTS применяется клиентом, он имеет некоторые ограничения:

• Клиент должен поддерживать HSTS.
• Для установки политики HSTS требуется по крайней мере один успешный HTTPS-запрос.
• Приложение должно проверить каждый HTTP-запрос и перенаправить или отклонить HTTP-запрос.

ASP.NET Core реализует HSTS с помощью UseHsts метода расширения. Следующий код вызывается 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 в первый раз, установите начальное значение HstsOptions.MaxAge на небольшой уровень, используя один из методов TimeSpan. Установите время от нескольких часов до одного дня в случае, если потребуется вернуть инфраструктуру 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 HSTS, но поддерживается веб-браузерами для предварительной загрузки сайтов HSTS на свежей установке. Дополнительные сведения см. в разделе https://hstspreload.org/.
• Включает параметр includeSubDomain, который применяет политику HSTS к поддоменам хоста.
• Явно устанавливает параметр max-age заголовка Strict-Transport-Security на 60 дней. Если значение не задано, значение по умолчанию — 30 дней. Дополнительные сведения см. в директиве max-age.
• Добавляет example.com в список узлов, которые нужно исключить.

UseHsts исключает следующие узлы для обратной связи:

• localhost : IPv4-адрес обратного соединения.
• 127.0.0.1 : IPv4-адрес обратного соединения.
• [::1] : адрес обратной связи IPv6.

Отказ от HTTPS/HSTS при создании проекта

В некоторых сценариях серверной службы, где безопасность подключения обрабатывается на общедоступном крае сети, настройка безопасности подключения на каждом узле не требуется. Веб-приложения, созданные из шаблонов в Visual Studio или с помощью команды dotnet new, включают перенаправление HTTPS и HSTS. Для развертываний, которые не требуют этих сценариев, вы можете отказаться от HTTPS/HSTS при создании приложения из шаблона.

Чтобы отказаться от HTTPS/HSTS, выполните приведенные действия.

dotnet new webapp --no-https

Доверять сертификату разработки ASP.NET Core HTTPS в Windows и macOS

В браузере Firefox см. следующий раздел.

Пакет SDK для .NET Core включает сертификат разработки 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.

При установке пакета SDK для .NET Core в локальное хранилище сертификатов пользователя устанавливается сертификат разработки HTTPS ASP.NET Core. Сертификат установлен, но он не является доверенным. Чтобы доверять сертификату, выполните однократный шаг для запуска dotnet dev-certs средства:

dotnet dev-certs https --trust

Следующая команда отображает справку по инструменту dotnet dev-certs.

dotnet dev-certs https --help

Доверяйте сертификату безопасности HTTPS в Firefox, чтобы предотвратить ошибку SEC_ERROR_INADEQUATE_KEY_USAGE

Браузер Firefox использует собственное хранилище сертификатов, поэтому не доверяет сертификатам IIS Express или Kestrel разработчика.

Существует два подхода к принятию сертификата HTTPS в Firefox: создание файла политики или настройка через браузер Firefox. При настройке с помощью браузера создается файл политики, поэтому два подхода эквивалентны.

Создание файла политики для доверия к сертификату HTTPS с помощью Firefox

Создайте файл политики (policies.jsonпо адресу:

• Виндовс: %PROGRAMFILES%\Mozilla Firefox\distribution\
• Macos: Firefox.app/Contents/Resources/distribution
• Linux: См. Как доверять сертификату в Firefox на Linux в этой статье.

Добавьте следующий код JSON в файл политики Firefox:

{
  "policies": {
    "Certificates": {
      "ImportEnterpriseRoots": true
    }
  }
}

Файл политики заставляет Firefox доверять сертификатам из хранилища доверенных сертификатов Windows. В следующем разделе представлен альтернативный подход к созданию предыдущего файла политики с помощью браузера Firefox.

Настройка доверия сертификата HTTPS с помощью браузера Firefox

Настройте security.enterprise_roots.enabled = true, следуя следующим инструкциям.

1. Введите about:config в браузере FireFox.
2. Нажмите кнопку "Принять риск" и "Продолжить ", если вы принимаете риск.
3. Выберите "Показать все"
4. Задайте значение security.enterprise_roots.enabled = true.
5. Выход и перезапуск Firefox

Дополнительные сведения см. в разделе "Настройка центров сертификации" в Firefox и mozilla/policy-templates/README-файле.

Настройка сертификата разработчика для Docker

Также см. эту проблему в GitHub.

Доверять сертификату HTTPS в Linux

Установка доверия зависит от конкретного дистрибутива и браузера. В следующих разделах приведены инструкции для некоторых популярных дистрибутивов и браузеров Chromium (Edge и Chrome) и Firefox.

Ubuntu доверяет сертификату для обмена данными между службами

Следующие инструкции не работают для некоторых версий Ubuntu, таких как 20.04. Дополнительные сведения см. в статье о проблеме GitHub dotnet/AspNetCore.Docs #23686.

1. Установите OpenSSL 1.1.1h или более поздней версии. Инструкции по обновлению OpenSSL см. в дистрибутиве.

2. Выполните следующие команды:

   dotnet dev-certs https
   sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM
   sudo update-ca-certificates
   

Предыдущие команды:

• Убедитесь, что создается сертификат разработчика текущего пользователя.
• Экспортирует сертификат с повышенными разрешениями, необходимыми для ca-certificates папки, с помощью среды текущего пользователя.
• Удаление -E флага экспортирует корневой сертификат пользователя, создав его при необходимости. Каждый созданный сертификат имеет другой отпечаток. При запуске от имени пользователя root sudo и -E не требуются.

Путь в предыдущей команде предназначен для Ubuntu. Для других дистрибутивов выберите соответствующий путь или используйте путь для центров сертификации (ЦС).

Доверие к сертификату HTTPS в Linux с помощью Edge или Chrome

cat <<EOF | sudo tee /usr/lib/firefox/distribution/policies.json
{
    "policies": {
        "Certificates": {
            "Install": [
                "/usr/local/share/ca-certificates/aspnet/https.crt"
            ]
        }
    }
}
EOF

dnf install nss-tools

cd ${ProjectDirectory}
dotnet dev-certs https -ep ${ProjectDirectory}/${CertificateName}.crt --format PEM

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

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

alias curl="curl --cacert ${ProjectDirectory}/${CertificateName}.crt"

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

Доверять сертификату с помощью Fedora 34

See:

• Комментарий GitHub
• Fedora: использование общих системных сертификатов
• Настройте среду разработки .NET в Fedora.

Доверяйте сертификату в других дистрибутивах

Также см. эту проблему в GitHub.

Доверять сертификату HTTPS из подсистема Windows для Linux

Следующие инструкции не работают для некоторых дистрибутивов Linux, таких как Ubuntu 20.04. Дополнительные сведения см. в статье о проблеме GitHub dotnet/AspNetCore.Docs #23686.

Подсистема Windows для Linux (WSL) создает самозаверяющий сертификат разработки HTTPS, который по умолчанию не является доверенным в Windows. Самый простой способ доверия Windows к сертификату WSL — настроить WSL для использования того же сертификата, что и Windows:

• В Windows экспортируйте сертификат разработчика в файл:

  dotnet dev-certs https -ep https.pfx -p $CREDENTIAL_PLACEHOLDER$ --trust
  

  Где $CREDENTIAL_PLACEHOLDER$ находится пароль.

• В окне WSL импортируйте экспортированный сертификат в экземпляр WSL.

  dotnet dev-certs https --clean --import <<path-to-pfx>> --password $CREDENTIAL_PLACEHOLDER$
  

Описанный подход — это однократная операция для каждого сертификата и каждой WSL-дистрибуции. Проще, чем экспортировать сертификат снова и снова. Если вы обновляете или повторно создаете сертификат в Windows, вам может потребоваться снова выполнить приведенные выше команды.

Устранение неполадок с сертификатами, таких как ненадежный сертификат

В этом разделе содержатся сведения о том, что сертификат разработки ASP.NET Core HTTPS установлен и доверен, но у вас по-прежнему есть предупреждения браузера о том, что сертификат не является доверенным. Сертификат разработки ASP.NET Core HTTPS используется компонентом Kestrel.

Чтобы восстановить сертификат IIS Express, ознакомьтесь с этой проблемой Stackoverflow .

Все платформы — сертификат не доверенный

Выполните следующие команды:

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

Закройте все открытые экземпляры браузера. Откройте новое окно браузера для приложения. Доверие сертификатов кэшируется браузерами.

dotnet dev-certs https --clean Сбой

Приведенные выше команды решают большинство проблем доверия браузера. Если браузер по-прежнему не доверяет сертификату, следуйте приведенным ниже предложениям для конкретной платформы.

Docker — сертификат не доверенный

• Удалите папку C:\Users{USER}\AppData\Roaming\ASP.NET\Https .
• Очистите решение. Удалите папки bin и obj.
• Перезапустите средство разработки. Например, Visual Studio или Visual Studio Code.

Windows — сертификат не доверенный

• Проверьте сертификаты в хранилище сертификатов. Должен быть localhost сертификат с удобочитаемым именем ASP.NET Core HTTPS development certificate как под Current User > Personal > Certificates, так и под Current User > Trusted root certification authorities > Certificates
• Удалите все найденные сертификаты как из личных, так и доверенных корневых удостоверяющих центров. Не удаляйте сертификат IIS Express localhost.
• Выполните следующие команды:

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

Закройте все открытые экземпляры браузера. Откройте новое окно браузера для приложения.

OS X — сертификат, не доверенный

• Откройте доступ к цепочке ключей.
• Выберите цепочку ключей системы.
• Проверьте наличие сертификата localhost.
• Убедитесь, что он содержит + символ на значке, чтобы указать, что он является доверенным для всех пользователей.
• Удалите сертификат из цепочки ключей системы.
• Выполните следующие команды:

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

Закройте все открытые экземпляры браузера. Откройте новое окно браузера для приложения.

Сведения об устранении неполадок с сертификатами в Visual Studio см. в статье об ошибке HTTPS с помощью IIS Express (dotnet/AspNetCore #16892).

Сертификат Linux не является доверенным

Убедитесь, что сертификат, настроенный для доверия, является сертификатом разработчика HTTPS, который будет использоваться сервером Kestrel .

Проверьте сертификат разработчика Kestrel HTTPS по умолчанию для текущего пользователя в следующем расположении:

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

Файл сертификата разработчика Kestrel HTTPS — это отпечаток SHA1. Когда файл удаляется с помощью dotnet dev-certs https --clean, он воссоздается по мере необходимости с другим отпечатком. Проверьте, совпадает ли отпечаток экспортированного сертификата с помощью следующей команды:

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

Если сертификат не соответствует, он может быть одним из следующих вариантов:

• Старый сертификат.
• Экспортирован сертификат разработчика для корневого пользователя. В этом случае экспортируйте сертификат.

Сертификат корневого пользователя можно проверить по адресу:

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

SSL-сертификат IIS Express, используемый в Visual Studio

Чтобы устранить проблемы с сертификатом IIS Express, выберите "Восстановить " в установщике Visual Studio. Дополнительные сведения см. здесь на GitHub.

Групповая политика не позволяет доверять самозаверенным сертификатам.

В некоторых случаях групповая политика может предотвратить доверие самозаверяемых сертификатов. Дополнительные сведения см. здесь на GitHub.

Дополнительные сведения

• Настройка ASP.NET Core для работы с прокси-серверами и подсистемами балансировки нагрузки
• Размещение ASP.NET Core на Linux с Nginx: настройка HTTPS
• Настройка SSL на IIS
• Настройка конечных точек для Kestrel веб-сервера
• Поддержка браузера OWASP HSTS

Перенаправление HTTP на HTTPS вызывает ошибку ERR_INVALID_REDIRECT в предварительном запросе CORS.

Запросы к конечной точке по протоколу HTTP, которые перенаправляются на HTTPS с использованием UseHttpsRedirection, завершаются ошибкой ERR_INVALID_REDIRECT в предварительном запросе CORS.

Проекты API могут отклонять HTTP-запросы, а не использовать UseHttpsRedirection для перенаправления запросов на HTTPS.

Требовать HTTPS

Рекомендуется использовать рабочие веб-приложения ASP.NET Core:

• Промежуточное программное обеспечение для перенаправления HTTPS (UseHttpsRedirection) для перенаправления HTTP-запросов на HTTPS.
• Посредник HSTS (UseHsts) для отправки клиентам заголовков протокола HTTP Strict Transport Security.

UseHttpsRedirection

Следующий код вызывает UseHttpsRedirection в файле Program.cs:

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).
• Использует значение по умолчанию HttpsRedirectionOptions.HttpsPort (null), если не переопределено переменной среды ASPNETCORE_HTTPS_PORT или IServerAddressesFeature.

Рекомендуется использовать временные перенаправления, а не постоянные перенаправления. Кэширование ссылок может привести к нестабильной работе в средах разработки. Если вы предпочитаете отправлять код состояния постоянного перенаправления, если приложение находится в нерабочей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. Переменная среды настраивает сервер. ПО промежуточного слоя косвенно обнаруживает порт HTTPS через IServerAddressesFeature. Этот подход не работает в развертывании обратного прокси-сервера.

• Веб-шаблоны ASP.NET Core настраивают HTTPS URL в Properties/launchsettings.json для Kestrel и IIS Express. launchsettings.json используется только на локальном компьютере.

• Настройте конечную точку HTTPS URL для публичного пограничного Kestrel развертывания сервера или сервера HTTP.sys. Приложение использует только один порт HTTPS. ПО промежуточного слоя обнаруживает порт через IServerAddressesFeature.

Пограничные развертывания

Если Kestrel или HTTP.sys используется в качестве общедоступного пограничного сервера, то необходимо настроить Kestrel или HTTP.sys для прослушивания обоих:

• Безопасный порт, в котором клиент перенаправляется (обычно 443 в рабочей среде и 5001 в разработке).
• Небезопасный порт (обычно 80 в производственной среде и 5000 в среде разработки).

Небезопасный порт должен быть доступен клиентом, чтобы приложение получило небезопасный запрос и перенаправляет клиента на безопасный порт.

Дополнительные сведения см. в разделе Kestrel о конфигурации конечной точки или реализации веб-сервера HTTP.sys в ASP.NET Core.

Сценарии развертывания

Любой брандмауэр между клиентом и сервером также должен иметь порты связи, открытые для трафика.

Если запросы перенаправляются в конфигурации обратного прокси-сервера, используйте ПО промежуточного слоя заголовков пересылки перед вызовом промежуточного ПО для перенаправления HTTPS. Промежуточное программное обеспечение для перенаправленных заголовков обновляет Request.Scheme с помощью заголовка X-Forwarded-Proto. Промежуточное ПО обеспечивает корректную работу URI перенаправления и других политик безопасности. Если промежуточное ПО для перенаправленных заголовков не используется, серверное приложение может не получить правильную схему и в конечном итоге оказаться в цикле перенаправления. Обычное сообщение об ошибке конечного пользователя заключается в том, что произошло слишком много перенаправлений.

При развертывании в службе приложений Azure следуйте инструкциям в руководстве по привязке существующего пользовательского SSL-сертификата к веб-приложениям Azure.

Options

Следующий выделенный вызов кода 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();

Вызов AddHttpsRedirection необходим только для изменения значений HttpsPort или RedirectStatusCode.

Предыдущий выделенный код:

• Задает 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 является использование Промежуточного ПО для переписывания URL-адресов. AddRedirectToHttps также может задать код состояния и порт при выполнении перенаправления. Дополнительные сведения см. в перезаписи URL с помощью промежуточного программного обеспечения.

При перенаправлении на HTTPS без требования к дополнительным правилам перенаправления рекомендуется использовать ПО промежуточного слоя перенаправления HTTPS(UseHttpsRedirection), описанное в этой статье.

Протокол строгой транспортной безопасности HTTP (HSTS)

Согласно OWASP, HTTP Strict Transport Security (HSTS) — это опция безопасности, которая может быть включена веб-приложением с помощью заголовка ответа. Когда браузер, поддерживающий HSTS, получает этот заголовок:

• Браузер сохраняет конфигурацию для домена, который предотвращает отправку сообщений по протоколу HTTP. Браузер принудительно выполняет обмен данными по протоколу HTTPS.
• Браузер запрещает пользователю использовать недоверенные или недопустимые сертификаты. Браузер отключает запросы, позволяющие пользователю временно доверять такому сертификату.

Так как HSTS применяется клиентом, он имеет некоторые ограничения:

• Клиент должен поддерживать HSTS.
• Для установки политики HSTS требуется по крайней мере один успешный HTTPS-запрос.
• Приложение должно проверить каждый HTTP-запрос и перенаправить или отклонить HTTP-запрос.

ASP.NET Core реализует HSTS с помощью UseHsts метода расширения. Следующий код вызывается 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 в первый раз, установите начальное значение HstsOptions.MaxAge на небольшой уровень, используя один из методов TimeSpan. Установите время от нескольких часов до одного дня в случае, если потребуется вернуть инфраструктуру 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 HSTS, но поддерживается веб-браузерами для предварительной загрузки сайтов HSTS на свежей установке. Дополнительные сведения см. в разделе https://hstspreload.org/.
• Включает параметр includeSubDomain, который применяет политику HSTS к поддоменам хоста.
• Явно устанавливает параметр max-age заголовка Strict-Transport-Security на 60 дней. Если значение не задано, значение по умолчанию — 30 дней. Дополнительные сведения см. в директиве max-age.
• Добавляет example.com в список узлов, которые нужно исключить.

UseHsts исключает следующие узлы для обратной связи:

• localhost : IPv4-адрес обратного соединения.
• 127.0.0.1 : IPv4-адрес обратного соединения.
• [::1] : адрес обратной связи IPv6.

Отказ от HTTPS/HSTS при создании проекта

В некоторых сценариях серверной службы, где безопасность подключения обрабатывается на общедоступном крае сети, настройка безопасности подключения на каждом узле не требуется. Веб-приложения, созданные из шаблонов в Visual Studio или с помощью команды dotnet new, включают перенаправление HTTPS и HSTS. Для развертываний, которые не требуют этих сценариев, вы можете отказаться от HTTPS/HSTS при создании приложения из шаблона.

Чтобы отказаться от HTTPS/HSTS, выполните приведенные действия.

dotnet new webapp --no-https

Доверять сертификату разработки ASP.NET Core HTTPS в Windows и macOS

В браузере Firefox см. следующий раздел.

Пакет SDK для .NET включает сертификат разработки 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.

Установка пакета SDK для .NET устанавливает сертификат разработки ASP.NET Core HTTPS в хранилище сертификатов локального пользователя. Сертификат установлен, но он не является доверенным. Чтобы доверять сертификату, выполните однократный шаг для запуска dotnet dev-certs средства:

dotnet dev-certs https --trust

Следующая команда отображает справку по инструменту dotnet dev-certs.

dotnet dev-certs https --help

Доверяйте сертификату безопасности HTTPS в Firefox, чтобы предотвратить ошибку SEC_ERROR_INADEQUATE_KEY_USAGE

Браузер Firefox использует собственное хранилище сертификатов, поэтому не доверяет сертификатам IIS Express или Kestrel разработчика.

Существует два подхода к принятию сертификата HTTPS в Firefox: создание файла политики или настройка через браузер Firefox. При настройке с помощью браузера создается файл политики, поэтому два подхода эквивалентны.

Создание файла политики для доверия к сертификату HTTPS с помощью Firefox

Создайте файл политики (policies.jsonпо адресу:

• Виндовс: %PROGRAMFILES%\Mozilla Firefox\distribution\
• Macos: Firefox.app/Contents/Resources/distribution
• Linux: См. Как доверять сертификату в Firefox на Linux в этой статье.

Добавьте следующий код JSON в файл политики Firefox:

{
  "policies": {
    "Certificates": {
      "ImportEnterpriseRoots": true
    }
  }
}

Файл политики заставляет Firefox доверять сертификатам из хранилища доверенных сертификатов Windows. В следующем разделе представлен альтернативный подход к созданию предыдущего файла политики с помощью браузера Firefox.

Настройка доверия сертификата HTTPS с помощью браузера Firefox

Настройте security.enterprise_roots.enabled = true, следуя следующим инструкциям.

1. Введите about:config в браузере FireFox.
2. Нажмите кнопку "Принять риск" и "Продолжить ", если вы принимаете риск.
3. Выберите "Показать все"
4. Задайте значение security.enterprise_roots.enabled = true.
5. Выход и перезапуск Firefox

Дополнительные сведения см. в разделе "Настройка центров сертификации" в Firefox и mozilla/policy-templates/README-файле.

Настройка сертификата разработчика для Docker

Также см. эту проблему в GitHub.

Доверять сертификату HTTPS в Linux

Установка доверия зависит от конкретного дистрибутива и браузера. В следующих разделах приведены инструкции для некоторых популярных дистрибутивов и браузеров Chromium (Edge и Chrome) и Firefox.

Доверять сертификату HTTPS в Linux с помощью инструмента linux-dev-certs

Linux-dev-certs — это глобальное средство с открытым кодом, поддерживаемое сообществом, .NET, которое предоставляет удобный способ создания и доверия сертификату разработчика в Linux. Средство не обслуживается и не поддерживается корпорацией Майкрософт.

Следующие команды устанавливают средство и создают доверенный сертификат разработчика:

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

Для получения дополнительной информации или чтобы сообщить о проблемах, см. репозиторий linux-dev-certs на GitHub.

Ubuntu доверяет сертификату для обмена данными между службами

Следующие инструкции не работают для некоторых версий Ubuntu, таких как 20.04. Дополнительные сведения см. в статье о проблеме GitHub dotnet/AspNetCore.Docs #23686.

1. Установите OpenSSL 1.1.1h или более поздней версии. Инструкции по обновлению OpenSSL см. в дистрибутиве.

2. Выполните следующие команды:

   dotnet dev-certs https
   sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM
   sudo update-ca-certificates
   

Предыдущие команды:

• Убедитесь, что создается сертификат разработчика текущего пользователя.
• Экспортирует сертификат с повышенными разрешениями, необходимыми для ca-certificates папки, с помощью среды текущего пользователя.
• Удаление -E флага экспортирует корневой сертификат пользователя, создав его при необходимости. Каждый созданный сертификат имеет другой отпечаток. При запуске от имени пользователя root sudo и -E не требуются.

Путь в предыдущей команде предназначен для Ubuntu. Для других дистрибутивов выберите соответствующий путь или используйте путь для центров сертификации (ЦС).

Доверие к сертификату HTTPS в Linux с помощью Edge или Chrome

cat <<EOF | sudo tee /usr/lib/firefox/distribution/policies.json
{
    "policies": {
        "Certificates": {
            "Install": [
                "/usr/local/share/ca-certificates/aspnet/https.crt"
            ]
        }
    }
}
EOF

dnf install nss-tools

cd ${ProjectDirectory}
dotnet dev-certs https -ep ${ProjectDirectory}/${CertificateName}.crt --format PEM

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

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

alias curl="curl --cacert ${ProjectDirectory}/${CertificateName}.crt"

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

Доверять сертификату с помощью Fedora 34

See:

• Комментарий GitHub
• Fedora: использование общих системных сертификатов
• Настройте среду разработки .NET в Fedora.

Доверяйте сертификату в других дистрибутивах

Также см. эту проблему в GitHub.

Доверять сертификату HTTPS из подсистема Windows для Linux

Следующие инструкции не работают для некоторых дистрибутивов Linux, таких как Ubuntu 20.04. Дополнительные сведения см. в статье о проблеме GitHub dotnet/AspNetCore.Docs #23686.

Подсистема Windows для Linux (WSL) создает самозаверяющий сертификат разработки HTTPS, который по умолчанию не является доверенным в Windows. Самый простой способ доверия Windows к сертификату WSL — настроить WSL для использования того же сертификата, что и Windows:

• В Windows экспортируйте сертификат разработчика в файл:

  dotnet dev-certs https -ep https.pfx -p $CREDENTIAL_PLACEHOLDER$ --trust
  

  Где $CREDENTIAL_PLACEHOLDER$ находится пароль.

• В окне WSL импортируйте экспортированный сертификат в экземпляр WSL.

  dotnet dev-certs https --clean --import <<path-to-pfx>> --password $CREDENTIAL_PLACEHOLDER$
  

Описанный подход — это однократная операция для каждого сертификата и каждой WSL-дистрибуции. Проще, чем экспортировать сертификат снова и снова. Если вы обновляете или повторно создаете сертификат в Windows, вам может потребоваться снова выполнить приведенные выше команды.

Устранение неполадок с сертификатами, таких как ненадежный сертификат

В этом разделе содержатся сведения о том, что сертификат разработки ASP.NET Core HTTPS установлен и доверен, но у вас по-прежнему есть предупреждения браузера о том, что сертификат не является доверенным. Сертификат разработки ASP.NET Core HTTPS используется компонентом Kestrel.

Чтобы восстановить сертификат IIS Express, ознакомьтесь с этой проблемой Stackoverflow .

Все платформы — сертификат не доверенный

Выполните следующие команды:

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

Закройте все открытые экземпляры браузера. Откройте новое окно браузера для приложения. Доверие сертификатов кэшируется браузерами.

dotnet dev-certs https --clean Сбой

Приведенные выше команды решают большинство проблем доверия браузера. Если браузер по-прежнему не доверяет сертификату, следуйте приведенным ниже предложениям для конкретной платформы.

Docker — сертификат не доверенный

• Удалите папку C:\Users{USER}\AppData\Roaming\ASP.NET\Https .
• Очистите решение. Удалите папки bin и obj.
• Перезапустите средство разработки. Например, Visual Studio или Visual Studio Code.

Windows — сертификат не доверенный

• Проверьте сертификаты в хранилище сертификатов. Должен быть localhost сертификат с удобочитаемым именем ASP.NET Core HTTPS development certificate как под Current User > Personal > Certificates, так и под Current User > Trusted root certification authorities > Certificates
• Удалите все найденные сертификаты как из личных, так и доверенных корневых удостоверяющих центров. Не удаляйте сертификат IIS Express localhost.
• Выполните следующие команды:

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

Закройте все открытые экземпляры браузера. Откройте новое окно браузера для приложения.

OS X — сертификат, не доверенный

• Откройте доступ к цепочке ключей.
• Выберите цепочку ключей системы.
• Проверьте наличие сертификата localhost.
• Убедитесь, что он содержит + символ на значке, чтобы указать, что он является доверенным для всех пользователей.
• Удалите сертификат из цепочки ключей системы.
• Выполните следующие команды:

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

Закройте все открытые экземпляры браузера. Откройте новое окно браузера для приложения.

Сведения об устранении неполадок с сертификатами в Visual Studio см. в статье об ошибке HTTPS с помощью IIS Express (dotnet/AspNetCore #16892).

Сертификат Linux не является доверенным

Убедитесь, что сертификат, настроенный для доверия, является сертификатом разработчика HTTPS, который будет использоваться сервером Kestrel .

Проверьте сертификат разработчика Kestrel HTTPS по умолчанию для текущего пользователя в следующем расположении:

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

Файл сертификата разработчика Kestrel HTTPS — это отпечаток SHA1. Когда файл удаляется с помощью dotnet dev-certs https --clean, он воссоздается по мере необходимости с другим отпечатком. Проверьте, совпадает ли отпечаток экспортированного сертификата с помощью следующей команды:

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

Если сертификат не соответствует, он может быть одним из следующих вариантов:

• Старый сертификат.
• Экспортирован сертификат разработчика для корневого пользователя. В этом случае экспортируйте сертификат.

Сертификат корневого пользователя можно проверить по адресу:

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

SSL-сертификат IIS Express, используемый в Visual Studio

Чтобы устранить проблемы с сертификатом IIS Express, выберите "Восстановить " в установщике Visual Studio. Дополнительные сведения см. здесь на GitHub.

Групповая политика не позволяет доверять самозаверенным сертификатам.

В некоторых случаях групповая политика может предотвратить доверие самозаверяемых сертификатов. Дополнительные сведения см. здесь на GitHub.

Дополнительные сведения

• Настройка ASP.NET Core для работы с прокси-серверами и подсистемами балансировки нагрузки
• Размещение ASP.NET Core на Linux с Nginx: настройка HTTPS
• Настройка SSL на IIS
• Настройка конечных точек для Kestrel веб-сервера
• Поддержка браузера OWASP HSTS