Résoudre une erreur de négociation SSL Kopano sur un port personnalisé

Définir ce à quoi ressemble une solution réussie

Une erreur de négociation SSL Kopano signifie qu'un client et un serveur n'ont pas pu établir ou finaliser la connexion TLS. Le port personnalisé peut être correct pour une partie de la configuration et incorrect pour une autre. Avant de modifier les certificats ou les paramètres de protocole, identifiez le service propriétaire du port et vérifiez si le protocole TLS y est requis.

Pour une configuration fonctionnelle, le port prévu accepte une connexion TLS, présente un certificat valide pour le nom d'hôte utilisé par les clients et permet l'exécution de l'étape suivante du protocole. Un navigateur doit accéder à la page de connexion de l'application Web sans avertissement de certificat. Un client Kopano Core doit se connecter en utilisant le port TLS correspondant et, le cas échéant, son certificat client de confiance. Une sonde TLS réussie ne garantit pas à elle seule le bon fonctionnement de la connexion à l'application Web, de l'authentification Kopano ou de la distribution des e-mails.

Commencez par séparer les deux configurations de ports communes.

Vérifié pour Kopano Core : le manuel d'administration de Kopano Core 8.0 décrit un écouteur TLS natif contrôlé par [ nom du gestionnaire de certificats server_listen_tls]. Son exemple utilise le port 237, précise que ce port peut être modifié et configure les fichiers de certificat et d'autorité de certification dans [ nom du répertoire] /etc/kopano/server.cfg. Le manuel montre également les clients utilisant un https://socket serveur avec le port et le certificat client correspondants. Voir Kopano Core : Connexions et certificats SSL et Configurations spéciales de Kopano Core .

Pour accéder à l'application Web, les utilisateurs ouvrent généralement une URL dans un navigateur hébergée par Apache, Nginx ou Kopano Web. La connexion TLS peut être établie au niveau de ce serveur frontal, qui transfère les requêtes aux services Kopano. Le manuel de Kopano explique comment configurer un proxy HTTP vers le serveur d'écoute principal sur le port 236, tandis que le guide de Kopano Web décrit la configuration des certificats TLS /etc/kopano/kwebd.cfg. Le port HTTPS du serveur frontal n'est pas automatiquement identique au port TLS du serveur principal. Consultez l' exemple de proxy inverse du serveur principal et le guide d'installation de Kopano Web .

Action : notez l’URL du client, le port personnalisé, le processus qui doit écouter sur ce port et si la connexion TLS se termine au niveau du proxy ou de Kopano Core. Ne modifiez pas les deux écouteurs simultanément.

1. Vérifiez ce qui écoute sur le port personnalisé

Sur l'hôte Kopano, remplacez 8443ci-dessous par le port qui pose problème :

sudo ss -ltnp | grep ':8443'

Une ligne correspondante devrait afficher un socket d'écoute. Si aucune ligne n'est présente, le service n'est pas lié à ce port, ou bien il est lié à une autre adresse. Si le port appartient à un proxy inverse local, examinez l'hôte virtuel du proxy. S'il s'agit du port TLS natif de Kopano Core, consultez server_listen_tlsla configuration /etc/kopano/server.cfg. Un processus écoutant uniquement sur un port spécifique 127.0.0.1ne peut pas accepter directement les connexions distantes ; ce comportement peut être intentionnel lorsqu'un proxy est utilisé.

Vérifiez également le pare-feu hôte, le pare-feu cloud et toute règle d'équilibrage de charge ou NAT. Le port public doit pouvoir accéder au serveur interne prévu. Un délai d'attente ou un refus de connexion indique un problème d'accessibilité ou de configuration du serveur ; cela ne signifie pas nécessairement que le certificat est invalide.

2. Sonder le protocole TLS sur le nom d'hôte et le port exacts

Depuis un poste client, testez le point de terminaison public avec OpenSSL. Utilisez le nom DNS figurant dans le certificat, et non une adresse IP non liée :

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

