Comment installer un certificat SSL commercial sur un serveur Zimbra

Un certificat SSL commercial sur Zimbra peut présenter plusieurs défaillances frustrantes, même si l'autorité de certification affirme qu'il a été émis correctement. Les problèmes les plus courants ne proviennent généralement pas du certificat lui-même : la clé privée ne correspond pas au certificat renvoyé, une autorité de certification intermédiaire est manquante, le nom d'hôte est absent du champ SAN (Subject Alternative Name) du certificat, ou l'administrateur déploie les fichiers avant d'avoir validé la chaîne.

La méthode la plus sûre consiste à procéder par étapes, en effectuant une série de vérifications plutôt qu'en utilisant une simple commande d'installation de certificat. L'outil de gestion des certificats de Zimbra, documenté par Zimbra, zmcertmgrpermet de créer une demande de signature de certificat (CSR), de vérifier la clé privée et la chaîne d'autorité de certification, de déployer le certificat sur les services Zimbra et d'afficher le certificat actuellement actif. Le Centre technique officiel de Zimbra documente ces commandes dans son guide « Outils de gestion des certificats pour la console d'administration et l'interface de ligne de commande » .

Voici à quoi devrait ressembler une installation Zimbra SSL réussie

Avant toute modification, définissez le résultat souhaité. Un déploiement correct doit respecter toutes les conditions suivantes :

• La liste SAN du certificat comprend tous les noms d'hôte publics réellement utilisés par les clients, tels que mail.example.com.
• Le certificat émis correspond à la clé privée stockée pour le certificat commercial.
• Zimbra peut valider la chaîne complète, du certificat serveur aux certificats d'autorité de certification intermédiaires, jusqu'à l'autorité de certification racine.
• zmcertmgr deploycrt commL'opération se termine sans erreur de correspondance de clé ni d'erreur de validation de chaîne.
• Les services Zimbra redémarrent correctement.
• zmcertmgr viewdeployedcrtaffiche le certificat attendu.
• Un navigateur ou un client TLS se connectant au nom d'hôte public voit le nouveau certificat et un avertissement de non-confiance.

Si l'un de ces contrôles échoue, corrigez la couche concernée avant de poursuivre. Le redéploiement répété des mêmes fichiers résout rarement un problème de clé, de SAN ou de chaîne.

Avant de commencer : choisissez le flux de travail de certificat approprié

La page du centre technique de Zimbra indique que, sur Zimbra 8.7 et versions ultérieures, zmcertmgrl'exécution se fait avec les zimbradroits de l'utilisateur. Elle précise également que la clé privée commerciale doit être nommée commercial.keydans le fichier /opt/zimbra/ssl/zimbra/commercialde configuration et que le certificat serveur ainsi que le fichier de chaîne d'autorité de certification doivent être placés dans un répertoire temporaire avant le déploiement.

Étape 1 : Sauvegardez le matériel de certificat actuel

Ne commencez pas par supprimer le répertoire SSL existant. Créez d'abord une sauvegarde que vous pourrez restaurer en cas d'échec du nouveau déploiement. En tant qu'administrateur, voici un exemple prudent :

cp -a /opt/zimbra/ssl/zimbra /opt/zimbra/ssl/zimbra.backup-$(date +%Y%m%d-%H%M%S)

Veuillez également noter le certificat actuellement déployé avant de le modifier :

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

Cela vous permet d'établir une base de comparaison après la modification. Si votre environnement comporte plusieurs nœuds Zimbra, il est important de noter l'état actuel du certificat sur chaque serveur concerné plutôt que de supposer qu'ils sont identiques.

Étape 2 : générez une CSR avec les noms d’hôtes dont vous avez réellement besoin.

Pour un nouveau certificat commercial, créez la CSR avec le nom d'hôte de production et les SAN supplémentaires. Zimbra documente la syntaxe suivante :

/opt/zimbra/bin/zmcertmgr createcsr comm -new \
-subject "/C=US/ST=CA/L=Sunnyvale/O=Example/OU=IT/CN=mail.example.com" \
-subjectAltNames "mail.example.com"

