Home
» Hoe
»
HTTPS configureren voor ONLYOFFICE-documentatie in Docker
HTTPS configureren voor ONLYOFFICE-documentatie in Docker
Voor een directe verbinding met ONLYOFFICE Docs publiceert u containerpoort 443, bewaart u de certificaatbestanden in de gekoppelde gegevensmap en laat u de container naar die bestanden verwijzen. Als een reverse proxy al HTTPS biedt, behoudt u TLS op die proxy en stuurt u de oorspronkelijke host en het protocol door naar ONLYOFFICE in plaats van standaard een tweede TLS-eindpunt in te schakelen.
Als de openbare hostnaam bijvoorbeeld is docs.example.com, bepaal dan eerst of deze rechtstreeks naar de Document Server of naar een proxy verwijst. Gebruik alleen de overeenkomende configuratie hieronder.
1. Bepaal waar HTTPS eindigt.
TLS eindigt waar HTTPS wordt gedecodeerd: ofwel in de ONLYOFFICE-container of bij een reverse proxy. Kies de component die de openbare verbinding ontvangt.
Directe toegang: clients maken verbinding https://docs.example.comvia poort 443 van de host, die is gekoppeld aan poort 443 van de container. De Document Server-container heeft een certificaat en de bijbehorende privésleutel nodig.
Proxytoegang: clients maken via HTTPS verbinding met de proxy; de proxy stuurt het verkeer door naar de documentenserver via het interne netwerk. In deze configuratie bevindt het certificaat zich normaal gesproken bij de proxy. De proxyrichtlijnen van ONLYOFFICE vereisen de headers X-Forwarded-Protoen X-Forwarded-Hostzodat de applicatie het openbare aanvraagschema en de hostnaam kan identificeren.
Poorttoewijzing 443:443creëert geen HTTPS; het wijst alleen poorten toe. Voor directe toegang moet de container ook het certificaat en de sleutel lezen. Als de proxy de openbare URL beheert, raadpleeg dan de officiële instructies voor reverse-proxy 's van ONLYOFFICE .
Een map met permanente certificaten bevat een certificaatbestand en een apart bestand met de privésleutel.
2. Configureer directe HTTPS in Docker Compose
Gebruik dit pad wanneer de container rechtstreeks HTTPS aanbiedt. Voor openbare toegang gebruikt u een certificaat dat door clients wordt vertrouwd voor de openbare hostnaam. Een zelfondertekend certificaat kan het verkeer versleutelen, maar clients zullen waarschuwen voor de identiteit, tenzij ze afzonderlijk zijn geconfigureerd om het te vertrouwen.
ONLYOFFICE Docs slaat certificaten /var/www/onlyoffice/Data/certsstandaard hieronder op, en de huidige Docker-configuratie vermeldt tls.crten tls.keyals de standaardpaden voor certificaten en sleutels. De documentatievoorbeelden hebben niet altijd identieke bestandsnamen gebruikt, dus in dit voorbeeld worden beide paden expliciet ingesteld.
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
Dit is een fragment, geen vervangende servicedefinitie. Behoud de bestaande instellingen voor image, JWT, netwerk en volume. Plaats het certificaat ten opzichte van het Compose-bestand op ./documentserver-data/certs/tls.crten de bijbehorende sleutel op ./documentserver-data/certs/tls.key. Voeg de certificaatketen van uw provider toe en zorg ervoor dat het certificaat ook geldt voor docs.example.com.
De bind mount zorgt ervoor dat de bestanden zich buiten een vervangbare container bevinden. Beperk de toegang tot de privésleutel, maar zorg er wel voor dat de container deze kan lezen; anders kan HTTPS mogelijk niet opstarten. Deel de sleutel nooit in een ondersteuningsverzoek.
Het Compose-fragment koppelt hostpoort 443 en maakt de gegevensmap aan de hostzijde beschikbaar voor de container.
3. Voer de wijziging door zonder de implementatie per ongeluk te vervangen.
Maak een back-up van het Compose-bestand en de certificaatmap en controleer vervolgens of het certificaat en de sleutel overeenkomen met de openbare hostnaam.
Voer de wijzigingen aan de poort, het volume en het pad door in de bestaande service. Start geen tweede container met dezelfde hostpoort en verwijder geen bestaande volumes om TLS toe te passen.
Maak de service opnieuw aan als u de poorten, mounts of omgeving ervan hebt gewijzigd. Voer met Compose de opdracht uit docker compose up -d documentservervanuit de map waarin het Compose-bestand zich bevindt, waarbij u de daadwerkelijke servicenaam vervangt. Als u alleen certificaatbestanden in een reeds gemounte map hebt vervangen, start u de bestaande container opnieuw zodat de server de bestanden opnieuw laadt: docker restart <container_name>.
Controleer de opstartlogboeken als HTTPS niet tot stand komt: docker logs <container_name>. Zoek naar fouten met ontbrekende bestanden, machtigingen of certificaten/sleutels voordat u niet-gerelateerde instellingen wijzigt.
Een herstart kan geen mount toevoegen of gepubliceerde poorten wijzigen; maak de service opnieuw aan voor die wijzigingen. Het vervangen van bestanden in een bestaande persistente mount vereist geen wijziging via Compose.
Start de bestaande container opnieuw op nadat u de bestanden in de gekoppelde certificaatmap hebt vervangen.
4. Houd TLS ingeschakeld op een reverse proxy wanneer deze al het domein bedient.
Als een reverse proxy al is beëindigd https://docs.example.com, bewaar dan de privésleutel ervan bij de proxy. Stuur het verkeer door via een beveiligd netwerk en stel X-Forwarded-Proto: httpsde pluswaarde X-Forwarded-Hostin op de openbare hostnaam. Gebruik het officiële voorbeeld voor uw proxysoftware.
Het hangslotje in de browser dekt de verbinding tussen client en proxy, niet per se elke interne hop. HTTP op een gecontroleerd Docker-netwerk is mogelijk geschikt voor sommige implementaties; beveilig de verbinding tussen proxy en container als deze via een onbetrouwbaar netwerk loopt.
Nog een beperking: het wijzigen van TLS lost een ongeldig JWT-bestand, een geblokkeerde firewallpoort of een onjuist openbaar documentserveradres in de integratie-instellingen niet op. Als het certificaat geldig is, maar het laden of bewerken van documenten nog steeds mislukt, controleer dan de relevante applicatie- en proxylogboeken in plaats van herhaaldelijk certificaten opnieuw te genereren.
Controleer in de browser de certificaatgegevens en bevestig dat deze overeenkomen met de hostnaam die in de adresbalk wordt gebruikt.
Controleer het resultaat
Open en controleer vanaf een client die de openbare dienst kan bereiken https://docs.example.comde certificaatgegevens van de browser. Controleer of de hostnaam overeenkomt, of het certificaat nog geldig is en of de browser geen melding maakt van een onbetrouwbare uitgever of een naamverschil. U kunt de TLS-handshake ook inspecteren vanuit een terminal curl -Iv https://docs.example.com; bekijk de certificaat- en verbindingsinformatie in plaats van alleen te vertrouwen op het laden van een pagina.
Open tot slot een document vanuit de integrerende applicatie. Een succesvolle browsercontrole bevestigt het openbare eindpunt, niet elke integratie-instelling of interne route. Controleer bij certificaatwaarschuwingen de hostnaam, certificaatketen, paden, machtigingen en TLS-terminatie opnieuw. Als HTTPS wel geverifieerd is, maar bewerken mislukt, controleer dan de logboeken en de authenticatie- of routeringsinstellingen.
Voor details over de ondersteunde Docker-paden, certificaatvariabelen en ingebouwde Let's Encrypt-opties, raadpleegt u de Docker-installatie- en HTTPS-documentatie van ONLYOFFICE . De exacte opdracht om een bestaande implementatie bij te werken, hangt af van hoe deze oorspronkelijk is gemaakt; behoud de huidige volumes en integratie-instellingen van die implementatie tijdens het toepassen van de relevante TLS-wijzigingen.