Comments 35
Но такой сертификат вызовет ошибки доверия в браузерах, потому что в доверенном хранилище отсутствует соответствующий центр сертификации.
А что мешает поставить этот сертификат в доверенное хранилище?
запустить и настроить собственный CA можно и другими средствами, но это требует нетривиальных знаний и навыков.
Попробуйте воспользоваться этим УЦ.
А зачем? Localhost и так считается SecureContext.
Можно уничтожать приватный ключ CA сразу после подписывания сертификата сервера; в этом случае сертификат сервера можно будет продолжать использовать до истечения его срока действия, но сформировать другой сертификат сервера будет уже нельзя без создания нового сертификата CA и добавления его в хранилище доверенных сертификатов.
Теоретически можно реализовать и вариант с возможностью последующего создания сертификатов только для имён из определённого домена, если сгенерировать промежуточный CA с нужными Name Constraints — в этом случае утечка приватного ключа такого промежуточного CA не даст злоумышленнику возможности создать доверенные сертификаты для произвольного домена.
вот нашел тут metanit.com/sharp/aspnet5/18.6.php
dotnet dev-certs https --trust
www.hanselman.com/blog/DevelopingLocallyWithASPNETCoreUnderHTTPSSSLAndSelfSignedCerts.aspx
Говорят, не работает на линуксе, но там и галку в студии поставить не получится :)
У меня была ситуация когда потребовалось чтобы site.localhost смотрел на соседний в сети комп, но какого было удивление когда я не смог это сделать через hosts.
Т.е. сначала мы забираем у разрабов .dev, и оставляем:
.test
.example
.invalid
.localhost
А потом внезапно ограничиваем .localhost. И что теперь использовать, myproject.invalid? А разрабов гугла это не парит.
Завтра заберут и .lan., и .local.
Не говоря уже о том, что придется поддерживать две структуры доменов (начиная с TLD) для dev- и prod- окружений, что реально может бомбануть
Раньше был отличный домен .dev, но гугл решил что ему этот домен нужнее чем остальному миру.
Домен .local
на самом деле довольно давно занят — он используется в Multicast DNS (RFC 6762). В Windows из коробки клиент Multicast DNS отсутствует, а вот в Mac OS X и многих дистрибутивах Linux он есть, и в этом случае при попытке использования имён из домена .local
для своих собственных целей могут возникать проблемы.
Домены верхнего уровня .lan
, .corp
, .home
сейчас свободны и теоретически могли бы быть кем-то зарегистрированы, как и .dev
, однако вероятность этого довольно мала, поскольку такие имена слишком часто используются в локальных сетях. В феврале 2018 года ICANN отклонила заявки на регистрацию доменов .corp
, .home
и .mail
как раз из-за возможных проблем безопасности по причине конфликтов имён.
.invalid
для этой цели тоже использовать нельзя — в RFC 6761 написано, что запросы имён из .invalid
могут обрабатываться специальным образом и в приложениях, и в библиотеке резолвера (как и .localhost
). Так что, если действовать строго по букве RFC, остаётся использовать либо оставшиеся зарезервированные домены .test
или .example
, либо субдомен в официально зарегистрированном домене (типа .dev.contoso.com
; разумеется, показывать такой субдомен всему миру в глобальном DNS совсем не обязательно).
Отдельный домен для каждого проекта не очень, тем более что хочется 2 уровня, а не десяток.
Рекомендую.
900мб? Srsly? А чего сразу не 2 или 4 ГиБ?
Линукс, уверен, с аналогичным функционалом и в 200-500МиБ впишется
Из коробки:
- Локальные домены — project.localhost;
- HTTPS — project.localhost;
- Поддомены — http://*.project.localhost;
- Работает на macOS, Linux и Windows, так как это node.js;
- Поддержка бэкенда — Node, Ruby, PHP, Go, Python ...
- Автостарт сервисов при обращении к ним;
- Режим прокси;
- и прочее...
Note: Firefox support is not available on your platform.
И как быть?
Mkcert: валидные HTTPS-сертификаты для localhost