Wenn beim Versand über IncaMail MGI die Fehlermeldung «535 5.3.2 Relaying denied, no client certificate» erscheint, weist dies in den meisten Fällen auf ein Konfigurationsproblem auf dem Outbound- bzw. Sende-Connector hin – nicht darauf, dass ein falsches Zertifikat installiert wurde, ein zusätzliches Zertifikat benötigt wird oder dass für jeden einzelnen Benutzer ein separates Client-Zertifikat erforderlich ist.
Hinweis: Dieser Fehler kann in bestimmten Fällen auch auftreten, wenn das Zertifikat zwar korrekt präsentiert wird, jedoch die clientAuth EKU nicht enthält. Falls dies auf Ihren Fall zutrifft, lesen Sie bitte folgenden Artikel: Zertifikatserneuerung und clientAuth EKU – Auswirkungen auf IncaMail MGI
Was bedeutet dieser Fehler?
Die Fehlermeldung bedeutet, dass der IncaMail-Server beim Verbindungsaufbau kein gültiges Client-Zertifikat erhalten hat. Dies kann folgende Ursachen haben:
- Das Zertifikat wird auf dem Outbound-Connector nicht gefunden.
- Das Zertifikat wird nicht korrekt präsentiert.
- Der Common Name (CN) des Zertifikats auf dem Outbound-Connector stimmt nicht mit dem CN auf dem Inbound-Connector überein.
Was sollte überprüft werden?
Gehen Sie die folgenden Punkte der Reihe nach durch, um die Ursache einzugrenzen:
1. STARTTLS und Mutual Authentication
Stellen Sie sicher, dass folgendes auf Ihrem Mailserver aktiviert ist:
- STARTTLS für die SMTP-Kommunikation über Port 25
- Mutual Authentication (auch «TwoWay-Authentication» genannt) für die TLS-Verschlüsselung – sowohl für eingehende (Inbound) als auch für ausgehende (Outbound) Verbindungen
2. SwissSign-Rootzertifikat im Truststore
Das SwissSign-Rootzertifikat des IncaMail-Serverzertifikats muss im Truststore Ihres Mailservers oder Mailgateways hinterlegt sein, damit die Vertrauenskette zu IncaMail aufgebaut werden kann.
3. Gültiges Zertifikat auf dem Outbound-Connector
Prüfen Sie, ob auf dem Outbound- bzw. Sende-Connector das korrekte und gültige Zertifikat installiert und aktiv ist.
4. Zertifikat in der «Client-Rolle»
Das Zertifikat muss auf dem Outbound-Connector explizit in der Client-Rolle präsentiert werden. Stellen Sie sicher, dass «Client Certificate Authentication» auf dem Connector aktiviert ist.
5. Reihenfolge der Zertifikatskette
Die Zertifikatskette muss in der korrekten Reihenfolge präsentiert werden:
Client-Zertifikat → Intermediate-Zertifikat → Root-Zertifikat
Eine falsche Reihenfolge kann dazu führen, dass die Kette vom IncaMail-Server nicht validiert werden kann.
6. Übereinstimmung des CN auf Inbound- und Outbound-Connector
Der Common Name (CN) des Zertifikats auf dem Outbound-Connector (Senden) muss mit dem CN übereinstimmen, der im IncaMail MGI-Verwaltungsportal für die Senderichtung hinterlegt ist. Prüfen Sie ebenfalls, ob der CN des Inbound-Connectors (Empfangen) korrekt eingetragen ist.
Die CNs können im MGI-Verwaltungsportal eingesehen und angepasst werden: 👉 Mail Gateway Integration – Verwaltungsportal
7. Standard-Zertifikat des Exchange Servers
Falls Sie Microsoft Exchange verwenden: Prüfen Sie, ob das Standard-Zertifikat (Default Certificate) des Exchange Servers noch aktiv und nicht deaktiviert ist. Ein noch aktives Default-Zertifikat kann dazu führen, dass Exchange das falsche Zertifikat für die SMTP-Kommunikation verwendet, anstatt des für IncaMail konfigurierten Zertifikats.
Zusammenfassung der Checkliste
| Prüfpunkt | Was zu beachten ist |
|---|---|
| STARTTLS / Mutual Auth | Aktiviert auf Inbound und Outbound, Port 25 |
| SwissSign-Rootzertifikat | Im Truststore des Mailservers hinterlegt |
| Zertifikat auf Outbound-Connector | Korrekt installiert und aktiv |
| Client-Rolle | «Client Certificate Authentication» aktiviert |
| Zertifikatskette | Reihenfolge: Client → Intermediate → Root |
| CN-Übereinstimmung | CN auf Outbound-Connector = CN im MGI-Portal (Senderichtung) |
| Exchange Default-Zertifikat | Deaktiviert, sofern vorhanden |