Résoudre le problème d'expiration des certificats Zimbra : Renouvelez vos certificats auto-signés en toute sécurité

Un serveur Zimbra peut sembler fonctionner correctement jusqu'à ce que les utilisateurs reçoivent soudainement un avertissement de leur navigateur tel que « certificat expiré », que les clients de messagerie refusent une connexion SSL/TLS ou qu'un administrateur découvre que la date d'expiration du certificat est dépassée. La solution la plus rapide et la plus sûre consiste à ne pas remplacer immédiatement tous les composants du certificat. Commencez par identifier les éléments expirés, puis renouvelez uniquement la partie nécessaire.

La procédure actuelle du Centre technique de Zimbra pour le déploiement d'un certificat auto-signé sur un serveur unique permet zmcertmgrde créer et de déployer des certificats. Il est important de noter que Zimbra précise que la création d'une nouvelle autorité de certification (AC) est facultative pour le renouvellement d'un certificat auto-signé classique ; il n'est pas nécessaire de remplacer l'AC à chaque expiration du certificat du serveur. Les références officielles utilisées pour ce guide ont été consultées le 6 octobre 2026 : Régénérer un certificat SSL auto-signé — Serveur unique et console d'administration et outils de certificat en ligne de commande .

Pourquoi un certificat Zimbra expiré provoque de réels problèmes de service

Zimbra utilise des certificats TLS pour ses services, notamment l'interface web, le proxy, LDAP et les protocoles de messagerie. Lorsqu'un certificat expire, les clients peuvent refuser la connexion, même si les processus Zimbra sous-jacents sont toujours en cours d'exécution. Un avertissement du navigateur n'est donc qu'un symptôme parmi d'autres. Selon votre architecture et la politique de sécurité de vos clients, vous pouvez également rencontrer des échecs de connexion IMAP/POP/SMTP sécurisée, des erreurs de proxy ou des problèmes LDAP/TLS.

Il existe deux cas d'expiration différents à distinguer :

• Seul le certificat du serveur a expiré. C'est le cas le plus simple. Conservez l'autorité de certification Zimbra existante si elle est encore valide, générez un nouveau certificat serveur, déployez-le et redémarrez les services.
• L'autorité de certification Zimbra a expiré. Recréez-la et déployez-la, puis créez et déployez un nouveau certificat serveur signé par cette autorité. Dans un déploiement multi-serveurs, la cohérence de l'autorité de certification entre les nœuds est essentielle ; par conséquent, ne traitez pas un environnement multi-nœuds comme un serveur unique.

Avant toute modification, effectuez une sauvegarde ou un instantané récent adapté à votre environnement. La régénération des certificats est généralement simple, mais une sauvegarde vous offre un point de restauration si le serveur comporte d'anciennes personnalisations, des certificats installés manuellement ou une topologie mixte.

Étape 1 : Vérifier que le certificat déployé est bien expiré.

Passez au compte Zimbra et examinez le certificat actuellement déployé sur les services locaux :

su - zimbra
/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Vérifiez les dates de validité et le sujet du certificat. Si le certificat est toujours valide, recherchez d'abord une incohérence dans le nom d'hôte, une autorité de certification auto-signée non approuvée, un ancien certificat toujours utilisé par un proxy ou une synchronisation serveur/client incorrecte, plutôt que de régénérer inutilement les certificats.

Vous pouvez également vérifier le certificat qu'un client distant reçoit effectivement sur HTTPS. Remplacez mail.example.compar le nom d'hôte auquel les utilisateurs se connectent :

openssl s_client -connect mail.example.com:443 -servername mail.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Cette vérification à distance est utile lorsque le certificat viewdeployedcrtsemble correct mais que les navigateurs affichent encore un ancien certificat, car elle teste le certificat présenté sur le réseau et non seulement les fichiers sur le disque.

Étape 2 : Vérifiez l’état du service et déterminez si l’autorité de certification doit également être renouvelée.

Avant de modifier les certificats, vérifiez l'état actuel du service Zimbra afin d'avoir une base de référence :

zmcontrol status

Si seul le certificat du serveur a expiré et que l'autorité de certification Zimbra est toujours valide, ignorez la recréation de l'autorité de certification et passez directement aux commandes de certificat serveur de la section suivante. Cela minimise les modifications de la chaîne de confiance. La documentation Zimbra pour serveur unique indique clairement que la création d'une nouvelle autorité de certification est facultative et n'est pas requise à chaque renouvellement d'un certificat auto-signé.

Si l'autorité de certification a expiré ou si vous avez une raison documentée de la remplacer, créez-en une nouvelle :

/opt/zimbra/bin/zmcertmgr createca -new
/opt/zimbra/bin/zmcertmgr deployca

Étape 3 : Générer et déployer un nouveau certificat de serveur auto-signé

Pour un renouvellement simple sur un seul serveur, Zimbra documente la procédure suivante. Cet exemple crée un certificat valable 365 jours :

/opt/zimbra/bin/zmcertmgr createcrt -new -days 365
/opt/zimbra/bin/zmcertmgr deploycrt self

