Cum se remediază eroarea Zimbra „Nu se poate porni TLS: SSL Handshake eșuat”

Mesajul Unable to start TLS: SSL handshake failedînseamnă că un client și un server nu au putut finaliza negocierea care inițiază o conexiune criptată. În Zimbra, mesajul poate proveni din locuri diferite. O variație frecventă apare în timpul zmcontrol statusși spune că verificarea certificatului de conexiune la masterul LDAP a eșuat. Un client de e-mail sau un retransmisor SMTP poate raporta, de asemenea, o problemă de handshake pe un port public de e-mail.

Remedierea depinde de conexiunea care a eșuat. Începeți prin a identifica serviciul și numele gazdei în liniile de jurnal aferente. Apoi verificați certificatul, lanțul de emitere a acestuia, ceasul sistemului și punctul final TLS. Evitați dezactivarea TLS ca primă intervenție: acest lucru poate ascunde simptomul în timp ce slăbește sau întrerupe comunicarea internă între serverul de mail.

Ce trebuie să știi înainte de a schimba ceva

TLS este protocolul care criptează o conexiune de rețea. O strângere de mână TLS este schimbul inițial în care cele două sisteme convin asupra parametrilor de criptare și validează certificatul serverului. STARTTLS începe ca o conexiune de protocol simplu, apoi trece la TLS atunci când ambele părți o solicită. Atât LDAP, cât și SMTP pot utiliza STARTTLS, deci această eroare singură nu identifică serviciul defect.

Înainte de a executa comenzi de reparare, înregistrați versiunea Zimbra, dacă instalarea este cu un singur nod sau cu mai multe noduri, comanda sau clientul exact care afișează eroarea și linia de jurnal completă aferentă. Programați implementarea certificatelor sau repornirea serviciilor în timpul unei ferestre de întreținere. Păstrați o copie de rezervă a fișierelor de certificat și a configurației înainte de a le edita.

• Executați comenzi administrative în numele contului și cu permisiunile necesare pentru versiunea dvs. de Zimbra.
• Nu lipiți chei private, parole sau jurnale de e-mail needitate în tichete sau forumuri publice.
• Nu modificați semnalizatoarele de securitate LDAP sau setările protocolului până nu știți care punct final a eșuat și nu i-ați verificat certificatul.

Pasul 1: Identificați conexiunea TLS defectă

Mai întâi reproduceți problema și citiți mesajul complet. Dacă apare când Zimbra verifică starea serviciului și include o formulă precum when connecting to ldap master, investigați TLS-ul LDAP intern. Dacă doar un client de e-mail eșuează la trimiterea SMTP, investigați endpoint-ul SMTP public și numele de gazdă, portul și modul de criptare al clientului.

su - zimbra
zmcontrol status

Verificați intrările recente din jurnalul Zimbra pentru aceeași marcă temporală. În multe instalări, jurnalul principal este /var/log/zimbra.log; utilizați locația jurnalului configurată pe server.

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

Căutați numele procesului, gazda la distanță, portul și orice detaliu OpenSSL mai specific, cum ar fi eroarea de verificare a certificatului, certificatul expirat, emitentul necunoscut sau alerta de protocol. Aceste detalii diferențiază o problemă de încredere a certificatului de o nepotrivire de rețea sau protocol.

Pentru o eroare LDAP internă, verificați ce gazde LDAP este configurat să utilizeze acest server. Interogați individual cheile de configurare locale și comparați numele lor de gazdă cu DNS și certificatul serverului:

zmlocalconfig ldap_url
zmlocalconfig ldap_master_url
zmlocalconfig ldap_starttls_supported
zmlocalconfig ldap_starttls_required

Disponibilitatea cheii și rezultatul pot varia în funcție de versiunea Zimbra și de rolul nodului. Acestea sunt citiri de diagnosticare; nu modificați o valoare doar pentru că apare în rezultat. Documentația Zimbra descrie rolul setărilor STARTTLS LDAP și recomandă menținerea TLS intern activat: valorile de configurare locală Zimbra TLS și STARTTLS .

Pasul 2: Verificați ceasul sistemului, DNS-ul și accesibilitatea

Validarea certificatului depinde de ceasul serverului. Dacă ceasul este mult în urmă sau în avans, un certificat valid poate părea încă nevalid sau expirat. Confirmați ora pe gazda Zimbra și pe orice master sau replică LDAP implicată în conexiune.

date -u
getent hosts ldap.example.com

Înlocuiți ldap.example.comcu numele de gazdă LDAP găsit în configurație sau jurnal. Confirmați că se rezolvă la adresa de server așteptată și că portul LDAP configurat este accesibil prin firewall-ul gazdă și rețea. În instalările cu mai multe noduri, testați de pe nodul Zimbra care a înregistrat eroarea pe nodul LDAP real - nu doar de pe stația de lucru.

