Bei neuen Exchange Bereitstellungen meinerseits werde ich immer wieder gefragt, warum ich diesen meinerseits „geringfügigen“, aus Sicht des Kunden jedoch erheblichen Aufwand betreibe, und nicht einfach die Zertifikate – so wie sie mir in den Sinn kommen – bei der Zertifizierungsstelle beantrage. Ganz einfach: Bis 11/2015 kann man zwar (noch) SAN-Zertifikate mit internen Hostnamen benutzen, ab diesem Zeitpunkt ist es spätestens jedoch vorbei. Gerade die deutschen (letzten zwei verbleibenden) Zertifizierungsstellen akzeptieren bereits jetzt nur noch widerwillig den Wunsch, interne Hostnamen in das Zertifikat mit aufzunehmen.
Zuvor sind Zerfikate in etwa wie folgt bestellt worden:
1. servername.internaldomain.tld
2. autodiscover.externaldomain.tld
3. mail.externaldomain.tld
4. outlook.externaldomain.tld
Die extern nicht auflösbare, „interne“ URL (1) darf zukünftig nicht mehr als alternativer Antragsstellername im Zertifikat enthalten sein. Das ist insbesondere für die interne Kommunikation der Clients problematisch, die spätestens dann mit dem Zugriff ein Problem bekommen (Fehlermeldung beim Zugriff mittels Outlook). Outlook stellt auch intern die Kommunikation zum Exchange-Server mittels https her und benötigt dafür ein adäquates Zertifikat. Da ich dem Kunden die Verwaltung der Systeme nach Ablauf der Zertifikate nicht unnötig erschweren möchte, konfiguriere ich bereits bei Implementierung so einfach wie möglich, so dass er sein vorhandenes Zertifikat bei Ablauf nur noch verlängern muss.
Die „umständliche“, aber sicherlich schickere Lösung ist natürlich eine private CA und adäquate Verwendung der Zertifikate am Exchange CAS. Für viele ist das jedoch mit Kanonen auf Spatzen geschossen, zumal der administrative Umgang damit erlernt, bzw. geschult werden muss. Da viele Geräte (u.a. auch BYOD) über die Schnittstelle intern, wie extern eine Kommunikation mit dem CAS via https aufnehmen, ist ein Zertifikat einer öffentlichen CA grundsätzlich zweckdienlich.
Die einfachste Lösung (allerdings ausdrücklich nicht Quick & Dirty, sondern vielfach so im Einsatz) ist die Änderung der Zugriffs-URL’s des Exchange CAS und Einrichtung einer Forward-Lookupzone im DNS (AD-gespeichert). Ich zeige dazu mit den relevanten, öffentlichen FQDN’s auf den Exchange, was für eine funktionierende Mail-Exchanger-Konfiguration sowieso gemacht werden sollte:
Anschließend setze ich die URL’s mittels Powershell:
Set-ClientAccessServer -Identity <<COMPUTERNAME>> -AutodiscoverServiceInternalUri "<<EXTERNALURL.TLD>>/autodiscover/autodiscover.xml" Set-WebServicesVirtualDirectory -Identity "<<COMPUTERNAME>>\EWS (Default Web Site)" -InternalUrl "<<EXTERNALURL.TLD>>/ews/exchange.asmx" Set-OabVirtualDirectory -Identity "<<COMPUTERNAME>>\OAB (Default Web Site)" -InternalUrl "<<EXTERNALURL.TLD>>/oab" Set-owavirtualdirectory -Identity "<<COMPUTERNAME>>\owa (Default Web Site)" -InternalUrl "<<EXTERNALURL.TLD>>/owa" Set-ecpvirtualdirectory -Identity "<<COMPUTERNAME>>\ecp (Default Web Site)" -InternalUrl "<<EXTERNALURL.TLD>>/ecp" Set-ActiveSyncVirtualDirectory -Identity "<<COMPUTERNAME>>\Microsoft-Server-ActiveSync (Default Web Site)" -InternalUrl "<<EXTERNALURL.TLD>>/Microsoft-Server-ActiveSync"
Und alles sollte nach einem Neustart des IIS problemlos klappen. Ihr könnt Euch mittels Get-Objektname, also z.B. „Get-WebservicesVirtualDirectory |fl“ die Konfiguration vorab ansehen, falls Ihr Euch unsicher seid. Eine wirklich tolle Referenz zu den CAS-URL’s gibt’s wie immer bei Frank Carius MSXFAQ (Link). Ebenso hat Frank ein cooles Script zusammengeklappert, mitdem Ihr Euch die Konfiguration anschauen könnt.
Hinweis: Wird oft und gerne bei der Verwendung von SMTP TLS vergessen: Der Sendeconnector sollte generell adäquat mit dem im RDNS und FQDN passenden Namen versehen werden:
