Jak naprawić błąd Zimbra „Nie można uruchomić TLS: nie udało się nawiązać połączenia SSL”

Komunikat Unable to start TLS: SSL handshake failedoznacza, że ​​klient i serwer nie mogli zakończyć negocjacji rozpoczynającej szyfrowane połączenie. W systemie Zimbra komunikat może pochodzić z różnych źródeł. Często pojawia się komunikat o błędzie zmcontrol status, informujący, że połączenie z serwerem głównym LDAP nie przeszło weryfikacji certyfikatu. Klient poczty elektronicznej lub przekaźnik SMTP może również zgłosić problem z uzgadnianiem na publicznym porcie pocztowym.

Rozwiązanie problemu zależy od tego, które połączenie zostało przerwane. Zacznij od zidentyfikowania usługi i nazwy hosta w otaczających wierszach logu. Następnie sprawdź certyfikat, jego łańcuch wystawcy, zegar systemowy i punkt końcowy TLS. Unikaj wyłączania TLS jako pierwszej reakcji: może to ukryć objaw, osłabiając lub przerywając wewnętrzną komunikację z serwerem pocztowym.

Co warto wiedzieć przed zmianą czegokolwiek

TLS to protokół szyfrujący połączenie sieciowe. Uzgadnianie TLS to początkowa wymiana, w której oba systemy uzgadniają parametry szyfrowania i weryfikują certyfikat serwera. STARTTLS rozpoczyna się jako połączenie w protokole zwykłym, a następnie przełącza się na TLS na żądanie obu stron. Zarówno LDAP, jak i SMTP mogą korzystać z STARTTLS, więc sam ten błąd nie identyfikuje usługi, która uległa awarii.

Przed uruchomieniem poleceń naprawczych zapisz wersję Zimbry, informację o tym, czy instalacja jest jedno- czy wielowęzłowa, dokładne polecenie lub klienta, który wyświetla błąd, oraz cały wiersz dziennika wokół niego. Zaplanuj wdrożenie certyfikatu lub ponowne uruchomienie usługi podczas okresu konserwacji. Przed edycją plików certyfikatów i konfiguracji utwórz kopię zapasową.

• Uruchom polecenia administracyjne jako konto i z uprawnieniami wymaganymi przez wersję Zimbra.
• Nie wklejaj kluczy prywatnych, haseł ani nieocenzurowanych dzienników poczty w zgłoszeniach ani na forach publicznych.
• Nie zmieniaj flag zabezpieczeń LDAP ani ustawień protokołu, dopóki nie dowiesz się, który punkt końcowy uległ awarii i nie sprawdzisz jego certyfikatu.

Krok 1: Zidentyfikuj niedziałające połączenie TLS

Najpierw odtwórz problem i przeczytaj cały komunikat. Jeśli pojawia się on podczas sprawdzania stanu usługi przez Zimbra i zawiera sformułowanie takie jak when connecting to ldap master, sprawdź wewnętrzny protokół LDAP TLS. Jeśli tylko klient poczty nie może przesłać danych SMTP, sprawdź publiczny punkt końcowy SMTP oraz nazwę hosta, port i tryb szyfrowania klienta.

su - zimbra
zmcontrol status

Przejrzyj ostatnie wpisy w dzienniku Zimbra pod kątem tego samego znacznika czasu. W wielu instalacjach główny dziennik to /var/log/zimbra.log; użyj lokalizacji dziennika skonfigurowanej na serwerze.

grep -Ei 'Unable to start TLS|SSL handshake|certificate|ldap|STARTTLS' /var/log/zimbra.log | tail -n 80

Sprawdź nazwę procesu, hosta zdalnego, port i wszelkie bardziej szczegółowe informacje dotyczące OpenSSL, takie jak błąd weryfikacji certyfikatu, wygasły certyfikat, nieznany wystawca lub alert protokołu. Te szczegóły pozwalają odróżnić problem z zaufaniem certyfikatu od niezgodności sieci lub protokołu.

W przypadku wewnętrznego błędu LDAP sprawdź, z których hostów LDAP korzysta ten serwer. Sprawdź indywidualnie lokalne klucze konfiguracyjne i porównaj ich nazwy hostów z DNS i certyfikatem serwera:

zmlocalconfig ldap_url
zmlocalconfig ldap_master_url
zmlocalconfig ldap_starttls_supported
zmlocalconfig ldap_starttls_required

