Zertifikatserneuerung und clientAuth EKU - Auswirkungen auf IncaMail MGI

Wenn Ihr Unternehmen IncaMail über die Mail Gateway Integration (MGI) betreibt und ein Zertifikat erneuert wurde, kann es vorkommen, dass der IncaMail-Versand plötzlich nicht mehr funktioniert. Dieser Artikel erklärt, warum das passiert und welche Lösungsmöglichkeiten es gibt.

Hintergrund: Was ist die clientAuth EKU?

Die Extended Key Usage (EKU) ist ein Zertifikatsfeld, das definiert, für welche Zwecke ein Zertifikat verwendet werden darf. Die clientAuth EKU (Object Identifier: 1.3.6.1.5.5.7.3.2) gibt an, dass das Zertifikat zur Client-Authentifizierung verwendet werden darf - also dafür, dass sich Ihr Mailserver gegenüber einem anderen System (in diesem Fall der IncaMail-Plattform) ausweist.

IncaMail MGI verwendet gegenseitige TLS-Authentifizierung (Mutual TLS): Beim Verbindungsaufbau prüft die IncaMail-Plattform das Zertifikat Ihres Mailgateways. Enthält dieses Zertifikat die clientAuth EKU nicht, wird die Verbindung abgelehnt und der Versand schlägt fehl.

Wann tritt das Problem auf?

Das Problem tritt typischerweise auf, wenn ein bestehendes Zertifikat erneuert wurde und das neue Zertifikat im Vergleich zum alten andere oder eingeschränkte EKU-Felder enthält. Dies kann vorkommen, wenn:

• der Zertifikatsanbieter die Standardkonfiguration geändert hat,
• ein anderes Zertifikatsprodukt oder eine andere Zertifikatsvorlage verwendet wurde,
• das Zertifikat intern ausgestellt wurde und die clientAuth EKU nicht explizit gesetzt wurde.

In solchen Fällen funktionierte der IncaMail-Versand vor der Zertifikatserneuerung einwandfrei - und stellt nach der Erneuerung ohne erkennbare Änderung an der Konfiguration plötzlich ein.

Wie erkenne ich das Problem?

Wenn der Versand nach einer Zertifikatserneuerung nicht mehr möglich ist, prüfen Sie zunächst die Fehlermeldungen in den Logs Ihres Mailgateways. Typische Hinweise sind:

• TLS-Handshake-Fehler beim Verbindungsaufbau zu IncaMail
• Fehlermeldungen im Zusammenhang mit der Zertifikatsvalidierung oder Authentifizierung. Eine typische Bounce-Meldung könnte lauten: 5.3.2 Relaying denied, no client certificate
• Der Versand von IncaMail-Nachrichten schlägt fehl, während der übrige E-Mail-Versand funktioniert

Um zu prüfen, ob Ihr Zertifikat die clientAuth EKU enthält, können Sie das Zertifikat in Ihrer Zertifikatsverwaltung oder über ein Tool wie OpenSSL inspizieren:

openssl x509 -in zertifikat.pem -text -noout | grep -A1 "Extended Key Usage"

Ein gültiges Ergebnis enthält den Eintrag TLS Web Client Authentication. Fehlt dieser Eintrag, unterstützt das Zertifikat keine clientAuth EKU. Sollten Sie sich bei der Auswertung der Ergebnisse unsicher sein, senden Sie uns bitte Ihr Zertifikat als PEM-Datei zu.

Lösungsmöglichkeiten

Es gibt zwei Möglichkeiten, das Problem zu beheben:

Option 1: Zertifikat mit clientAuth EKU installieren (empfohlen)

Die nachhaltigste Lösung ist die Installation eines Zertifikats, das die clientAuth EKU explizit enthält. Wenden Sie sich dazu an Ihren Zertifikatsanbieter oder Ihre interne PKI-Stelle und stellen Sie sicher, dass das neue Zertifikat folgende EKU-Einträge enthält:

• 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)

Falls Ihr Provider kein solches Zertifikat bereitstellt, besteht die Möglichkeit, dass wir eines für Sie erstellen - ohne zusätzliche Kosten. Dazu müssen Sie einen CSR generieren und diesen an unser Support-Team senden. Wir stellen dann ein spezielles Zertifikat für Sie aus, das 1 Jahr lang gültig ist. Dieses dedizierte Zertifikat wird von IncaMail selbst ausgestellt und kann daher ausschließlich zur Authentifizierung bei den IncaMail-Servern verwendet werden. Es wird von anderen Diensten nicht anerkannt.

Die Anforderungen an den CSR lauten wie folgt:

1. Er sollte PEM-kodiert sein 
2. Die Größe darf maximal 16 kB betragen
3. Die Signatur kann RSA: 2048–8192 oder ECDSA P-256, P-384, P-521 sein

Wir prüfen nicht oder ignorieren: Subject / SAN / angeforderte EKUs - Diese fügen wir selbst dem Zertifikat hinzu.

Wenn Sie über ein entsprechendes Zertifikat verfügen, muss dieses bei Ihnen auf Ihrem Mailserver installiert werden.

Sobald das korrekte Zertifikat auf ihrem Mailserver installiert und ggf. die CN-Angaben in Ihrem IncaMail MGI-Verwaltungsportal aktualisiert wurden, sollte der Versand wieder problemlos funktionieren.

Hinweis: Falls sich der Common Name (CN) des neuen Zertifikats geändert hat, muss dieser im MGI-Verwaltungsportal unter Einstellungen → Mail Gateway Integration aktualisiert werden.

Option 2: Server-Authentifizierung aktivieren

Falls kurzfristig kein geeignetes Zertifikat mit clientAuth EKU beschafft werden kann, oder es ist nicht möglich, ein dediziertes Client-Zertifikat auf Ihrem Mailserver zu installieren, bietet IncaMail einen Workaround, der die Client-Authentifizierung umgeht und stattdessen ausschliesslich auf Server-Authentifizierung setzt. In diesem Modus prüft IncaMail lediglich das Zertifikat des empfangenden Servers, nicht aber das des sendenden Clients.

In bestimmten Fällen ist diese Option die einzige verfügbare Lösung, z.B.:

1. Exchange Online (O365)
2. SeppMail
3. Hornetsecurity
4. HostStar

Um den Workaround zu aktivieren, reichen Sie eine Support-Anfrage ein und geben Sie dabei die betroffene Domain an.

Zusammenfassung

Benötigen Sie Unterstützung?

Falls Sie nicht sicher sind, ob Ihr Zertifikat die clientAuth EKU enthält, oder wenn Sie den Workaround aktivieren möchten, steht Ihnen der IncaMail Support gerne zur Verfügung:

👉 Support-Anfrage einreichen

Bitte geben Sie bei Ihrer Anfrage die betroffene Domain an, damit wir Ihre Konfiguration gezielt prüfen können.