Без разглашения Слишком много информации, мне нужно настроить систему веб-сервера, которая предназначена для использования конечными пользователями по всему Интернету.
прецедент таков, что:
Так как распределенное программное обеспечение будет уникальным веб-сервером на каждой машине отдельных пользователей, я не знаю, как или даже если это возможно, получить SSL-сертификат THIRD PARTY SIGNED, который не приведет к ошибкам надежности, когда пользователь подключается к нему через веб-браузер. Конечно, он может использовать самоподписанные SSL-сертификаты, но идея состоит в том, чтобы избежать предупреждений браузера, чтобы конечные пользователи неявно "доверяли" данные, поступающие из собственного приложения, работающего под своим веб-сервером через SSL.
Возможно ли это?
Возможно, вы можете сделать нас это предложение GlobalSign (другие ЦС предлагают сопоставимые услуги). Вкратце, предложение позволяет иметь сертификат ЦС (и регистрировать сертификаты конечного пользователя для localhost/независимо), которые будут подписаны сертификатом GlobalSign. Стоимость может быть значительной, хотя (я считаю, что они определяют ее в каждом конкретном случае).
Вам не будет выдано соответствующее https-сертификат для localhost. строго запрещено. Потому что причины.
Короче:
/etc/hostslocalhost.foo.local, это может привести к неправильному разрешению localhost (вы, вероятно, раньше видели этот класс ошибок)Вы можете создать корневой сертификат и затем создать так называемый "самозаверяющий" сертификат, подписанный созданным вами корнем. Вы все равно получите уродливый экран предупреждения, но он будет работать.
Вместо фактических сертификатов 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.example.com и выдать каждой установке секретный xyz.localhost.example.com (и включить его в список суффикса для предотвращения атак на example.com)Если вы не включили в примечание PSL, что:
Обновить: с помощью таких функций, как greenlock, которые используют ACME/Let Encrypt, это уже не особенно актуально.
Это, пожалуй, очень плохая идея, потому что мы не хотим, чтобы пользователи привыкли устанавливать Root CA волей-неволей (и мы знаем, как получилось для Lenovo), но для корпоративных/клонированных машин это может быть разумным вариантом с низким бюджетом.
У меня было это же требование. Поэтому причина, почему вы должны использовать 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.
Вы когда-нибудь находили лучший способ?
Поскольку вы находитесь на локальном хосте, вы можете сообщить своему браузеру, что он доверяет любому сертификату, который вам нужен.
Сделайте самозаверяющий сертификат для localhost и сообщите своему браузеру, чтобы он ему доверял.
Решение "Укажите ваш localhost.MY-SLD.MY-TLD до 127.0.0.1, предоставленный предоставленный CoolAJ86, отлично работает, и вы видите более подробное объяснение здесь:
Как PLEX делает https для всех своих пользователей
PS: Я просто не знаю, насколько это устойчиво, потому что кто-то с похожим сценарием имел свой ключ, отозванный CA как если ключ был скомпрометирован.