Подписанный SSL-сертификат третьей стороны для localhost или 127.0.0.1?
Не разглашая много информации, мне нужно настроить систему веб-сервера, предназначенную для использования конечными пользователями по всему Интернету.
прецедент таков, что:
- конечные пользователи (обычно) находятся в своих домах за локальными брандмауэрами при подключении к системе.
- Система состоит из удаленного сервера, размещенного нами, строго по https (с использованием SSL)
- Механизм авторизации требует самосоздания учетной записи пользователя на удаленном сервере, который после успешного создания учетной записи потребует загрузки и установки части программного обеспечения на компьютер конечного пользователя. Это программное обеспечение содержит, помимо прочего, локальный веб-сервер.
- Этот «локальный» веб-сервер также должен разрешать только https-подключения к браузеру пользователя.
Поскольку распределенное программное обеспечение будет уникальным веб-сервером на каждой машине отдельных пользователей, я не знаю, как и даже если это возможно, получить сертификат SSL, подписанный THIRD PARTY SIGNED, который не приведет к ошибкам надежности, когда пользователь подключится к нему через веб-браузер. Конечно, он может использовать самоподписанные сертификаты SSL, но идея состоит в том, чтобы избежать предупреждений браузера, чтобы конечные пользователи неявно «доверяли» данные, поступающие из собственного приложения, работающего под своим веб-сервером через SSL.
- Java SSL: как отключить проверку имени хоста
- Как сообщить `ссылкам` игнорировать истекший SSL-сертификат и продолжить?
- Возможно ли иметь сертификат SSL для IP-адреса, а не доменное имя?
- проверка сертификата сервера не удалась. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
- Можно ли динамически вернуть сертификат SSL в NodeJS?
Это возможно?
- Что мне нужно сделать, чтобы заставить Internet Explorer 8 принять самоподписанный сертификат?
- Почему локальное хранилище сертификатов отсутствует в Windows 8.1?
- Использование SSL и SslStream для одноранговой аутентификации?
- Сертификаты SSL привязаны к IP-адресу серверов?
- Java7 Отказ от доверия сертификату в хранилище доверия
- Использование самозаверяющего сертификата с .NET HttpWebRequest / Response
- Вызывается: java.security.UnrecoverableKeyException: невозможно восстановить ключ
- как добавить терминологическое имя объекта в ssl certs?
Вероятно, вы можете сделать это предложение 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.com
(иxyz.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, как будто ключ был скомпрометирован.