• Bewerte uns auf OMR Reviews: Klick

  • 25Reports geht live, schaut es euch an: Klick

  • Achtet bitte in den Beiträgen darauf, dass ihr keine Informationen teilt, die der DSGVO unterliegen können. Verpixelt bitte die entsprechenden Stellen in Screenshots, postet hier auf keinen Fall Messagetracks ohne Rücksprache und auch in den Log Files können persönliche oder sensible Daten enthalten sein.

    Macht uns auch bitte per PN darauf aufmerksam wenn ihr etwas seht. Schreibt mich (@sören) einfach direkt an. 

  • Zertifikate vom Deutschen Forschungsnetz beziehen (Harica CA)? Klick

Gelöst Office 365 Konnektor: Zertifikat für Client-Indentität entfernen

Fabian

Moderator

Registriert
4 Juni 2024
Beiträge
151
Reaktionspunkte
106
Hallo zusammen,

wie im Blogbeitrag Ende der TLS-Client-Authentifizierungszertifikate erwähnt:
"[...]
Kunden können ihre bisher verwendeten, „normalen“ TLS-Zertifikate nicht länger für die Client-Authentifizierung einsetzen
[...]"

fällt die Option eine Client-Indetität mitzugeben mit den bisherigen (Server Authentication und Client Authentication)
Zertifikaten weg.
Nun heißt es, hat man für Office 365 aka Exchange Online 2 Optionen:

1. Separates Zertifikat mit passendem Verwendungszweck besorgen
oder
2. Auf IP-Filterung umsteigen bzw. auf IP-Filter anstatt IP-Filter + Client-Authentifizierung umstellen in EXO.

Beim Versuch das Zertifikat beim Konnektor unter E-Mail-Server des Unternehmens, Type Office 365 zu entfernen scheitere ich jedoch.
Es gibt diese Option in der GUI nicht - nur mit einem anderen zu ersetzen.

1766997251999.png

Einfach aus dem Zertifikatsspeicher löschen findet der NSP auch nicht so cool :eek: (keine Angst, wofür hat man eine Testumgebung)
1766997415918.png

Das PowerShell Befehl:
C#:
# Get-NspInboundSendConnector -> Hat nur den Office365 Konnektor zurück geliefert, sonst zuvor filtern
Get-NspInboundSendConnector | Set-NspInboundSendConnector -TlsCertificateThumbprint $null -Office365

Das hat auch nicht wirklich geholfen.

Bliebe noch final den Konnektor zu löschen und neu anlegen -> Ist das die gewollte Lösung oder gibt es einen besseren Weg?

LG
Fabian
 
Danke für den Hinweis =)

Tatsache wird dir löschen und neu anlegen auch nicht helfen denn du musst eine der beiden Optionen auswählen und das führt dazu, dass du immer ein TLS Zertifikat in irgendeiner Form haben musst ^^

Ich habe aber gestern ein Update zum Thema bekommen:
Es wurde erfolgreich getestet wie sich EXO verhält wenn die EKU fehlt:
1767872429976.png
Wir haben dafür ein neues Lets Encrypt Zertifikat angefragt und in einer unserer Umgebungen eingesetzt.
EXO arbeitet problemlos mit diesem Zertifikat, somit kannst du jedes beliebige TLS Zertifikat verwenden.
Über die NCC ist es nur derzeit nicht mögliches jedes auszuwählen, das werden wir ändern, per PS lässt es sich aber auf jeden Fall schon setzen.

Ein Update zum Blogbeitrag werde ich ebenfalls noch veranlassen =)
 
EXO arbeitet problemlos mit diesem Zertifikat, somit kannst du jedes beliebige TLS Zertifikat verwenden.
Verstehe ich das so richtig?

Nutze ich ein Zertifikat einer öffentlichen CA (in unserem Fall GlobalSign), Eku-Globalsign.png
dann wird mein Exchange-Online-Inbound-Connector (mit Mutual TLS-Prüfung) weiter funktionieren?ExO-Inbound-Connector-Mutual-TLS.png
Wenn dem so ist, müsste dann nicht der Artikel https://www.nospamproxy.de/de/ende-der-tls-client-authentifizierungszertifikate/ geupdatet werden?
Der Satz "empfiehlt es sich, die Konnektoren auf IP-basierte Filterung umzustellen" wäre doch nicht korrekt, da man tatsächlich NICHT auf IP-Filter umstellen muss?
 
Hey,

Ja es ist richtig, dass es ohne die Erweiterung funktioniert 👍
Ich schaue mir den Beitrag nochmal an, eig hatten wir ein Update gemacht, vlt ist da was schief gegangen.

Danke für den Hinweis 🙃
 
Zurück
Oben