Вопрос или проблема
Я настраиваю небольшую сеть с несколькими серверами, такими как vaultwarden, jenkins и gitlab.
Я хочу использовать HTTPS с сертификатом, подписанным центром сертификации. Для этого я купил домен (допустим, foobar.com) и уже получил wildcard сертификат для *.hq.foobar.com.
Когда я обращаюсь к https://vaultwarden.hq.foobar.com/, у моего браузера нет никаких претензий, и сертификат действителен.
Неудивительно, что если я обращаюсь к https://vaultwarden/, браузер предупреждает о потенциальном риске безопасности, так как выданный сертификат действителен только для доменов в *.hq.foobar.com.
Мой вопрос: есть ли способ избежать использования таких длинных имен (gitlab.hq.foobar.com, jenkins.hq.foobar.com…) для всех служб в моей сети, сохраняя при этом сертификат, доверенный общественностью?
Я хотел бы избегать использования самоподписанных сертификатов или создания частного центра сертификации и необходимости доверять любому из этих сертификатов на всех компьютерах в моей сети.
Как компании решают эту проблему? Везде, где я работал раньше, были самоподписанные сертификаты, что не кажется мне безопасным, но это было удобно.
Мой вопрос: есть ли способ избежать использования таких длинных имен (gitlab.hq.foobar.com, jenkins.hq.foobar.com…) для всех служб в моей сети, сохраняя при этом сертификат, доверенный общественностью?
Нет. NetBIOS (только имена хостов) не допускаются в Интернете PKI. Каждый сертификат выдается против имени хоста (или всех хостов в случае wildcard) в указанном домене. И вам нужно доказать право собственности на домен.
В вашем случае https://vaultwarden/ рассматривается как однозначное vaultwarden доменное имя, а не имя хоста. Одноименные домены также не допускаются, и вы не можете доказать их право собственности, и не можете их купить. Это означает, что вы не можете сделать это с сертификатом, полученным от глобально доверенного CA.
Вместо использования самоподписанных сертификатов может быть удобнее использовать частный CA, который доверен только в пределах управляемой вами среды.
Пусть короткое имя указывает на перенаправление к FQDN или обратному прокси с внутренним CA сертификатом на коротком имени.
Ответ или решение
По вашему вопросу о том, как упростить использование длинных доменных имен, таких как gitlab.hq.foobar.com или jenkins.hq.foobar.com, во время работы с публично доверенными сертификатами, следует рассмотреть несколько вариантов, которые помогут вам достичь подобной цели, сохраняя при этом легкость доступа к вашим сервисам.
1. Понимание ограничений публичных сертификатов
Прежде всего, важно понимать, что публичные сертификаты, выданные удостоверяющими центрами (ЦА), требуют, чтобы доменное имя, на которое они выданы, имело правильную структуру. Ваша нынешняя конфигурация с использованием wildcard сертификата (*.hq.foobar.com) действительно подразумевает, что вы можете обращаться к поддоменам, однако использование бездоменных имён (например, vaultwarden) создает проблемы с безопасностью и верификацией.
2. Использование локального DNS или файла hosts
Одним из наиболее простых решений является использование локального DNS-сервера или редактирование файла hosts на каждом устройстве в вашей сети. Вы можете добавить записи, чтобы сделать короткие адреса, такие как vaultwarden или gitlab, ссылающимися на их полные доменные имена (FQDN):
192.168.1.10 vaultwarden
192.168.1.11 gitlabТаким образом, пользователи смогут вводить короткие имена в браузере, не сталкиваясь с предупреждениями о безопасности. Однако стоит учитывать, что этот метод предполагает управление каждым клиентским устройством, что может быть трудоемким при большом количестве пользователей.
3. Обратный прокси
Другим эффективным решением является использование обратного прокси-сервера. Вы можете настроить, например, Nginx или Apache, чтобы он обрабатывал все запросы к коротким именам и перенаправлял их к соответствующим сервисам на их поддоменах. В этом случае, пользователи смогут обращаться к:
https://vaultwarden/И запрос будет автоматически перенаправлен на https://vaultwarden.hq.foobar.com/.
4. Частный удостоверяющий центр
Хотя вы хотите избежать использования самоподписанных сертификатов или создания частного удостоверяющего центра, этот метод по-прежнему является хорошим вариантом для внутренней сети. С помощью частного CA вы можете создавать сертификаты для коротких доменных имен и доверять этому CA на всех клиентах в вашей сети. Тем не менее, этот метод требует некоторой начальной настройки и управления, но в долгосрочной перспективе может снизить сложные проблемы с SSL-сертификатами.
Заключение
Итак, в зависимости от ваших предпочтений и требований к безопасности, вам может подойти одно из решений, описанных выше. Использование локального DNS или файла hosts подходит для небольших систем, в то время как обратный прокси представляет собой более универсальный подход для управления различными сервисами и их именами. Частный удостоверяющий центр, хотя и требует некоторого управления, может обеспечить удобный и безопасный доступ к вашим внутренним сервисам без использования длинных доменных имен.