If your company operates IncaMail via the Mail Gateway Integration (MGI) and a certificate has been renewed, it may happen that IncaMail sending suddenly stops working. This article explains why this happens and what solutions are available.
Background: What is the clientAuth EKU?
The Extended Key Usage (EKU) is a certificate field that defines for which purposes a certificate may be used. The clientAuth EKU (Object Identifier: 1.3.6.1.5.5.7.3.2) indicates that the certificate may be used for client authentication—that is, to identify your mail server to another system (in this case, the IncaMail platform).
IncaMail MGI uses mutual TLS authentication: When establishing a connection, the IncaMail platform checks the certificate of your mail gateway. If this certificate does not contain the clientAuth EKU, the connection is rejected and sending fails.
When does the problem occur?
The problem typically occurs when an existing certificate has been renewed and the new certificate contains different or more restricted EKU fields compared to the old one. This can happen if:
- the certificate provider has changed the default configuration,
- a different certificate product or certificate template was used,
- the certificate was issued internally and the clientAuth EKU was not explicitly set.
In such cases, IncaMail sending worked perfectly before the certificate renewal—and suddenly stops after renewal without any apparent configuration changes.
How do I recognize the problem?
If sending is no longer possible after a certificate renewal, first check the error messages in your mail gateway logs. Typical indications are:
- TLS handshake errors when connecting to IncaMail
- Error messages related to certificate validation or authentication. A typical bounce message might read:
5.3.2 Relaying denied, no client certificate - Sending IncaMail messages fails while other email sending works
To check whether your certificate contains the clientAuth EKU, you can inspect the certificate in your certificate management or use a tool like OpenSSL:
openssl x509 -in certificate.pem -text -noout | grep -A1 "Extended Key Usage"
A valid result contains the entry TLS Web Client Authentication. If this entry is missing, the certificate does not support the clientAuth EKU. If you are unsure when evaluating the results, please send us your certificate as a PEM file.
Possible solutions
There are two ways to resolve the problem:
Option 1: Install a certificate with clientAuth EKU (recommended)
The most sustainable solution is to install a certificate that explicitly includes the clientAuth EKU. Contact your certificate provider or your internal PKI authority and ensure that the new certificate contains the following EKU entries:
-
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)
If your provider does not offer such a certificate, it is possible for us to create one for you—at no additional cost. For this, you need to generate a CSR and send it to our support team. We will then issue a special certificate for you that is valid for 1 year. This dedicated certificate is issued by IncaMail itself and can therefore be used exclusively for authentication with the IncaMail servers. It will not be recognized by other services.
The requirements for the CSR are as follows:
- It should be PEM-encoded
- The size must not exceed 16 kB
- The signature can be RSA: 2048–8192 or ECDSA P-256, P-384, P-521
We do not check or ignore: Subject / SAN / requested EKUs — we add these ourselves to the certificate.
If you have a suitable certificate, it must be installed on your mail server.
Once the correct certificate is installed on your mail server and, if necessary, the CN entries are updated in your IncaMail MGI administration portal, sending should work smoothly again.
Note: If the Common Name (CN) of the new certificate has changed, it must be updated in the MGI administration portal under Settings → Mail Gateway Integration.
Option 2: Enable server authentication
If a suitable certificate with clientAuth EKU cannot be obtained quickly, or it is not possible to install a dedicated client certificate on your mail server, IncaMail offers a workaround that bypasses client authentication and instead relies solely on server authentication. In this mode, IncaMail only checks the certificate of the receiving server, not that of the sending client.
In certain cases, this option is the only available solution, for example:
- Exchange Online (O365)
- SeppMail
- Hornetsecurity
- HostStar
To activate the workaround, submit a support request and specify the affected domain.
Summary
| Situation | Recommended action |
|---|---|
| New certificate does not contain clientAuth EKU |
Option 1: Request and install a certificate with clientAuth EKU from your provider Option 2: Request and install a certificate from IncaMail support with CSR file |
| CN of the new certificate has changed | Update CN in the MGI administration portal |
| No suitable certificate available or installation not possible | Contact support to activate the server authentication workaround |
Need assistance?
If you are unsure whether your certificate contains the clientAuth EKU, or if you want to activate the workaround, the IncaMail support team is happy to assist you:
Please include the affected domain in your request so that we can specifically review your configuration.