Pentru o conexiune SMTP STARTTLS orientată către client, ghidul de depanare SMTP de la Zimbra demonstrează testarea portului 25 cu OpenSSL. Portul 587 este, de asemenea, utilizat în mod obișnuit pentru trimiterea de mesaje cu STARTTLS. Folosiți numele de gazdă și portul configurate în clientul de e-mail:

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

Pentru SMTP pe portul 25, înlocuiți 587cu 25. Portul 465 utilizează TLS implicit, deci nu adăugați -starttls smtpla testarea portului respectiv. O conexiune TCP reușită nu dovedește în sine că certificatul este de încredere sau că clientul utilizează modul de securitate corect. Consultați ghidul de depanare SMTP și OpenSSL de la Zimbra .

Pasul 3: Inspectați certificatul implementat efectiv de Zimbra

Un certificat este un document de identitate semnat pentru un server. Certificatul trebuie să fie valid pentru numele de gazdă utilizat de clienți, să fie în termenele de valabilitate și să fie legat de o autoritate de certificare în care are încredere componenta de conectare. Un certificat poate arăta corect într-un browser în timp ce un alt certificat este implementat pe LDAP, Postfix sau un nod proxy.

În calitate de administrator Zimbra, vizualizați certificatul raportat de Zimbra ca fiind implementat:

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Verificați subiectul sau numele alternativ al subiectului (SAN), emitentul, data de expirare și serviciile fiecărui certificat listat. SAN-ul ar trebui să conțină numele gazdei utilizat efectiv pentru conexiunea LDAP sau de e-mail. De asemenea, verificați dacă toate nodurile dintr-o implementare multi-server au certificatul și lanțul așteptate. Zimbra notează că vizualizarea certificatelor implementate este locală pentru server, așadar rulați verificarea pe fiecare nod relevant.

Dacă aveți fișierele certificatului sursă, verificați datele și numele acestora înainte de implementare:

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

Înlocuiți calea exemplu cu fișierul certificat pe care îl evaluați. Un SAN lipsă, un certificat expirat sau intermediar, un nume de gazdă greșit sau un certificat emis pentru un alt server pot cauza eșecul validării.

Pasul 4: Verificați cheia privată și lanțul de certificate

Lanțul de certificate este setul de certificate emitent care permite unui client să urmărească certificatul serverului până la o autoritate de încredere. Dacă fișierul lanț omite un certificat intermediar sau conține lanțul greșit, clienții pot respinge serverul chiar și atunci când certificatul frunză este actual. Certificatul și cheia privată trebuie, de asemenea, să fie o pereche potrivită.

Pentru un certificat comercial, instrumentele de certificare Zimbra oferă o etapă de verificare. Adaptați căile fișierelor la instalarea și autoritatea de certificare:

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

Continuați numai dacă verificarea confirmă că certificatul și cheia privată se potrivesc și că lanțul de certificate este valid. Nu implementați un certificat după o verificare eșuată. Utilizați lanțul intermediar furnizat de autoritatea de certificare și formatul de lanț așteptat de versiunea dvs. de Zimbra; nu asamblați un lanț ghicind sau adăugând certificate rădăcină fără legătură.

Ghidul Zimbra pentru certificate documentează secvența de verificare și implementare, inclusiv lanțul CA: instalarea certificatului Zimbra și instrumentele CLI . Pagina sa de depanare a lanțului de certificate explică, de asemenea, erorile de verificare a lanțului emitentului: îndrumări pentru lanțul de certificate Zimbra .

Pasul 5: Corectați și implementați certificatul în siguranță

Dacă verificarea arată un certificat expirat, o cheie greșită, un intermediar lipsă sau o nepotrivire a numelui de gazdă, obțineți sau generați fișierele corecte înainte de implementare. Urmați procedura pentru versiunea Zimbra și tipul de certificat. Pentru un certificat comercial, comanda documentată are această formă generală:

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

Folosiți sintaxa exactă a comenzilor și privilegiile documentate pentru versiunea instalată. Interfața CLI a Zimbra poate instala certificate pentru componente precum MTA, LDAP și proxy, astfel încât implementarea poate afecta mai multe servicii. Într-un mediu cu mai multe noduri, confirmați că certificatul este implementat corect pe fiecare server relevant, inclusiv pe serverul master LDAP.

După o implementare verificată, reporniți serviciile Zimbra în timpul ferestrei de mentenanță planificată, dacă procedura de lansare o impune, apoi confirmați starea serviciului și certificatele implementate:

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

