Вопрос или проблема
В моей (большой) компании я настраиваю веб-сервер на внутренней машине. Я хочу, чтобы сервер поддерживал SSL прозрачно. К нему могут получить доступ только пользователи по VPN, и его имя (foo.mycompany.com
) разрешается только внутренним DNS в VPN. Машина может выходить в Интернет, если это поможет.
Компания предоставляет систему самосертификации, но (насколько я могу судить) сертификаты все цепляются к доверенному внутреннему корневому сертификату. Этот корневой сертификат автоматически устанавливается на машины, которые управляются ИТ, но неуправляемые машины, находящиеся в VPN, должны вручную установить этот сертификат, чтобы SSL работал. Я пытаюсь выяснить, есть ли безопасное и действительное решение, которое НЕ требует от пользователей неуправляемых машин вручную устанавливать сертификат.
Я понимаю, что LetsEncrypt не является вариантом, поскольку сервер недоступен извне VPN. Я прав, полагая, что все другие общедоступные доверенные корни будут вести себя так же, что если они не могут подтвердить личность сервера, они не предоставят доверенный сертификат?
Есть ли способ получить сертификат, который будет доверен всеми клиентами, без необходимости вручную устанавливать корневой сертификат компании?
Я понимаю, что LetsEncrypt не является вариантом, поскольку сервер недоступен извне VPN. Я прав, полагая, что все другие общедоступные доверенные корни будут вести себя так же, что если они не могут подтвердить личность сервера, они не предоставят доверенный сертификат?
Прежде всего, проверка подлинности сервера не требует доступа к серверу, поскольку на самом деле не сервер проверяется; то, что на самом деле сертифицируют УЦ, это просто имя (право собственности или хотя бы контроль над ним), контроль над HTTP-сервером за этим именем является его прокси. Но есть и другие способы доказать контроль над доменным именем помимо создания прямого подключения к серверу.
Например, Let’s Encrypt поддерживал проверки на основе DNS на протяжении большей части своего существования как альтернативу проверке HTTP. Вы можете получить сертификат для любого доменного имени, над которым вы можете доказать контроль DNS (при условии, что вы можете автоматизировать обновления DNS).
Многие другие УЦ (например, Sectigo) подтверждают только базовый домен, а не отдельные поддомены, и после того, как вы пройдете ежегодную процедуру DV (которая в наши дни также чаще основывается на DNS), вы можете использовать эту учетную запись для заказа сертификатов для любого поддомена, даже тех, которые не существуют в публичном DNS.
Но поскольку у серверов нет внутренней идентичности, вы также можете внешне указывать доменное имя на другой IP-адрес другого сервера (используя представления DNS) и дать этому серверу использовать HTTP-проверку для получения сертификата, а затем автоматически развернуть его на внутреннем сервере.
Ответ или решение
Установка доверенного SSL-сертификата на внутреннем сервере компании
Ваша задача по установке веб-сервера на внутренней машине компании с поддержкой SSL представляет собой вызов, особенно в условиях ограничения доступа к ресурсам VPN и требуемой надежности сертификатов. Рассмотрим наиболее подходящие решения с учётом вашего контекста.
Понимание текущей ситуации
Вы настроили веб-сервер, который доступен только для пользователей, подключённых к VPN, и имеет имя домена foo.mycompany.com
, разрешаемое только внутренней DNS-системой. Ваша компания предлагает внутреннюю систему самосертификации, однако это требует, чтобы пользователи с unmanaged-устройствами вручную устанавливали корневой сертификат, что нежелательно.
Вы правы в том, что сертификаты Let’s Encrypt не подойдут в этой ситуации, так как сервер не доступен извне, и большинство публичных центров сертификации (CA) также не смогут выдать сертификат, если не могут проверить домен.
Альтернативные способы получения сертификата
1. Использование DNS-валидации
Некоторые CA, включая Let’s Encrypt, поддерживают DNS-валидацию для подтверждения контроля над доменным именем. Вы можете воспользоваться этой функцией, создав TXT-запись в DNS, чтобы подтвердить свои полномочия на домен foo.mycompany.com
. Вот как это можно реализовать:
- Выберите CA, поддерживающий DNS-валидацию, например, Let’s Encrypt или Sectigo.
- Настройте DNS-запись для домена
foo.mycompany.com
, согласно инструкциям выбранного CA. - После получения сертификата настройте автоматическое обновление его на вашем внутреннем сервере.
Это решение позволит вам избежать необходимости вручную устанавливать сертификаты для unmanaged-устройств.
2. Использование внешнего сервера для валидации
Если у вас есть доступ к другому серверу, который доступен из интернета, вы можете использовать его для получения сертификата:
- Настройте временную сопоставляемость вашего домена
foo.mycompany.com
с IP-адресом внешнего сервера. - На внешнем сервере выполните процесс подтверждения и получите сертификат (например, через HTTP-валидацию).
- После успешного получения сертификата обновите DNS-запись обратно на внутренний сервер и установите полученный сертификат на ваш веб-сервер в их внутренней сети.
Это обеспечивает автоматизированный процесс получения сертификата, минуя необходимость в ручной установке корневого сертификата пользователями.
3. Модификация внутренней политики
Если ни одно из вышеперечисленных решений не подходит или выходит за рамки текущих возможностей, рекомендуется обсудить с IT-отделом возможность изменения внутренней политики по установке сертификатов. Один из вариантов — рассмотреть автоматизированное развертывание корневого сертификата на unmanaged-устройствах через соответствующие скрипты или инструменты управления.
Заключение
Хотя ваша ситуация ограничивает возможности установки стандартных SSL-сертификатов, правильное понимание процедур валидации и возможности автоматизации значительно могут помочь. Выбор DNS-валидации или использование внешнего сервера способствуют получению сертификата, который будет всем клиентам без необходимости ручной установки корневого сертификата. Важно учитывать, что реализация любого из предложенных решений должна вестись в рамках корпоративных политик безопасности и IT-управления.