
136165
28.05.2018
Zuordnung internes AD-Zertifikat und externes DigiCert Zertifikat für Remotedesktop
Guten Morgen,
für meine externe Sub.Domain, welche auf mein internes RD-Gateway zeigt (IP-Weiterleitung)
habe ich ein Zertifikat gekauft und erfolgreich über IIS-Serverzertifikate installiert.
Das gekaufte Zertifikat für das Gateway wird im Browser was vertrauenswürdig DigiCert angezeigt (hurra)
Für den "RD-Verbindungsbroker" und "Web-Access für RD" hab ich ein internes AD-Zertifikat erstellt, welches
als .pfx jeweils im ServerManager unter RD-Zertifikate eingebunden wurde.
Das steht jeweils "Vertrauenswürdig" und der Status ist "OK".
Somit haben die internen Server das Zertifikat vom AD
und nur das RD-Gateway das gekaufte für die sichere Verbindung.
Nun steht bei den RD-Zertifikaten folgende Warnung:
"Auf dem Server sind sowohl der Rollendienst "RD-Gateway" als auch der Rollendienst "Web Access für Remotedesktop" installiert.
Für diese Serverdienste sollten keine unterschiedlichen Zertifikate konfiguriert werden".//
Wenn ich nun dem RD-Gateway ebenfalls das AD-Zertifikat übergeben würde, dann wäre das bestimmt falsch,
da ja dort das gekaufte Zertifikat eingesetzt wurde (mit dem Namen der Sub.Domain)
aber wie soll das Zertifikat gleich sein, wenn die externe Sub-Domain und die interne Ad-Domain unterschiedliche
Namen haben ? Ein Wildcard-Zertifikat wäre ja somit auch Unsinn, da die Endungen je einmal ".de" und einmal ".local" sind. (?)
Was ist falsch / was muss ich anders machen ? ? ? ? ?
Danke für deinen / Ihren Rat
Michel
für meine externe Sub.Domain, welche auf mein internes RD-Gateway zeigt (IP-Weiterleitung)
habe ich ein Zertifikat gekauft und erfolgreich über IIS-Serverzertifikate installiert.
Das gekaufte Zertifikat für das Gateway wird im Browser was vertrauenswürdig DigiCert angezeigt (hurra)
Für den "RD-Verbindungsbroker" und "Web-Access für RD" hab ich ein internes AD-Zertifikat erstellt, welches
als .pfx jeweils im ServerManager unter RD-Zertifikate eingebunden wurde.
Das steht jeweils "Vertrauenswürdig" und der Status ist "OK".
Somit haben die internen Server das Zertifikat vom AD
und nur das RD-Gateway das gekaufte für die sichere Verbindung.
Nun steht bei den RD-Zertifikaten folgende Warnung:
"Auf dem Server sind sowohl der Rollendienst "RD-Gateway" als auch der Rollendienst "Web Access für Remotedesktop" installiert.
Für diese Serverdienste sollten keine unterschiedlichen Zertifikate konfiguriert werden".//
Wenn ich nun dem RD-Gateway ebenfalls das AD-Zertifikat übergeben würde, dann wäre das bestimmt falsch,
da ja dort das gekaufte Zertifikat eingesetzt wurde (mit dem Namen der Sub.Domain)
aber wie soll das Zertifikat gleich sein, wenn die externe Sub-Domain und die interne Ad-Domain unterschiedliche
Namen haben ? Ein Wildcard-Zertifikat wäre ja somit auch Unsinn, da die Endungen je einmal ".de" und einmal ".local" sind. (?)
Was ist falsch / was muss ich anders machen ? ? ? ? ?
Danke für deinen / Ihren Rat
Michel
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 375290
Url: https://administrator.de/forum/zuordnung-internes-ad-zertifikat-und-externes-digicert-zertifikat-fuer-remotedesktop-375290.html
Ausgedruckt am: 29.04.2025 um 13:04 Uhr
5 Kommentare
Neuester Kommentar
Moin,
deshalb verwendet man schon lange .local nicht mehr als AD.
Auch weil man .local eigentlich noch nie hätte verwenden dürfen.
Siehe http://www.mdmarra.com/2012/11/why-you-shouldnt-use-local-in-your.html
Empfohlen wird ad.firma.de.
Dann kann man einfach ein WC-Zertifikat (prima Abkürzung) verwenden und ist glücklich.
Vermutlich willst Du nicht Dein AD wechseln und alles neu machen.
Aber für .local stellt Dir Niemand mehr Zertifikate aus. Schon seit Jahren nicht mehr.
Also:
A) Zwei Zertifikate
B) Ein selbsterstelltes Zertifikat für alles
Stefan
deshalb verwendet man schon lange .local nicht mehr als AD.
Auch weil man .local eigentlich noch nie hätte verwenden dürfen.
Siehe http://www.mdmarra.com/2012/11/why-you-shouldnt-use-local-in-your.html
Empfohlen wird ad.firma.de.
Dann kann man einfach ein WC-Zertifikat (prima Abkürzung) verwenden und ist glücklich.
Vermutlich willst Du nicht Dein AD wechseln und alles neu machen.
Aber für .local stellt Dir Niemand mehr Zertifikate aus. Schon seit Jahren nicht mehr.
Also:
A) Zwei Zertifikate
B) Ein selbsterstelltes Zertifikat für alles
Stefan
Wie schon gesagt: Eure Active Directory Domäne wurde falsch geplant und konfiguriert. *.local ist kein geeignetes Suffix. Ihr hättet intern einen zum externen Domänen-Namen untergeordneten Namensraum wählen müssen.
Übrigens: Wer falsche Namensräume gewählt hat, der hat oftmals auch falsche Rollen- bzw. Gruppenmodelle, schlecht geplante Gruppenrichtlinien und div. weitere Fehler in seinem AD. Evtl. lohnt sich mal ein Blick "unter die Haube".
Es wird mir für immer unbegreiflich bleiben, warum so viele AD Umgebungen falsch und kaputt sind.
Übrigens: Wer falsche Namensräume gewählt hat, der hat oftmals auch falsche Rollen- bzw. Gruppenmodelle, schlecht geplante Gruppenrichtlinien und div. weitere Fehler in seinem AD. Evtl. lohnt sich mal ein Blick "unter die Haube".
Es wird mir für immer unbegreiflich bleiben, warum so viele AD Umgebungen falsch und kaputt sind.
Zitat von @Matsushita:
Es wird mir für immer unbegreiflich bleiben, warum so viele AD Umgebungen falsch und kaputt sind.
Weil die Assistenten von Microsofts SBS 2003 und 2011 .local vorgeschlagen haben. Also sind viele dieser Empfehlung gefolgt und haben nun den Salat (ohne Gurken und ohne Dressing).Es wird mir für immer unbegreiflich bleiben, warum so viele AD Umgebungen falsch und kaputt sind.
Moin
Vielleicht noch mal als Nachtrag: Nicht nur die SBS-Server haben die Endung .local verwendet.
Wenn man ein wenig "oldschool" ist, hat man das auch für manuelle AD-Installationen so gelernt.
Das ist lange Zeit die offizielle Version seitens Microsoft gewesen ein AD aufzusetzen. Ich selbst habe damals während meiner Windows 2000 MCSE-Ausbildung das so gelernt. (aber klar: wer rastet der rostet)
Gruß
Vielleicht noch mal als Nachtrag: Nicht nur die SBS-Server haben die Endung .local verwendet.
Wenn man ein wenig "oldschool" ist, hat man das auch für manuelle AD-Installationen so gelernt.
Das ist lange Zeit die offizielle Version seitens Microsoft gewesen ein AD aufzusetzen. Ich selbst habe damals während meiner Windows 2000 MCSE-Ausbildung das so gelernt. (aber klar: wer rastet der rostet)
Gruß