SSL verkeer Exchange 2010 na virus niet werkend

[HellBeast]

Kan iemand mij in de juiste richting sturen? Bij een klant is er recentelijk een virus uitbraak geweest (Malware). De server is helemaal geschoond, maar nu blijkt SSL verkeer niet meer te werken op de Exchange server. Er zijn een paar Mac clients die nu geen mail meer kunnen ophalen en de OWA pagina doet het ook niet meer. ("this page cannot be displayed"). Ook is de out of office niet meer in te stellen.

De poorten staan netjes open. De certificaten zijn allemaal geldig en present. Met de Echange troubleshooter kom ik niet veel verder. Iemand misschien een tip wat ik nog kan checken? Het is een Windows 2008R2 std server. Er draait verder McAfee Virusscan Enterprise en een Backup Exec agent op. Verder niets. De machine is een VM op VmWare ESXi 5.5.

[ Voor 3% gewijzigd door HellBeast op 16-03-2015 10:29 ]

[Room42]

Wat meer info aangaande symptomen (foutmeldingen e.d.) zou welkom zijn.

Je geeft aan dat de poorten open staan maar luisteren de processen wel? Wat voor diagnostiek heb je al gedraaid om te constateren wat er wel en niet werkt? Wat was de output daarvan?

[HellBeast]

Netstat -a geeft dat poort 443 op listening staat. Dat lijkt me dus prima. Server is al (een paar keer) herstart. De Event log geeft geen rare meldingen.

[jimbo123]

Als het virus echt op de server zelf actief is geweest dan zou ik deze geheel herinstalleren.

Dat gezegd hebbende, kijk eens of het SSL certificaat wel aan Exchange gekoppeld is via de management shell en kijk ook eens of het wel gebind is aan de IIS website van OWA.

[Room42]

HellBeast schreef op maandag 16 maart 2015 @ 10:44:
Netstat -a geeft dat poort 443 op listening staat. Dat lijkt me dus prima. Server is al (een paar keer) herstart. De Event log geeft geen rare meldingen.

Oja, dat is veel meer info

[HellBeast]

Als ik require SSL uitschakel in IIS, dan werkt het op poort 80 wel. De certificaten zijn gebind aan IIS.

[Question Mark]

HellBeast schreef op maandag 16 maart 2015 @ 11:20:
Als ik require SSL uitschakel in IIS, dan werkt het op poort 80 wel. De certificaten zijn gebind aan IIS.

Dat was de vraag niet....

jimbo123 schreef op maandag 16 maart 2015 @ 10:47:
Dat gezegd hebbende, kijk eens of het SSL certificaat wel aan Exchange gekoppeld is via de management shell en kijk ook eens of het wel gebind is aan de IIS website van OWA.

Controleer ook even de internal en external url's voor alle webdiensten voor Exchange. "Page cannot be displayed"klinkt nl. eerder alsof de sites niet bestaan, en lijkt niet op een certificaatfout (dan had je immers wel een certificaatfoutmelding gekregen).

Wat staat er verder in de eventlog van de server? Het kan haast niet anders of daar moeten foutmeldingen in staan.

Voor de rest zou ik ook de server opnieuw installeren. Vooraf even een backup maken van de database, herinstalleer het OS en herinstalleer Exchange (tip: /recoverserver) en zet de databases terug. Daarna de config opnieuw instellen en klaar.

[ Voor 7% gewijzigd door Question Mark op 16-03-2015 12:06 ]

[HellBeast]

Het probleem is dat de klant de malware besmetting pas na 1,5 week heeft gemeld. Ze hebben daily backups van max een week terug in de tijd. Een simpele disaster recovery wordt het dus helaas niet

De klant gebruik geen external url, maar de interne staat in ieder geval goed. Ik heb de event log meerdere keren doorgenomen, maar er staat echt niets bruikbaars in.

[Question Mark]

Je kunt toch gewoon nu even een backup maken van de DB's? De rest (OS en Exchange) herinstalleer je gewoon.

[HellBeast]

Ik denk ook dat het dat gaat worden, helaas

[Jazzy]

Doe eerst anders wat meer basic testen. Telnet servernaam 443, https://localhost op de server starten, etc.

[HellBeast]

Ik heb het eindelijk gevonden. Het zat in een heel andere hoek. Er miste een registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

Daar zou dan een DWORD key moeten staan met "Enabled" op waarde 1. Deze key was er niet, dus het hele SSL protocol was eigenlijk niet actief. Ik heb de key aangemaakt, server herstart en alles deed het weer.

[nexhil]

Ben benieuwd hoe je hierachter gekomen bent?

[Brahiewahiewa]

HellBeast schreef op maandag 16 maart 2015 @ 16:47:
Ik heb het eindelijk gevonden. Het zat in een heel andere hoek. Er miste een registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

Daar zou dan een DWORD key moeten staan met "Enabled" op waarde 1. Deze key was er niet, dus het hele SSL protocol was eigenlijk niet actief. Ik heb de key aangemaakt, server herstart en alles deed het weer.

Dat zou natuurlijk kunnen betekenen dat het virus nog steeds actief is...

[Killah_Priest]

HellBeast schreef op maandag 16 maart 2015 @ 16:47:
Ik heb het eindelijk gevonden. Het zat in een heel andere hoek. Er miste een registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

Daar zou dan een DWORD key moeten staan met "Enabled" op waarde 1. Deze key was er niet, dus het hele SSL protocol was eigenlijk niet actief. Ik heb de key aangemaakt, server herstart en alles deed het weer.

Ik hoop toch wel dat je meteen SSL 2 en 3 uitgezet hebt en TLS gebruikt voor OWA? Dat doe je namelijk ook met de regkeys daar.

[Question Mark]

nexhil schreef op maandag 16 maart 2015 @ 16:51:
Ben benieuwd hoe je hierachter gekomen bent?

De CAPI2 eventlog zou onderstaande melding moeten geven als dit probleem optreedt:

An unknown connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed..

Toevallig ben ik afgelopen week bezig geweest met een DPM issue, waarbij uiteindelijk de issue ook veroorzaakt werd door het niet beschikbaar te zijn van de juiste SSL-ciphers op een OS.

[HellBeast]

Ik kwam erachter toen ik in eerste instantie bezig was met het CertDiag.exe tooltje. Daarna ging ik wat verder googlen en toen kwam ik een artikel tegen van iemand die voorstelde om eens in het register te kijken bij die key.

[Question Mark]

Kleine tip dan om de volgende keer bij "vreemde" SSL foutmeldingen even de CAPI2 eventlog te enablen, de issue reproduceren en dan even in die log te spitten. Die eventlogfile is namelijk precies voor dat doeleinde in het leven geroepen.

Enable CAPI2 event logging to troubleshoot PKI and SSL Certificate Issues

[HellBeast]

Dankjewel voor de tip! Weer wat geleerd.