SSL-сертификат для службы - не для FQDN
Моя организация развертывает сервер данных и клиентское устройство (два устройства) во внутренних сетях клиентов, чтобы они могли использовать наше решение; клиентское устройство подключается только к серверу данных; однако любой сайт клиента не обязательно может предоставлять статический IP-адрес или имя хоста, а также гарантировать постоянство IP-адресов устройств. Единственное, что мы знаем наверняка, мы можем контролировать, - это наш сервер и клиентское устройство; требования заказчиков диктуют настройку сети.
Клиентское устройство должно безопасно подключаться к серверу данных через HTTPS, и мы хотим предоставить возможность установки нашего собственного сертификата с использованием нашего собственного CA на сервере данных. (клиента также могут установить свой собственный сертификат, но это выходит за рамки этого вопроса)
Поскольку IP-адрес сервера данных не гарантирует постоянство, я задаюсь вопросом, можно ли выдать сертификат для service , а не выдавать сертификат для адреса / имени?
Я искал «сертификаты ssl для сервисов», «для переменных IP-адресов» и т.п., но не нашел ничего подходящего. Мне не хватает терминологии, которая поможет сузить поиск, или это вообще не вопрос?
Спасибо
Отправьте самоподписанный сертификат и предоставьте клиенту возможность загрузить свой собственный сертификат.
Так делают все, потому что это единственный вариант, который действительно работает. Администратор, настраивающий службу, ожидает этого и имеет возможность установить действующий сертификат для своих пользователей.
После повторного чтения вопроса и размышления над ним я думаю, что на самом деле есть вариант:
для пользователя интерфейс:
- поставляется с самоподписанным сертификатом
- предоставляет возможность загрузки сертификата для администраторов
для связи между устройствами:
- создает свой собственный ЦС (в вашей собственной внутренней сети этот ЦС не оставляет ваша компания)
- настройте клиентские устройства, которые вы доставляете своим клиентам, чтобы доверять этому ЦС.
- создать Суб-ЦС вашего ЦС на своем серверном устройстве
- после установки сервера на сайте клиента иметь серверное устройство создать сертификат для себя суб-CA
- на этом этапе у вас есть IP-адрес, и вы можете преобразовать IP-адрес в допустимое внутреннее DNS-имя
- (необязательно: после установки клиента на сайте клиента клиентское устройство должно запросить сертификат из суб-CA на сервере.
На самом деле в этом нет необходимости, но его можно использовать для аутентификации клиента сервером, если вы хотите, чтобы только ваши собственные клиенты могли взаимодействовать с сервером)
Таким образом, ваши клиенты доверяют вашему собственному серверу, а вы может даже расширить его до двустороннего доверия между вашими устройствами.
Найдите термин динамический DNS. Я всегда использую его для сайтов, на которых я не могу гарантировать статический IP-адрес.
Namecheap и несколько других регистраторов DNS предоставляют эту услугу без дополнительных затрат, если вы хотите ее использовать для своего собственного домена (ов), но есть отдельные объекты, которые предоставить услугу за небольшую плату, назначив вам субдомен для собственного доменного имени.
Вам необходимо выпустить сертификат для DNS-имени, а не для IP-адреса. Если ваш внутренний сервер прослушивает service.example.com , тогда сертификат должен соответствовать этому «общему имени». Если сервер получает новый IP-адрес при каждой загрузке, вам просто нужно убедиться, что DHCP-сервер обновляет DNS-сервер новой информацией, чтобы запись A для service.example.com всегда указывала на правильный IP-адрес. Для этого вам нужно будет работать вместе с каждым клиентом, у которого вы хотите развернуть свое приложение, поскольку каждая компания может отличаться тем, как они это реализуют.
Конечно, будет лучше «потребовать» фиксированный IP-адрес или резервирование DHCP, чтобы сервер DHCP всегда давал вашему серверу один и тот же IP-адрес на основе MAC-адреса вашего сервера.
Если вы захотите, настроить свой собственный сервер CA в сети вашего клиента, вам снова нужно будет тесно сотрудничать с клиентом, поскольку им нужно будет разместить ваш корневой сертификат на каждом клиентском компьютере в компании, чтобы сертификаты вашего CA были доверенными . В противном случае браузер выдаст большое жирное предупреждение о том, что (корневой) ЦС не является доверенным.