Si des utilisateurs se connectent également via un autre nom, par exemple `<nom_hôte>` webmail.example.com, incluez-le dans la liste SAN lors de la demande de certificat. Les clients TLS modernes valident les noms d'hôtes par rapport aux SAN ; par conséquent, un certificat qui semble correct d'après le nom commun seul peut tout de même générer un avertissement dans le navigateur si le nom d'hôte est manquant.

Veuillez vérifier la CSR avant de l'envoyer à votre autorité de certification :

/opt/zimbra/bin/zmcertmgr viewcsr comm /opt/zimbra/ssl/zimbra/commercial/commercial.csr

Point de contrôle : arrêtez-vous ici si les noms DNS demandés sont incorrects. Si vous émettez le certificat en premier et découvrez ultérieurement un SAN manquant, vous devrez généralement demander à l’autorité de certification de le réémettre.

Étape 3 : récupérer le certificat du serveur et la chaîne d’autorité de certification complète

Après validation, votre autorité de certification commerciale renvoie généralement le certificat serveur ainsi qu'un ou plusieurs certificats intermédiaires. La procédure officielle de Zimbra pour les certificats commerciaux à nœud unique exige le certificat serveur au format PEM et indique aux administrateurs de combiner les certificats d'autorité de certification intermédiaires et racine dans un fichier de chaîne.

Une configuration typique de scène est :

/tmp/commercial.crt
/tmp/ca_intermediary.crt
/tmp/ca.crt

Ensuite, construisez la chaîne dans l'ordre documenté par Zimbra :

cat /tmp/ca_intermediary.crt /tmp/ca.crt > /tmp/ca_chain.crt

Utilisez les fichiers fournis par votre autorité de certification pour votre produit de certificat spécifique. Ne copiez pas un certificat intermédiaire provenant d'un tutoriel sans rapport avec le sujet, même si le nom de l'autorité de certification semble similaire. Les hiérarchies des autorités de certification évoluent, et l'utilisation d'un certificat intermédiaire incorrect est une cause fréquente de problèmes unable to get local issuer certificate.

Étape 4 : vérifier la clé privée, le certificat du serveur et la chaîne avant le déploiement

Il s'agit de la mesure de sécurité la plus importante. Exécutez la commande de vérification documentée en tant qu'utilisateur Zimbra sur les versions actuelles de Zimbra :

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

Une vérification réussie indique que le certificat et la clé privée correspondent et que le certificat est valide. La documentation de l'outil de gestion des certificats de Zimbra explique que cette vérification verifycrtcombine un contrôle de clé et un contrôle de la chaîne de certificats.

Si la vérification échoue, choisissez la solution en fonction de l'erreur.

• Certificat et clé privée incompatibles : le certificat d’autorité de certification n’a pas été émis à partir de la demande de signature de certificat (CSR) associée à la session actuelle commercial.key. Restaurez la clé correcte ou réémettez le certificat à partir d’une nouvelle CSR.
• Impossible de valider la chaîne de certificats : le paquet intermédiaire/racine est incomplet, dans le mauvais ordre, expiré ou ne correspond pas à la chaîne de ce certificat serveur. Veuillez obtenir la chaîne correcte auprès de l’autorité de certification émettrice.
• Le certificat a expiré : ne le déployez pas. Demandez un certificat valide et vérifiez également si un certificat intermédiaire ou racine de la chaîne a expiré. Zimbra documente ce type d’erreur dans son guide de dépannage relatif aux autorités de certification racine expirées .
• Nom d'hôte manquant : la vérification peut ne pas correspondre à celle effectuée par un navigateur. Vérifiez les SAN émis et réémettez-les si le nom public est absent.

Étape 5 : déployer le certificat commercial

Vous ne devriez le déployer qu'après la réussite de la vérification :

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

Le processus de déploiement documenté de Zimbra copie le certificat commercial dans sa zone SSL, ajoute la chaîne d'autorité de certification, met à jour la configuration du certificat et installe le matériel de certificat pour les services tels que les composants MTA, LDAP, proxy et de boîte aux lettres, selon le serveur.

