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

Перенаправление 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) для отправки заголовков ПРОТОКОЛА HSTS http Strict Transport Security Protocol (HSTS) клиентам.

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.

Рекомендуется использовать временные перенаправления, а не постоянные перенаправления. Кэширование ссылок может привести к нестабильной работе в средах разработки. Если вы предпочитаете отправлять код состояния постоянного перенаправления, если приложение находится в среде, отличной от разработки, см . раздел "Настройка постоянных перенаправлений в рабочей среде ". Мы рекомендуем использовать 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-адрес Properties/launchsettings.json HTTPS как для Kestrel IIS Express. launchsettings.json используется только на локальном компьютере.

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

Развертывания Edge

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

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

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

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

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

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

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

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

Параметры

Следующие выделенные вызовы 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.

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

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

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

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

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

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

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

var app = builder.Build();

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

    app.UseHsts();
}

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Альтернативный подход к перенаправлению HTTPS

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

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

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

Для OWASP 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, включите перенаправление HTTPS и HSTS. Для развертываний, которые не требуют этих сценариев, вы можете отказаться от HTTPS/HSTS при создании приложения из шаблона.

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

dotnet new webapp --no-https

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

Пакет 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

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

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

Рекомендации, связанные с Linux

Дистрибутивы Linux существенно отличаются в том, как они помечают сертификаты как доверенные. Хотя dotnet dev-certs ожидается, что оно широко применимо только официально поддерживается в Ubuntu и Fedora, и в частности направлена на обеспечение доверия в браузерах Firefox и Chromium (Edge, Chrome и Chromium).

Зависимости

Чтобы установить доверие OpenSSL, openssl средство должно находиться на пути.

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

Доверие OpenSSL

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

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

Обратите внимание, что для этого требуется версия 1.1.1h или более поздней версии или 3.0.0 или более поздней версии в зависимости от используемой основной версии.

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

Переопределения

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

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

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

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

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

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

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

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

Дополнительные сведения или сведения о проблемах см. в репозитории GitHub linux-dev-certs.

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

В этом разделе содержатся сведения о том, что сертификат разработки 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 для ASP.NET Core
• Поддержка браузера 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) для отправки заголовков ПРОТОКОЛА HSTS http Strict Transport Security Protocol (HSTS) клиентам.

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.

Рекомендуется использовать временные перенаправления, а не постоянные перенаправления. Кэширование ссылок может привести к нестабильной работе в средах разработки. Если вы предпочитаете отправлять код состояния постоянного перенаправления, если приложение находится в среде, отличной от разработки, см . раздел "Настройка постоянных перенаправлений в рабочей среде ". Мы рекомендуем использовать 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-адрес Properties/launchsettings.json HTTPS как для Kestrel IIS Express. launchsettings.json используется только на локальном компьютере.

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

Развертывания Edge

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

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

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

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

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

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

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

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

Параметры

Следующие выделенные вызовы 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.

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

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

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

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

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

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

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

var app = builder.Build();

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

    app.UseHsts();
}

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Альтернативный подход к перенаправлению HTTPS

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

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

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

Для OWASP 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, включите перенаправление 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по адресу:

• Windows: %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

Дополнительные сведения или сведения о проблемах см. в репозитории GitHub linux-dev-certs.

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

См.

• Комментарий 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 для ASP.NET Core
• Поддержка браузера OWASP HSTS

Требование использовать HTTPS

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

• ПО промежуточного слоя перенаправления HTTPS (UseHttpsRedirection) для перенаправления HTTP-запросов на HTTPS.
• По промежуточному слоям HSTS (UseHsts) для отправки заголовков ПРОТОКОЛА HSTS http Strict Transport Security Protocol (HSTS) клиентам.

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.

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

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

Развертывания Edge

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

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

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

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

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

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

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

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

Параметры

Следующие выделенные вызовы 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.

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

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

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

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

При настройке служб в 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 являетсяUseHttpsRedirection использование ПО промежуточного слоя переопределения URL-адресов (AddRedirectToHttps). 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, включите перенаправление 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по адресу:

• Windows: %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 Удалите флаг для экспорта корневого сертификата пользователя, создав его при необходимости. Каждый созданный сертификат имеет другой отпечаток. При выполнении в качестве корневого каталога 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. Для других дистрибутивов выберите соответствующий путь или используйте путь для центров сертификации (ЦС).

• JSСоздайте ON-файл /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 см. в этой статье, чтобы настроить файл политики с помощью браузера.

Доверять сертификату с помощью 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