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

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

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

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

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

Это возможно?

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

локальный

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

Вкратце:

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

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

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

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

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

daplie.me находится в публичном списке суффикса, а localhost.daplie.me также представляется для включения .

Это означает, что cookies, localStorage и т. Д. Защищены от совместного использования с родителем ( daplie.me ) и братьями и сестрами ( xyz.daplie.me ).

Направьте свой localhost.MY-SLD.MY-TLD на 127.0.0.1

  • Приобретите сертификат *.localhost.example.com и выпустите каждую установку на секретный xyz.localhost.example.comxyz.localhost.example.com его в список суффикса для предотвращения атак на example.com)
  • Используйте приложение с поддержкой greenlock для создания таких сертификатов «на лету» (через https://letsencrypt.org ) непосредственно на клиенте (или передайте их клиенту)

Если вы не включили в примечание PSL, что:

  • сеансы, localstorage, indexeddb и т. д. разделяются доменом
  • изменение порта не изменяет их совместное использование

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

Обновление : с такими вещами, как greenlock, которые используют ACME / Let’s 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, как будто ключ был скомпрометирован.

  • Как настроить SSL-сертификат для сервера express.js?
  • Как сообщить `ссылкам` игнорировать истекший SSL-сертификат и продолжить?
  • Установка SSL на сервере Wamp: ошибка в httpd-ssl.conf
  • Как создать самозаверяющий сертификат с помощью SubjectAltName с помощью OpenSSL?
  • Trust Anchor не найден для подключения SSL для Android
  • Создавать самостоятельно подписанный сертификат на лету
  • Преобразование Java Keystore в формат PEM
  • Как добавить самозаверяющий сертификат в качестве исключения в Chrome?
  • Постоянное получение ошибок сертификата https во всех браузерах
  • Присвоение имени домена локальному хосту для среды разработки
  • Как исправить ошибку «java.security.cert.CertificateException: нет альтернативных имен объектов»?
  • Давайте будем гением компьютера.