GoDaddy SAN Zertifikat mit DynDNS URL

[PathFinder 10]

Hallo zusammen,

 

Ich möcht gerne eine UCC/SAN Zertfikat bei GoDaddy kaufen mit den folgenden Eigenschaften.

 

Common Name = firma.de

SAN1 = owa.firma.de

SAN2 = firma.dyndns.org

SAN3 = exsrv.firma.local

SAN4 = autodiscover.firma.local

 

Frage1: ist mit dem Common Name schon eines der 5 Möglichen Zertifikate belegt oder gilt die Anzahl nur für SANs? Sprich ich hätte noch einen zur verfügung?

 

Frage2: Ist es möglich eine dyndns.org URL mit einzubeziehen? wenn ja wie =)

 

Verstehe ich es richtig das die dyndns.org URL miteinbezogen werden muss wenn wir owa.firma.de über DynDNS an den Firmenrouter leiten? Feste IP bekommen wir leider an dem Standort nicht.

 

Es leitet eine FritzBox an einen TMG Server weiter, von dort per Veröffentlichungsregel an den Exchange2010 inHouse.

 

danke fürs lesen, der Path

[LukasB 10]

Ein SSL-Zertifikat für eine DynDNS-Domain zu bekommen ist nicht möglich, da dir die domain dyndns.org nicht gehört.

 

Du kannst mit CNAMEs arbeiten, oder mit dem DynDNS for your own Domain Service.

[PathFinder 10]

Hallo Lukas,

 

danke für deine Antwort.

 

Das habe ich jetzt auch rausgelesen, das mir die Domäne nicht gehört ist in dem Zusammenhang klar, ich habe ja keinerlei Aktien in der Sache. Ich dachte nur das es vielleicht für diese Fälle eine Möglichkeit gäbe, aber gut alles klar! DynDNS for your own Domain Service.

 

Ich bin nur auf die Idee gekommen weil ich an der Stelle wohl einfach ein Verständnisproblem habe.

 

Wenn unsere owa.firma.de Adresse(CNAME DNS extern) auf eine DynDNS Adresse weitergeleitet wird, hat dann diese DynDNS Adresse einen Einfluss auf die SSL Kette?

 

Wenn ich owa.firma.de auf eine feste IP weiterleite habe ich ja den Idealfall und kein Problem.

 

Wenn ich owa.firma.de auf eine DynDNS Adresse weiterleite dann leitet diese ja erst auf eine IP.

 

Oder ist die DynDNS Adresse dann transparent und es existieren nur owa.firma.de und die IP am Ende?

 

Bekomm das gedanklich noch nicht ganz auf die Reihe und bin dankbar für Erhellung.

 

der Path

[LukasB 10]

Wenn du via HTTP weiterleitest (301 Redirect), dann hat die DynDNS-Adresse einen Einfluss.

 

Wenn du einen DNS CNAME verwendest (was keine Weiterleitung ist), dann erfährt der Browser nie etwas von dem anderen Namen (.dyndns.org)- das wird im Resolver gehandelt.

[PathFinder 10]

Ich danke dir vielmals.

 

Ich habe im DNS Manager unserer Domänenkonfiguration einen CNAME mit owa.firma.de eingerichtet Weiterleitung auf DynDNS also keinen Redirect somit ist die DynDNS Adresse nicht von belang.

 

Aus der oben beschrieben Zertifikat Anforderung nehme ich DynDNS raus und nehme lieber noch den externen autodiscover mit rein.

 

Das Zertfikat vervollständige ich auf dem Ex2010 und lege alle Dienste auf das neue Zertifikat.

 

Das Zertfikat exportiere ich und lade es auf den TMG lokaler Computer-> Eigene Zertifikate.

 

Dieses Zertfikat kann ich dann im Weblistener für OWA auswählen.

 

Somit müsste die Verbindung über owa.firma.de über den TMG zum Exchange Server klappen?

[LukasB 10]

Ja. Alternativ zu der In/Externen DNS-Konfiguration kannst du auch generell nur die externe Adresse verwenden - so mache ich das meist. Hat in kleinen Deployments auch keine Nachteile und macht die Konfiguration und das Debugging einfacher (kann weniger kaputtgehen). Man muss dann einfach sicherstellen das die Internen Hosts auch über die Externe Adresse zugreifen kann.

 

Dine Vorgehensweise ist aber grundsätzlich richtig.

[PathFinder 10]

Du meinst das ich exsrv.firma.local und autodiscover.firma.local aus der Anfrage raus lasse und nur externe Adressen verwende?

 

bedeutet das das ich nur das Zertifikat auf dem Client intern installieren muss, da der Exchange Server sich ja folglich mit der externen Adresse ausweist?

[LukasB 10]

Das Zertifikat sollte auf dem Exchange und dem TMG installiert werden. Was willst du auf den Clients genau machen?

[PathFinder 10]

Ja. Alternativ zu der In/Externen DNS-Konfiguration kannst du auch generell nur die externe Adresse verwenden - so mache ich das meist. Hat in kleinen Deployments auch keine Nachteile und macht die Konfiguration und das Debugging einfacher (kann weniger kaputtgehen). Man muss dann einfach sicherstellen das die Internen Hosts auch über die Externe Adresse zugreifen kann.

 

Das ich generell nur externe Adressen verwenden kann.

 

Wenn ich die internen Adresssen aus dem Zertifikat lasse, dann bekomme ich beim starten von Outlook im LAN ja eine Zertifikat Fehlermeldung.

 

Ich fragte mich ob ich das richtig verstanden habe, das wenn ich nur externe Adressen verwende, ich das neue Zertifikat auch auf den internen PCs installieren muss um die Outlook SSL Fehlermeldung zu vermeiden.

 

Oder wie meintest du das?

[LukasB 10]

Wenn ich die internen Adresssen aus dem Zertifikat lasse, dann bekomme ich beim starten von Outlook im LAN ja eine Zertifikat Fehlermeldung.

 

Wenn Exchange und der SCP richtig konfiguriert sind nicht. Dort steht jetzt natürlich noch der lokale Namen drin - wenn du aber sicherstellt das sowohl in den Feldern für den Externen Namen und für den Internen Namen der gleiche Externe Wert drinsteht, dann klappts.

 

Ich fragte mich ob ich das richtig verstanden habe, das wenn ich nur externe Adressen verwende, ich das neue Zertifikat auch auf den internen PCs installieren muss um die Outlook SSL Fehlermeldung zu vermeiden.

 

Nein, das Zertifikat muss intern nicht installiert werden.

[PathFinder 10]

Das ist natürlich interessant, damit würde ich "Platz" im Zertifikat sparen und vielleicht noch die Sharepoint Adresse mit aufnehmen können.

 

Ich danke dir für deine Mühe und deine Erklärungen, ich denke ich werde es erstmal wie zuerst besprochen durchführen.

 

Aber den Tipp werde ich nicht vergessen.

 

liebe Grüße und besten Dank.