none
Exchange 2010 Zertifikate und .local Domänen RRS feed

  • Frage

  • Hallo liebe Forumsleser,

    ich weiß es wurde schon viel über Zertifikate in dem Forum geschrieben. Ich wollte mir lediglich Rat für mein weiteres Vorgehen bei euch holen für den bevorstehenden Wechsel des eingesetzten UCC Zertifikats. Mein "Hauptproblem" ist dabei eigentlich nur wie im Threadtitel erwähnt ein interner Domänenname .local der ja nun demnächst nicht mehr von den Zertifizierungsstellen abgedeckt wird.

    Zur Umgebung:

    2 Exchange Server 2010 jeweils mit M/H/T, ohne CAS Array. Einfach nur 2 Server die gleichberechtigt nebeneinander stehen. Funktioniert alles prima seit mehreren Jahren.

    Bisher wurden UCC Zertifikate von CA's beschafft die sowohl die internen als auch externen URL's abgedeckt haben.

    Da ich das ja nun nicht mehr kann und eine Domänenumbennung mit installiertem Exchange 2007 / 2010 wohl nicht supportet ist, bleibt mir vermutlich nur die Möglichkeit die Service URLS auf die externe Domain anzupassen (Anleitungen dazu gibt es ja einige), meinen internen DNS Servern entsprechend eine DNS Zone anzulegen die meiner Maildomain entspricht und diese zu pflegen.

    Ich würde nun folgendes machen:

    Die entsprechenden virtuellen Verzeichnisse für den Zugriff von extern wie bisher lassen:

    https://mail.sld.tld

    und für intern auf den entsprechenden Instanzen mail1\defaultwebsite und mail2\defaultwebsite anpassen auf:

    https://mail1.sld.tld für den internen Server mail1

    bzw.

    https://mail2.sld.tld für den internen Server mail2

    Dazu würde ich im gleichen Atemzuge ein neues UCC Zertifikat bei einer CA anfragen in dem die folgenden 4 Namen abgedeckt sind:

    mail.sld.tld; mail1.sld.tld; mail2.sld.tld; autodiscover.sld.tld

    Sehe ich das völlig falsch, bzw. habe ich in meinem Vorgehen etwas vergessen?

    Vielen Dank für eure Kommentare und Hinweise :-)


    Marcel Brabetz


    Freitag, 22. August 2014 16:52

Antworten

  • Hallo Marcel,

    das CAS-Array wird für den RPC/MAP-Zugriff benutzt. Du hast oben URL für den HTTPS-Zugriff. Der Name des CAS-Arrays muss daher nicht ins Zertifikat sollte anders sein. Und es muss auch kein externer Name sein, da er von außen nicht benutzt wird.

    Normalweise sieht das ungefähr so aus:

    LB hat VIP_INTERN

    FQDN für die URLs (OAB, EWS, EAS, OA, Autodiscover intern):
    mail.sld.tld

    FQDN für Autodiscover extern:
    autodiscover.sld.tld

    FQDN für das CAS-Array:
    cas.internername.local

    DNS intern
    mail.sld.tld -> VIP_INTERN
    autodiscover.sld.tld -> VIP_INTERN (für Nicht-AD-Clients im internen Netzwerk)
    cas.internername.tls -> VIP_INTERN

    Zusätzlich wird der SCP für AD-Autodiscover mit "mail.sld.tld" gefüllt.

    DNS extern
    mail.sld.tld -> EXTERNE IP
    autodiscover.sld.tld -> EXTERNE IP

    Das wäre ein Musteraufbau, der dazu führt, dass Du die zwei Namen im Zertifikat brauchst:
    mail.sld.tld -> VIP_INTERN
    autodiscover.sld.tld -> VIP_INTERN (für Nicht-AD-Clients im internen Netzwerk)


    Nimmst Du keinen Load Balancer, dann wäre VIP_INTERN = IP des ersten Exchange. In einem Fehlerfall der ersten Exchange musst Du dann im DNS die IP-Adresse für die drei internen Einträge auf die IP des zweiten Exchange ändern.

    Tschüss
    Robert






    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Montag, 25. August 2014 11:06

