Браузер ругается на внутренний GitLab? Разбираемся с SSL без лишних трат

Красный экран браузера с надписью «Ваше подключение не защищено» на внутреннем корпоративном сервисе — одна из тех вещей, которые я лично терпеть не могу. Не потому что страшно, а потому что это раздражает людей, снижает доверие к инструментам и периодически вообще блокирует работу. За несколько лет я перепробовал все варианты — и самоподписанные сертификаты, и Let's Encrypt, и корпоративный CA. Расскажу, что в итоге работает, а что создаёт только видимость решения.

Почему браузер ругается на внутренние сервисы — и почему это не мелочь

Открываешь GitLab, Nextcloud или корпоративный портал — и вместо нужной страницы получаешь красный экран. Пользователи начинают звонить, спрашивать «всё ли нормально». Кто-то нажимает «Принять риск» и работает дальше, кто-то просто закрывает вкладку и идёт разбираться лично. Это не вопрос эстетики. Это вопрос доверия к инструменту.

Chrome, начиная с версии 94, принудительно переходит на HTTPS для всех адресов, которые похожи на что-то серьёзное. Корпоративные домены, IP-адреса в диапазоне 192.168.x.x, имена вида gitlab.company.local — всё попадает под раздачу. Firefox чуть мягче, но ненадолго. Edge, которым в итоге пользуется половина офиса на Windows 11, работает на хромиумовском движке — то есть всё то же самое. А начиная с Chrome 99 кнопка «Принять риск» на некоторых ошибках вообще исчезла.

У меня был клиент — небольшая юридическая контора на 12 человек. Подняли им Nextcloud для внутреннего документооборота без сертификата. Полгода все нажимали «Принять риск» и привыкли. Потом обновился Chrome — и кнопка пропала. Зайти стало невозможно. Приехали, за три часа настроили корпоративный CA, раскатили корневой сертификат через групповую политику — и всё заработало. Три часа работы против шести месяцев раздражения.

Три пути — и почему два из них создают больше проблем, чем решают

Когда видишь предупреждение на внутреннем сервисе, мозг предлагает три варианта. Первый — сделать самоподписанный сертификат. Второй — взять Let's Encrypt. Третий — поднять собственный корневой центр сертификации. Все три технически работают. Но опыт показывает: два из трёх создают новые головные боли.

Самоподписанный — это когда сервер сам себе выдаёт справку о надёжности. Как если бы человек написал себе рекомендательное письмо. Браузер понимает это и говорит: «Не верю». Для одноразового теста или локального контейнера на машине разработчика — ещё куда ни шло. Но как только к сервису обращаются три и больше человека — начинается боль. Каждому надо объяснять, как добавить исключение. На телефонах это отдельный квест. Через полгода сертификат истекает — и всё повторяется сначала. Снова. Каждый раз.

Let's Encrypt — отличный сервис, я сам его использую для публичных сайтов. Бесплатно, автоматически, 90 дней и продление через certbot. Но для внутренней инфраструктуры он работает только при одном условии: домен должен быть публичным. Если у вас gitlab.company.local или сервер на адресе 192.168.1.50 — Let's Encrypt не выдаст сертификат. Публичные центры сертификации не подписывают приватные адреса — это политика, а не баг.

Когда Let's Encrypt всё-таки подходит для внутренних сервисов

Есть один легальный способ получить сертификат Let's Encrypt на внутренний сервис — DNS-01 challenge. Это когда вместо HTTP-запроса к вашему серверу Let's Encrypt проверяет TXT-запись в DNS. Вы добавляете запись — они убеждаются, что домен ваш — выдают сертификат. Сам сервер при этом может вообще не иметь выхода в интернет.

Но есть условие. Домен должен быть настоящим публичным: company.ru или company.com, а не company.local. И нужен DNS-провайдер с API — Cloudflare, Route53, Reg.ru, Selectel DNS и ещё пара десятков. Certbot работает с ними через плагины. Схема: сервер закрыт, домен публичный, сертификат выдаёт Let's Encrypt, браузеры его знают и доверяют без каких-либо дополнительных настроек на клиентах. Красивое решение, если всё сходится.

