Подписанный SSL-сертификат третьей стороны для localhost или 127.0.0.1?
Не разглашая много информации, мне нужно настроить систему веб-сервера, предназначенную для использования конечными пользователями по всему Интернету.
прецедент таков, что:
- конечные пользователи (обычно) находятся в своих домах за локальными брандмауэрами при подключении к системе.
- Система состоит из удаленного сервера, размещенного нами, строго по https (с использованием SSL)
- Механизм авторизации требует самосоздания учетной записи пользователя на удаленном сервере, который после успешного создания учетной записи потребует загрузки и установки части программного обеспечения на компьютер конечного пользователя. Это программное обеспечение содержит, помимо прочего, локальный веб-сервер.
- Этот «локальный» веб-сервер также должен разрешать только https-подключения к браузеру пользователя.
Поскольку распределенное программное обеспечение будет уникальным веб-сервером на каждой машине отдельных пользователей, я не знаю, как и даже если это возможно, получить сертификат SSL, подписанный THIRD PARTY SIGNED, который не приведет к ошибкам надежности, когда пользователь подключится к нему через веб-браузер. Конечно, он может использовать самоподписанные сертификаты SSL, но идея состоит в том, чтобы избежать предупреждений браузера, чтобы конечные пользователи неявно «доверяли» данные, поступающие из собственного приложения, работающего под своим веб-сервером через SSL.
- Не удалось создать путь PKIX: не удалось найти допустимый путь сертификации для запрошенной цели
- ошибка получения: «Ошибка: ошибка SSL: SELF_SIGNED_CERT_IN_CHAIN» при использовании npm
- Java SSL: как отключить проверку имени хоста
- Создавать самостоятельно подписанный сертификат на лету
- Самоподписанный SSL-прием на Android
Это возможно?
- Сертификаты SSL привязаны к IP-адресу серверов?
- VBA ServerXMLHTTP запрос https с самозаверяющим сертификатом
- Возможно ли иметь сертификат SSL для IP-адреса, а не доменное имя?
- Как правильно импортировать самоподписанный сертификат в хранилище ключей Java, доступное для всех приложений Java по умолчанию?
- Как настроить SSL-сертификат для сервера express.js?
- Как создать самозаверяющий сертификат с помощью SubjectAltName с помощью OpenSSL?
- Присвоение имени домена локальному хосту для среды разработки
- javax.net.ssl.SSLPeerUnverifiedException: имя хоста не соответствует теме сертификата, предоставленной партнером
Вероятно, вы можете сделать это предложение 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, как будто ключ был скомпрометирован.