Strona główna
» Jak
»
Konfigurowanie protokołu HTTPS dla dokumentów ONLYOFFICE w Dockerze
Konfigurowanie protokołu HTTPS dla dokumentów ONLYOFFICE w Dockerze
Aby nawiązać bezpośrednie połączenie z ONLYOFFICE Docs, opublikuj port kontenera 443, zachowaj pliki certyfikatów w zamontowanym katalogu danych i skieruj kontener na te pliki. Jeśli odwrotny serwer proxy obsługuje już protokół HTTPS, zachowaj protokół TLS na tym serwerze proxy i przekieruj oryginalnego hosta i protokół do ONLYOFFICE zamiast domyślnie włączać drugi punkt końcowy TLS.
Na przykład, jeśli publiczna nazwa hosta to docs.example.com, najpierw określ, czy wskazuje ona bezpośrednio na Serwer Dokumentów, czy na serwer proxy. Użyj tylko pasującej konfiguracji poniżej.
1. Zdecyduj, gdzie kończy się HTTPS
Protokół TLS kończy działanie w momencie odszyfrowania protokołu HTTPS: albo w kontenerze ONLYOFFICE, albo na odwrotnym serwerze proxy. Wybierz komponent, który odbiera połączenie publiczne.
Dostęp bezpośredni: klienci łączą się za pośrednictwem https://docs.example.comportu hosta 443, który jest mapowany na port kontenera 443. Kontener serwera dokumentów wymaga certyfikatu i odpowiadającego mu klucza prywatnego.
Dostęp przez serwer proxy: klienci łączą się z serwerem proxy przez HTTPS; serwer proxy przekierowuje ruch do serwera dokumentów przez sieć wewnętrzną. W tej konfiguracji certyfikat zazwyczaj znajduje się na serwerze proxy. Wskazówki dotyczące serwera proxy w ONLYOFFICE wymagają nagłówków X-Forwarded-Protoi X-Forwarded-Host, aby aplikacja mogła zidentyfikować publiczny schemat żądania i nazwę hosta.
Mapowanie portów 443:443nie tworzy protokołu HTTPS, a jedynie mapuje porty. Aby uzyskać dostęp bezpośredni, kontener musi również odczytać certyfikat i klucz. Jeśli serwer proxy jest właścicielem publicznego adresu URL, należy skorzystać z oficjalnych instrukcji dotyczących odwrotnego serwera proxy firmy ONLYOFFICE .
Trwały folder certyfikatów zawiera plik certyfikatu i oddzielny plik klucza prywatnego.
2. Skonfiguruj bezpośredni protokół HTTPS w Docker Compose
Użyj tej ścieżki, gdy kontener obsługuje protokół HTTPS bezpośrednio. W przypadku dostępu publicznego użyj certyfikatu, któremu klienci ufają dla publicznej nazwy hosta. Certyfikat podpisany samodzielnie może szyfrować ruch, ale klienci będą ostrzegać o tożsamości, chyba że zostaną osobno skonfigurowani tak, aby mu ufać.
/var/www/onlyoffice/Data/certsDokumentacja ONLYOFFICE domyślnie przechowuje poniższe certyfikaty , a obecna konfiguracja Dockera wskazuje tls.crti tls.keyjako domyślne ścieżki certyfikatów i kluczy. Przykłady dokumentacji nie zawsze używały identycznych nazw plików, dlatego ten przykład jawnie ustawia obie ścieżki.
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
To fragment, a nie zastępcza definicja usługi. Zachowaj istniejące ustawienia obrazu, tokenu JWT, sieci i woluminu. W odniesieniu do pliku Compose umieść certyfikat w , ./documentserver-data/certs/tls.crta odpowiadający mu klucz w ./documentserver-data/certs/tls.key. Dołącz łańcuch certyfikatów dostarczony przez dostawcę i upewnij się, że certyfikat obejmuje docs.example.com.
Montowanie powiązania utrzymuje pliki poza wymiennym kontenerem. Ogranicz dostęp do klucza prywatnego, zapewniając jednocześnie możliwość jego odczytu przez kontener; w przeciwnym razie protokół HTTPS może się nie uruchomić. Nigdy nie udostępniaj klucza w zgłoszeniu do pomocy technicznej.
Fragment Compose mapuje port hosta 443 i udostępnia kontenerowi katalog danych po stronie hosta.
3. Zastosuj zmianę, nie zastępując przypadkowo wdrożenia
Utwórz kopię zapasową pliku Compose i katalogu certyfikatów, a następnie sprawdź, czy certyfikat i klucz pasują do siebie pod względem publicznej nazwy hosta.
Wprowadź zmiany portu, woluminu i ścieżki w istniejącej usłudze. Nie uruchamiaj drugiego kontenera z tym samym portem hosta ani nie usuwaj istniejących woluminów, aby zastosować TLS.
Utwórz usługę ponownie, jeśli zmieniłeś jej porty, montowania lub środowisko. W programie Compose uruchom program docker compose up -d documentserverz katalogu zawierającego plik Compose, zastępując go rzeczywistą nazwą usługi. Jeśli zastąpiłeś pliki certyfikatów tylko w już zamontowanym katalogu, uruchom ponownie istniejący kontener, aby serwer ponownie załadował pliki: docker restart <container_name>.
Sprawdź logi uruchamiania, jeśli HTTPS się nie pojawia: docker logs <container_name>. Przed zmianą niezwiązanych z tym ustawień sprawdź, czy nie występują błędy związane z brakującymi plikami, uprawnieniami lub certyfikatami/kluczami.
Ponowne uruchomienie nie może dodać montowania ani zmienić opublikowanych portów; należy ponownie utworzyć usługę dla tych zmian. Zastąpienie plików w istniejącym, trwałym montowaniu nie wymaga zmiany w programie Compose.
Uruchom ponownie istniejący kontener po zastąpieniu plików w zamontowanym katalogu certyfikatów.
4. Zachowaj protokół TLS na odwrotnym serwerze proxy, jeśli obsługuje on już domenę
Jeśli serwer proxy odwrotny już się zakończył https://docs.example.com, zachowaj jego klucz prywatny na serwerze proxy. Przekieruj ruch przez kontrolowaną sieć i ustaw znak X-Forwarded-Proto: httpsplus X-Forwarded-Hostna publiczną nazwę hosta. Użyj oficjalnej próbki dla swojego oprogramowania proxy.
Kłódka przeglądarki obejmuje połączenie klient-serwer proxy, niekoniecznie każdy wewnętrzny przeskok. Protokół HTTP w kontrolowanej sieci Docker może pasować do niektórych wdrożeń; należy zabezpieczyć przeskok z serwera proxy do kontenera, jeśli przechodzi on przez niezaufaną sieć.
Kolejne ograniczenie: zmiana protokołu TLS nie naprawia nieprawidłowego JWT, zablokowanego portu zapory sieciowej ani nieprawidłowego publicznego adresu serwera dokumentów w ustawieniach integracji. Jeśli certyfikat jest ważny, ale ładowanie lub edycja dokumentów nadal się nie udaje, sprawdź odpowiednie logi aplikacji i serwera proxy, zamiast wielokrotnie generować certyfikaty.
W przeglądarce sprawdź szczegóły certyfikatu i upewnij się, że identyfikują one tę samą nazwę hosta, która jest używana w pasku adresu.
Sprawdź wynik
Z poziomu klienta, który ma dostęp do usługi publicznej, otwórz https://docs.example.comi sprawdź szczegóły certyfikatu przeglądarki. Upewnij się, że nazwa hosta jest zgodna, certyfikat nie narusza okresu ważności i przeglądarka nie zgłasza niezaufanego wystawcy ani niezgodności nazw. Możesz również sprawdzić uzgadnianie TLS z poziomu terminala za pomocą curl -Iv https://docs.example.com; sprawdź certyfikat i dane wyjściowe połączenia, zamiast polegać tylko na tym, czy strona się załadowała.
Na koniec otwórz dokument z aplikacji integrującej. Powodzenie przeglądarki potwierdza publiczny punkt końcowy, a nie każde ustawienie integracji lub trasę wewnętrzną. W przypadku ostrzeżeń dotyczących certyfikatów sprawdź ponownie nazwę hosta, łańcuch, ścieżki, uprawnienia i zakończenie TLS. Jeśli weryfikacja HTTPS powiedzie się, ale edycja się nie powiedzie, sprawdź logi oraz ustawienia uwierzytelniania lub routingu.
Szczegółowe informacje na temat obsługiwanych ścieżek Dockera, zmiennych certyfikatów i wbudowanych opcji Let's Encrypt można znaleźć w dokumentacji instalacji Dockera i protokołu HTTPS ONLYOFFICE . Dokładne polecenie aktualizacji istniejącego wdrożenia zależy od sposobu jego pierwotnego utworzenia; należy zachować bieżące woluminy i ustawienia integracji wdrożenia podczas stosowania odpowiednich zmian protokołu TLS.