Подписанный SSL-сертификат третьей стороны для localhost или 127.0.0.1?

Без разглашения Слишком много информации, мне нужно настроить систему веб-сервера, которая предназначена для использования конечными пользователями по всему Интернету.

прецедент таков, что:

  • конечные пользователи (обычно) находятся в своих домах за локальными брандмауэрами при подключении к системе.
  • Система состоит из удаленного сервера, размещенного нами, строго по https (с использованием SSL).
  • Механизм авторизации требует самостоятельного создания учетной записи пользователя на удаленном сервере, который после успешного создания учетной записи потребует загрузки и установки части программного обеспечения на компьютер конечного пользователя. Это программное обеспечение содержит, помимо прочего, локальный веб-сервер.
  • Этот "локальный" веб-сервер должен также разрешать только https-подключения к пользовательскому браузеру.

Так как распределенное программное обеспечение будет уникальным веб-сервером на каждой машине отдельных пользователей, я не знаю, как или даже если это возможно, получить SSL-сертификат THIRD PARTY SIGNED, который не приведет к ошибкам надежности, когда пользователь подключается к нему через веб-браузер. Конечно, он может использовать самоподписанные SSL-сертификаты, но идея состоит в том, чтобы избежать предупреждений браузера, чтобы конечные пользователи неявно "доверяли" данные, поступающие из собственного приложения, работающего под своим веб-сервером через SSL.

Возможно ли это?

ОТВЕТЫ

Ответ 1

Возможно, вы можете сделать нас это предложение GlobalSign (другие ЦС предлагают сопоставимые услуги). Вкратце, предложение позволяет иметь сертификат ЦС (и регистрировать сертификаты конечного пользователя для localhost/независимо), которые будут подписаны сертификатом GlobalSign. Стоимость может быть значительной, хотя (я считаю, что они определяют ее в каждом конкретном случае).

Ответ 2

локальный

Вам не будет выдано соответствующее https-сертификат для localhost. строго запрещено. Потому что причины.

Короче:

  • Неисправные устройства фактически существуют в дикой природе, которые ждут поиска, прежде чем разрешать localhost с /etc/hosts
  • Если маршрутизатор определяет localhost.foo.local, это может привести к неправильному разрешению localhost (вы, вероятно, раньше видели этот класс ошибок)

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

localhost.daplie.me(также указывает на 127.0.0.1)

Вместо фактических сертификатов localhost я делаю то, что предлагает Юджин, - создайте запись 127.0.0.1 в общедоступном домене.

Сертификаты HTTPS для localhost.daplie.me (а также ряд других сертификатов для тестирования, таких как localhost.foo.daplie.me, localhost.bar.daplie.me) доступны в Daplie git, если другие хотели бы использовать это как частичное решение:

daplie.me находится в Public Suffix List и localhost.daplie.me также для включения.

Это означает, что файлы 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 и т.д. совместно используются доменом
  • изменение порта не изменяет их совместное использование.

Будьте собственным корневым сертификатом

Обновить: с помощью таких функций, как greenlock, которые используют ACME/Let Encrypt, это уже не особенно актуально.

Это, пожалуй, очень плохая идея, потому что мы не хотим, чтобы пользователи привыкли устанавливать Root CA волей-неволей (и мы знаем, как получилось для Lenovo), но для корпоративных/клонированных машин это может быть разумным вариантом с низким бюджетом.

Ответ 3

У меня было это же требование. Поэтому причина, почему вы должны использовать SSL, состоит в том, что почти каждый браузер теперь работает, если вы используете https и пытаетесь подключиться к http-ресурсу, даже если ресурс http находится на localhost, что глупо для меня.

Из-за JS SOP наш локальный веб-сервер обслуживает js файл, а затем JS внутри webapp может совершать вызовы на этом веб-сервере localhost.

Итак, мы сделали local.example.com точкой 127.0.0.1 и фактически купили SSL-сертификат для этого имени хоста. Затем мы отправляем закрытый ключ внутри этого веб-сервера, который устанавливается на пользовательский компьютер. Да, мы сумасшедшие.

Все это работает очень хорошо. Сегодня мы работаем примерно с несколькими сотнями пользователей в течение 6 месяцев.

Единственная проблема, с которой мы иногда сталкиваемся, заключается в том, что это не работает правильно, когда пользователь использует прокси-сервер. Запросы отправляются на прокси-сервер и он пытается подключиться к 127.0.0.1 на прокси-сервере, который, очевидно, не работает. Обход заключается в том, чтобы добавить исключение в конфигурацию прокси-сервера, чтобы он обходил прокси-сервер для запросов на local.example.com

Другой сценарий, когда он будет немного сложнее, - это когда пользователи пытаются использовать Citrix или Terminal Services. Вы должны убедиться, что веб-сервер для каждого пользователя запущен на другом порту, а затем информирует ваш удаленный веб-сервер о номере порта, чтобы страницы, сгенерированные на сервере, имели нужный номер порта. К счастью, мы пока не сталкивались с этим. Также кажется, что больше людей используют виртуальные машины в наши дни вместо Citrix.

Вы когда-нибудь находили лучший способ?

Ответ 4

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

Сделайте самозаверяющий сертификат для localhost и сообщите своему браузеру, чтобы он ему доверял.

Ответ 5

Решение "Укажите ваш localhost.MY-SLD.MY-TLD до 127.0.0.1, предоставленный предоставленный CoolAJ86, отлично работает, и вы видите более подробное объяснение здесь:
Как PLEX делает https для всех своих пользователей

PS: Я просто не знаю, насколько это устойчиво, потому что кто-то с похожим сценарием имел свой ключ, отозванный CA как если ключ был скомпрометирован.