Napraw błąd uzgadniania protokołu Kopano SSL na porcie niestandardowym

Zdefiniuj, jak wygląda udana naprawa

Błąd uzgadniania SSL Kopano oznacza, że ​​klient i serwer nie mogli uzgodnić lub nawiązać połączenia TLS. Port niestandardowy może być poprawny dla jednej części konfiguracji, a błędny dla innej. Przed zmianą certyfikatów lub ustawień protokołu należy ustalić, która usługa jest właścicielem portu i czy TLS jest tam oczekiwany.

Aby konfiguracja działała, docelowy port akceptuje połączenie TLS, prezentuje certyfikat ważny dla nazwy hosta używanej przez klientów i umożliwia ukończenie kolejnego kroku protokołu. Przeglądarka powinna przejść na stronę logowania aplikacji internetowej bez ostrzeżenia o certyfikacie. Klient Kopano Core powinien połączyć się, używając odpowiedniego portu TLS i, jeśli jest skonfigurowany, zaufanego certyfikatu klienta. Samo pomyślne sprawdzenie protokołu TLS nie dowodzi, że logowanie do aplikacji internetowej, uwierzytelnianie Kopano ani dostarczanie poczty działają.

Najpierw oddziel dwie typowe konfiguracje portów

Zweryfikowano dla Kopano Core: Podręcznik administratora Kopano Core 8.0 opisuje natywny odbiornik TLS kontrolowany przez server_listen_tls. W przykładzie użyto portu 237, zaznaczono, że port można zmienić, oraz skonfigurowano pliki certyfikatów i urzędów certyfikacji w /etc/kopano/server.cfg. Podręcznik pokazuje również klientów korzystających z https://gniazda serwera z pasującym portem i certyfikatem klienta. Zobacz Kopano Core: Połączenia SSL i certyfikaty oraz Specjalne konfiguracje Kopano Core .

Osobno, w przypadku dostępu do aplikacji internetowej: użytkownicy zazwyczaj otwierają adres URL w przeglądarce obsługiwany przez Apache, Nginx lub Kopano Web. Protokół TLS może zostać zakończony na tym serwerze front-end podczas przekazywania żądań do usług Kopano. Podręcznik Kopano dokumentuje proxy HTTP do odbiornika Core na porcie 236, a przewodnik Kopano Web opisuje ustawienia certyfikatu TLS w [ /etc/kopano/kwebd.cfgbrakuje informacji]. Ten port HTTPS front-end nie jest automatycznie taki sam jak port TLS Core. Sprawdź przykład odwrotnego proxy Core i przewodnik instalacji Kopano Web .

Działanie: zapisz adres URL klienta, port niestandardowy, proces, który ma nasłuchiwać, oraz informację, czy TLS kończy się na serwerze proxy, czy w rdzeniu Kopano. Nie zmieniaj obu serwerów nasłuchujących jednocześnie.

1. Sprawdź, co nasłuchuje na porcie niestandardowym

Na hoście Kopano zastąp 8443poniższy port portem, który ulega awarii:

sudo ss -ltnp | grep ':8443'

Pasujący wiersz powinien wskazywać gniazdo nasłuchujące. Jeśli nie ma wiersza, usługa nie jest powiązana z tym portem lub jest powiązana z innym adresem. Jeśli port należy do lokalnego odwrotnego serwera proxy, sprawdź wirtualny host serwera proxy. Jeśli powinien to być natywny port TLS Kopano Core, sprawdź server_listen_tlsw /etc/kopano/server.cfg. Proces nasłuchujący tylko na 127.0.0.1nie może bezpośrednio akceptować połączeń zdalnych; może to być celowe, gdy serwer proxy znajduje się przed nim.

Sprawdź również zaporę hosta, zaporę chmurową oraz wszelkie moduły równoważenia obciążenia lub reguły NAT. Port publiczny musi docierać do docelowego wewnętrznego odbiornika. Przekroczenie limitu czasu lub odmowa połączenia wskazują na dostępność lub konfigurację odbiornika; samo w sobie nie oznacza to nieprawidłowego certyfikatu.

2. Sprawdź TLS pod kątem dokładnej nazwy hosta i portu

Na komputerze klienckim przetestuj publiczny punkt końcowy za pomocą OpenSSL. Użyj nazwy DNS widocznej w certyfikacie, a nie niepowiązanego adresu IP:

openssl s_client -connect mail.example.com:8443 -servername mail.example.com -showcerts

