Настройка HTTPS для ONLYOFFICE Docs в Docker

Для прямого подключения к ONLYOFFICE Docs опубликуйте порт контейнера 443, сохраните файлы сертификата в смонтированном каталоге данных и укажите контейнеру путь к этим файлам. Если обратный прокси-сервер уже предоставляет HTTPS, сохраните TLS на этом прокси и перенаправьте исходный хост и протокол на ONLYOFFICE вместо включения второй конечной точки TLS по умолчанию.

Например, если общедоступное имя хоста — docs.example.com, сначала определите, указывает ли оно напрямую на Document Server или на прокси-сервер. Используйте только соответствующую конфигурацию, указанную ниже.

1. Определите, где заканчивается протокол HTTPS.

Протокол TLS завершается там, где происходит расшифровка HTTPS: либо в контейнере ONLYOFFICE, либо на обратном прокси-сервере. Выберите компонент, который принимает публичное соединение.

• Прямой доступ: клиенты подключаются к https://docs.example.comпорту 443 хоста, который сопоставлен с портом 443 контейнера. Контейнеру Document Server требуется сертификат и соответствующий ему закрытый ключ.
• Доступ через прокси: клиенты подключаются к прокси по протоколу HTTPS; прокси перенаправляет трафик на Document Server по внутренней сети. В этой конфигурации сертификат обычно находится у прокси. В рекомендациях ONLYOFFICE по работе с прокси указаны заголовки X-Forwarded-Protoи X-Forwarded-Host, чтобы приложение могло идентифицировать схему публичного запроса и имя хоста.

Переадресация портов 443:443не создает HTTPS; она лишь сопоставляет порты. Для прямого доступа контейнер также должен прочитать сертификат и ключ. Если прокси-сервер владеет публичным URL-адресом, используйте официальные инструкции по настройке обратного прокси-сервера от ONLYOFFICE .

2. Настройте прямое подключение по HTTPS в Docker Compose.

Используйте этот путь, если контейнер напрямую предоставляет HTTPS-трафик. Для публичного доступа используйте сертификат, которому доверяют клиенты, для публичного имени хоста. Самоподписанный сертификат может шифровать трафик, но клиенты будут выдавать предупреждение о его подлинности, если они не настроены отдельно на доверие к нему.

В документации ONLYOFFICE /var/www/onlyoffice/Data/certsпо умолчанию хранятся указанные ниже сертификаты, а в текущей конфигурации Docker tls.crtв tls.keyкачестве путей к сертификатам и ключам указаны пути по умолчанию. В примерах документации не всегда использовались одинаковые имена файлов, поэтому в этом примере оба пути заданы явно.

services:
  documentserver:
    # Keep your existing image, environment, networks, and other settings.
    ports:
      - "443:443"
    volumes:
      - ./documentserver-data:/var/www/onlyoffice/Data
    environment:
      SSL_CERTIFICATE_PATH: /var/www/onlyoffice/Data/certs/tls.crt
      SSL_KEY_PATH: /var/www/onlyoffice/Data/certs/tls.key

Это фрагмент, а не замена определения службы. Сохраните существующие настройки образа, JWT, сети и тома. Относительно файла Compose, поместите сертификат по адресу ./documentserver-data/certs/tls.crtи соответствующий ему ключ по адресу ./documentserver-data/certs/tls.key. Включите цепочку сертификатов, предоставленную вашим поставщиком, и убедитесь, что сертификат охватывает docs.example.com.

Привязка монтирования позволяет хранить файлы вне заменяемого контейнера. Ограничьте доступ к закрытому ключу, обеспечив при этом возможность его чтения контейнером; в противном случае запуск HTTPS может завершиться неудачей. Никогда не сообщайте ключ в запросе в службу поддержки.

3. Примените изменения, не допуская случайной замены развертывания.

1. Создайте резервную копию файла Compose и каталога сертификатов, затем убедитесь, что сертификат и ключ соответствуют общедоступному имени хоста.
2. Внесите изменения в порт, том и путь в существующей службе. Не запускайте второй контейнер с тем же портом хоста и не удаляйте существующие тома для применения TLS.
3. Если вы изменили порты, точки монтирования или окружение, создайте службу заново. Для этого запустите Compose docker compose up -d documentserverиз каталога, содержащего файл Compose, заменив фактическое имя вашей службы. Если вы заменили только файлы сертификатов в уже смонтированном каталоге, перезапустите существующий контейнер, чтобы сервер перезагрузил файлы: docker restart <container_name>.
4. Если HTTPS не устанавливается, проверьте журналы запуска docker logs <container_name>. Прежде чем изменять несвязанные настройки, поищите ошибки, связанные с отсутствующими файлами, правами доступа или сертификатами/ключами.

Перезапуск не позволяет добавить точку монтирования или изменить опубликованные порты; для внесения этих изменений необходимо пересоздать службу. Замена файлов в существующей постоянной точке монтирования не требует внесения изменений в Compose.

4. Сохраняйте TLS на обратном прокси-сервере, если он уже обслуживает домен.

Если обратный прокси-сервер уже завершил работу https://docs.example.com, храните его закрытый ключ у прокси-сервера. Перенаправляйте трафик по контролируемой сети и установите X-Forwarded-Proto: httpsзначение «плюс» X-Forwarded-Hostравным публичному имени хоста. Используйте официальный пример для вашего прокси-программного обеспечения.

Замок в браузере защищает соединение между клиентом и прокси-сервером, а не обязательно каждый внутренний узел. HTTP в контролируемой сети Docker может подойти для некоторых развертываний; защитите соединение от прокси-сервера к контейнеру, если оно проходит через недоверенную сеть.

Ещё одно ограничение: изменение TLS не исправляет недействительный JWT, заблокированный порт брандмауэра или некорректный публичный адрес сервера документов в настройках интеграции. Если сертификат действителен, но загрузка или редактирование документа по-прежнему не удается, проверьте соответствующие журналы приложения и прокси-сервера, а не перегенерируйте сертификаты заново.

Проверьте результат

С клиентского компьютера, имеющего доступ к общедоступному сервису, откройте https://docs.example.comи проверьте сведения о сертификате в браузере. Убедитесь, что имя хоста совпадает, сертификат действителен в течение определенного срока, и браузер не сообщает о недоверенном издателе или несоответствии имени. Вы также можете проверить рукопожатие TLS из терминала с помощью команды `npm run src` curl -Iv https://docs.example.com; просмотрите вывод сертификата и соединения, а не полагайтесь только на то, загружается ли страница.

Наконец, откройте документ из интегрирующего приложения. Успешное открытие в браузере подтверждает общедоступную конечную точку, а не все настройки интеграции или внутренний маршрут. При появлении предупреждений о сертификатах перепроверьте имя хоста, цепочку, пути, разрешения и завершение TLS. Если HTTPS подтвержден, но редактирование не удается, проверьте журналы и настройки аутентификации или маршрутизации.

Подробную информацию о поддерживаемых путях Docker, переменных сертификатов и встроенных параметрах Let's Encrypt см. в документации ONLYOFFICE по установке Docker и HTTPS . Точная команда для обновления существующего развертывания зависит от способа его первоначального создания; сохраните текущие тома и параметры интеграции этого развертывания, одновременно применяя соответствующие изменения TLS.