Dostępność klucza i dane wyjściowe mogą się różnić w zależności od wersji Zimbra i roli węzła. Są to odczyty diagnostyczne; nie należy zmieniać wartości tylko dlatego, że pojawia się ona w danych wyjściowych. Dokumentacja Zimbra opisuje rolę ustawień LDAP STARTTLS i zaleca włączenie wewnętrznego protokołu TLS: Wartości konfiguracji lokalnej Zimbra TLS i STARTTLS .

Krok 2: Sprawdź zegar systemowy, DNS i dostępność

Walidacja certyfikatu zależy od zegara serwera. Jeśli zegar jest znacznie opóźniony lub przyspieszony, ważny certyfikat może wydawać się nieważny lub wygasły. Sprawdź czas na hoście Zimbra oraz na każdym serwerze głównym LDAP lub replice biorącej udział w połączeniu.

date -u
getent hosts ldap.example.com

Zastąp ldap.example.comnazwą hosta LDAP znalezioną w konfiguracji lub logu. Sprawdź, czy odpowiada ona oczekiwanemu adresowi serwera i czy skonfigurowany port LDAP jest dostępny przez zaporę sieciową hosta i sieć. W instalacjach wielowęzłowych przetestuj połączenie z węzła Zimbra, który zarejestrował awarię, do rzeczywistego węzła LDAP — nie tylko ze stacji roboczej.

W przypadku połączenia SMTP STARTTLS skierowanego do klienta, poradnik rozwiązywania problemów SMTP firmy Zimbra demonstruje testowanie portu 25 za pomocą OpenSSL. Port 587 jest również powszechnie używany do przesyłania wiadomości za pomocą STARTTLS. Użyj nazwy hosta i portu skonfigurowanych w kliencie pocztowym:

openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com -showcerts

W przypadku protokołu SMTP na porcie 25 należy zastąpić 587. 25Port 465 korzysta z niejawnego protokołu TLS, więc nie należy go dodawać -starttls smtppodczas testowania tego portu. Udane połączenie TCP samo w sobie nie dowodzi, że certyfikat jest zaufany ani że klient używa właściwego trybu zabezpieczeń. Zapoznaj się z poradnikiem Zimbra dotyczącym rozwiązywania problemów z protokołem SMTP i OpenSSL .

Krok 3: Sprawdź certyfikat faktycznie wdrożony przez Zimbra

Certyfikat to podpisany dokument tożsamości serwera. Certyfikat musi być ważny dla nazwy hosta używanej przez klientów, nie może się ziścić w okresie ważności i być powiązany z urzędem certyfikacji, któremu ufa łączący się komponent. Certyfikat może wyglądać poprawnie w przeglądarce, podczas gdy inny certyfikat jest wdrożony na serwerze LDAP, Postfix lub węźle proxy.

Jako administrator Zimbra sprawdź, czy certyfikaty Zimbra zostały wdrożone:

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Sprawdź podmiot lub alternatywną nazwę podmiotu (SAN), wystawcę, datę wygaśnięcia i usługi każdego z wymienionych certyfikatów. Nazwa SAN powinna zawierać nazwę hosta faktycznie używaną dla połączenia LDAP lub poczty elektronicznej. Sprawdź również, czy wszystkie węzły we wdrożeniu wieloserwerowym mają oczekiwany certyfikat i łańcuch. Zimbra zauważa, że ​​przeglądanie wdrożonych certyfikatów odbywa się lokalnie na serwerze, dlatego przeprowadź sprawdzenie na każdym odpowiednim węźle.

Jeśli posiadasz pliki certyfikatów źródłowych, przed wdrożeniem sprawdź ich daty i nazwy:

openssl x509 -in /tmp/commercial.crt -noout -dates -subject -issuer -ext subjectAltName

Zastąp przykładową ścieżkę plikiem certyfikatu, który oceniasz. Brak SAN, wygasły certyfikat liściowy lub pośredni, nieprawidłowa nazwa hosta lub certyfikat wydany dla innego serwera – wszystko to może spowodować niepowodzenie walidacji.

Krok 4: Zweryfikuj klucz prywatny i łańcuch certyfikatów

