Один сертификат для системы, встреч и TURN: самоподписанный, Let's Encrypt или свой сертификат организации; прокси организации, FRONTEND_URL и кластер.
Обновлено 24.10.2026
После установки volrix.pm открывается по адресу http://<адрес сервера>:3000. Для рабочей эксплуатации нужен HTTPS: без него пароли и документы идут по сети открытым текстом. Сертификат у сервера один: его получают адрес системы, адрес видеовстреч и имя TURN на 443. Источник выбирается на одном экране, «Настройки продукта» → «Сертификаты TLS»: встроенный веб-сервер Caddy сам получает и продлевает сертификат Let's Encrypt, вы загружаете сертификат своего центра сертификации, или (пока ничего не выбрано) система сама выпускает самоподписанный. Есть и четвертый путь: HTTPS завершает прокси вашей организации - так делают в закрытом контуре. В отказоустойчивом кластере HTTPS устроен иначе - см. раздел «HTTPS в кластере» ниже.
В поставке есть контейнер volrix-frontend - веб-сервер Caddy. Он отдает интерфейс, передает запросы /api на backend и слушает порты 80, 443 и 3000 (на 3000 - тот же сайт, что на 80). Сертификат Caddy не хранит: при каждом TLS-подключении он спрашивает его у backend (get_certificate), поэтому замена сертификата на экране действует сразу, без перезапуска, - в том числе для TURN на 443 и при входе по IP-адресу. Для Let's Encrypt Caddy выпускает сертификат по требованию (on-demand TLS): при первом HTTPS-обращении к имени он спрашивает backend по адресу /api/v1/tls/authorize, можно ли выпускать сертификат. Backend разрешает, только если включен автовыпуск, не выбран свой сертификат и имя точно совпадает с доменным именем из настроек, адресом видеовстреч или именем TURN на 443, - поэтому сертификат не выпустится для чужого имени, направленного на ваш сервер. Адрес выдачи сертификата закрыт снаружи и защищен токеном TLS_CERT_FETCH_TOKEN из .env (новые установки получают его сами); закрытые ключи хранятся зашифрованными ключом SECRET_KEY.
Не включайте автовыпуск, если HTTPS завершает прокси организации: два независимых механизма выпуска на одном имени не нужны, а сертификат Let's Encrypt для имени, которое указывает на прокси, все равно не выпустится.
На 443 к серверу приходят под разными именами. Все они получают один сертификат; блок «Имена сервера» на экране показывает каждое имя, его назначение и есть ли оно в сертификате.
Chrome не подключается к TURN по TLS с сертификатом, которому не доверяет, и согласие на странице сайта на TURN не распространяется. Поэтому для участников из закрытых сетей нужен сертификат организации с корневым, которому доверяют их машины, или Let's Encrypt.
Где находится: «Администрирование» → «Настройки продукта» → «Сертификаты TLS». Нужно право «TLS-сертификаты - Настройки TLS-сертификатов» (по умолчанию только у администратора системы).
Продление автоматическое: Caddy обновляет сертификат заранее, без участия администратора. Сертификаты и ключи хранятся в томе caddy_data и переживают перезапуск контейнера.
Форма требует e-mail, но в стандартном frontend/Caddyfile строка email закомментирована, и Caddy этот адрес не получает. На выпуск и продление это не влияет.
У Let's Encrypt есть лимиты на число выпусков для домена. Чтобы отладить схему, не расходуя их, запустите Caddy с тестовым центром сертификации: добавьте строку в .env каталога установки и пересоздайте контейнер frontend. Сертификату тестового центра браузер не доверяет - после проверки удалите строку и снова пересоздайте контейнер.
# в .env ACME_CA=https://acme-staging-v02.api.letsencrypt.org/directory # применить docker compose -f docker-compose.release.yml up -d frontend
**Где находится:** «Администрирование» → «Настройки продукта» → «Сертификаты TLS», вверху «Источник сертификата» → «Свой сертификат». Нужно то же право, что для Let's Encrypt. Подходит, когда сертификат выпускает центр сертификации вашей организации (или куплен), а HTTPS завершает сам volrix.pm без отдельного прокси.
Ключ хранится зашифрованным и в интерфейс не отдается. Пока выбран свой сертификат, Let's Encrypt сертификаты не выпускает; загруженный сертификат при переключении остается, и к нему можно вернуться кнопкой «Использовать загруженный сертификат». «Удалить свой сертификат» возвращает самоподписанный. Если раньше на этом домене работал Let's Encrypt, после перехода на свой сертификат один раз выполните docker restart volrix-frontend: Caddy держит выпущенный сертификат в памяти.
Сертификат один на все имена: разные сертификаты для адреса системы и для имени TURN не поддерживаются - нужны все имена в одном сертификате или маска на весь домен. Пока backend перезапускается (обновление), новые TLS-подключения, включая TURN на 443, не устанавливаются; уже открытые не рвутся.
Если сервер не виден из интернета или сертификаты выпускает корпоративный центр, HTTPS завершает прокси организации (nginx, HAProxy, балансировщик). На нем - сертификат и ключ для имени, например pm.corp.local, а к серверу volrix.pm прокси обращается по HTTP на порт 80. Автовыпуск на экране «Сертификаты TLS» оставьте выключенным - состояние «Выключено»; если прокси не нужен, загрузите сертификат на экран (вариант 2).
server { listen 443 ssl; server_name pm.corp.local; ssl_certificate /etc/nginx/tls/pm.corp.local.crt; ssl_certificate_key /etc/nginx/tls/pm.corp.local.key; client_max_body_size 1024m; location / { proxy_pass http://10.0.0.5:80; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto https; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 300s; } }
# frontend/Caddyfile, глобальный блок в начале файла { servers { trusted_proxies static 10.0.0.10/32 } # ... остальные строки блока без изменений }
В примерах 10.0.0.5 - сервер volrix.pm, 10.0.0.10 - прокси организации. Замените на свои адреса. После правки Caddyfile выполните docker compose -f docker-compose.release.yml up -d --force-recreate frontend.
Backend не знает, по какому адресу пользователь открыл сайт, - публичный адрес он берет из переменной FRONTEND_URL в файле .env каталога установки. От нее зависят ссылки в письмах, адрес возврата для OIDC и защита cookie: если FRONTEND_URL начинается с https://, cookie сессии получает признак Secure автоматически, отдельно включать AUTH_COOKIE_SECURE не нужно. Установщик записывает туда http://<адрес>:3000 - после перехода на HTTPS адрес нужно заменить.
# в .env FRONTEND_URL=https://pm.example.ru # применить: пересоздаются контейнеры, у которых изменились настройки docker compose -f docker-compose.release.yml up -d
После перехода открывайте систему только по https-адресу. Старый адрес http://<сервер>:3000 продолжает открываться (Caddy не перенаправляет HTTP на HTTPS), но cookie с признаком Secure браузер по HTTP не сохраняет: после обновления страницы или через полчаса работы снова появится форма входа. Сообщите сотрудникам новый адрес и закройте порт 3000.
Backend видит не браузер пользователя, а ближайший прокси - в стандартной поставке это контейнер Caddy (volrix-frontend). Настоящий адрес пользователя приходит в заголовке X-Forwarded-For, но backend доверяет ему только от адресов из TRUSTED_PROXY_CIDRS; в docker-compose.release.yml по умолчанию это 127.0.0.1/32,::1/128, то есть адреса Caddy там нет. Тогда все запросы выглядят пришедшими с одного адреса: в журнале аудита у всех один IP, а ограничение «не больше 5 попыток входа в минуту с одного адреса» становится общим на всю организацию.
docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' volrix-frontend # в .env (вариант 1) TRUSTED_PROXY_CIDRS=172.21.0.4/32 # в .env (вариант 2) TRUSTED_PROXY_CIDRS=172.21.0.4/32,10.0.0.10/32
В отказоустойчивом кластере HTTPS завершает HAProxy на балансировщиках, а не Caddy: он слушает порт 443, запросы на порт 80 перенаправляет на HTTPS (код 301) и добавляет в ответы заголовок Strict-Transport-Security. Caddy на узлах приложения работает без HTTPS. Поэтому экран «Сертификаты TLS» с выпуском Let's Encrypt в кластере не используется, а FRONTEND_URL и доверенные адреса прокси мастер установки прописывает сам.
Заменить самоподписанный сертификат на сертификат организации можно позже: загрузите его на шаге «Точка входа» и снова нажмите «Развернуть» - см. Установка.
Если на основном домене организации включен HSTS для поддоменов, браузер не даст открыть систему с самоподписанным сертификатом. Нужен сертификат организации; до его загрузки работайте по виртуальному IP-адресу.
Каталог установки, .env и первые команды.
Адрес возврата зависит от FRONTEND_URL.
Проверить адреса пользователей после настройки.