Recherchez le certificat présenté, le protocole et le chiffrement négociés, ainsi que les éventuelles erreurs de vérification. Cette -servernameoption envoie le nom d'hôte SNI TLS ; cela est important lorsqu'un serveur héberge plusieurs sites TLS. OpenSSL documente ces options dans son manuel s_client . Appuyez sur Ctrl+C pour quitter l'interface interactive.

En l'absence de certificat, le point de terminaison peut utiliser le protocole HTTP non standard, le port peut appartenir à un service incorrect ou un proxy peut rediriger vers un serveur en amont erroné. Si un certificat est présent mais que son nom, son émetteur ou sa date d'expiration sont incorrects, corrigez la sélection ou la chaîne de certificats sur le point de terminaison TLS. Une incohérence de nom d'hôte ne sera pas résolue par la modification du port d'écoute de Kopano Core.

Pour un point de terminaison accessible via un navigateur, poursuivez avec :

curl -v https://mail.example.com:8443/webapp/

La sortie détaillée permet de distinguer la vérification TLS d'une réponse HTTP telle qu'une redirection, une erreur 404 ou 502. Une erreur 404 après une négociation TLS réussie indique un problème de chemin ou de routage, et non un échec de négociation TLS. À des fins de diagnostic ponctuel, cette fonctionnalité curl -vkpermet de déterminer si le fait de désactiver la vérification du certificat modifie le résultat. Ne désactivez pas la vérification des certificats dans un navigateur, un client ou un proxy.

Limite importante : Kopano Core prend en charge nativement le protocole TLS et peut utiliser des certificats clients. Un s_clienttest de base sans certificat client peut être rejeté même si le service TLS fonctionne correctement. Si le serveur exige une authentification du client, répétez le test avec le certificat et la clé clients autorisés, ou effectuez le test avec le client de service Kopano configuré. Ne divulguez jamais votre clé privée dans un journal de commandes ou un ticket d'assistance.

3. Faire correspondre le protocole à l'écouteur

Une erreur fréquente lors de la configuration d'un port personnalisé consiste à configurer un client HTTPS pour qu'il contacte un serveur HTTP simple, ou à rediriger le trafic HTTPS vers un serveur en amont qui attend du trafic HTTP. Le schéma et le port doivent correspondre au même point de terminaison.

• https://mail.example.com:8443/webapp/cela signifie que le navigateur attend une connexion TLS sur le port 8443.
• L'exemple documenté de Kopano Core envoie du HTTP via un proxy 127.0.0.1:236. Si votre déploiement utilise ce modèle, le proxy en amont doit utiliser http://HTTPS, même si la connexion du navigateur public utilise HTTPS.
• Pour le protocole TLS natif de Kopano Core, l'exemple du manuel utilise server_listen_tls = *:237une URL client commençant par `/etc/kopanocore.com` https://. Si vous remplacez le port 237 par un port personnalisé, mettez à jour tous les clients ou proxys dépendants avec cette même valeur.

Vérifiez la présence de lignes de configuration copiées présentant des incohérences concernant le port ou le schéma. Dans une configuration multi-serveurs, examinez également l'URL du serveur ou du proxy publiée : un client peut établir une connexion initiale, puis échouer après que Kopano l'a redirigé vers un ancien nom d'hôte ou port.

4. Réparer la configuration de l'écouteur et du certificat

S'il s'agit du client TLS natif de Kopano Core, modifiez la configuration existante plutôt que d'ajouter des directives en double. Voici un exemple simplifié pour un port personnalisé ; conservez les chemins d'accès aux certificats et l'autorité de certification adaptés à votre installation :

server_listen_tls = *:1237
server_ssl_ca_file = /etc/kopano/ssl/ca.pem
server_ssl_key_file = /etc/kopano/ssl/server.pem
server_ssl_key_pass = your-key-passphrase

