Martin.U

Oha, ich glaube, wir kommen dem Problem näher: Microsoft Exchange konnte ein Zertifikat nicht finden, das den Domänennamen "xxxxxxxxxxxxxxxxxx.de" im persönlichen Informationsspeicher auf dem lokalen Computer enthält. Daher kann die STARTTLS-SMTP-Aktionsart für den Connector "xxxxxxxxxxxxxxxxxx.de" mit einem FQDN-Parameter von "xxxxxxxxxxxxxxxxxx.de" nicht unterstützt werden. Überprüfen Sie die Connectorkonfiguration sowie die installierten Zertifikate, damit sichergestellt wird, dass ein Zertifikat mit einem Domänennamen für jeden Connector-FQDN vorhanden ist. Wenn das Zertifikat vorhanden ist, führen Sie "Enable-ExchangeCertificate -Services SMTP" aus, damit sichergestellt ist, dass der Microsoft Exchange-Transportdienst auf den Zertifikatschlüssel zugreifen kann. Das TLS-Zertifikat (Transport Layer Security) des Smarthosts für den Connector 'xxxxxxxxxxxxxxxxxx.de' konnte nicht überprüft werden. Der Zertifikatüberprüfungsfehler für das Zertifikat ist SubjectMismatch. Wenn das Problem weiterhin besteht, wenden Sie sich an den Administrator des Smarthosts, um das Problem zu beheben. Ich werde mir nochmal genau die Zertifikate ansehen, die vom Relay, vom Mailserver (Computer) und vom Exchange verwendet werden und sicherstellen, dass alle Zertifikate den FQDN enthalten. Mal sehen, ob es dann klappt.

Hallo basstscho, hast Du bereits eine Lösung gefunden? Ich stehe nämlich vor genau demselben Problem: Unser Kunde wollte seine Linux-Infrastruktur gegen Windows tauschen, kann aber wegen seiner wechselnden IP-Adresse (DynDNS) nicht auf den Smarthost verzichten. Auf dem Smarthost läuft ein Postfix, der als Anmeldemethode verschlüsseltes SMTP-Auth (STARTTLS) erwartet und mit dem alten Zarafa-Mailserver tadellos funktioniert. Nur Exchange weigert sich beharrlich, sich am Relay anzumelden und gibt stattdessen die Meldung aus: >>Primary target IP address responded with: "454 4.7.5 Certificate validation failure." (...)<< Ich bin auf einen Kommentar im Netz gestoßen, der darauf hindeutet, dass Exchange 2013 für die SMTP-Authentifizierung keine selbstsignierten Zertifikate akzeptiert. Kann das jemand bestätigen? Insbesondere zertifikatseitig habe ich schon einiges probiert: Ich habe im DC die Zertifikatsdienste installiert und dem Relay ein Zertifikat mitgegeben, das von der Root-CA der Domäne signiert wurde, hat aber nichts geholfen: Das Problem blieb. Kann es wirklich sein, dass nur für die STARTTLS-Authentifizierung ein Zertifikat gekauft werden muss? P.S.: Für den Sendekonnektor des Exchange Servers habe ich unter Zustellung folgendes eingestellt: E-Mail über Smarthosts weiterleiten aktiviert, Unter SMARTHOST den Smarthost eingegeben, Standardauthentifizierung gewählt und Standardauthentifizierung erst nach dem Start von TLS anbieten aktiviert, Benutzername und Kennwort sind korrekt. Hier die relevanten Teile der Postfix-Konfiguration: # (...) mynetworks = 127.0.0.0/8 relay_domains = xxxxxxxxxxxxxxxxxx.de, yyyyyyyyyyyyyyyyyy.de parent_domain_matches_subdomains = debug_peer_list, smtpd_access_maps smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination transport_maps = hash:/etc/postfix/transport # (...) smtpd_sasl_local_domain = $myhostname smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous broken_sasl_auth_clients = yes # (...) smtpd_tls_auth_only = yes smtp_tls_security_level = may smtpd_tls_security_level = may smtp_tls_note_starttls_offer = yes smtpd_tls_cert_file=/etc/ssl/certs/xxxxxxxxxxxxxxxxxx.pem smtpd_tls_key_file=/etc/ssl/private/xxxxxxxxxxxxxxxxxx.key smtpd_tls_session_cache_timeout = 3600s tls_random_source = dev:/dev/urandom smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache und hier die smtpd.conf: pwcheck_method: saslauthd mech_list: PLAIN LOGIN saslauthd_path: /var/run/saslauthd/mux