Łańcuch certyfikatów to zestaw certyfikatów wystawcy, który umożliwia klientowi prześledzenie certyfikatu serwera do zaufanego urzędu certyfikacji. Jeśli plik łańcucha pomija certyfikat pośredni lub zawiera niewłaściwy łańcuch, klienci mogą odrzucić serwer, nawet jeśli certyfikat potomny jest aktualny. Certyfikat i klucz prywatny muszą również stanowić pasującą parę.

W przypadku certyfikatu komercyjnego narzędzia certyfikacyjne Zimbra oferują etap weryfikacji. Dostosuj ścieżki plików do swojej instalacji i urzędu certyfikacji:

/opt/zimbra/bin/zmcertmgr verifycrt comm   /opt/zimbra/ssl/zimbra/commercial/commercial.key   /tmp/commercial.crt   /tmp/ca_chain.crt

Kontynuuj tylko wtedy, gdy weryfikacja potwierdzi zgodność certyfikatu i klucza prywatnego oraz ważność łańcucha certyfikatów. Nie wdrażaj certyfikatu po nieudanej weryfikacji. Użyj pośredniego łańcucha dostarczonego przez urząd certyfikacji i formatu łańcucha wymaganego przez Twoją wersję Zimbra; nie twórz łańcucha, zgadując lub dodając niepowiązane certyfikaty główne.

Przewodnik po certyfikatach Zimbra dokumentuje sekwencję weryfikacji i wdrażania, w tym łańcuch CA: Instalacja certyfikatu Zimbra i narzędzia CLI . Strona poświęcona rozwiązywaniu problemów z łańcuchem certyfikatów wyjaśnia również błędy weryfikacji łańcucha wystawcy: Wskazówki dotyczące łańcucha certyfikatów Zimbra .

Krok 5: Popraw i bezpiecznie wdróż certyfikat

Jeśli weryfikacja wykaże wygasły certyfikat, nieprawidłowy klucz, brakujący certyfikat pośredni lub niezgodność nazwy hosta, przed wdrożeniem należy uzyskać lub wygenerować poprawne pliki. Postępuj zgodnie z procedurą odpowiednią dla wersji Zimbra i typu certyfikatu. W przypadku certyfikatu komercyjnego udokumentowane polecenie ma następującą ogólną postać:

/opt/zimbra/bin/zmcertmgr deploycrt comm /tmp/commercial.crt /tmp/ca_chain.crt

Użyj dokładnej składni poleceń i uprawnień udokumentowanych dla zainstalowanej wersji. Interfejs wiersza poleceń Zimbra umożliwia instalację certyfikatów dla komponentów takich jak MTA, LDAP i serwer proxy, więc wdrożenie może wpłynąć na kilka usług. W środowisku wielowęzłowym sprawdź, czy certyfikat jest poprawnie wdrożony na każdym odpowiednim serwerze, w tym na serwerze głównym LDAP.

Po zweryfikowaniu wdrożenia uruchom ponownie usługi Zimbra w trakcie planowanego okna konserwacji, jeśli procedura wydania tego wymaga, a następnie potwierdź status usługi i wdrożone certyfikaty:

su - zimbra
zmcontrol restart
zmcontrol status
/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Ponowne uruchomienie przerywa dostęp do poczty i internetu, a usługi zatrzymują się i powracają. Nie należy uruchamiać go przypadkowo na obciążonym serwerze produkcyjnym. Przewodnik po certyfikacie Zimbra opisuje użycie zmcontrol restartpo wdrożeniu i sprawdzenie wyniku za pomocą viewdeployedcrt.

Krok 6: Sprawdź konfigurację zaufania LDAP bez wyłączania protokołu TLS

Jeśli sam certyfikat zostanie zweryfikowany, ale klient LDAP Zimbry nadal go odrzuca, należy sprawdzić materiał zaufania LDAP i węzeł, który uległ awarii. Zarchiwizowana notatka rozwiązywania problemów MTA Zimbry wymienia nieprawidłowy łańcuch urzędów certyfikacji, wygasłe certyfikaty urzędów certyfikacji i nieoczekiwane pliki jako /opt/zimbra/conf/camożliwe przyczyny błędów LDAP STARTTLS. Należy to traktować jako przyczynę diagnostyczną, a nie jako powód do usuwania plików: należy porównać katalog ze znaną, dobrą kopią zapasową lub instrukcją dla konkretnej wersji i zachować jego zawartość przed wprowadzeniem zmian.

