Wenn der Scanner nicht mehr mailen will: Exchange SE, Windows Server 2025 und eine fehlende TLS-Cipher-Suite

Ein Praxisbericht — und warum die Fehlermeldung gelogen hat.

Ausgangslage

Bei einem Kunden haben wir den Exchange auf Exchange Server SE gehoben, frisch aufgesetzt auf Windows Server 2025. Die Receive Connectors hatten wir sauber mit meinem Migrationsskript vom Altsystem übernommen — auf dem Papier alles identisch: gleiche Bindings, gleiche Remote-IP-Ranges, gleiche Permission-Groups.

Und dann kamen die Drucker. Der Kunde betreibt eine ganze Flotte HP OfficeJet MFP unterschiedlichen Alters, die per Scan2Mail über den Exchange als SMTP-Relay verschicken. Am Altsystem lief das seit Jahren klaglos, am neuen Server: nichts. Zusätzliche Rahmenbedingung: An der Konfiguration der Drucker sollte möglichst nichts geändert werden — schlicht wegen der Stückzahl.

Der erste Hinweis: Brother-Geräte im selben Netz hatten das Problem nicht. Die mailten weiter, als wäre nichts. Also lag es nicht am Connector, sondern am Gerät bzw. dessen TLS-Stack.

Die falsche Fährte

Die Fehlermeldung auf den HP-Geräten deutete auf ein Authentifizierungsproblem hin — „Anmeldung fehlgeschlagen“ in gerätetypisch wenig aussagekräftiger Formulierung. Zwei Dinge machten aber stutzig:

1. Der Fehler kam sofort — kein Timeout, kein längeres Handshake-Gestocher.
2. Am alten Server, mit identischer Connector-Konfiguration, lief es problemlos.

Ein Fehler, der so früh auftritt, passiert vor dem eigentlichen AUTH-Dialog. Das lenkte den Verdacht Richtung TLS-Handshake: Wenn STARTTLS scheitert, weil sich Client und Server auf keine gemeinsame Cipher Suite einigen, bricht die Session ab, bevor authentifiziert wird. Viele MFP-Firmwares ordnen diesen Abbruch nicht sauber dem TLS-Layer zu und melden pauschal „Authentifizierung fehlgeschlagen“.

Lesson #1: Die Fehlermeldung war ein Symptom, keine Ursache — der eigentliche Bruch lag eine Schicht tiefer.

Die Analyse

Um den Verdacht zu prüfen, habe ich ein kleines PowerShell-Skript gebaut, das den STARTTLS-Handshake gegen den MX-Host durchspielt und für jede TLS-Version zurückgibt, ob und mit welcher Cipher/Hash-Kombination er gelingt:

function Test-SmtpTls {
    param([string]$Server, [int]$Port = 25)
    foreach ($proto in 'Tls13','Tls12','Tls11','Tls') {
        $p = [System.Security.Authentication.SslProtocols]$proto
        $tcp = New-Object Net.Sockets.TcpClient
        try {
            $tcp.Connect($Server, $Port)
            $s = $tcp.GetStream()
            $r = New-Object IO.StreamReader($s)
            $w = New-Object IO.StreamWriter($s); $w.AutoFlush = $true
            $r.ReadLine() | Out-Null                       # 220 Banner
            $w.WriteLine("EHLO test.local")
            do { $l = $r.ReadLine() } while ($l -notmatch '^250 ')
            $w.WriteLine("STARTTLS"); $r.ReadLine() | Out-Null   # 220 Ready
            $ssl = New-Object Net.Security.SslStream($s, $false, {$true})
            $ssl.AuthenticateAsClient($Server, $null, $p, $false)
            "{0,-6} OK   {1} {2}-bit / {3}" -f $proto, $ssl.CipherAlgorithm, $ssl.CipherStrength, $ssl.HashAlgorithm
            $ssl.Dispose()
        } catch {
            "{0,-6} FAIL {1}" -f $proto, $_.Exception.InnerException.Message
        } finally { $tcp.Close() }
    }
}

$domain = "example.net"
$res    = Resolve-DnsName -Type MX $domain
$server = ($res | Select-Object -First 1).NameExchange
Test-SmtpTls -Server $server