Я так делаю для клиентов, у которых уже есть нормальный публичный домен и вменяемый DNS-провайдер. Пример: небольшая медклиника, внутренний Nextcloud на nextcloud.clinic-name.ru, IP сервера 192.168.10.20, снаружи недоступен. DNS у них на Cloudflare. Настроили certbot с плагином certbot-dns-cloudflare, автообновление через systemd timer — и всё. Пользователи видят зелёный замочек, никаких вопросов ни от врачей, ни от администраторов. Стоимость: ноль рублей за сертификат плюс час нашей работы.

Корпоративный CA — когда это единственный правильный ответ

Если у вас домен .local, несколько серверов, RDP-сессии и VPN — корпоративный CA это то, что нужно. Один раз поднял, один раз раскатил корневой сертификат по машинам — дальше новые сертификаты выпускаешь сам, бесплатно, без зависимости от интернета и без каких-либо ограничений на адреса. Хоть 192.168.x.x, хоть company.local, хоть отдельный поддомен для каждого сервиса.

Что такое корпоративный CA? Это ваш собственный центр сертификации. Программа, которая хранит корневой сертификат и умеет им подписывать другие. Когда браузер видит сертификат, подписанный вашим CA, он проверяет: «Знаю ли я этот корневой CA?» Если да — доверяет. Вот и весь механизм. Главное — один раз добавить ваш корневой сертификат в доверенные на всех устройствах.

Инструментов несколько. На Windows Server есть встроенная роль Active Directory Certificate Services (AD CS) — полноценный корпоративный CA с глубокой интеграцией в домен. Мощный вариант, но требует Windows Server и Active Directory. Для небольших офисов без домена или с Linux-серверами есть step-ca от Smallstep — открытый проект с автообновлением через ACME-протокол, как Let's Encrypt, только внутри сети. И совсем базовый вариант — OpenSSL, командная строка, никаких зависимостей, работает везде. Именно с него и начну.

Как поднять CA на OpenSSL: практический минимум

OpenSSL есть на любом Linux — Ubuntu, Debian, CentOS, без разницы. Никакой установки дополнительного ПО, никаких лицензий, никаких подписок. Занимает полтора-два часа в первый раз, потом работает годами без вашего участия.

Сначала создаём корневой ключ и сертификат. Команда для ключа: openssl genrsa -aes256 -out rootCA.key 4096. Затем сам корневой сертификат: openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 3650 -out rootCA.crt. Срок 3650 дней — это десять лет. Корневой CA делают долгосрочным, чтобы не перераскатывать доверие каждые два года по всем машинам. Файл rootCA.crt — это то, что потом добавляется на все устройства в доверенные.

Для каждого сервиса — отдельный сертификат. Генерируете CSR с именем сервиса: gitlab.company.local, nextcloud.company.local, rdp.company.local. Подписываете корневым ключом. Получаете готовую пару .key + .crt. Nginx, Apache, Nextcloud, GitLab — все умеют принять именно такой формат. Важный момент, который нельзя пропустить: в конфиге OpenSSL обязательно прописывайте subjectAltName = DNS:gitlab.company.local, IP:192.168.1.100. Современные браузеры смотрят только на SAN — поле CN им давно неинтересно. Если забыть SAN — Chrome всё равно будет ругаться, даже при идеальном во всём остальном сертификате.

Раскатываем доверие: как добавить корневой сертификат на все машины

Самое важное и при этом чаще всего забываемое. Мало выпустить правильный сертификат — нужно убедить каждый браузер и каждую ОС, что вашему CA можно доверять. Иначе будут те же красные экраны, просто с другим текстом ошибки.

Если у вас домен Active Directory — всё просто. Открываете «Управление групповой политикой», редактируете нужный GPO, идёте в Computer Configuration → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certification Authorities, импортируете rootCA.crt. После gpupdate /force все Windows-машины в домене автоматически получают ваш CA в доверенные. Edge и Chrome читают системное хранилище Windows — сразу начинают доверять. Без перезагрузки, без ручных действий от пользователей.

Firefox — отдельная история. Он не читает системное хранилище Windows по умолчанию. Нужно либо прописать путь к сертификату через политику GPO специально для Firefox через файл policies.json или ADMX-шаблоны Mozilla, либо попросить пользователей один раз зайти в Настройки → Конфиденциальность → Просмотр сертификатов и добавить вручную. Мы обычно раскладываем policies.json через ту же GPO — занимает около двадцати минут на настройку, потом работает само.