O repornire întrerupe accesul la e-mail și web în timp ce serviciile se opresc și revin. Nu rulați comanda întâmplător pe un server de producție ocupat. Ghidul pentru certificate Zimbra documentează utilizarea zmcontrol restartdupă implementare și verificarea rezultatului cu viewdeployedcrt.

Pasul 6: Verificați configurația de încredere LDAP fără a dezactiva TLS

Dacă certificatul în sine se verifică, dar clientul LDAP al Zimbra îl respinge în continuare, inspectați materialul de încredere LDAP și nodul defect. Nota de depanare MTA arhivată a Zimbra listează un lanț CA nevalid, certificate CA expirate și fișiere neașteptate printre /opt/zimbra/conf/cacauzele posibile ale erorilor LDAP STARTTLS. Tratați acest lucru ca pe un indiciu de diagnosticare, nu ca pe un motiv pentru ștergerea fișierelor: comparați directorul cu o copie de rezervă cunoscută ca fiind validă sau cu instrucțiuni specifice versiunii și păstrați conținutul acestuia înainte de a face modificări.

Pentru o simplă sondă LDAP STARTTLS, un client OpenLDAP poate solicita StartTLS și interoga Root DSE fără a furniza acreditările contului:

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

Folosește gazda și portul LDAP reale în implementarea ta. Cu instrumentele OpenLDAP, -ZZsolicită StartTLS și tratează eșecul de a-l stabili ca pe o eroare. Dacă această sondă eșuează cu un mesaj de încredere sau certificat, compară certificatul returnat de punctul final LDAP cu certificatul implementat și încrederea CA disponibilă clientului. Dacă testul reușește de la un nod, dar eșuează de la altul, investighează diferențele dintre DNS, fișierele CA sau configurația locală.

Pasul 7: Luați în considerare compatibilitatea protocolului numai după verificarea certificatelor

O strângere de mână poate eșua și dacă clientul și serverul nu pot ajunge la un acord asupra unei versiuni de protocol TLS sau a unei suite de cifruri. Acest lucru se poate întâmpla în cazul clienților învechiți, al securității personalizate sau al setărilor implicite specifice versiunii. Testați endpoint-ul cu un client OpenSSL curent și inspectați setările TLS ale Zimbra pentru versiunea exactă a produsului. Evitați copierea comenzilor vechi de protocol din paginile arhivate într-o instalare mai nouă; configurația cifrului și a protocolului se poate modifica între versiuni.

Nu „remediați” eroarea prin activarea SSLv3, slăbirea verificării sau dezactivarea globală a LDAP STARTTLS. Un fir de discuție pe forumul Zimbra conține o soluție istorică care dezactiva LDAP STARTTLS, dar un alt respondent a avertizat corect că dezactivarea unei funcții de securitate nu este o reparare solidă a certificatului. Notele de configurare locală ale Zimbra recomandă lăsarea TLS interproces și LDAP STARTTLS activate. Utilizați o astfel de modificare doar ca o diagnosticare temporară, strict controlată, dacă asistența Zimbra vă indică acest lucru și restaurați imediat setările de securitate.

Cum se confirmă reparația

• zmcontrol statusse finalizează fără eroarea LDAP TLS, dacă aceasta a fost operațiunea eșuată.
• Punctul final LDAP sau SMTP afectat prezintă certificatul așteptat, neexpirat, și lanțul complet al emitentului.
• Un test de pe aceeași gazdă și cale de rețea are succes cu modul TLS dorit.
• Jurnalele Zimbra nu mai afișează erori de verificare a certificatului sau de handshake în momentul testării.
• Pentru SMTP, trimiteți un mesaj de test în ambele direcții și confirmați livrarea în cozile sau jurnalele relevante.

Dacă eroarea persistă, colectați eroarea completă, versiunea Zimbra, serviciul și numele gazdei afectate, datele certificatelor și SAN-ul, rezultatul verificării și liniile de jurnal relevante. Redactați cheile private, acreditările, adresele utilizatorilor și detaliile sensibile ale gazdei înainte de partajare. Mesajul precis este un simptom, nu un diagnostic complet; numele serviciului înconjurător și motivul OpenSSL determină repararea corectă.

Notă despre documentație: Paginile publice de certificate și TLS ale Zimbra includ materiale pentru mai multe versiuni, iar unele pagini de depanare sunt arhivate explicit. Comenzile de aici reflectă modelul CLI documentat, dar căile de certificat, privilegiile și cerințele de repornire trebuie verificate în raport cu documentația pentru versiunea instalată de Zimbra. Revizuit la 6 octombrie 2026.