Si votre entreprise utilise IncaMail via l'intégration Mail Gateway (MGI) et qu'un certificat a été renouvelé, il se peut que l'envoi IncaMail cesse soudainement de fonctionner. Cet article explique pourquoi cela se produit et quelles solutions existent.
Contexte : Qu’est-ce que l’EKU clientAuth ?
L’Extended Key Usage (EKU) est un champ de certificat qui définit les usages autorisés du certificat. L’EKU clientAuth (Identifiant d’objet : 1.3.6.1.5.5.7.3.2) indique que le certificat peut être utilisé pour une authentification client – c’est-à-dire pour que votre serveur mail s’identifie auprès d’un autre système (dans ce cas, la plateforme IncaMail).
IncaMail MGI utilise une authentification TLS mutuelle (Mutual TLS) : lors de l’établissement de la connexion, la plateforme IncaMail vérifie le certificat de votre passerelle mail. Si ce certificat ne contient pas l’EKU clientAuth en particulier, la connexion est refusée et l’envoi échoue.
Quand le problème survient-il ?
Le problème survient typiquement lorsqu’un certificat existant a été renouvelé et que le nouveau certificat contient, par rapport à l’ancien, des champs EKU différents ou plus restreints. Cela peut arriver si :
- le fournisseur de certificat a modifié la configuration standard,
- un autre produit de certificat ou un autre modèle de certificat a été utilisé,
- le certificat a été émis en interne et que l’EKU clientAuth n’a pas été explicitement définie.
Dans ces cas, l’envoi IncaMail fonctionnait parfaitement avant le renouvellement du certificat – et cesse soudainement de fonctionner après le renouvellement, sans modification apparente de la configuration.
Comment reconnaître le problème ?
Si l’envoi n’est plus possible après un renouvellement de certificat, commencez par vérifier les messages d’erreur dans les journaux de votre passerelle mail. Les indices typiques sont :
- Erreur de négociation TLS lors de la connexion à IncaMail
- Messages d’erreur liés à la validation ou à l’authentification du certificat. Un message de rebond typique pourrait être :
5.3.2 Relaying denied, no client certificate - L’envoi de messages IncaMail échoue alors que le reste de l’envoi d’e-mails fonctionne
Pour vérifier si votre certificat contient l’EKU clientAuth, vous pouvez inspecter le certificat dans votre gestionnaire de certificats ou avec un outil comme OpenSSL :
openssl x509 -in certificat.pem -text -noout | grep -A1 "Extended Key Usage"
Un résultat valide contient l’entrée TLS Web Client Authentication. Si cette entrée est absente, le certificat ne supporte pas l’EKU clientAuth. Si vous avez un doute sur l’interprétation des résultats, veuillez nous envoyer votre certificat au format PEM.
Solutions possibles
Il existe deux façons de résoudre le problème :
Option 1 : Installer un certificat avec EKU clientAuth (recommandé)
La solution la plus durable est d’installer un certificat qui contient explicitement l’EKU clientAuth. Contactez votre fournisseur de certificats ou votre service PKI interne et assurez-vous que le nouveau certificat contient les entrées EKU suivantes :
-
TLS Web Server Authentication (
1.3.6.1.5.5.7.3.1) -
TLS Web Client Authentication (
1.3.6.1.5.5.7.3.2)
Si votre fournisseur ne propose pas un tel certificat, il est possible que nous en émettions un pour vous – sans frais supplémentaires. Pour cela, vous devez générer une CSR et l’envoyer à notre équipe support. Nous émettrons alors un certificat spécial valable 1 an. Ce certificat dédié est émis par IncaMail lui-même et ne peut être utilisé que pour l’authentification auprès des serveurs IncaMail. Il ne sera pas reconnu par d’autres services.
Les exigences pour la CSR sont les suivantes :
- Elle doit être encodée en PEM
- La taille ne doit pas dépasser 16 Ko
- La signature peut être RSA : 2048–8192 ou ECDSA P-256, P-384, P-521
Nous ne vérifions pas et ignorons : Subject / SAN / EKU demandées – nous les ajoutons nous-mêmes au certificat.
Si vous disposez d’un certificat approprié, il doit être installé sur votre serveur mail.
Dès que le certificat correct est installé sur votre serveur mail et que, le cas échéant, les informations CN sont mises à jour dans votre portail d’administration IncaMail MGI, l’envoi devrait de nouveau fonctionner sans problème.
Remarque : Si le nom commun (CN) du nouveau certificat a changé, il doit être mis à jour dans le portail d’administration MGI sous Paramètres → Intégration Mail Gateway.
Option 2 : Activer l’authentification serveur
Si vous ne pouvez pas obtenir rapidement un certificat adapté avec EKU clientAuth, ou si vous ne pouvez pas installer un certificat client dédié sur votre serveur mail, IncaMail propose une solution de contournement qui évite l’authentification client et s’appuie uniquement sur l’authentification serveur. Dans ce mode, IncaMail vérifie uniquement le certificat du serveur destinataire, et non celui du client émetteur.
Dans certains cas, cette option est la seule solution disponible, par exemple :
- Exchange Online (O365)
- SeppMail
- Hornetsecurity
- HostStar
Pour activer cette solution de contournement, soumettez une demande de support en indiquant le domaine concerné.
Résumé
| Situation | Mesure recommandée |
|---|---|
| Le nouveau certificat ne contient pas l’EKU clientAuth |
Option 1 : Demander et installer un certificat avec EKU clientAuth auprès du fournisseur Option 2 : Demander et installer un certificat via le support IncaMail avec un fichier CSR |
| Le CN du nouveau certificat a changé | Mettre à jour le CN dans le portail d’administration MGI |
| Pas de certificat adapté disponible ou installation impossible | Contacter le support pour activer la solution de contournement d’authentification serveur |
Besoin d’aide ?
Si vous n’êtes pas sûr que votre certificat contienne l’EKU clientAuth, ou si vous souhaitez activer la solution de contournement, le support IncaMail est à votre disposition :
👉 Soumettre une demande de support
Merci d’indiquer dans votre demande le domaine concerné afin que nous puissions vérifier votre configuration de manière ciblée.