Alle Antworten

  • Moin,

    richte das mit Split DNS ein.

    Dann brauchst Du im Zertifikate nur noch zwei Namen: mail.sld.tld und autodiscover.sld.tld.

    Danach werden alle SSL-basierten Dienste (SCP, OWA, OAB, EAS, ECP) intern und extern auf die gleiche URL eingestellt.

    Das ist nicht umsonst die empfohlene Konfiguration, da es die Einrichtung und Benutzer deutlich erleichtert.


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Freitag, 22. August 2014 18:05
  • Hallo Robert,

    vielen Dank für deine Empfehlung. Ich habe mich ein wenig auf der msxfaq Seite darüber belesen und habe nach dem Lesen und deinem Post gefühlt mehr Konfusion als vorher.

    Ich verstehe SplitDNS so, dass du intern und extern den gleichen Domänenamen verwendest und dem entsprechend eine interne und eine externe Zone betreibst und darin intern und extern unterschiedliche Einträge gepflegt werden.

    Wolltest du mir mit deiner Empfehlung nun mitteilen, dass ich alle Exchange Server deinstallieren soll, meine interne Domain umbenenne und danach neu installieren soll?

    Oder sollte sie heißen: So wie ich bereits geschrieben habe, nur das ich statt der 2 internen vorgeschlagenen Namen den gleichen nehmen soll, wie den externen?

    Produziere ich mir damit von intern aber nicht zusätzlich Last auf einem der beiden Server? Oder meinst du ich sollte dann 2 Host Einträge mit den beiden IP's im DNS pflegen?

    Vielen Dank für deine Mühe.


    Marcel Brabetz

    Montag, 25. August 2014 09:41
  • Moin,

    > Ich verstehe SplitDNS so, dass du intern und extern den gleichen Domänenamen verwendest und dem entsprechend eine interne und eine externe Zone betreibst und darin intern und extern unterschiedliche Einträge gepflegt werden.

    Korrekt.

    > Wolltest du mir mit deiner Empfehlung nun mitteilen, dass ich alle Exchange Server deinstallieren soll, meine interne Domain umbenenne und danach neu installieren soll?

    Nein. Du verwechselst eine DNS-Domäne/-URL mit der AD-Domäne. Die haben zwar zufällig den gleichen Namen, in diesem Fall aber überhaupt nichts miteinander zu tun.

    Bei Exchange kannst Du in den betreffenden Feldern jeder URL eintragen, die Du willst. Sie muss in DNS auffindbar sein, aber nichts mit AD zu tun haben.

    > Oder sollte sie heißen: So wie ich bereits geschrieben habe, nur das ich statt der 2 internen vorgeschlagenen Namen den gleichen nehmen soll, wie den externen?

    Korrekt. Das ist Split DNS. 

    > Produziere ich mir damit von intern aber nicht zusätzlich Last auf einem der beiden Server? Oder meinst du ich sollte dann 2 Host Einträge mit den beiden IP's im DNS pflegen?

    Zusätzlich sicher nicht, der arbeitet ja jetzt schon.

    Allerdings hört Dein Design nicht bei den URLs im Zertifikat auf. Im Gegenteil: Eigentlich sind die nur das Endergebnis des Designs und Du zäumst das Pferd gerade von hinten auf.

    Round Robin DNS nehmen wir lieber nicht, weil das die Failover-Vorgänge auf den Client verlagert und das kann nicht jeder.

    Die saubere Lösung ist ein vorgeschalteter Load Balancer. WNLB geht bei Dir wegen der DAG nicht.

    Na ja, theoretisch kann man auch den DNS-Eintrag für die URLs auf einen der Server zeigen lassen und im Fehlerfall manuell auf den zweiten ändern. Braucht dann einen Client-Neustart, funktioniert aber und nutze ich selbst auch bei Kunden.

    Auch ein CAS-Array sollte eingerichtet werden, denn sonst kannst Du RPC im Fehlerfall nicht auf den zweiten Server umstellen.

    Wie gesagt: Das sind die Dinge, die man vorher klärt und einrichte. Das Zertifikat mit seinen URLs ist dann nur der logische Schluss daraus.


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Montag, 25. August 2014 09:53
  • Hallo Robert,

    danke für die ausführlichen Kommentare.

    Die Unabhängigkeit zwischen dem AD Namen und der DNS Domain (hier speziell für den Mailversand) ist mir bewusst danke. :-)

    Ich wollte nur wirklich deine erste kurze Aussage besser verstehen, um Missdeutungen meinerseits zu verhindern.

    Also aus deiner Sicht CAS Array auf den externen DNS Namen mail.sld.tld bilden, im internen Netzwerk auf eine der beiden internen IP-Adressen zeigen lassen und dann entsprechend dass nächste Zertifikat auf die 2 Namen zeigen lassen (mail und autodiscover).

    Vielen Dank


    Marcel Brabetz

    Montag, 25. August 2014 10:15
  • Hallo Marcel,

    das CAS-Array wird für den RPC/MAP-Zugriff benutzt. Du hast oben URL für den HTTPS-Zugriff. Der Name des CAS-Arrays muss daher nicht ins Zertifikat sollte anders sein. Und es muss auch kein externer Name sein, da er von außen nicht benutzt wird.

    Normalweise sieht das ungefähr so aus:

    LB hat VIP_INTERN

    FQDN für die URLs (OAB, EWS, EAS, OA, Autodiscover intern):
    mail.sld.tld

    FQDN für Autodiscover extern:
    autodiscover.sld.tld

    FQDN für das CAS-Array:
    cas.internername.local

    DNS intern
    mail.sld.tld -> VIP_INTERN
    autodiscover.sld.tld -> VIP_INTERN (für Nicht-AD-Clients im internen Netzwerk)
    cas.internername.tls -> VIP_INTERN

    Zusätzlich wird der SCP für AD-Autodiscover mit "mail.sld.tld" gefüllt.

    DNS extern
    mail.sld.tld -> EXTERNE IP
    autodiscover.sld.tld -> EXTERNE IP

    Das wäre ein Musteraufbau, der dazu führt, dass Du die zwei Namen im Zertifikat brauchst:
    mail.sld.tld -> VIP_INTERN
    autodiscover.sld.tld -> VIP_INTERN (für Nicht-AD-Clients im internen Netzwerk)


    Nimmst Du keinen Load Balancer, dann wäre VIP_INTERN = IP des ersten Exchange. In einem Fehlerfall der ersten Exchange musst Du dann im DNS die IP-Adresse für die drei internen Einträge auf die IP des zweiten Exchange ändern.

    Tschüss
    Robert






    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Montag, 25. August 2014 11:06
  • Vielen Dank, deine Erläuterungen haben mir wieder etwas mehr Licht in das Dunkel gebracht.

    Einen schönen sonnigen Tag noch in Berlin :-)


    Marcel Brabetz

    Montag, 25. August 2014 11:22