Exchange 2007 SSL probleem

[Verwijderd]

Ik heb een Exchange 2007 (SP1 x64) server draaien en krijg een certificaatmelding bij het opstarten van een Outlook 2007 client. De server op zich functioneert prima, ik kan mail verzenden/ontvangen, owa en de overige virtuele directory's werken ook allemaal naar behoren. Er is wel een self-signed certificaat gebruikt voor exchange omdat ik pas een certificaat wil aanschaffen als alle security-meldingen verdwenen zijn.

Dit probleem speelt sinds ik mijn router heb vervangen door een Cisco 876 router. Outlook probeert de Exchange server bij het opstarten via m'n remote IP te benaderen en komt vanuit een intern adres op het adres van de router uit (loopback). Omdat de Cisco router een SSL certificaat zonder domeinnaam heeft geeft Outlook terecht de melding dat de domainnaam niet klopt. Als outlook zou kiezen voor het certificaat van de exchange server in plaats van het certificaat van de router zou de genoemde domeinnaam wel geldig zijn maar vanwege de loopback wordt automatisch het IOS-Self-Signed-XXXX certificate van de cisco router genomen.

Moet ik nu een certificaat voor m'n router aanschaffen waar de domeinnaam van de gateway en van de exchange server is opgenomen of kan ik voorkomen dat Outlook de exchange server extern benaderd? De autodiscover functie bevat enkel interne host-names maar als ik vanuit Outlook de autodiscover configuratie test zie ik onder Results - HTTP toch een aantal externe host-names staan (verder geen errors). Door een andere router aan te sluiten is het probleem opgelost maar dit is vanzelfsprekend geen gewenste oplossing.

Kan iemand me uitleggen hoe ik van deze certificaat-melding af kom?

[sanfranjake]

Er gaat duidelijk iets mis in je Cisco config als die niet het certificaat van je website gebruikt lijkt me. Kan je niet een reverse-proxy ofzo (ik doe dat bij klanten met ISA server) tussen gooien met het certificaat?

Exchange team blog over hoe en wat met autodiscover en certs: http://msexchangeteam.com/archive/2007/04/30/438249.aspx

[Verwijderd]

Outlook probeert de Exchange server bij het opstarten via m'n remote IP te benaderen en komt vanuit een intern adres op het adres van de router uit (loopback).

Dat zou ik eerst eens gaan troubleshooten. Is je client wel goed geconfigureerd qua ip settings? Hoe heb je autodiscover geconfigureerd?

[Jazzy]

Ik weet niet precies wat je beoogt met deze opstelling, maar die loopback constructie is niet juist. Je clients (Outlook Anywhere hebben we het dan over) zullen eerst via MAPI proberen te connecten op de interne servernaam. Die dient natuurlijk te resolven zijn en moet ook op je certificaat staan.

Externe clients zullen de server benaderen op het IP-adres wat overeenkomt met de externe naam van je server, bijvoorbeeld mail.domein.nl. Het enige wat je router moet doen is dat verkeer op poort 443 forwarden naar je Client Access server en er verder afblijven. De Cisco doet dus helemaal niets met het certificaat.

Die externe gebruikers komen dus uit op de zelfde IIS vdir als de interne, dat betekent dat ook de externe naam op het certificaat moet staan. Daarom gebruikt Exchange 2007 een type certificaten waar meerdere alternatieve servernamen op kunnen staan (SAN).

Hoe heb je het self-signed certificaat aangemaakt? Als het goed is ongeveer zo:
New-ExchangeCertificate -DomainName server1,server1.domain.local,mail.domein.nl,autodiscover.domain.nl,domain.nl –subjectname "c=NL o=Jouw bedrijf, CN=mail.domein.nl"

Vervolgens zet Exchange een certificaat in de store en geeft aan wat de thumbprint is, nu kun je dat certificaat koppelen aan de webdiensten:
Enable-ExchangeCertificate -thumbprint xxxxxxxxxxxxxxxx

[ Voor 8% gewijzigd door Jazzy op 09-10-2008 17:12 ]

[Verwijderd]

Bedankt voor jullie reacties, het zou inderdaad goed aan de autodiscover functie kunnen liggen. Het certificaat is aangemaakt zoals beschreven door Jazzy en werkt zowel intern als extern naar behoren (ook bij autodiscover).

Het autodiscover.xml bestand toont bij benadering over https een code 600 (Invalid request) en als ik het bestand edit staat een redirecturl (https://localexchange.corp.xxxx.eu) gevuld. De ip-adresssen en overige client-instellingen staan goed ingesteld want alle overige servers werken prima en e-mailen lukt ook zonder problemen.

Een ISA-server wil ik in de toekomst gaan toevoegen aan het netwerk maar ik zit nog op twee Intel processoren te wachten voor deze machine. Zover mij bekend kun je vanuit het interne netwerk nooit een resource benaderen via je externe IP-adres (misschien wel met ISA?) maar waarschijnlijk is het probleem opgelost als de autodiscover functie goed staat ingesteld en niet meer naar externe host-names verwijst.

Als ik de autodiscover functie test via Outlook krijg ik geen enkele error of aanknopingspunt dat er iets niet functioneert, ook de Event Viewer op de client en server zegt dat alles in orde is. De genoemde site van MSExchangeTeam had ik reeds bekeken maar hier is me niet helemaal duidelijk wat nu interne en externe adressen zijn. Moet ik mail.company.com als een lokale fqdn beschouwen of is dit een publieke host-name? Verder geven ze aan dat DNS ingesteld moet worden maar moet dit dan op de lokale DNS (Active Directory) of op de externe DNS (Dedicated Server van m'n domeinnaam) worden ingesteld of beide?

Het SCP object verwijst nu naar het autodiscover.xml bestand (lokale fqdn) en de redirecturl in het XML bestand verwijst ook naar het autodiscover.xml bestand (lokale fqdn). In DNS heb ik alleen een Host-A record aangemaakt met autodiscover.corp.xxx.eu --> lokale IP exchange server.

De router forward verder poort 443 en 25 naar de exchange server en zowel de mailflow als OWA werken intern en extern goed. Het probleem speelt ook alleen bij Outlook 2007, bij een Outlook 2003 client krijg ik geen melding. MAPI wordt volgens mij niet gebruikt mocht dit wel zo zijn hoe kan ik er dan voor zorgen dat dit te resolven is? Ik ben nog geen DNS-naam tegengekomen waar MAPI in voor komt.

[Verwijderd]

Het probleem is opgelost dmv DNS-configuratie, alle externe hostnames heb ik nu naar m'n interne IP-adres laten verwijzen waardoor de melding is verdwenen.