Sprawdź prezentowany certyfikat, wynegocjowany protokół i szyfr oraz ewentualne błędy weryfikacji. -servernameOpcja ta wysyła nazwę hosta TLS SNI; ma to znaczenie, gdy serwer hostuje więcej niż jedną witrynę TLS. OpenSSL dokumentuje te opcje w instrukcji s_client . Naciśnij Ctrl+C, aby opuścić interaktywną sondę.

Jeśli certyfikat jest nieobecny, punkt końcowy może komunikować się za pomocą zwykłego protokołu HTTP, niewłaściwa usługa może posiadać port lub serwer proxy może przekierowywać do nieprawidłowego serwera nadrzędnego. Jeśli certyfikat pojawia się, ale jego nazwa, wystawca lub data ważności są nieprawidłowe, popraw wybór certyfikatu lub łańcuch w punkcie końcowym TLS. Niezgodności nazw hostów nie można naprawić poprzez zmianę portu nasłuchującego Kopano Core.

W przypadku punktu końcowego widocznego w przeglądarce wykonaj następujące czynności:

curl -v https://mail.example.com:8443/webapp/

Szczegółowe dane wyjściowe pomagają odróżnić weryfikację TLS od odpowiedzi HTTP, takiej jak przekierowanie, 404 lub 502. Błąd 404 po zakończeniu uzgadniania oznacza problem ze ścieżką lub routingiem, a nie błąd negocjacji TLS. W ramach jednorazowej diagnostyki curl -vkmoże pokazać, czy pominięcie weryfikacji certyfikatu zmienia wynik. Nie należy pozostawiać wyłączonej weryfikacji certyfikatów w przeglądarce, kliencie ani serwerze proxy.

Ważne ograniczenie: natywny protokół TLS w Kopano Core może korzystać z certyfikatów klienta. Podstawowy s_clienttest bez certyfikatu klienta może zostać odrzucony, nawet gdy nasłuchiwacz TLS działa poprawnie. Jeśli serwer żąda uwierzytelnienia klienta, należy powtórzyć test z autoryzowanym certyfikatem klienta i kluczem lub przetestować go ze skonfigurowanym klientem usługi Kopano. Nigdy nie ujawniaj klucza prywatnego w transkrypcji polecenia ani zgłoszeniu do pomocy technicznej.

3. Dopasuj protokół do odbiornika

Częstym błędem w przypadku niestandardowych portów jest konfigurowanie klienta HTTPS do kontaktu ze zwykłym odbiornikiem HTTP lub przekierowywanie ruchu HTTPS do nadrzędnego urządzenia oczekującego na HTTP. Schemat i port muszą opisywać ten sam punkt końcowy.

• https://mail.example.com:8443/webapp/oznacza, że ​​przeglądarka oczekuje protokołu TLS na porcie 8443.
• Udokumentowany przykład Kopano Core wysyła proxy HTTP do 127.0.0.1:236. Jeśli wdrożenie korzysta z tego wzorca, serwer proxy musi użyć http://, nawet jeśli połączenie z przeglądarką publiczną korzysta z HTTPS.
• W przypadku natywnego protokołu Kopano Core TLS przykład w podręczniku używa server_listen_tls = *:237adresu URL klienta zaczynającego się od https://. Jeśli zmienisz port 237 na niestandardowy, zaktualizuj każdego zależnego klienta lub serwer proxy do tej samej wartości.

Sprawdź, czy skopiowane linie konfiguracji nie różnią się od siebie co do portu lub schematu. W konfiguracji wieloserwerowej sprawdź również opublikowany adres URL serwera lub serwera proxy: klient może nawiązać połączenie początkowe, a następnie zakończyć je niepowodzeniem po przekierowaniu go przez Kopano na starą nazwę hosta lub port.

4. Napraw konfigurację programu nasłuchującego i certyfikatu

Jeśli jest to natywny nasłuchiwacz TLS Kopano Core, edytuj istniejącą konfigurację zamiast dodawać duplikaty dyrektyw. Poniżej znajduje się uproszczony przykład portu niestandardowego; zachowaj ścieżki certyfikatów i urząd certyfikacji odpowiednie dla instalacji:

server_listen_tls = *:1237
server_ssl_ca_file = /etc/kopano/ssl/ca.pem
server_ssl_key_file = /etc/kopano/ssl/server.pem
server_ssl_key_pass = your-key-passphrase

