Я разрабатываю продукт для управления сетью. Мы отправляем наш продукт клиентам в виде виртуальной машины, которую они устанавливают на гипервизор в своей сети. Этим виртуальным машинам предоставляются статические частные IP-адреса в сети клиента. Они отслеживают устройства клиентов и запускают веб-сервер (Apache / Django), показывающий состояние сети. Клиенты получают доступ к сайту по частному IP-адресу, а мы получаем доступ к виртуальным машинам напрямую, используя TeamViewer (установленный перед их отправкой), поэтому публичный IP-адрес или доменное имя не используются. Мы очень хотели бы предоставить сертификаты SSL на наши виртуальные машины, чтобы клиенты перестали видеть уведомления о том, что наш сайт небезопасен (и, конечно же, чтобы наш сайт перестал быть небезопасным). Желательно, чтобы клиентам не приходилось добавлять доверие для нового центра сертификации или добавлять исключения безопасности в свои браузеры.
Как это сделать наиболее эффективным и рентабельным способом? Я пробовал LetsEncrypt, но они поддерживают сертификаты только для доменных имен, а не для IP-адресов.
Просто используйте самозаверяющий сертификат, как вы уже это делаете, и не пытайтесь использовать какие-либо грязные хаки, чтобы обойти ошибку. Предоставьте своим клиентам возможность заменить этот сертификат своим собственным. Замещающий сертификат может быть подписан общедоступным ЦС с использованием собственного общедоступного (под) доменного имени или локально доверенным ЦС, например с помощью служб сертификации Active Directory. В любом случае, он всегда будет совместим с их инфраструктурой и политикой безопасности.
Вы можете настроить домен с DNS-серверами, чтобы возвращать частные IP-адреса для запросов DNS. Вот что я здесь делаю.
$ resolveip node-1.example.com
IP address of node-1.example.com is 192.168.1.71
Таким образом, вы можете использовать сертификаты tls на основе имени и получить действительный DNS
В вопросе есть несколько противоречащих друг другу требований, которые я предлагаю вам решить, используя доменное имя, а не IP-адрес.
Вы запрашиваете сертификат для внутреннего IP-адреса от центра сертификации, которому уже доверяют браузеры. Однако, если ЦС будет выдавать такие сертификаты, браузеры, вероятно, перестанут доверять ЦС, что в первую очередь лишит вас цели выбора этого ЦС.
Однако вы можете получить сертификат для реального доменного имени и указать это имя на внутренний IP-адрес. На этом этапе нужно будет принять несколько решений. Одно из решений зависит от того, почему вы вообще используете внутренний IP-адрес. Используете ли вы внутренний IP-адрес из-за нехватки IP-адресов, или вы используете внутренний IP-адрес в качестве метода контроля доступа?
В оставшейся части своего ответа я предполагаю, что вы используете его как метод контроля доступа. Если вы делаете это только из-за нехватки IP-адресов, есть другие и, возможно, более простые решения.
Для выдачи сертификата LetsEncrypt необходимо отправить HTTP-запрос в домен, по этой причине домен должен разрешить реальный IP-адрес, доступный для LetsEncrypt. Сервер, на который вы направляете LetsEncrypt, - это тот сервер, на котором вы генерируете сертификат, который не обязательно должен быть таким же, как тот, на котором вы в конечном итоге будете использовать сертификат. А поскольку вам нужен строгий контроль доступа к виртуальной машине с помощью сертификата, вы, вероятно, захотите, чтобы LetsEncrypt взаимодействовал с другим сервером.
Вы никогда не хотите, чтобы сервер, на котором вы сгенерировали сертификат, фактически использовал его, вместо этого вы скопируете его на виртуальную машину на сайте клиента.
На сайте конечного пользователя вы затем переопределите это доменное имя в их конфигурации DNS, чтобы оно указывало на локальный IP-адрес виртуальной машины.
Все это можно сделать, используя одно и то же имя для каждой виртуальной машины на каждом сайте клиента. Но использование того же имени представляет угрозу безопасности, поскольку любой из ваших клиентов будет иметь доступ к сертификату, который потенциально может быть использован против других клиентов. Вместо этого я рекомендую вам зарегистрировать доменное имя и создать поддомен для каждой виртуальной машины (не помещайте эти имена под своим обычным доменным именем, используемым для других целей). Если вы зарегистрировались example.com, вы можете использовать что-то вроде customername.example.com для каждой виртуальной машины (или замените имя клиента другим значением, если клиент не хочет, чтобы его имя отображалось в записях аудита выбранного ЦС).
Клиентов не следует заставлять использовать поддомен example.com. Вы можете сделать это для них по умолчанию. Но вы также должны разрешить клиенту указать свое собственное доменное имя, и в этом случае он также должен предоставить свой собственный сертификат. Для этой цели вы можете использовать виртуальную машину для экспорта CSR, которая может быть подписана в CA, а также реализовать интеграцию с LetsEncrypt.
Мы планируем использовать несколько вариантов, размещенных здесь.
1) Для клиентов с собственной инфраструктурой CA (ADCS или другой) мы будем использовать один из их сертификатов.
2) Для клиентов без CA, но с DNS, мы получим сертификат с подстановочными знаками для * .productname.com и попросим ИТ-отдел клиента добавить запись DNS, указывающую на нашу виртуальную машину в их сети. Насколько я понимаю, тогда мы сможем использовать этот групповой сертификат для всех клиентов этого типа.
3) Для клиентов без CA и без внутреннего DNS мы будем использовать самозаверяющие сертификаты и попросим пользователей клиентов вручную добавлять их в свои браузеры. Я надеялся избежать этого, но единственный другой вариант - использовать сертификат с подстановочными знаками с общедоступной записью DNS, указывающей на частный IP-адрес в их сети. Это приведет к утечке как информации о сетях наших клиентов (по крайней мере, IP-адрес нашего сервера), так и о нашем списке клиентов, что делает это недопустимым для нас.