Ergebnis: TLS 1.2 war grundsätzlich möglich — der Handshake gelang mit einer modernen Suite. Ein reines Protokoll-Problem war damit ausgeschlossen, der Verdacht verengte sich auf die Cipher Suites.

Der entscheidende Schritt war der direkte Vergleich alt gegen neu:

Get-TlsCipherSuite | Select-Object Name

Auf beiden Servern ausgeführt, die Ausgaben nebeneinandergelegt — und da war die Differenz: Der neue Windows Server 2025 bot TLS_RSA_WITH_AES_128_CBC_SHA256 nicht mehr an. Die alten HP-Geräte sind aber genau darauf festgelegt (statisches RSA, CBC, SHA-256, keine Forward Secrecy). Die Brother-Geräte konnten auf modernere Suites ausweichen und liefen deshalb weiter.

Lesson #2: Get-TlsCipherSuite im Alt/Neu-Vergleich ist das schärfste Werkzeug — nicht raten, welche Suite fehlt, sondern die Diff sichtbar machen.

Warum fehlte die Suite überhaupt?

Kein Zufall, sondern Microsofts Richtung. Ab Windows Server 2025 ist die Standard-Liste der per Schannel aktivierten Cipher Suites weiter ausgedünnt; die statischen RSA-CBC-Suites gehören nicht mehr zum Default. Passend dazu hat Microsoft zum 20. Oktober 2025 in den Microsoft-365-Diensten die Legacy-Suites ohne Forward Secrecy deprecatet. Wer mit alter Hardware arbeitet, wird dieses Muster künftig öfter sehen: Nicht das Gerät ist „kaputt“, sondern die Welt zieht unter ihm die Leiter weg.

Der Fix

Die fehlende Suite lässt sich per PowerShell reaktivieren:

Enable-TlsCipherSuite -Name "TLS_RSA_WITH_AES_128_CBC_SHA256" -Position 0

Danach mailten die HP-Geräte sofort wieder — aber noch nicht sauber. -Position 0 setzt die schwache Suite an die Spitze; der Server würde sie dann auch Clients anbieten, die längst Besseres können. Sinnvoller ist, sie ganz ans Ende zu stellen: Moderne Clients handeln weiterhin eine starke Suite aus, nur die alten HP-Geräte fallen auf die Legacy-Suite zurück.

Disable-TlsCipherSuite -Name "TLS_RSA_WITH_AES_128_CBC_SHA256"
Enable-TlsCipherSuite  -Name "TLS_RSA_WITH_AES_128_CBC_SHA256" -Position 999

Restart-Service MSExchangeTransport
Restart-Service MSExchangeFrontendTransport

Hinweis: Schannel-Änderungen greifen sauber erst nach Neustart der betroffenen Dienste bzw. des Servers. Bis dahin gilt die alte Reihenfolge weiter.

Lessons Learned auf einen Blick

• Eine „Authentifizierungs“-Meldung muss nicht mit Authentifizierung zu tun haben. Bricht die Verbindung sehr früh ab, lohnt der Blick auf den TLS-Handshake — der passiert vor AUTH.
• Gleiches Netz, Gerät A läuft, Gerät B nicht (Brother vs. HP) ist ein starkes Indiz für den Client-TLS-Stack als Ursache, nicht den Server-Connector.
• Get-TlsCipherSuite alt gegen neu diffen ist der schnellste Weg, eine fehlende Suite zu finden.
• Windows Server 2025 dünnt die Default-Cipher-Suites weiter aus — Legacy-Hardware mit fest verdrahteten RSA-CBC-Suites bekommt das zunehmend zu spüren.
• Legacy-Suite nur reaktivieren, wenn nötig — und ganz ans Ende der Prioritätsliste, damit alle anderen weiter modern verschlüsseln.
• Transport-Dienste (bzw. Reboot) nach der Änderung nicht vergessen.

Zum Schluss: Das Reaktivieren einer Suite ohne Forward Secrecy ist ein bewusster, dokumentierter Kompromiss zugunsten alter Hardware. Auf Dauer ist der bessere Weg, die Geräte zu ertüchtigen oder Scan2Mail über ein modernes Relay zu führen. Für eine große Flotte, die man nicht einzeln anfassen will, ist die ans Ende priorisierte Legacy-Suite aber ein vertretbarer, kontrollierter Weg.