Как стать автором
Обновить

Mkcert: валидные HTTPS-сертификаты для localhost

Время на прочтение 2 мин
Количество просмотров 85K
Всего голосов 65: ↑54 и ↓11 +43
Комментарии 35

Комментарии 35

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

А что мешает поставить этот сертификат в доверенное хранилище?


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

Попробуйте воспользоваться этим УЦ.

НЛО прилетело и опубликовало эту надпись здесь

Для удобной разработки все равно придется купить впс с внешним ип.

А зачем? Localhost и так считается SecureContext.

Есть вот такая утилитка, github.com/cloudflare/cfssl — несколько менее популярная, чем mkcert, но имхо, более удобная и более гибкая.
При этом есть риск начать доверять кому угодно, подписанным этим CA. Достаточно, чтобы приватный ключ CA утёк. Это куда более вероятно в dev-среде, чем кажется. Среда dev, а машины-то (разработчиков) вполне себе продакшен.

Можно уничтожать приватный ключ CA сразу после подписывания сертификата сервера; в этом случае сертификат сервера можно будет продолжать использовать до истечения его срока действия, но сформировать другой сертификат сервера будет уже нельзя без создания нового сертификата CA и добавления его в хранилище доверенных сертификатов.


Теоретически можно реализовать и вариант с возможностью последующего создания сертификатов только для имён из определённого домена, если сгенерировать промежуточный CA с нужными Name Constraints — в этом случае утечка приватного ключа такого промежуточного CA не даст злоумышленнику возможности создать доверенные сертификаты для произвольного домена.

Ну это способ, требующий студии, на самом деле можно просто
dotnet dev-certs https --trust
www.hanselman.com/blog/DevelopingLocallyWithASPNETCoreUnderHTTPSSSLAndSelfSignedCerts.aspx
Говорят, не работает на линуксе, но там и галку в студии поставить не получится :)
Первый тост — за localhost! Админы локалхостов ликуют!
В хроме переиграли в безопасность и решили чтобы .localhost всегда смотрел на 127.0.0.1.
У меня была ситуация когда потребовалось чтобы site.localhost смотрел на соседний в сети комп, но какого было удивление когда я не смог это сделать через hosts.
Т.е. сначала мы забираем у разрабов .dev, и оставляем:
.test
.example
.invalid
.localhost

А потом внезапно ограничиваем .localhost. И что теперь использовать, myproject.invalid? А разрабов гугла это не парит.
А в чем суть проблемы? Я в локальных использую example.lan, example.local

Завтра заберут и .lan., и .local.
Не говоря уже о том, что придется поддерживать две структуры доменов (начиная с TLD) для dev- и prod- окружений, что реально может бомбануть

Выше 4 домена первого уровня официально зарезервированных для разработки (или тестирования, не важно). Все остальное вы можете использовать на свой страх и риск.
Раньше был отличный домен .dev, но гугл решил что ему этот домен нужнее чем остальному миру.

Домен .local на самом деле довольно давно занят — он используется в Multicast DNS (RFC 6762). В Windows из коробки клиент Multicast DNS отсутствует, а вот в Mac OS X и многих дистрибутивах Linux он есть, и в этом случае при попытке использования имён из домена .local для своих собственных целей могут возникать проблемы.


Домены верхнего уровня .lan, .corp, .home сейчас свободны и теоретически могли бы быть кем-то зарегистрированы, как и .dev, однако вероятность этого довольно мала, поскольку такие имена слишком часто используются в локальных сетях. В феврале 2018 года ICANN отклонила заявки на регистрацию доменов .corp, .home и .mail как раз из-за возможных проблем безопасности по причине конфликтов имён.

Я в своей сети сейчас использую .lan
Вообще, мне кажется, что должны быть зарезервированы ключевые домены, как те же приватные диапазоны IP

.invalid для этой цели тоже использовать нельзя — в RFC 6761 написано, что запросы имён из .invalid могут обрабатываться специальным образом и в приложениях, и в библиотеке резолвера (как и .localhost). Так что, если действовать строго по букве RFC, остаётся использовать либо оставшиеся зарезервированные домены .test или .example, либо субдомен в официально зарегистрированном домене (типа .dev.contoso.com; разумеется, показывать такой субдомен всему миру в глобальном DNS совсем не обязательно).

Если .example еще кое-как можно принять, то .test для разработки вообще не в кассу. Было 4 несчастных домена из которых по сути остаются вообще 2. Глупая ситуация, как по мне. Для разрабов надо было оставлять .dev и не выпендриваться. Это мое мнение.
Отдельный домен для каждого проекта не очень, тем более что хочется 2 уровня, а не десяток.
RFC не «запрещает», а «не рекомендует» (или рекомендует не...), что следует из аббревиатуры, кстати :D
У разработчиков NET и Windows нет такой проблемы. Из коробки можно поднять центр сертификации для домена. Дальше выпускайте сертификаты сколько вашей душе угодно. 2016 server c ролями DC DNS DHCP CA занимает около 900 мб. оперативной памяти.
Рекомендую.

900мб? Srsly? А чего сразу не 2 или 4 ГиБ?
Линукс, уверен, с аналогичным функционалом и в 200-500МиБ впишется

Это когда в линукс завезли поддержку AD и нормальную бесшовную работы SMB и интеграцию всех служб с AD ?

А она там нужна? Ну, да - какая-то поддержка есть, конечно )))

Зачем поднимать домен? Все решается гораздо легче. Правим руками файл hosts, прописываем какой душе угодно домен на 127.0.0.1 и ставим самоподписанный сертификат. И все.
Подправить hosts руками и использовать самоподписанный сертификат на любой домен. И делов то…
Подправить hosts руками и использовать самоподписанный сертификат на любой домен. И делов то…

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

Очень интересно. Без подначки пишу.
Статья о том, как приложить совсем немного усилий для решения несуществующей проблемы.
Пока самый полезный пост в новом году (и не менее полезные комменты)
Для «разработки» есть довольно удобные инструменты, так как в этом случае нужен не только https, а как минимум среда исполнения и управления. Для себя нашел весьма удобное решение — typecode/hotel.

Из коробки:
  • Локальные домены — 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.
И как быть?
НЛО прилетело и опубликовало эту надпись здесь
Лиса всегда шла со своим репозиторием сертификатов, для лисы нужно отдельно скармливать корневой, она не смотрит на хранилище в винде или другой ОС как делают остальные браузеры
Зарегистрируйтесь на Хабре , чтобы оставить комментарий