Сторонний подписанный SSL-сертификат для localhost или 127.0.0.1?
не разглашая слишком много информации, мне нужно настроить систему веб-сервера, которая предназначена для использования конечными пользователями по всему интернету.
прецедент таков, что:
- конечные пользователи (обычно) находятся в своих домах за своими локальными брандмауэрами при подключении к системе.
- система состоит из удаленного сервера, размещенного нами, строго по https (с использованием SSL)
- механизм авторизации требует учетной записи пользователя самостоятельное создание на удаленном сервере, которое после успешного создания учетной записи потребует загрузки и установки программного обеспечения на компьютер конечных пользователей. Это программное обеспечение содержит, среди прочего, локальный сервер.
- этот "локальный" веб-сервер также должен разрешать только https-соединения с браузером пользователя.
поскольку распределенное программное обеспечение будет уникальным веб-сервером на каждой машине отдельных пользователей, я не уверен, как или даже если это возможно, получить сторонний подписанный SSL-сертификат, который не вызовет ошибок надежности при подключении пользователя к нему через веб-браузер. Конечно, он может использовать самозаверяющие SSL-сертификаты, но идея заключается в том, чтобы избежать предупреждений браузера, чтобы конечные пользователи неявно "доверяли" данным, поступающим из их собственного приложения, работающего на своем веб-сервере через SSL.
это возможно?
5 ответов
Вероятно, вы можете сделать нас это предложение от GlobalSign (другие обслуживания предложения КАС соответствующие). Короче говоря, предложение позволяет вам иметь сертификат CA (и регистрировать сертификаты конечного пользователя для localhost / whatever), который будет подписан сертификатом GlobalSign. Стоимость может быть значительной (я считаю, что они определяют ее в каждом конкретном случае).
localhost в
вам никогда не будет выдан правильный сертификат https для localhost. Это строго запрещен. Потому что причины.
короче:
- неправильно сконфигурированные устройства на самом деле существует, в дикой природе, которые ждут поиска перед разрешением localhost из
/etc/hosts
- если маршрутизатор определяет
localhost.foo.local
он может причинитьlocalhost
чтобы решить неправильно (вы, вероятно, видели этот класс ошибка перед)
вы можете создать корневой сертификат и затем создайте так называемый" самозаверяющий " сертификат, подписанный созданным вами корневым ЦС. Вы все равно получите уродливый экран предупреждения, но он будет работать.
localhost.дэпли.me (также указывает на 127.0.0.1)
вместо фактический localhost
certs, я делаю то, что предлагает Евгений - создать запись 127.0.0.1 в общественном достоянии.
услуги https сертификаты localhost.daplie.me
(а также ряд других сертификатов для тестирования, такие как localhost.foo.daplie.me
, localhost.bar.daplie.me
) доступны на git Daplie, если другие хотели бы использовать это как частичное решение:
daplie.me
в публичный список суффиксов и localhost.daplie.me
is и , представленного для включения.
это означает, что файлы cookie, localStorage и т. д. защищены от совместного использования с родителем (daplie.me
) и братьев и сестер (xyz.daplie.me
).
укажите ваш localhost.MY-SLD.MY-TLD до 127.0.0.1
- купить
*.localhost.example.com
сертификат и выдать каждой установке секретxyz.localhost.example.com
(и включить его в список публичных суффиксов, чтобы предотвратить атаки на example.com) - использовать приложение с поддержкой greenlock генерировать такие сертификаты на лету (через https://letsencrypt.org) непосредственно на клиента (или передать их клиенту)
если вы не получаете включены в PSL обратите внимание, что:
- сеансы, localstorage, indexeddb и т. д. разделяются доменом
- изменение порта не меняет их sharedness
Будьте Сами По Себе Корневой Сертификат
обновление: С greenlock которые используют ACME / Let's Encrypt, это больше не особенно актуально.
это, вероятно, действительно плохая идея, потому что мы не хотим, чтобы пользователи привыкли к установке Root CAs волей-неволей (и мы знаем, как это оказалось для Lenovo), но для корпоративных / клонированных машин это может быть разумный низкобюджетный вариант.
У меня было такое же требование. Поэтому причина, по которой вы должны использовать SSL, заключается в том, что почти каждый браузер теперь блюет, если вы используете https и пытаетесь подключиться к HTTP-ресурсу, даже если http-ресурс находится на localhost, что глупо для меня.
из-за JS SOP наш веб-сервер localhost обслуживает файл js, а затем JS внутри webapp может совершать звонки на этот веб-сервер localhost.
Так мы сделали local.example.com укажите 127.0.0.1 и фактически купили SSL сертификат для этого узла. Затем мы отправляем закрытый ключ внутри этого веб-сервера, который устанавливается на компьютер пользователя. Да, мы сумасшедшие.
все это на самом деле работает довольно хорошо. Мы работаем так с несколькими сотнями пользователей уже около 6 месяцев.
единственная проблема, с которой мы иногда сталкиваемся-это то, что это не работает при использовании прокси-сервер. Запросы отправляются на прокси-сервер, и он пытается подключиться к 127.0.0.1 на прокси-сервере сервер, который явно не работает. Обходной путь заключается в добавлении исключения в конфигурацию прокси-сервера, чтобы он обходил прокси-сервер для запросов к local.example.com
другой сценарий, где это будет немного сложно, когда пользователи пытаются использовать Citrix или Terminal Services. Вы должны убедиться, что веб-сервер для каждого пользователя работает на другом порту, а затем сообщить удаленному веб-серверу номер порта, чтобы страницы, созданные на сервере, имели правильный порт число. К счастью, мы еще не столкнулись с этим. Также кажется, что в наши дни все больше людей используют виртуальные машины вместо Citrix.
вы когда-нибудь найти лучший способ?
Так ты на localhost, вы можете сказать, Ваш браузер доверял сертификат.
сделайте самозаверяющий сертификат для localhost и скажите своему браузеру доверять ему.
решение " укажите свой localhost.MY-SLD.MY-TLD до 127.0.0.1 " предоставляется предоставлено CoolAJ86 работает отлично, и вы видите более подробное объяснение здесь:
как PLEX делает https для всех своих пользователей
PS: Я просто не знаю, насколько это устойчиво, потому что кто-то с подобным сценарием их ключ был отозван CA, как будто ключ был скомпрометирован.