Принудительное применение HTTPS в ASP.NET Core
В этом документе показано, как:
- Требовать HTTPS для всех запросов.
- Перенаправляет все запросы HTTP на HTTPS.
Ни один API не может запретить клиенту отправлять конфиденциальные данные в первом запросе.
Предупреждение
Проекты API
Не используйте RequireHttpsAttribute веб-API, получающие конфиденциальную информацию. RequireHttpsAttribute использует коды состояния HTTP для перенаправления браузеров из HTTP в HTTPS. Клиенты API могут не понимать или подчиняться перенаправлениям из HTTP в HTTPS. Такие клиенты могут отправлять данные по протоколу HTTP. Веб-API должны иметь следующее:
- Не прослушивать HTTP.
- Закройте подключение с кодом состояния 400 (недопустимый запрос) и не обслуживайте запрос.
Чтобы отключить перенаправление HTTP в API, задайте ASPNETCORE_URLS переменную среды или используйте флаг командной --urls строки. Дополнительные сведения см. в разделе "Использование нескольких сред" в ASP.NET Core и 8 способов задания URL-адресов для приложения ASP.NET Core от Эндрю Lock.
Проекты HSTS и API
Проекты API по умолчанию не включают HSTS, так как HSTS обычно является инструкцией только для браузера. Другие абоненты, такие как телефонные или классические приложения, не подчиняются инструкции. Даже в браузерах один прошедший проверку подлинности вызов API через HTTP имеет риски в небезопасных сетях. Безопасный подход заключается в настройке проектов API только для прослушивания и реагирования по протоколу HTTPS.
Перенаправление HTTP на HTTPS вызывает ERR_INVALID_REDIRECT в предварительном запросе CORS
Запросы к конечной точке с использованием HTTP, перенаправленных на HTTPS, сбоем UseHttpsRedirectionERR_INVALID_REDIRECT on the CORS preflight request.
Проекты API могут отклонять HTTP-запросы, а не использовать UseHttpsRedirection для перенаправления запросов на HTTPS.
Требование использовать HTTPS
Рекомендуется использовать рабочие веб-приложения ASP.NET Core:
- ПО промежуточного слоя перенаправления HTTPS (UseHttpsRedirection) для перенаправления HTTP-запросов на HTTPS.
- По промежуточному слоям HSTS (UseHsts) для отправки заголовков ПРОТОКОЛА HSTS http Strict Transport Security Protocol (HSTS) клиентам.
Примечание.
Приложения, развернутые в конфигурации обратного прокси-сервера, позволяют прокси-серверу обрабатывать безопасность подключения (HTTPS). Если прокси-сервер также обрабатывает перенаправление HTTPS, нет необходимости использовать ПО промежуточного слоя перенаправления HTTPS. Если прокси-сервер также обрабатывает запись заголовков HSTS (например, встроенная поддержка HSTS в IIS 10.0 (1709) или более поздней версии), ПО промежуточного слоя HSTS не требуется приложению. Дополнительные сведения см. в разделе "Отказ от HTTPS/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_PORTSсреды или IServerAddressesFeature.
Рекомендуется использовать временные перенаправления, а не постоянные перенаправления. Кэширование ссылок может привести к нестабильной работе в средах разработки. Если вы предпочитаете отправлять код состояния постоянного перенаправления, если приложение находится в среде, отличной от разработки, см . раздел "Настройка постоянных перенаправлений в рабочей среде ". Мы рекомендуем использовать HSTS для сигнала клиентам о том, что в приложение должны отправляться только безопасные запросы ресурсов (только в рабочей среде).
Конфигурация порта
Порт должен быть доступен для по промежуточного слоя для перенаправления небезопасного запроса на HTTPS. Если порт недоступен:
- Перенаправление на HTTPS не происходит.
- ПО промежуточного слоя записывает предупреждение "Не удалось определить порт https для перенаправления".
Укажите порт HTTPS с помощью любого из следующих подходов:
Задайте httpsRedirectionOptions.HttpsPort.
https_portЗадайте параметр узла:В конфигурации узла.
Задав
ASPNETCORE_HTTPS_PORTSпеременную среды.Добавив запись верхнего уровня в
appsettings.json:{ "https_port": 443, "Logging": { "LogLevel": { "Default": "Information", "Microsoft.AspNetCore": "Warning" } }, "AllowedHosts": "*" }
Укажите порт с безопасной схемой с помощью переменной среды ASPNETCORE_URLS. Переменная среды настраивает сервер. ПО промежуточного слоя косвенно обнаруживает порт HTTPS через IServerAddressesFeature. Этот подход не работает в развертывании обратного прокси-сервера.
Веб-шаблоны ASP.NET Core задают URL-адрес
Properties/launchsettings.jsonHTTPS как для Kestrel IIS Express.launchsettings.jsonиспользуется только на локальном компьютере.Настройте конечную точку URL-адреса HTTPS для общедоступного пограничного Kestrel развертывания сервера или сервера HTTP.sys . Приложение использует только один порт HTTPS. ПО промежуточного слоя обнаруживает порт через IServerAddressesFeature.
Примечание.
Когда приложение выполняется в конфигурации обратного прокси-сервера, 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-Security60 дней. Если значение не задано, значение по умолчанию — 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, выполните приведенные действия.
Un проверка поле Configure for HTTPS проверка box.
Доверять сертификату разработки 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
Следующая команда вызывает справку по средству dev-certs.
dotnet dev-certs https --help
Предупреждение
Не создавайте сертификат разработки в среде, которая будет распространяться, например образ контейнера или виртуальная машина. Это может привести к спуфингову и повышению привилегий. Чтобы предотвратить это, задайте DOTNET_GENERATE_ASPNET_CERTIFICATE переменную false среды перед вызовом .NET CLI в первый раз. Это пропустит автоматическое создание сертификата разработки ASP.NET Core во время первого запуска интерфейса командной строки.
Доверяйте сертификату 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 инструкции:
- Введите
about:configв браузере FireFox. - Нажмите кнопку "Принять риск" и "Продолжить ", если вы принимаете риск.
- Выберите "Показать все"
- Задайте значение
security.enterprise_roots.enabled=true. - Выход и перезапуск Firefox
Дополнительные сведения см. в разделе "Настройка центров сертификации" в Firefox и mozilla/policy-templates/README-файле.
Настройка сертификата разработчика для Docker
Также см. эту проблему в GitHub.
Доверять сертификату HTTPS в Linux
Установка доверия — это распределение и браузер. В следующих разделах приведены инструкции для некоторых популярных дистрибутивов и браузеров Chromium (Edge и Chrome) и Firefox.
Ubuntu доверяет сертификату для обмена данными между службами
Следующие инструкции не работают для некоторых версий Ubuntu, таких как 20.04. Дополнительные сведения см. в статье о проблеме GitHub dotnet/AspNetCore.Docs #23686.
Установите OpenSSL 1.1.1h или более поздней версии. Инструкции по обновлению OpenSSL см. в дистрибутиве.
Выполните следующие команды:
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 certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -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. Для других дистрибутивов выберите соответствующий путь или используйте путь для центров сертификации (ЦС).
Создайте ON-файл
/usr/lib/firefox/distribution/policies.jsonс помощью следующей JSкоманды:
cat <<EOF | sudo tee /usr/lib/firefox/distribution/policies.json
{
"policies": {
"Certificates": {
"Install": [
"/usr/local/share/ca-certificates/aspnet/https.crt"
]
}
}
}
EOF
Примечание. Ubuntu 21.10 Firefox поставляется как пакет оснастки и папка /snap/firefox/current/usr/lib/firefoxустановки.
Сведения о настройке доверия сертификата HTTPS с помощью браузера Firefox в этом документе см. в качестве альтернативного способа настройки файла политики с помощью браузера.
Доверять сертификату с помощью 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 с конфигурацией Apache: HTTPS
- Узел ASP.NET Core в Linux с nginx: конфигурация HTTPS
- Настройка SSL в службах IIS
- Настройка конечных точек для веб-сервера Kestrel для ASP.NET Core
- Поддержка браузера OWASP HSTS
Предупреждение
Проекты API
Не используйте RequireHttpsAttribute веб-API, получающие конфиденциальную информацию. RequireHttpsAttribute использует коды состояния HTTP для перенаправления браузеров из HTTP в HTTPS. Клиенты API могут не понимать или подчиняться перенаправлениям из HTTP в HTTPS. Такие клиенты могут отправлять данные по протоколу HTTP. Веб-API должны иметь следующее:
- Не прослушивать HTTP.
- Закройте подключение с кодом состояния 400 (недопустимый запрос) и не обслуживайте запрос.
Чтобы отключить перенаправление HTTP в API, задайте ASPNETCORE_URLS переменную среды или используйте флаг командной --urls строки. Дополнительные сведения см. в разделе "Использование нескольких сред" в ASP.NET Core и 5 способах задания URL-адресов для приложения ASP.NET Core от Эндрю Lock.
Проекты HSTS и API
Проекты API по умолчанию не включают HSTS, так как HSTS обычно является инструкцией только для браузера. Другие абоненты, такие как телефонные или классические приложения, не подчиняются инструкции. Даже в браузерах один прошедший проверку подлинности вызов API через HTTP имеет риски в небезопасных сетях. Безопасный подход заключается в настройке проектов API только для прослушивания и реагирования по протоколу HTTPS.
Требование использовать HTTPS
Рекомендуется использовать рабочие веб-приложения ASP.NET Core:
- ПО промежуточного слоя перенаправления HTTPS (UseHttpsRedirection) для перенаправления HTTP-запросов на HTTPS.
- По промежуточному слоям HSTS (UseHsts) для отправки заголовков ПРОТОКОЛА HSTS http Strict Transport Security Protocol (HSTS) клиентам.
Примечание.
Приложения, развернутые в конфигурации обратного прокси-сервера, позволяют прокси-серверу обрабатывать безопасность подключения (HTTPS). Если прокси-сервер также обрабатывает перенаправление HTTPS, нет необходимости использовать ПО промежуточного слоя перенаправления HTTPS. Если прокси-сервер также обрабатывает запись заголовков HSTS (например, встроенная поддержка HSTS в IIS 10.0 (1709) или более поздней версии), ПО промежуточного слоя HSTS не требуется приложению. Дополнительные сведения см. в разделе "Отказ от HTTPS/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_PORTSсреды или IServerAddressesFeature.
Рекомендуется использовать временные перенаправления, а не постоянные перенаправления. Кэширование ссылок может привести к нестабильной работе в средах разработки. Если вы предпочитаете отправлять код состояния постоянного перенаправления, если приложение находится в среде, отличной от разработки, см . раздел "Настройка постоянных перенаправлений в рабочей среде ". Мы рекомендуем использовать HSTS для сигнала клиентам о том, что в приложение должны отправляться только безопасные запросы ресурсов (только в рабочей среде).
Конфигурация порта
Порт должен быть доступен для по промежуточного слоя для перенаправления небезопасного запроса на HTTPS. Если порт недоступен:
- Перенаправление на HTTPS не происходит.
- ПО промежуточного слоя записывает предупреждение "Не удалось определить порт https для перенаправления".
Укажите порт HTTPS с помощью любого из следующих подходов:
Задайте httpsRedirectionOptions.HttpsPort.
https_portЗадайте параметр узла:В конфигурации узла.
Задав
ASPNETCORE_HTTPS_PORTSпеременную среды.Добавив запись верхнего уровня в
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.
Примечание.
Когда приложение выполняется в конфигурации обратного прокси-сервера, 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-Security60 дней. Если значение не задано, значение по умолчанию — 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, выполните приведенные действия.
Un проверка поле Configure for HTTPS проверка box.
Доверять сертификату разработки 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
Следующая команда вызывает справку по средству dev-certs.
dotnet dev-certs https --help
Предупреждение
Не создавайте сертификат разработки в среде, которая будет распространяться, например образ контейнера или виртуальная машина. Это может привести к спуфингову и повышению привилегий. Чтобы предотвратить это, задайте DOTNET_GENERATE_ASPNET_CERTIFICATE переменную false среды перед вызовом .NET CLI в первый раз. Это пропустит автоматическое создание сертификата разработки ASP.NET Core во время первого запуска интерфейса командной строки.
Доверяйте сертификату 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 инструкции:
- Введите
about:configв браузере FireFox. - Нажмите кнопку "Принять риск" и "Продолжить ", если вы принимаете риск.
- Выберите "Показать все"
- Задайте значение
security.enterprise_roots.enabled=true. - Выход и перезапуск Firefox
Дополнительные сведения см. в разделе "Настройка центров сертификации" в Firefox и mozilla/policy-templates/README-файле.
Настройка сертификата разработчика для Docker
Также см. эту проблему в GitHub.
Доверять сертификату HTTPS в Linux
Установка доверия — это распределение и браузер. В следующих разделах приведены инструкции для некоторых популярных дистрибутивов и браузеров Chromium (Edge и Chrome) и Firefox.
Ubuntu доверяет сертификату для обмена данными между службами
Установите OpenSSL 1.1.1h или более поздней версии. Инструкции по обновлению OpenSSL см. в дистрибутиве.
Выполните следующие команды:
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 certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -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
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по