Ce message Unable to start TLS: SSL handshake failedindique que la négociation entre le client et le serveur, nécessaire à l'établissement d'une connexion chiffrée, a échoué. Sous Zimbra, ce message peut provenir de différentes sources. Une variante fréquente apparaît lors de zmcontrol statusla vérification du certificat de connexion au serveur LDAP principal. Un client de messagerie ou un relais SMTP peut également signaler un problème d'établissement de liaison sur un port de messagerie public.
La solution dépend de la connexion défaillante. Commencez par identifier le service et le nom d'hôte dans les lignes de journalisation concernées. Vérifiez ensuite le certificat, sa chaîne d'émission, l'horloge système et le point de terminaison TLS. Évitez de désactiver TLS dans un premier temps : cela risque de masquer le problème tout en affaiblissant, voire en interrompant, la communication interne du serveur de messagerie.
TLS est le protocole qui chiffre une connexion réseau. L' établissement d'une liaison TLS est l'échange initial au cours duquel les deux systèmes s'accordent sur les paramètres de chiffrement et valident le certificat du serveur. STARTTLS démarre une connexion en protocole non chiffré, puis bascule vers TLS lorsque les deux parties le demandent. LDAP et SMTP peuvent tous deux utiliser STARTTLS ; par conséquent, cette erreur seule ne permet pas d'identifier le service défaillant.
Avant d'exécuter des commandes de réparation, notez la version de Zimbra, le type d'installation (mono-nœud ou multi-nœuds), la commande ou le client exact qui génère l'erreur, ainsi que la ligne de journal complète correspondante. Planifiez le déploiement des certificats ou le redémarrage des services pendant une fenêtre de maintenance. Conservez une sauvegarde des fichiers de certificats et de la configuration avant toute modification.
Commencez par reproduire le problème et lisez le message complet. S'il apparaît lorsque Zimbra vérifie l'état du service et contient des termes tels que « » when connecting to ldap master, examinez le protocole TLS LDAP interne. Si seul un client de messagerie rencontre un problème lors de l'envoi d'un SMS, examinez le point de terminaison SMTP public ainsi que le nom d'hôte, le port et le mode de chiffrement du client.
su - zimbra
zmcontrol status
Consultez les entrées récentes du journal Zimbra correspondant à l'horodatage. Sur de nombreuses installations, le journal principal se trouve ici/var/log/zimbra.log ; utilisez l'emplacement du journal configuré sur votre serveur.
grep -Ei 'Unable to start TLS|SSL handshake|certificate|ldap|STARTTLS' /var/log/zimbra.log | tail -n 80
Recherchez le nom du processus, l'hôte distant, le port et toute information OpenSSL plus spécifique, comme un échec de vérification du certificat, un certificat expiré, un émetteur inconnu ou une alerte de protocole. Ces détails permettent de distinguer un problème de confiance du certificat d'une incompatibilité de réseau ou de protocole.
En cas d'erreur LDAP interne, vérifiez les hôtes LDAP configurés pour ce serveur. Interrogez individuellement les clés de configuration locales et comparez leurs noms d'hôte avec le DNS et le certificat du serveur :
zmlocalconfig ldap_url
zmlocalconfig ldap_master_url
zmlocalconfig ldap_starttls_supported
zmlocalconfig ldap_starttls_required
La disponibilité et le résultat des clés peuvent varier selon la version de Zimbra et le rôle du nœud. Ces lectures sont destinées au diagnostic ; ne modifiez pas une valeur simplement parce qu'elle apparaît dans le résultat. La documentation de Zimbra décrit le rôle des paramètres LDAP STARTTLS et recommande de maintenir le protocole TLS interne activé : Valeurs de configuration locale TLS et STARTTLS de Zimbra .
La validation des certificats dépend de l'horloge du serveur. Si cette horloge est en avance ou en retard, un certificat valide peut apparaître comme invalide ou expiré. Vérifiez l'heure sur le serveur Zimbra et sur tout serveur LDAP (maître ou réplique) impliqué dans la connexion.
date -u
getent hosts ldap.example.com
Remplacez ldap.example.compar le nom d'hôte LDAP indiqué dans la configuration ou le journal. Vérifiez qu'il correspond bien à l'adresse du serveur attendue et que le port LDAP configuré est accessible via le pare-feu et le réseau de l'hôte. Dans les installations multi-nœuds, effectuez le test depuis le nœud Zimbra ayant enregistré l'erreur jusqu'au nœud LDAP, et non pas seulement depuis votre poste de travail.
Pour une connexion SMTP STARTTLS côté client, le guide de dépannage SMTP de Zimbra explique comment tester le port 25 avec OpenSSL. Le port 587 est également couramment utilisé pour l'envoi de messages avec STARTTLS. Utilisez le nom d'hôte et le port configurés dans votre client de messagerie.
openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com -showcerts
Pour le protocole SMTP sur le port 25, remplacez 587par 25. Le port 465 utilise TLS implicite ; n'ajoutez donc pas -starttls smtplors des tests sur ce port. Une connexion TCP réussie ne prouve pas à elle seule que le certificat est approuvé ni que le client utilise le mode de sécurité approprié. Consultez le guide de dépannage SMTP et OpenSSL de Zimbra .
Un certificat est un document d'identité signé pour un serveur. Il doit être valide pour le nom d'hôte utilisé par les clients, être valide pendant sa période de validité et provenir d'une autorité de certification à laquelle le composant de connexion fait confiance. Un certificat peut sembler correct dans un navigateur alors qu'un certificat différent est déployé sur LDAP, Postfix ou un nœud proxy.
En tant qu'administrateur Zimbra, consultez le certificat que Zimbra signale comme déployé :
/opt/zimbra/bin/zmcertmgr viewdeployedcrt
Vérifiez le sujet ou le nom alternatif du sujet (SAN) de chaque certificat listé, l'émetteur, la date d'expiration et les services. Le SAN doit contenir le nom d'hôte utilisé pour la connexion LDAP ou de messagerie. Assurez-vous également que tous les nœuds d'un déploiement multi-serveurs possèdent le certificat et la chaîne attendus. Zimbra précise que la consultation des certificats déployés est locale au serveur ; effectuez donc la vérification sur chaque nœud concerné.
Si vous disposez des fichiers de certificat source, vérifiez leurs dates et leurs noms avant le déploiement :
openssl x509 -in /tmp/commercial.crt -noout -dates -subject -issuer -ext subjectAltName
Remplacez le chemin d'accès d'exemple par le fichier de certificat que vous évaluez. Un SAN manquant, un certificat final ou intermédiaire expiré, un nom d'hôte incorrect ou un certificat émis pour un autre serveur peuvent tous entraîner un échec de validation.
La chaîne de certificats est l'ensemble des certificats d'émetteurs permettant à un client de retracer le certificat du serveur jusqu'à une autorité de confiance. Si le fichier de chaîne omet un certificat intermédiaire ou contient une chaîne incorrecte, les clients peuvent rejeter le serveur même si le certificat final est valide. Le certificat et la clé privée doivent également former une paire cohérente.
Pour un certificat commercial, les outils de certificats de Zimbra proposent une étape de vérification. Adaptez les chemins d'accès aux fichiers à votre installation et à votre autorité de certification :
/opt/zimbra/bin/zmcertmgr verifycrt comm /opt/zimbra/ssl/zimbra/commercial/commercial.key /tmp/commercial.crt /tmp/ca_chain.crt
Procédez uniquement si la vérification confirme la correspondance du certificat et de la clé privée et la validité de la chaîne de certificats. Ne déployez pas de certificat après un échec de vérification. Utilisez la chaîne intermédiaire fournie par l'autorité de certification et le format de chaîne attendu par votre version de Zimbra ; n'assemblez pas de chaîne par supposition ou en y ajoutant des certificats racine non liés.
Le guide des certificats de Zimbra décrit la séquence de vérification et de déploiement, y compris la chaîne d'autorité de certification : Installation des certificats Zimbra et outils en ligne de commande . Sa page de dépannage de la chaîne de certificats explique également les erreurs de vérification de la chaîne d'émetteurs : Guide de la chaîne de certificats Zimbra .
Si la vérification révèle un certificat expiré, une clé incorrecte, un fichier intermédiaire manquant ou une incohérence de nom d'hôte, obtenez ou générez les fichiers corrects avant le déploiement. Suivez la procédure correspondant à votre version de Zimbra et à votre type de certificat. Pour un certificat commercial, la commande documentée se présente généralement sous la forme suivante :
/opt/zimbra/bin/zmcertmgr deploycrt comm /tmp/commercial.crt /tmp/ca_chain.crt
Utilisez la syntaxe de commande et les privilèges exacts documentés pour votre version installée. L'interface de ligne de commande (CLI) de Zimbra permet d'installer des certificats pour des composants tels que le MTA, LDAP et le proxy ; le déploiement peut donc affecter plusieurs services. Dans un environnement multi-nœuds, vérifiez que le certificat est correctement déployé sur chaque serveur concerné, y compris le serveur LDAP principal.
Après un déploiement vérifié, redémarrez les services Zimbra pendant la fenêtre de maintenance planifiée si la procédure de mise en production l'exige, puis confirmez l'état du service et les certificats déployés :
su - zimbra
zmcontrol restart
zmcontrol status
/opt/zimbra/bin/zmcertmgr viewdeployedcrt
Un redémarrage interrompt l'accès à la messagerie et au Web pendant l'arrêt et le redémarrage des services. Ne l'exécutez pas à la légère sur un serveur de production fortement sollicité. Le guide des certificats Zimbra documente leur utilisation zmcontrol restartaprès le déploiement et la vérification du résultat viewdeployedcrt.
Si le certificat est valide mais que le client LDAP de Zimbra le rejette, examinez les informations de confiance LDAP et le nœud défaillant. La note de dépannage MTA archivée de Zimbra mentionne une chaîne d'autorité de certification invalide, des certificats d'autorité de certification expirés et des fichiers inattendus /opt/zimbra/conf/caparmi les causes possibles d'échecs STARTTLS LDAP. Considérez cela comme une piste de diagnostic, et non comme une raison de supprimer des fichiers : comparez le répertoire avec une sauvegarde valide ou les instructions spécifiques à votre version, et conservez son contenu avant toute modification.
Pour une simple sonde LDAP STARTTLS, un client OpenLDAP peut exiger StartTLS et interroger le DSE racine sans fournir d'informations d'identification du compte :
ldapsearch -x -ZZ -H ldap://ldap.example.com:389 -b "" -s base namingContexts
Utilisez l'hôte et le port LDAP réels de votre déploiement. Avec les outils OpenLDAP, -ZZune requête StartTLS est effectuée et tout échec d'établissement de cette connexion est considéré comme une erreur. Si cette requête échoue avec un message d'erreur relatif à la confiance ou au certificat, comparez le certificat renvoyé par le point de terminaison LDAP avec le certificat déployé et la confiance de l'autorité de certification (CA) disponible pour le client. Si le test réussit sur un nœud mais échoue sur un autre, examinez les différences au niveau du DNS, des fichiers de l'autorité de certification ou de la configuration locale.
L'établissement d'une liaison TLS peut également échouer si le client et le serveur ne parviennent pas à s'accorder sur la version du protocole TLS ou la suite de chiffrement. Cela peut se produire avec des clients obsolètes, des configurations de sécurité personnalisées ou des paramètres par défaut spécifiques à une version. Testez le point de terminaison avec un client OpenSSL à jour et vérifiez la version exacte du produit dans les paramètres TLS de Zimbra. Évitez de copier d'anciennes commandes de protocole depuis des archives vers une installation plus récente ; la configuration du chiffrement et du protocole peut changer d'une version à l'autre.
Ne tentez pas de « corriger » l'erreur en activant SSLv3, en affaiblissant la vérification ou en désactivant globalement LDAP STARTTLS. Un sujet du forum Zimbra mentionne une ancienne solution de contournement qui désactivait LDAP STARTTLS, mais un autre utilisateur a, à juste titre, averti que la désactivation d'une fonction de sécurité n'est pas une solution fiable pour réparer un certificat. Les notes de configuration locale de Zimbra recommandent de laisser TLS interprocessus et LDAP STARTTLS activés. N'utilisez cette modification qu'à titre de diagnostic temporaire et strictement contrôlé, si le support Zimbra vous le demande, et rétablissez immédiatement les paramètres de sécurité.
zmcontrol statusL'opération se termine sans erreur LDAP TLS, si telle était l'opération ayant échoué.Si le problème persiste, veuillez collecter l'erreur complète, la version de Zimbra, le service et le nom d'hôte concernés, les dates et SAN des certificats, le résultat de la vérification et les lignes de journal pertinentes. Avant de partager ces informations, masquez les clés privées, les identifiants, les adresses IP et les données sensibles de l'hôte. Le message d'erreur précis n'est qu'un symptôme et non un diagnostic complet ; le nom du service concerné et la raison OpenSSL déterminent la réparation appropriée.
Note concernant la documentation : les pages relatives aux certificats publics et au protocole TLS de Zimbra contiennent des informations pour plusieurs versions, et certaines pages de dépannage sont archivées. Les commandes présentées ici suivent le modèle de ligne de commande documenté, mais il est recommandé de vérifier les chemins d’accès aux certificats, les privilèges et les exigences de redémarrage dans la documentation de la version de Zimbra installée. Mise à jour le 6 octobre 2026.
Comparez 10 outils de balayage ping pour une découverte rapide du réseau local, une analyse multiplateforme et la gestion des adresses IP. Découvrez ce qu'un balayage peut – et ne peut pas – vous révéler.
Comparez six outils de gestion de réseau pour la surveillance des performances, notamment la couverture SNMP, la cartographie, les alertes, les modèles de déploiement et les compromis en matière de coûts.
Comparez sept moniteurs de ping gratuits et open source, allant des suites réseau complètes aux sondes de latence ciblées, et choisissez celui qui convient le mieux à vos besoins en matière de disponibilité, de perte de paquets et d'historique.
Comparez les meilleurs analyseurs Wi-Fi pour Windows, iPhone et Android, incluant des outils pour la congestion des canaux, la couverture du signal, les cartes thermiques et le dépannage réseau.
Découvrez ce que signifie la QoS dans le domaine des réseaux, comment les marquages DSCP et les files d'attente de trafic priorisent la voix, la vidéo et les applications professionnelles, et ce que la QoS ne peut pas corriger.
Comparez les logiciels serveurs SFTP fiables pour Windows et Linux, notamment OpenSSH, Bitvise, SolarWinds et SFTPGo. Trouvez la solution idéale pour vos besoins en matière de sécurité et de transfert de fichiers.
Comparez sept outils de gestion d'adresses IP pour la découverte de sous-réseaux, la coordination DNS et DHCP, l'inventaire réseau et l'IPAM open source.
Mettez en place une surveillance réseau pratique avec une couverture claire des périphériques, des indicateurs de performance utiles, des alertes exploitables et une comparaison de SolarWinds NPM, PRTG et OpManager.
Comparez les outils d'analyse réseau pour la découverte rapide des périphériques, les analyses IP multiplateformes et la gestion des identités et des accès IP (IPAM) d'entreprise, avec des conseils pour adapter chaque option à votre réseau.
Utilisez l'option --traceroute de Nmap pour associer les sauts à un hôte autorisé, comprendre les résultats des sauts et du RTT, et résoudre les problèmes de réponses manquantes sans sur-analyse.