W przypadku prostego badania LDAP STARTTLS klient OpenLDAP może wymagać StartTLS i wysłać zapytanie do Root DSE bez podawania danych uwierzytelniających konta:

ldapsearch -x -ZZ -H ldap://ldap.example.com:389 -b "" -s base namingContexts

Użyj rzeczywistego hosta i portu LDAP w swoim wdrożeniu. W przypadku narzędzi OpenLDAP -ZZżądanie StartTLS i traktowanie braku możliwości jego utworzenia jako błędu. Jeśli to badanie zakończy się niepowodzeniem z komunikatem o zaufaniu lub certyfikacie, porównaj certyfikat zwrócony przez punkt końcowy LDAP z wdrożonym certyfikatem i zaufaniem CA dostępnym dla klienta. Jeśli test zakończy się pomyślnie na jednym węźle, ale nie powiedzie się na innym, zbadaj różnice w DNS, plikach CA lub konfiguracji lokalnej.

Krok 7: Rozważ zgodność protokołu dopiero po sprawdzeniu certyfikatu

Uzgadnianie może się również nie powieść, jeśli klient i serwer nie mogą uzgodnić wersji protokołu TLS lub zestawu szyfrów. Może się to zdarzyć w przypadku przestarzałych klientów, niestandardowego wzmocnienia zabezpieczeń lub domyślnych ustawień specyficznych dla danej wersji. Przetestuj punkt końcowy za pomocą aktualnego klienta OpenSSL i sprawdź ustawienia TLS Zimbry pod kątem konkretnej wersji produktu. Unikaj kopiowania starych poleceń protokołu z archiwalnych stron do nowszej instalacji; konfiguracja szyfru i protokołu może się zmieniać między wersjami.

Nie „naprawiaj” błędu, włączając protokół SSLv3, osłabiając weryfikację ani globalnie wyłączając protokół LDAP STARTTLS. Wątek na forum Zimbra zawiera historyczne obejście problemu, które wyłączyło protokół LDAP STARTTLS, ale inny użytkownik słusznie ostrzegł, że wyłączenie funkcji bezpieczeństwa nie jest skuteczną naprawą certyfikatu. Własne notatki dotyczące konfiguracji lokalnej Zimbra zalecają pozostawienie włączonego protokołu TLS i protokołu LDAP STARTTLS międzyprocesorowego. Używaj takiej zmiany wyłącznie jako ściśle kontrolowanej, tymczasowej diagnostyki, jeśli wsparcie techniczne Zimbra zaleci jej wykonanie, i natychmiast przywróć bezpieczne ustawienia.

Jak potwierdzić naprawę

• zmcontrol statuskończy się bez błędu LDAP TLS, jeśli to była operacja powodująca błąd.
• Dotknięty problemem punkt końcowy LDAP lub SMTP przedstawia oczekiwany, niewygasły certyfikat i kompletny łańcuch wystawcy.
• Test z tego samego hosta i tej samej ścieżki sieciowej kończy się pomyślnie przy zamierzonym trybie TLS.
• Dzienniki Zimbra nie pokazują już błędów weryfikacji certyfikatu ani błędów uzgadniania w czasie testu.
• W przypadku protokołu SMTP należy wysłać wiadomość testową w obu kierunkach i potwierdzić jej dostarczenie w odpowiednich kolejkach lub dziennikach.

Jeśli błąd nadal występuje, zbierz pełny opis błędu, wersję Zimbra, usługę, której dotyczy problem, nazwę hosta, daty certyfikatów i SAN, dane wyjściowe weryfikacji oraz odpowiednie wiersze dziennika. Usuń klucze prywatne, dane uwierzytelniające, adresy użytkowników i poufne dane hosta przed udostępnieniem. Dokładny komunikat to objaw, a nie pełna diagnoza; nazwa usługi i przyczyna usterki OpenSSL decydują o właściwym sposobie naprawy.

Uwaga dotycząca dokumentacji: strony certyfikatów publicznych i protokołu TLS Zimbra zawierają materiały dla wielu wydań, a niektóre strony rozwiązywania problemów są jawnie zarchiwizowane. Polecenia tutaj odzwierciedlają udokumentowany wzorzec CLI, ale ścieżki certyfikatów, uprawnienia i wymagania dotyczące ponownego uruchomienia należy sprawdzić w dokumentacji zainstalowanej wersji Zimbra. Sprawdzono 6 października 2026 r.