Le manuel de Kopano spécifie les paramètres du listener, de l'autorité de certification (CA), de la clé serveur et du mot de passe, et requiert un redémarrage kopano-serveraprès la modification du listener natif. Vérifiez que la version installée prend en charge les options indiquées ; l'organisation des paquets et les directives peuvent varier. Protégez le répertoire de clés et assurez-vous que le compte de service Kopano dispose des droits de lecture sur les fichiers requis.

Vérifiez que le certificat correspond bien au nom d'hôte utilisé par les clients, qu'il est valide et qu'il inclut tous les certificats intermédiaires requis. Le manuel de Kopano indique que ses composants vérifient le nom commun et les noms alternatifs du sujet du certificat. Dans une configuration TLS multi-serveurs, le serveur doit également faire confiance à l'autorité de certification qui a signé les certificats clients, et les certificats clients autorisés doivent être configurés. N'utilisez pas de certificat auto-signé pour remplacer un certificat existant, même par simple commodité pour un service de navigateur public.

Si la connexion TLS est terminée par Apache, Nginx ou Kopano Web, configurez le certificat et listenle port personnalisé au niveau de ce serveur frontal. Ensuite, configurez le protocole et le port en amont en fonction du serveur d'écoute réel du serveur dorsal. N'activez pas le protocole TLS en amont simplement parce que le côté public utilise HTTPS ; vérifiez d'abord que le port du serveur dorsal prend également en charge TLS.

5. Validez et rechargez le service approprié

Avant de redémarrer un serveur web, exécutez une vérification de sa configuration, par exemple sudo nginx -tpour Nginx ou sudo apachectl configtestApache. Si le test signale une erreur, corrigez-la avant de redémarrer. Utilisez le nom du service installé sur votre distribution ; par exemple :

sudo systemctl restart kopano-server
sudo systemctl status kopano-server --no-pager

Redémarrez Kopano Core uniquement après avoir modifié sa configuration. Pour une modification de port ou de certificat concernant uniquement l'interface utilisateur, validez et rechargez le service frontal. Consultez son journal ou son journal d'erreurs immédiatement après la modification et répétez la même requête OpenSSL depuis le réseau client. La négociation TLS devrait alors présenter le certificat attendu. Testez ensuite l'URL de l'application web ou la connexion du client Kopano, car la réussite de la connexion TLS ne suffit pas à valider la route de l'application ni l'authentification.

Lisez le résultat avant de modifier davantage

• Aucune socket d'écoute : vérifiez l'écouteur configuré, l'état du service et l'adresse de liaison.
• Connexion refusée ou délai d'attente dépassé : vérifiez le pare-feu, le NAT, l'équilibreur de charge et si le port cible est accessible.
• Certificat incorrect : vérifiez le certificat configuré sur le point de terminaison répondant à ce port, y compris la sélection SNI et la chaîne de certificats.
• Le protocole TLS fonctionne en local mais pas à distance : comparez le chemin du proxy public ou de l’équilibreur de charge avec l’écouteur local et examinez les valeurs d’hôte et de port transférées.
• La négociation HTTP a réussi, mais l'application Web a échoué : vérifiez le statut HTTP, le chemin du proxy, les journaux PHP/WebApp et la connectivité de Kopano Core. Poursuivez l'exécution au niveau de l'application.
• Seuls les clients Core rencontrent des problèmes : vérifiez leurs server_socketparamètres de port personnalisé, d’autorité de certification de confiance et de certificat client. Le chemin TLS Core peut nécessiter une authentification mutuelle par certificat.

Une solution fiable modifie uniquement le point de terminaison responsable de l'échec de la négociation. Le manuel d'administration de Kopano Core disponible pour cette procédure est la version 8.0.0 ; ses exemples doivent être vérifiés par rapport aux paquets installés et aux pages de manuel locales. Si votre déploiement utilise une version différente de Kopano, un conteneur ou un proxy inverse géré, vérifiez la configuration actuelle de ce composant avant d'appliquer les directives d'exemple.