Podręcznik Kopano określa ustawienia nasłuchiwacza, urzędu certyfikacji, klucza serwera i przekazywania klucza. kopano-serverPo zmianie natywnego nasłuchiwacza wymagane jest ponowne uruchomienie. Sprawdź, czy zainstalowana wersja obsługuje pokazane opcje; układy pakietów i dyrektywy mogą się różnić. Zabezpiecz katalog kluczy i upewnij się, że konto usługi Kopano może odczytać wymagane pliki.

Sprawdź, czy certyfikat jest przeznaczony dla nazwy hosta faktycznie używanej przez klientów, nie stracił ważności i zawiera wszystkie wymagane certyfikaty pośrednie. W podręczniku Kopano zaznaczono, że jego komponenty sprawdzają wspólną nazwę certyfikatu i alternatywne nazwy podmiotu. W konfiguracji TLS z wieloma serwerami serwer musi również ufać urzędowi certyfikacji, który podpisał certyfikaty klientów, a autoryzowane certyfikaty klientów muszą być skonfigurowane. Nie zastępuj certyfikatu certyfikatem podpisanym samodzielnie jako skrótem do publicznej usługi przeglądarki.

Jeśli protokół TLS kończy się na serwerze Apache, Nginx lub Kopano Web, skonfiguruj certyfikat i niestandardowy listenport na tym serwerze. Następnie ustaw schemat i port nadrzędny zgodnie z rzeczywistym odbiornikiem serwera zaplecza. Nie włączaj protokołu TLS nadrzędnego tylko dlatego, że strona publiczna używa protokołu HTTPS; najpierw upewnij się, że port zaplecza również obsługuje protokół TLS.

5. Sprawdź poprawność usługi i załaduj ją ponownie

Przed ponownym załadowaniem serwera WWW należy uruchomić sprawdzanie jego konfiguracji, na przykład sudo nginx -tdla Nginx lub sudo apachectl configtestApache. Jeśli test zgłosi błąd, popraw go przed ponownym załadowaniem. Użyj nazwy usługi zainstalowanej w dystrybucji, na przykład:

sudo systemctl restart kopano-server
sudo systemctl status kopano-server --no-pager

Uruchom ponownie Kopano Core tylko po zmianie konfiguracji. W przypadku zmiany portu lub certyfikatu tylko dla front-endu, zweryfikuj i przeładuj usługę front-endu. Sprawdź jej dziennik lub dziennik błędów natychmiast po zmianie i powtórz dokładne badanie OpenSSL z sieci klienta. Uzgodnienie powinno teraz wyświetlić oczekiwany certyfikat. Następnie przetestuj rzeczywisty adres URL aplikacji internetowej lub połączenie klienta Kopano, ponieważ samo powodzenie protokołu TLS nie weryfikuje trasy aplikacji ani uwierzytelnienia.

Przeczytaj wynik przed zmianą

• Brak gniazda nasłuchującego: sprawdź skonfigurowany moduł nasłuchujący, stan usługi i adres powiązania.
• Odmowa połączenia lub przekroczenie limitu czasu: sprawdź zaporę sieciową, NAT, moduł równoważenia obciążenia i czy port docelowy jest osiągalny.
• Nieprawidłowy certyfikat: sprawdź certyfikat skonfigurowany w punkcie końcowym odpowiadającym temu portowi, w tym wybór SNI i łańcuch certyfikatów.
• Protokół TLS działa lokalnie, ale nie zdalnie: porównaj ścieżkę publicznego serwera proxy lub modułu równoważenia obciążenia z lokalnym nasłuchiwaczem i sprawdź przekazane wartości hosta i portu.
• Uzgadnianie kończy się sukcesem, ale aplikacja internetowa nie działa: sprawdź status HTTP, ścieżkę proxy, logi PHP/aplikacji internetowej i łączność z rdzeniem Kopano. Kontynuuj na poziomie aplikacji.
• Tylko klienci Core nie mogą: zweryfikuj server_socketustawienia swojego adresu, portu niestandardowego, zaufanego urzędu certyfikacji i certyfikatu klienta. Ścieżka Core TLS może wymagać wzajemnego uwierzytelnienia certyfikatu.

Niezawodna poprawka zmienia tylko punkt końcowy, który jest właścicielem nieudanego uzgadniania. Podręcznik administratora rdzenia Kopano dostępny dla tej procedury ma wersję 8.0.0, a zawarte w nim przykłady należy sprawdzić w zainstalowanych pakietach i lokalnych stronach podręcznika. Jeśli wdrożenie korzysta z innej wersji Kopano, kontenera lub zarządzanego odwrotnego serwera proxy, przed zastosowaniem przykładowych dyrektyw należy potwierdzić bieżącą konfigurację tego komponentu.