Проблема с сертификатом разработки .NET HTTPS, который не считается доверенным на Ubuntu 24.04 (Edge и Chrome)

Вопрос или проблема

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

dotnet dev-certs https -ep ~/.aspnet/https/dotnet-dev-cert.pfx -p mypassword

openssl pkcs12 -in ~/.aspnet/https/dotnet-dev-cert.pfx -clcerts -nokeys -out ~/.aspnet/https/dotnet-dev-cert.crt -passin pass:mypassword

sudo cp ~/.aspnet/https/dotnet-dev-cert.crt /usr/local/share/ca-certificates/dotnet-dev-cert.crt
sudo chmod 644 /usr/local/share/ca-certificates/dotnet-dev-cert.crt

sudo update-ca-certificates --verbose

openssl x509 -noout -text -in /usr/local/share/ca-certificates/dotnet-dev-cert.crt

dotnet dev-certs https --check --verbose

Был найден валидный сертификат: 318C61EC862324710949E1644B09097C4FBB0CF5 - CN=localhost - Действителен с 2025-02-19 по 2026-02-19 - IsHttpsDevelopmentCertificate: true - IsExportable: true

curl -v https://localhost:44352

Ответ или решение

Конфигурирование среды для разработки, включающей HTTPS-сертификаты на Ubuntu, часто представляет собой отдельную задачу, особенно при возникновении вопросов доверия к сертификатам в браузерах, таких как Microsoft Edge и Google Chrome. В данном случае проблема заключается в том, что браузеры не признают сертификат, сгенерированный .NET, доверенным, что вызывает ошибку NET::ERR_CERT_AUTHORITY_INVALID.

Теория

Сначала разберем основы работы сертификатов в .NET и их интеграцию с системами Linux, такими как Ubuntu. Когда вы создаете HTTPS-сертификат для локального сервера разработки с помощью dotnet dev-certs, .NET генерирует самоподписанный сертификат. Этот сертификат обычно используется для того, чтобы обеспечить безопасное соединение при локальной разработке. Однако браузеры, такие как Chrome и Edge, не доверяют самоподписанным сертификатам из-за отсутствия подписанного доверенного корневого центра сертификации (CA).

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

Пример

В данном случае, предпринятые вами шаги по установке и доверию сертификату были следующими:

1. Стерли существующие сертификаты и сгенерировали новые:

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

2. Экспортировали сертификат в формат PFX и преобразовали в формат CRT:

   dotnet dev-certs https -ep ~/.aspnet/https/dotnet-dev-cert.pfx -p mypassword
   openssl pkcs12 -in ~/.aspnet/https/dotnet-dev-cert.pfx -clcerts -nokeys -out ~/.aspnet/https/dotnet-dev-cert.crt -passin pass:mypassword

3. Переместили сертификат в хранилище доверенных сертификатов системы и обновили его:

   sudo cp ~/.aspnet/https/dotnet-dev-cert.crt /usr/local/share/ca-certificates/dotnet-dev-cert.crt
   sudo chmod 644 /usr/local/share/ca-certificates/dotnet-dev-cert.crt
   sudo update-ca-certificates --verbose

4. Проверили установку и верификацию сертификата с помощью curl, что показало положительный результат.

Применение

Однако даже при успешной установке сертификата на уровне системы, браузеры Google Chrome и Microsoft Edge могут использовать свои собственные хранилища доверенных сертификатов, особенно актуально для самоподписанных сертификатов. Чтобы браузеры признали сертификат доверенным:

1. Импорт в собственные хранилища браузеров:

   • Обратите внимание, что браузеры Chrome и Edge могут использовать собственные системы управления сертификатами и иногда независимы от системных настроек Ubuntu.
   • Для каждого браузера необходимо вручную добавить сертификат в их доверенные хранилища. Это можно сделать, перейдя в "Настройки" -> "Управление сертификатами" и импортировав ваш .crt файл.

2. Отключение строгой проверки сертификата (не рекомендуется для постоянного использования):

   • Временно отключить проверку сертификатов в браузере для локальной разработки. В Chrome это можно сделать с помощью параметров запуска:

     google-chrome --ignore-certificate-errors

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

3. Дополнительные диагностики:

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

Заключение

Проблема с доверенностью сертификата связана с механизмами управления доверенными сертификатами браузеров, которые независимы от системных сертификатных хранилищ. Решение данной проблемы заключается в явной интеграции вашего самоподписанного сертификата в доверенные сертификаты браузеров, что требует отдельного подхода в настройках Chrome и Edge. Однако, несмотря на все вышеописанные методы, помните об осторожности при работе с самоподписанными сертификатами и старайтесь переходить на использование официальных CA при переходе в продуктивные среды.