Сторонний подписанный 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, как будто ключ был скомпрометирован.