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

локальный

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

Вкратце:

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

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

• См. https://coolaj86.com/articles/how-to-create-a-csr-for-https-tls-ssl-rsa-pems/

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, если другие захотят используйте это как частичное решение:

• https://git.daplie.com/Daplie/localhost.daplie.me-certificates

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, как будто ключ был скомпрометирован.