Il messaggio Unable to start TLS: SSL handshake failedindica che client e server non sono riusciti a completare la negoziazione che avvia una connessione crittografata. In Zimbra, il messaggio può provenire da diverse fonti. Una variante frequente si verifica durante la fase di handshake zmcontrol statuse indica che la connessione al master LDAP non è riuscita a verificare il certificato. Anche un client di posta o un relay SMTP possono segnalare un problema di handshake su una porta di posta pubblica.
La soluzione dipende dalla connessione che ha generato l'errore. Inizia identificando il servizio e il nome host nelle righe di log circostanti. Quindi controlla il certificato, la sua catena di emissione, l'orologio di sistema e l'endpoint TLS. Evita di disabilitare TLS come prima soluzione: ciò potrebbe mascherare il problema e al contempo indebolire o interrompere la comunicazione interna con il server di posta.
TLS è il protocollo che crittografa una connessione di rete. L' handshake TLS è lo scambio iniziale in cui i due sistemi concordano sui parametri di crittografia e convalidano il certificato del server. STARTTLS inizia come una connessione di protocollo semplice, per poi passare a TLS quando entrambe le parti lo richiedono. Sia LDAP che SMTP possono utilizzare STARTTLS, quindi questo errore da solo non identifica il servizio che non funziona.
Prima di eseguire i comandi di riparazione, annota la versione di Zimbra, se l'installazione è a nodo singolo o multi-nodo, il comando o il client esatto che mostra l'errore e la riga di log completa che lo contiene. Pianifica la distribuzione dei certificati o il riavvio dei servizi durante una finestra di manutenzione. Esegui un backup dei file dei certificati e della configurazione prima di modificarli.
Innanzitutto, riproduci il problema e leggi il messaggio completo. Se compare quando Zimbra controlla lo stato del servizio e include una dicitura come when connecting to ldap master, esamina il TLS LDAP interno. Se solo un client di posta elettronica riscontra un errore nell'invio SMTP, esamina l'endpoint SMTP pubblico e il nome host, la porta e la modalità di crittografia del client.
su - zimbra
zmcontrol status
Esamina le voci di registro Zimbra più recenti relative allo stesso timestamp. In molte installazioni, il file di registro principale è /var/log/zimbra.log; utilizza il percorso del file di registro configurato sul tuo server.
grep -Ei 'Unable to start TLS|SSL handshake|certificate|ldap|STARTTLS' /var/log/zimbra.log | tail -n 80
Cerca il nome del processo, l'host remoto, la porta e qualsiasi altro dettaglio OpenSSL specifico, come ad esempio un errore di verifica del certificato, un certificato scaduto, un emittente sconosciuto o un avviso di protocollo. Questi dettagli permettono di distinguere un problema di attendibilità del certificato da un'incongruenza di rete o di protocollo.
In caso di errore LDAP interno, verificare quali host LDAP sono configurati per utilizzare questo server. Interrogare singolarmente le chiavi di configurazione locali e confrontare i relativi nomi host con il DNS e il certificato del server:
zmlocalconfig ldap_url
zmlocalconfig ldap_master_url
zmlocalconfig ldap_starttls_supported
zmlocalconfig ldap_starttls_required
La disponibilità delle chiavi e l'output possono variare a seconda della versione di Zimbra e del ruolo del nodo. Si tratta di letture diagnostiche; non modificare un valore solo perché appare nell'output. La documentazione di Zimbra descrive il ruolo delle impostazioni LDAP STARTTLS e raccomanda di mantenere abilitato il TLS interno: Valori di configurazione locale di Zimbra TLS e STARTTLS .
La validazione del certificato dipende dall'orologio del server. Se l'orologio è molto indietro o avanti, un certificato valido potrebbe risultare non ancora valido o scaduto. Verificare l'ora sull'host Zimbra e su qualsiasi master o replica LDAP coinvolta nella connessione.
date -u
getent hosts ldap.example.com
Sostituisci ldap.example.comcon il nome host LDAP trovato nella configurazione o nel log. Verifica che si risolva nell'indirizzo del server previsto e che la porta LDAP configurata sia raggiungibile tramite il firewall e la rete dell'host. Nelle installazioni multi-nodo, esegui il test dal nodo Zimbra che ha registrato l'errore verso il nodo LDAP effettivo, e non solo dalla tua workstation.
Per una connessione SMTP STARTTLS lato client, la guida alla risoluzione dei problemi SMTP di Zimbra mostra come testare la porta 25 con OpenSSL. Anche la porta 587 è comunemente utilizzata per l'invio di messaggi con STARTTLS. Utilizzare il nome host e la porta configurati nel client di posta:
openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com -showcerts
Per SMTP sulla porta 25, sostituire 587con 25. La porta 465 utilizza TLS implicito, quindi non aggiungere -starttls smtpquando si testa tale porta. Una connessione TCP riuscita non dimostra di per sé che il certificato sia attendibile o che il client stia utilizzando la modalità di sicurezza corretta. Consultare la guida alla risoluzione dei problemi di SMTP e OpenSSL di Zimbra .
Un certificato è un documento di identità firmato per un server. Il certificato deve essere valido per il nome host utilizzato dai client, rientrare nel suo periodo di validità e risalire a un'autorità di certificazione di cui il componente che si connette si fida. Un certificato può apparire corretto in un browser, mentre su LDAP, Postfix o su un nodo proxy ne è stato distribuito uno diverso.
In qualità di amministratore di Zimbra, visualizza il certificato che Zimbra segnala come distribuito:
/opt/zimbra/bin/zmcertmgr viewdeployedcrt
Verifica il soggetto o il nome alternativo del soggetto (SAN), l'emittente, la data di scadenza e i servizi di ciascun certificato elencato. Il SAN dovrebbe contenere il nome host effettivamente utilizzato per la connessione LDAP o di posta elettronica. Verifica inoltre che tutti i nodi in una distribuzione multi-server dispongano del certificato e della catena previsti. Zimbra precisa che la visualizzazione dei certificati distribuiti è locale al server, pertanto esegui il controllo su ciascun nodo interessato.
Se si dispone dei file del certificato sorgente, prima della distribuzione verificarne date e nomi:
openssl x509 -in /tmp/commercial.crt -noout -dates -subject -issuer -ext subjectAltName
Sostituisci il percorso di esempio con il file del certificato che stai valutando. Un SAN mancante, un certificato foglia o intermedio scaduto, un nome host errato o un certificato emesso per un altro server possono causare l'errore di convalida.
La catena di certificati è l'insieme dei certificati emittenti che permette a un client di risalire all'autorità di certificazione del server. Se il file della catena omette un certificato intermedio o contiene una catena errata, i client potrebbero rifiutare il server anche se il certificato foglia è valido. Il certificato e la chiave privata devono inoltre corrispondere.
Per un certificato commerciale, gli strumenti di certificazione di Zimbra prevedono una fase di verifica. Adatta i percorsi dei file alla tua installazione e all'autorità di certificazione:
/opt/zimbra/bin/zmcertmgr verifycrt comm /opt/zimbra/ssl/zimbra/commercial/commercial.key /tmp/commercial.crt /tmp/ca_chain.crt
Procedere solo se la verifica conferma la corrispondenza tra certificato e chiave privata e la validità della catena di certificati. Non distribuire un certificato dopo una verifica non riuscita. Utilizzare la catena intermedia fornita dall'autorità di certificazione e il formato di catena previsto dalla versione di Zimbra in uso; non assemblare una catena a caso o aggiungendo certificati radice non correlati.
La guida ai certificati di Zimbra documenta la sequenza di verifica e distribuzione, inclusa la catena di autorità di certificazione (CA): Installazione dei certificati Zimbra e strumenti CLI . La pagina di risoluzione dei problemi relativi alla catena di certificati spiega anche gli errori di verifica della catena di emittenti: Guida alla catena di certificati di Zimbra .
Se la verifica rileva un certificato scaduto, una chiave errata, un certificato intermedio mancante o una mancata corrispondenza del nome host, ottenere o generare i file corretti prima della distribuzione. Seguire la procedura specifica per la versione di Zimbra e il tipo di certificato in uso. Per un certificato commerciale, il comando documentato ha la seguente forma generale:
/opt/zimbra/bin/zmcertmgr deploycrt comm /tmp/commercial.crt /tmp/ca_chain.crt
Utilizza la sintassi del comando e i privilegi esatti documentati per la versione installata. La CLI di Zimbra può installare certificati per componenti come MTA, LDAP e proxy, pertanto la distribuzione potrebbe influire su diversi servizi. In un ambiente multi-nodo, verifica che il certificato sia stato distribuito correttamente su ogni server interessato, incluso il master LDAP.
Dopo aver verificato l'avvenuta distribuzione, riavviare i servizi Zimbra durante la finestra di manutenzione pianificata, se la procedura di rilascio lo richiede, quindi confermare lo stato del servizio e i certificati distribuiti:
su - zimbra
zmcontrol restart
zmcontrol status
/opt/zimbra/bin/zmcertmgr viewdeployedcrt
Un riavvio interrompe l'accesso alla posta e al web mentre i servizi si arrestano e riprendono. Non eseguirlo casualmente su un server di produzione occupato. La guida ai certificati Zimbra documenta l'utilizzo zmcontrol restartdopo la distribuzione e la verifica del risultato con viewdeployedcrt.
Se il certificato viene verificato correttamente ma il client LDAP di Zimbra lo rifiuta comunque, è necessario esaminare il materiale di attendibilità LDAP e il nodo problematico. La nota di risoluzione dei problemi MTA archiviata da Zimbra elenca una catena di CA non valida, certificati CA scaduti e file imprevisti /opt/zimbra/conf/catra le possibili cause di errori di STARTTLS di LDAP. Considerate questo come un indizio diagnostico, non come un motivo per eliminare i file: confrontate la directory con un backup funzionante o con le linee guida specifiche della versione e conservatene il contenuto prima di apportare modifiche.
Per una semplice verifica LDAP STARTTLS, un client OpenLDAP può richiedere StartTLS ed eseguire query sul Root DSE senza fornire le credenziali dell'account:
ldapsearch -x -ZZ -H ldap://ldap.example.com:389 -b "" -s base namingContexts
Utilizzare l'host e la porta LDAP effettivi nella propria implementazione. Con gli strumenti OpenLDAP, -ZZvengono richieste le connessioni StartTLS e l'eventuale mancata connessione viene considerata un errore. Se questa verifica fallisce con un messaggio relativo alla fiducia o al certificato, confrontare il certificato restituito dall'endpoint LDAP con il certificato distribuito e con la fiducia CA disponibile per il client. Se il test ha esito positivo da un nodo ma fallisce da un altro, analizzare le differenze nei file DNS, nei file CA o nella configurazione locale.
L'handshake può fallire anche se client e server non riescono a concordare una versione del protocollo TLS o una suite di cifratura. Ciò può accadere con client obsoleti, configurazioni di sicurezza personalizzate o impostazioni predefinite specifiche della versione. Testa l'endpoint con un client OpenSSL aggiornato e verifica le impostazioni TLS di Zimbra per accertarti che la versione del prodotto sia corretta. Evita di copiare vecchi comandi di protocollo da pagine archiviate in un'installazione più recente; la configurazione della cifratura e del protocollo può cambiare tra una versione e l'altra.
Non "correggere" l'errore abilitando SSLv3, indebolendo la verifica o disabilitando globalmente LDAP STARTTLS. In una discussione sul forum di Zimbra è presente una soluzione temporanea che prevedeva la disattivazione di LDAP STARTTLS, ma un altro utente ha giustamente avvertito che disabilitare una funzionalità di sicurezza non rappresenta una corretta riparazione del certificato. Le note di configurazione locale di Zimbra raccomandano di lasciare abilitati sia TLS interprocesso che LDAP STARTTLS. Utilizzare tale modifica solo come strumento diagnostico temporaneo e strettamente controllato, qualora il supporto di Zimbra lo richieda, e ripristinare immediatamente le impostazioni di sicurezza.
zmcontrol statusl'operazione si completa senza errori LDAP TLS, se questo era il problema.Se il problema persiste, raccogli l'errore completo, la versione di Zimbra, il servizio e il nome host interessati, le date dei certificati e il SAN, l'output della verifica e le righe di log pertinenti. Prima di condividere, oscura le chiavi private, le credenziali, gli indirizzi utente e i dettagli sensibili dell'host. Il messaggio preciso è un sintomo, non una diagnosi completa; il nome del servizio circostante e la causa OpenSSL determinano la soluzione corretta.
Nota sulla documentazione: le pagine pubbliche di Zimbra relative ai certificati e al TLS includono materiale per diverse versioni e alcune pagine di risoluzione dei problemi sono esplicitamente archiviate. I comandi qui riportati riflettono il modello CLI documentato, ma i percorsi dei certificati, i privilegi e i requisiti di riavvio devono essere verificati consultando la documentazione della versione di Zimbra installata. Revisionato il 6 ottobre 2026.
Comprendere come i termini "ingress" e "egress" descrivono il traffico in entrata e in uscita, perché la direzione dipende dal confine della rete e come monitorare la larghezza di banda e individuare i trasferimenti di dati rischiosi.
Confronta sei server e collettori syslog gratuiti per Windows e Linux, inclusi strumenti con interfaccia grafica, opzioni open source, funzionalità di ricerca, avvisi e trasporto sicuro.
Scopri cosa fa Microsoft IIS, come funzionano la sua pipeline di richieste e i pool di applicazioni e quando Apache, NGINX o Caddy potrebbero essere più adatti alle tue esigenze di server web.
Diagnostica i picchi di utilizzo della CPU del browser Jitsi Meet e riduci il carico del client controllando i riquadri video, gli effetti della fotocamera, la grafica del browser e le impostazioni dell'host.
Monitora lo stato di salute, il carico della conferenza e il traffico di Jitsi Videobridge con il suo endpoint Prometheus integrato, quindi esplora e visualizza i dati in Grafana.
Configura un dominio personalizzato per Jitsi Meet Docker con DNS, URL pubblico, HTTPS, Let's Encrypt, porte del firewall, impostazioni NAT e verifica end-to-end.
Fix Zimbra Admin Console 404 errors after SSL renewal by checking the correct URL and port, proxy routing, service status, deployed certificates, and logs.
Scopri come diagnosticare e risolvere l'avviso di configurazione di PHP OPcache di Nextcloud controllando l'SAPI PHP attivo, i limiti di dimensionamento, i commenti e le impostazioni di riconvalida.
Risolvere i problemi di migrazione del database Kopano dopo un aggiornamento di MySQL o MariaDB verificando i backup, le versioni del server, le modalità SQL, il set di caratteri, lo stato dello schema e i log.
Collega Nextcloud a LDAP o Active Directory con trasporto sicuro, filtri per utenti e gruppi, attributi di accesso e un'implementazione collaudata.