Ne remplacez pas manuellement des fichiers de clés Java ou des certificats de service aléatoires, sauf si la documentation de votre version de Zimbra l'exige explicitement. L'objectif zmcertmgrest de garantir la cohérence des certificats spécifiques au service.

Étape 6 : redémarrer les services Zimbra

Après le déploiement, redémarrez Zimbra :

su - zimbra
zmcontrol restart

Vérifiez ensuite l'état du service :

zmcontrol status

Si un service ne répond pas Running, effectuez des investigations avant de déclarer la modification du certificat terminée. Les problèmes de certificat peuvent affecter LDAP, le proxy, la messagerie ou d'autres communications dépendant de TLS, notamment dans les installations multi-nœuds.

Étape 7 : vérifier le résultat côté Zimbra et côté client

Utilisez d'abord la vue de certificats de Zimbra :

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Vous pouvez également vérifier si un certificat de service déployé arrive bientôt à expiration :

/opt/zimbra/bin/zmcertmgr checkcrtexpiration all -days 30

Enfin, vérifiez le nom d'hôte public exact que les utilisateurs consultent. Une vérification OpenSSL utile depuis une autre machine consiste à :

openssl s_client -connect mail.example.com:443 -servername mail.example.com -showcerts

Recherchez le certificat final attendu, le nom d'hôte correct, une chaîne complète et un résultat de vérification positif. Ouvrez ensuite la même URL HTTPS dans un navigateur actuel. Ce test est important car il vérifie le nom d'hôte réellement accessible par les utilisateurs, et non seulement les fichiers de certificat sur le disque.

Lorsque la procédure standard ne suffit pas

Modifiez votre approche plutôt que de forcer les étapes à nœud unique si l'une de ces conditions s'applique :

• Dans une architecture Zimbra multi-nœuds, le déploiement des certificats peut nécessiter de couvrir les rôles de proxy, de boîte aux lettres, de LDAP et de MTA sur différents hôtes. L'outil de gestion des certificats de Zimbra prend en charge les options multi-serveurs ; toutefois, il est impératif de vérifier la procédure adaptée à votre topologie avant de les utiliser.
• Le proxy inverse ou l'équilibreur de charge externe termine la connexion TLS : le certificat public doit peut-être également être installé sur ce périphérique. Un certificat Zimbra valide ne modifiera pas à lui seul ce que voient les clients si la connexion TLS est terminée en amont.
• Vous importez une clé existante : assurez-vous qu’elle est placée à l’endroit où Zimbra attend la clé privée commerciale et que les autorisations correspondent aux exigences de la version avant la vérification.
• Votre autorité de certification ne fournit qu'un ensemble intermédiaire : suivez les instructions de la chaîne de certificats actuelle de l'autorité de certification plutôt que de créer un certificat racine. Zimbra a besoin d'une chaîne qu'il peut valider ; les fichiers exacts dépendent de l'émetteur.
• Le certificat a été renouvelé avec le même nom d'hôte mais une clé différente : veuillez mettre à jour la clé privée correspondante avant la vérification. commercial.keyUn certificat précédemment émis pour une nouvelle paire de clés ne peut être validé.

Auto-vérification finale

L'installation est terminée uniquement lorsque toutes les conditions suivantes sont remplies : verifycrtl'installation deploycrtréussit, les services Zimbra reviennent à l'état « En cours d'exécution », viewdeployedcrtle nouveau certificat est affiché et une connexion TLS externe au nom d'hôte réel reçoit le même certificat valide sans avertissement de confiance ou de nom d'hôte.

Pour la syntaxe des commandes et le comportement spécifique à chaque version, veuillez consulter la documentation officielle de Zimbra relative aux outils de certificats . Les exemples présentés ici utilisent mail.example.comdes valeurs génériques ; remplacez les noms, les fichiers de certificats et les informations organisationnelles par les valeurs correspondantes dans votre environnement.