Si des clients se connectent via plusieurs noms DNS, générez le certificat avec les noms alternatifs de sujet (SAN) requis plutôt que de supposer que le nom d'hôte par défaut est suffisant. L'outil de certificats de Zimbra prend en charge cette fonctionnalité -subjectAltNames. Par exemple :

/opt/zimbra/bin/zmcertmgr createcrt -new -days 365 -subjectAltNames "mail.example.com,webmail.example.com"
/opt/zimbra/bin/zmcertmgr deploycrt self

Utilisez des noms qui pointent réellement vers ce service Zimbra et que vos utilisateurs ou intégrations utilisent effectivement. Un certificat peut être valide mais échouer à la validation si le nom d'hôte demandé n'est pas couvert par ses valeurs de sujet/SAN.

N’utilisez pas cette procédure d’auto-signature pour remplacer par erreur un certificat commercial/publiquement reconnu. Si votre serveur est censé utiliser un certificat commercial, arrêtez-vous ici et suivez plutôt la procédure de déploiement de certificat commercial de Zimbra.

Étape 4 : Vérifiez le déploiement, redémarrez Zimbra et effectuez un test côté client.

Veuillez confirmer que Zimbra a déployé le nouveau certificat :

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Redémarrez ensuite Zimbra pour que les services chargent le nouveau certificat :

zmcontrol restart

Une fois le redémarrage terminé, exécutez :

zmcontrol status
/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Le résultat souhaité est simple : les services attendus sont opérationnels et le certificat déployé a désormais une date d’expiration ultérieure. Enfin, relancez le test OpenSSL distant sur le nom d’hôte auquel les utilisateurs accèdent réellement. Cela permet de vérifier ce qui est servi sur le réseau après le redémarrage.

Si le navigateur affiche toujours l'ancien certificat ou celui qui a expiré, veuillez le signaler.

Ne régénérez pas immédiatement un autre certificat. Suivez les étapes suivantes dans l'ordre :

• Vérifiez le DNS et le nom d'hôte. Assurez-vous de tester le même nom d'hôte que celui couvert par le nouveau certificat et d'accéder au serveur Zimbra prévu.
• Vérifiez le chemin du proxy. La documentation de dépannage des certificats de Zimbra indique qu'un proxy peut, dans certains cas, continuer à présenter un ancien certificat. Examinez le certificat présenté à distance, et pas seulement les fichiers de certificat locaux. Consultez la section Erreurs de certificat Zimbra .
• Vérifiez la confiance accordée par le client. Un certificat auto-signé renouvelé peut être valide jusqu'à une certaine date tout en restant non reconnu par les navigateurs ou les clients de messagerie. Expiration et confiance sont deux choses distinctes.
• Vérifiez l'heure système. Une horloge incorrecte sur le serveur ou le client peut faire apparaître un certificat pourtant valide comme non valide ou expiré.
• Vérifiez l'autorité de certification. Si le certificat final est récent mais que l'autorité de certification Zimbra émettrice a expiré, remplacez-la et régénérez le certificat du serveur à partir de la nouvelle autorité de certification.

Zimbra multi-serveurs nécessite un niveau de maintenance différent.

Pour une installation multi-nœuds, utilisez la procédure multi-serveurs plutôt que de répéter aveuglément les commandes mono-serveur sur chaque hôte. Zimbra documente la création et le déploiement de l'autorité de certification, puis le déploiement du certificat auto-signé sur les nœudsdeploycrt self -allserver ; il est également précisé que cette viewdeployedcrtprocédure ne prend en compte que le serveur local. La documentation officielle est : Régénérer un certificat SSL auto-signé – Multi-serveurs .

Une incompatibilité d'autorité de certification entre un serveur LDAP maître et ses réplicas peut engendrer des problèmes de TLS et de réplication. Dans une topologie multi-serveurs, vérifiez la chaîne d'autorité de certification sur chaque nœud concerné et respectez l'ordre de déploiement documenté.

Auto-vérification : comment savoir si la réparation est terminée

Avant de clore l'incident, veuillez vérifier les points suivants :

• zmcontrol statusaffiche les services Zimbra attendus en cours d'exécution.
• zmcertmgr viewdeployedcrtaffiche un certificat dont la date d'expiration est future.
• Une openssl s_clientvérification à distance renvoie les mêmes dates de nouveau certificat pour le nom d'hôte public/interne réellement utilisé par les utilisateurs.
• Le sujet du certificat ou SAN couvre ce nom d'hôte.
• Le webmail et les protocoles de messagerie utilisés par votre environnement peuvent établir des connexions TLS.
• Si vous avez intentionnellement remplacé l'autorité de certification Zimbra, les clients ou les systèmes internes qui épinglent ou font confiance à l'ancienne autorité de certification ont été mis à jour comme prévu.

En cas d'expiration de certificat sur un serveur unique, la solution la moins perturbatrice consiste généralement à conserver un certificat d'autorité de certification Zimbra encore valide, à créer un nouveau certificat serveur auto-signé, à le déployer, à redémarrer les services et à vérifier le certificat depuis l'extérieur du serveur. Il est recommandé de remplacer l'autorité de certification uniquement lorsqu'elle expire ou s'il existe une autre raison valable de la renouveler. Cette approche permet de résoudre l'interruption de service immédiate tout en évitant des modifications inutiles de la chaîne de confiance.