Для Linux-машин корневой сертификат копируется в /usr/local/share/ca-certificates/ и запускается update-ca-certificates. На macOS — через Keychain Access или командой security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain rootCA.crt. На мобильных устройствах чуть сложнее: Android позволяет установить пользовательский CA через настройки безопасности, iOS требует профиля конфигурации с явным включением доверия. Если у вас есть MDM вроде Microsoft Intune или Jamf — раскатывается на все устройства за пять минут и без участия пользователей.

Типичные ошибки, на которых обжигаются даже опытные

Самый частый косяк — забывают прописать Subject Alternative Name. Повторю ещё раз, потому что это действительно убивает людей: Chrome, Edge и Safari давно не смотрят на поле CN. Им нужен SAN. Если выпустить сертификат только с CN=gitlab.company.local без явного SAN в расширениях — браузер выдаст ошибку NET::ERR_CERT_COMMON_NAME_INVALID. Всегда прописывайте subjectAltName в конфиге. Если уже выпустили без него — перевыпускайте, другого варианта нет.

Второй косяк — сроки. Серверный сертификат делают на год, потом забывают. Я сам пару раз так попадал в начале. Теперь либо ставлю напоминание в календаре за месяц до истечения, либо — лучше — использую step-ca с ACME, который обновляет сертификаты автоматически точно так же, как certbot обновляет Let's Encrypt. Для офисов с несколькими серверами это сейчас мой первый выбор: поднимаем step-ca, раздаём доступ по ACME, и все сертификаты обновляются сами каждые 90 дней. Никаких авралов.

Третий — корневой сертификат с коротким сроком. Видел такое: системный администратор сделал root CA на один год. Через год всё умерло одновременно — и корневой, и все выпущенные под ним сертификаты. Раскатывать новый CA по всем машинам пришлось в авральном режиме в пятницу вечером. Хорошего было мало. Правило простое: root CA — на десять-пятнадцать лет, серверные сертификаты — на один-два года.

И последнее: приватный ключ корневого CA не должен лежать на том же сервере, где всё остальное. Если rootCA.key похитят — весь ваш PKI под угрозой: злоумышленник может выдать себе доверенный сертификат на любое имя в вашей сети. Идеально: отдельная виртуалка только для CA, без открытых портов снаружи, с регулярным бэкапом ключа в зашифрованном виде. Мы обычно делаем задание Veeam на бэкап этой VM и дополнительно экспортируем ключ в запароленный архив на отдельный диск. Потеряете ключ — придётся перевыпускать всё с нуля и снова раскатывать доверие по всем машинам.

Частые вопросы

Можно ли использовать Let's Encrypt для сервера без выхода в интернет?
Да, через DNS-01 challenge. Ваш сервер может быть полностью изолирован от интернета, но вам нужен публичный домен — не .local — и доступ к API вашего DNS-провайдера. Certbot запрашивает сертификат через TXT-запись в DNS, а не через HTTP-запрос к серверу. Если ваш DNS-провайдер поддерживается — Cloudflare, Route53, Selectel DNS и многие другие — работает без проблем и продлевается автоматически.

Сколько времени занимает настройка корпоративного CA с нуля?
На OpenSSL — от полутора до трёх часов, включая настройку первого сервиса и раскатку корневого сертификата через GPO. На step-ca примерно столько же, но потом проще жить — автообновление сертификатов встроено. На Windows AD CS с нуля — около дня, если первый раз. Мы обычно закладываем полдня на типовой офис до тридцати рабочих мест.

Как это работает на смартфонах сотрудников?
На корпоративных устройствах под управлением MDM — автоматически, через профиль конфигурации. На личных смартфонах придётся попросить установить корневой сертификат вручную: Android через Настройки → Безопасность → Установить из памяти, iOS через открытие файла .crt и явное включение доверия в Настройки → Основные → Об устройстве → Доверие сертификату. Звучит страшно, но на практике занимает две минуты.

Что выбрать: AD CS, step-ca или OpenSSL?
AD CS — если у вас домен Active Directory на двадцать и более человек: тесная интеграция с GPO, автоматическое распространение сертификатов, поддержка смарт-карт. Step-ca — если нет домена или инфраструктура смешанная: Linux, Windows, Mac, и вы хотите автообновление без ручного труда. OpenSSL — когда нужно быстро, без лишних зависимостей, и обслуживать будет технический человек, которому не лень изредка перевыпустить сертификат вручную.