Комментарии 5
Все члены команды должны вручную создавать (и пересоздавать) свои собственные самоподписанные сертификаты.
Так же как при использовании lcl.host и mkcert
Самоподписанные сертификаты нужно вручную добавлять в каждое хранилище доверия в системе.
Так же как при использовании lcl.host и mkcert
Домены
app.localhostработают не везде, поэтому для небраузерных клиентов (например,curl) требуются записи в/etc/hostsили DNS-сервер разработки.
Какое-либо расширенное разрешение доменных имён не предо при использовании lcl.host и mkcert, и работает точно так же при использовании любого инструмента управления сертификатами.
Запуск приложений в локальных контейнерах требует постоянного обновления сертификатов и хранилища доверия.
Так же как при использовании lcl.host и mkcert
Описанные инструменты lcl.host и mkcert всего лишь упрощают работу с *самоподписанными сертификатами* и имеют те же ограничения, а так же дополнительно ограничивают использование, за счёт чего они и снижают требования к разработчику.
Я считаю, что прежде чем нахваливать ограниченный инструмент, стоит попробовать разобраться в принципе его работы, найти реальные преимущества перед другими, а затем уже рекомендовать новичкам.
Думаю во всей этой истории проще использовать https://get.localhost.direct/
Только любая публикация приватного сертификата - это его компрометация, т.е. его в любой момент отозвать могут (по правилам - как только эта информация дойдет до центра выдачи сертификатов).
P.S. при всей удобности подобного подхода - есть и риски. DNS-ответы могут подменить, после чего трафик пойдет неизвестно куда.
P.P.S. знаю подобный проект, с прикрученным traefik для управления поддоменами: https://habr.com/ru/articles/714916/
Я вот делал кроссплатформенную имплементацию подобного: https://github.com/denisvmedia/devenv
Локальный HTTPS в dev-окружении — простая настройка