Configurați HTTPS pentru ONLYOFFICE Docs în Docker

Pentru o conexiune directă la ONLYOFFICE Docs, publicați portul 443 al containerului, păstrați fișierele de certificat în directorul de date montat și direcționați containerul către acele fișiere. Dacă un proxy invers oferă deja HTTPS, păstrați TLS la acel proxy și redirecționați gazda și protocolul originale către ONLYOFFICE în loc să activați un al doilea punct final TLS în mod implicit.

De exemplu, dacă numele public de gazdă este docs.example.com, stabiliți mai întâi dacă indică direct către serverul de documente sau către un proxy. Folosiți doar configurația corespunzătoare de mai jos.

1. Decideți unde se termină HTTPS

TLS se termină acolo unde HTTPS este decriptat: fie în containerul ONLYOFFICE, fie la un proxy invers. Alegeți componenta care primește conexiunea publică.

• Acces direct: clienții se conectează la https://docs.example.comportul 443 al gazdei, care este mapat la portul 443 al containerului. Containerul Document Server are nevoie de un certificat și de cheia privată corespunzătoare.
• Acces proxy: clienții se conectează la proxy prin HTTPS; proxy-ul redirecționează traficul către Document Server prin rețeaua internă. În această configurație, certificatul aparține în mod normal proxy-ului. Ghidul proxy ONLYOFFICE solicită anteturile X-Forwarded-Protoși , X-Forwarded-Hostastfel încât aplicația să poată identifica schema de solicitare publică și numele de gazdă.

Maparea porturilor 443:443nu creează HTTPS; aceasta doar mapează porturile. Pentru acces direct, containerul trebuie să citească și certificatul și cheia. Dacă proxy-ul deține adresa URL publică, utilizați instrucțiunile oficiale de reverse-proxy ale ONLYOFFICE .

2. Configurați HTTPS direct în Docker Compose

Folosește această cale atunci când containerul deservește direct HTTPS. Pentru acces public, folosește un certificat în care clienții au încredere pentru numele de gazdă public. Un certificat autosemnat poate cripta traficul, dar clienții vor avertiza despre identitate, cu excepția cazului în care sunt configurați separat să aibă încredere în acesta.

ONLYOFFICE Docs stochează certificatele de mai jos /var/www/onlyoffice/Data/certsîn mod implicit, iar configurația sa Docker curentă listează tls.crtși tls.keyca căi implicite pentru certificate și chei. Exemplele de documentație nu au folosit întotdeauna nume de fișiere identice, așa că acest exemplu setează ambele căi în mod explicit.

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

Acesta este un extras, nu o definiție de serviciu care înlocuiește. Păstrați setările existente pentru imagine, JWT, rețea și volum. Relativ la fișierul Compose, plasați certificatul la ./documentserver-data/certs/tls.crtși cheia corespunzătoare la ./documentserver-data/certs/tls.key. Includeți lanțul de certificate furnizat de furnizorul dvs. și asigurați-vă că certificatul acoperă docs.example.com.

Montarea prin legare păstrează fișierele în afara unui container înlocuibil. Restricționați accesul la cheia privată, asigurându-vă în același timp că containerul o poate citi; altfel, HTTPS ar putea eșua să pornească. Nu partajați niciodată cheia într-o solicitare de asistență.

3. Aplicați modificarea fără a înlocui accidental implementarea

1. Faceți o copie de rezervă a fișierului Compose și a directorului de certificate, apoi confirmați că certificatul și cheia sunt perechea potrivită pentru numele de gazdă public.
2. Efectuați modificările portului, volumului și căii în serviciul existent. Nu porniți un al doilea container cu același port gazdă și nu eliminați volumele existente pentru a aplica TLS.
3. Recreați serviciul dacă ați modificat porturile, montările sau mediul acestuia. Cu Compose, rulați docker compose up -d documentserverdin directorul care conține fișierul Compose, înlocuind numele real al serviciului. Dacă ați înlocuit doar fișierele de certificat dintr-un director deja montat, reporniți containerul existent, astfel încât serverul să reîncarce fișierele: docker restart <container_name>.
4. Verificați jurnalele de pornire dacă HTTPS nu apare:. docker logs <container_name>Căutați erori de fișiere, permisiuni sau certificate/chei lipsă înainte de a modifica setările care nu au legătură cu acestea.

O repornire nu poate adăuga o montare sau modifica porturile publicate; recreați serviciul pentru acele modificări. Înlocuirea fișierelor dintr-o montare persistentă existentă nu necesită o modificare Compose.

4. Păstrați TLS la un proxy invers atunci când acesta deservește deja domeniul

Dacă un proxy invers se termină deja https://docs.example.com, păstrați cheia sa privată la proxy. Redirecționați traficul printr-o rețea controlată și setați X-Forwarded-Proto: httpssemnul plus X-Forwarded-Hostla numele de gazdă public. Folosiți exemplul oficial pentru software-ul dvs. proxy.

Lacătul browserului acoperă conexiunea client-proxy, nu neapărat fiecare salt intern. HTTP pe o rețea Docker controlată se poate potrivi unor implementări; securizați saltul proxy-container dacă acesta traversează o rețea neîncrezătoare.

O altă limită: modificarea TLS nu repară un JWT invalid, un port firewall blocat sau o adresă publică incorectă a serverului de documente în setările de integrare. Dacă certificatul este valid, dar încărcarea sau editarea documentelor eșuează în continuare, verificați jurnalele relevante ale aplicației și proxy-ului, în loc să regenerați în mod repetat certificatele.

Verificați rezultatul

De la un client care poate accesa serviciul public, deschideți https://docs.example.comși inspectați detaliile certificatului browserului. Confirmați că numele gazdei se potrivește, că certificatul se află în perioada de valabilitate și că browserul nu raportează un emitent neîncrezător sau o nepotrivire de nume. De asemenea, puteți inspecta handshake-ul TLS de la un terminal cu curl -Iv https://docs.example.com; verificați rezultatul certificatului și al conexiunii, în loc să vă bazați doar pe încărcarea unei pagini.

În final, deschideți un document din aplicația de integrare. Succesul browserului confirmă endpoint-ul public, nu fiecare setare de integrare sau rută internă. Pentru avertismentele privind certificatul, verificați din nou numele gazdei, lanțul, căile, permisiunile și terminarea TLS. Dacă HTTPS se verifică, dar editarea eșuează, verificați jurnalele și setările de autentificare sau rutare.

Pentru detalii despre căile Docker acceptate, variabilele de certificat și opțiunile Let's Encrypt încorporate, consultați documentația de instalare Docker și HTTPS de la ONLYOFFICE . Comanda exactă pentru actualizarea unei implementări existente depinde de modul în care a fost creată inițial; păstrați volumele actuale ale implementării și setările de integrare în timp ce aplicați modificările TLS relevante.