Configurer HTTPS pour ONLYOFFICE Docs dans Docker

Pour une connexion directe à ONLYOFFICE Docs, publiez le port 443 du conteneur, stockez les fichiers de certificat dans le répertoire de données monté et configurez le conteneur pour qu'il utilise ces fichiers. Si un proxy inverse fournit déjà le protocole HTTPS, conservez la configuration TLS au niveau de ce proxy et redirigez l'hôte et le protocole d'origine vers ONLYOFFICE au lieu d'activer un second point de terminaison TLS par défaut.

Par exemple, si le nom d'hôte public est docs.example.com, commencez par déterminer s'il pointe directement vers le serveur de documents ou vers un proxy. Utilisez uniquement la configuration correspondante ci-dessous.

1. Déterminez où se termine le protocole HTTPS.

La connexion TLS s'achève là où HTTPS est déchiffré : soit dans le conteneur ONLYOFFICE, soit au niveau d'un proxy inverse. Choisissez le composant qui reçoit la connexion publique.

• Accès direct : les clients se connectent https://docs.example.comau port 443 de l’hôte, qui est mappé sur le port 443 du conteneur. Le conteneur du serveur de documents a besoin d’un certificat et de sa clé privée correspondante.
• Accès proxy : les clients se connectent au proxy via HTTPS ; le proxy achemine le trafic vers le serveur de documents via le réseau interne. Dans cette configuration, le certificat est généralement hébergé sur le proxy. Les recommandations d’ONLYOFFICE concernant les proxys préconisent la présence des en X-Forwarded-Proto- X-Forwarded-Hosttêtes `@Provider` et `@HostName` afin que l’application puisse identifier le schéma de requête public et le nom d’hôte.

Le mappage de ports 443:443ne crée pas de protocole HTTPS ; il ne fait que mapper les ports. Pour un accès direct, le conteneur doit également lire le certificat et la clé. Si le proxy est propriétaire de l'URL publique, suivez les instructions officielles d'ONLYOFFICE concernant le proxy inverse .

2. Configurer le protocole HTTPS direct dans Docker Compose

Utilisez ce chemin lorsque le conteneur sert directement le trafic HTTPS. Pour un accès public, utilisez un certificat approuvé par les clients pour le nom d'hôte public. Un certificat auto-signé peut chiffrer le trafic, mais les clients émettront un avertissement concernant l'identité du certificat, sauf s'ils sont configurés pour lui faire confiance.

ONLYOFFICE Docs stocke /var/www/onlyoffice/Data/certspar défaut les certificats à l'emplacement indiqué ci-dessous, et sa configuration Docker actuelle les définit tls.crtcomme tls.keychemins d'accès par défaut pour les certificats et les clés. Les exemples de documentation n'utilisant pas toujours des noms de fichiers identiques, cet exemple spécifie explicitement les deux chemins.

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

Ceci est un extrait, et non une définition de service de remplacement. Conservez les paramètres d'image, de JWT, de réseau et de volume existants. Par rapport au fichier Compose, placez le certificat à l'emplacement indiqué ./documentserver-data/certs/tls.crtet sa clé correspondante à l'emplacement indiqué ./documentserver-data/certs/tls.key. Incluez la chaîne de certificats fournie par votre fournisseur et assurez-vous que le certificat couvre l'ensemble des certificats docs.example.com.

Le montage de liaison maintient les fichiers hors d'un conteneur remplaçable. Limitez l'accès à la clé privée tout en vous assurant que le conteneur peut la lire ; sinon, le protocole HTTPS risque de ne pas démarrer. Ne communiquez jamais la clé dans une demande d'assistance.

3. Appliquez la modification sans remplacer accidentellement le déploiement

1. Sauvegardez le fichier Compose et le répertoire du certificat, puis vérifiez que le certificat et la clé correspondent bien au nom d'hôte public.
2. Modifiez le port, le volume et le chemin d'accès dans le service existant. Ne démarrez pas un second conteneur avec le même port hôte et ne supprimez pas les volumes existants pour appliquer TLS.
3. Recréez le service si vous avez modifié ses ports, ses points de montage ou son environnement. Avec Compose, exécutez la commande docker compose up -d documentserverdepuis le répertoire contenant le fichier Compose, en remplaçant le nom de votre service. Si vous avez uniquement remplacé des fichiers de certificat dans un répertoire déjà monté, redémarrez le conteneur existant pour que le serveur recharge les fichiers docker restart <container_name>.
4. Si la connexion HTTPS ne s'établit pas, consultez les journaux de démarragedocker logs <container_name> : recherchez les erreurs de fichier manquant, d'autorisation ou de certificat/clé avant de modifier des paramètres non liés à cela.

Un redémarrage ne permet pas d'ajouter un point de montage ni de modifier les ports publiés ; il est nécessaire de recréer le service pour effectuer ces modifications. Le remplacement de fichiers dans un point de montage persistant existant ne requiert aucune modification via Compose.

4. Conservez le protocole TLS au niveau du proxy inverse lorsqu'il gère déjà le domaine.

Si un proxy inverse est déjà arrêté https://docs.example.com, conservez sa clé privée sur le proxy. Redirigez le trafic via un réseau contrôlé et ajoutez le signe X-Forwarded-Proto: httpsplus X-Forwarded-Hostau nom d'hôte public. Utilisez l'exemple officiel fourni avec votre logiciel proxy.

Le cadenas du navigateur protège la connexion entre le client et le proxy, mais pas nécessairement chaque étape interne. Le protocole HTTP sur un réseau Docker sécurisé peut convenir à certains déploiements ; sécurisez la connexion entre le proxy et le conteneur si elle traverse un réseau non fiable.

Autre limitation : la modification du protocole TLS ne corrige pas un jeton JWT invalide, un port de pare-feu bloqué ou une adresse de serveur de documents publique incorrecte dans les paramètres d’intégration. Si le certificat est valide mais que le chargement ou la modification des documents échoue toujours, consultez les journaux de l’application et du proxy concernés plutôt que de régénérer les certificats à répétition.

Vérifier le résultat

Depuis un client ayant accès au service public, ouvrez https://docs.example.comet examinez les détails du certificat du navigateur. Vérifiez que le nom d'hôte correspond, que le certificat est valide et que le navigateur ne signale pas d'émetteur non approuvé ni d'incohérence de nom. Vous pouvez également examiner la négociation TLS depuis un terminalcurl -Iv https://docs.example.com ; analysez le certificat et les informations de connexion plutôt que de vous fier uniquement au chargement de la page.

Enfin, ouvrez un document depuis l'application intégrée. La confirmation par le navigateur indique que le point de terminaison public est valide, mais pas tous les paramètres d'intégration ni les routes internes. En cas d'avertissement de certificat, vérifiez le nom d'hôte, la chaîne de certificats, les chemins d'accès, les permissions et la terminaison TLS. Si la connexion HTTPS est établie mais que la modification échoue, consultez les journaux et les paramètres d'authentification ou de routage.

Pour plus d'informations sur les chemins Docker pris en charge, les variables de certificat et les options intégrées de Let's Encrypt, consultez la documentation d'ONLYOFFICE relative à l'installation de Docker et au protocole HTTPS . La commande exacte permettant de mettre à jour un déploiement existant dépend de sa méthode de création initiale ; veillez à conserver les volumes et les paramètres d'intégration actuels de ce déploiement tout en appliquant les modifications TLS nécessaires.