Lorsque le message d'erreur « 535 5.3.2 Relaying denied, no client certificate » apparaît lors de l'envoi via IncaMail MGI, cela indique dans la plupart des cas un problème de configuration sur le connecteur sortant (Outbound) ou d'envoi – et non que le mauvais certificat a été installé, qu'un certificat supplémentaire est nécessaire ou qu'un certificat client séparé est requis pour chaque utilisateur.
Remarque : Cette erreur peut également survenir dans certains cas lorsque le certificat est correctement présenté, mais ne contient pas la clientAuth EKU. Si cela s'applique à votre cas, veuillez lire l'article suivant : Renouvellement du certificat et clientAuth EKU – impacts sur IncaMail MGI
Que signifie cette erreur ?
Le message d'erreur signifie que le serveur IncaMail n'a pas reçu de certificat client valide lors de l'établissement de la connexion. Cela peut être dû aux causes suivantes :
- Le certificat n'est pas trouvé sur le connecteur sortant.
- Le certificat n'est pas présenté correctement.
- Le nom commun (CN) du certificat sur le connecteur sortant ne correspond pas au CN sur le connecteur entrant.
Que faut-il vérifier ?
Suivez les points suivants dans l'ordre pour identifier la cause :
1. STARTTLS et authentification mutuelle
Assurez-vous que les éléments suivants sont activés sur votre serveur mail :
- STARTTLS pour la communication SMTP via le port 25
- Authentification mutuelle (également appelée « TwoWay-Authentication ») pour le chiffrement TLS – à la fois pour les connexions entrantes (Inbound) et sortantes (Outbound)
2. Certificat racine SwissSign dans le Truststore
Le certificat racine SwissSign du certificat serveur IncaMail doit être stocké dans le Truststore de votre serveur mail ou passerelle mail afin que la chaîne de confiance vers IncaMail puisse être établie.
3. Certificat valide sur le connecteur sortant
Vérifiez que le certificat correct et valide est installé et actif sur le connecteur sortant (Outbound) ou d'envoi.
4. Certificat en « rôle client »
Le certificat doit être explicitement présenté en tant que client sur le connecteur sortant. Assurez-vous que l'option « Authentification par certificat client » est activée sur le connecteur.
5. Ordre de la chaîne de certificats
La chaîne de certificats doit être présentée dans le bon ordre :
Certificat client → Certificat intermédiaire → Certificat racine
Un ordre incorrect peut empêcher le serveur IncaMail de valider la chaîne.
6. Correspondance du CN sur les connecteurs entrant et sortant
Le Nom commun (CN) du certificat sur le connecteur sortant (envoi) doit correspondre au CN enregistré dans le portail de gestion IncaMail MGI pour la direction d'envoi. Vérifiez également que le CN du connecteur entrant (réception) est correctement configuré.
Les CN peuvent être consultés et modifiés dans le portail de gestion MGI : 👉 Mail Gateway Integration – Portail de gestion
7. Certificat par défaut du serveur Exchange
Si vous utilisez Microsoft Exchange : vérifiez si le certificat par défaut (Default Certificate) du serveur Exchange est toujours actif et non désactivé. Un certificat par défaut encore actif peut amener Exchange à utiliser le mauvais certificat pour la communication SMTP au lieu de celui configuré pour IncaMail.
Résumé de la liste de contrôle
| Point de contrôle | À vérifier |
|---|---|
| STARTTLS / Authentification mutuelle | Activé sur Inbound et Outbound, port 25 |
| Certificat racine SwissSign | Stocké dans le Truststore du serveur mail |
| Certificat sur connecteur sortant | Correctement installé et actif |
| Rôle client | « Authentification par certificat client » activée |
| Chaîne de certificats | Ordre : Client → Intermédiaire → Racine |
| Correspondance CN | CN sur connecteur sortant = CN dans le portail MGI (direction d'envoi) |
| Certificat par défaut Exchange | Désactivé, si présent |