14
Remote App 2012 Verbindung nicht vertrauenswürdig
Hallo an alle,
habe mir einen Server 2012 installiert und dort eine RemoteApp Umgebung eingerichtet.
(RD-Verbindungsbroker, RD-Sitzungshost, RD-Gateway, RD-Lizensierung und Web Access)
[Alle folgenden Namen sind exemplarisch, spiegeln aber genau im wesentlichen die Konfiguration wieder]
Von der internen "Root CA TEST" habe ich mir ein Zertifikat für "remote.test.com" ausgestellt und dieses in der gesamten RemoteApp Umgebung an den notwendigen Plätzen eingespielt.
Ablauf bei einem Domänenrechner:
Das "Root CA TEST" befindet sich auf dem Rechner da dieser in der Domäne hängt.
Ich verbinde mich auf https://remote.test.com/ (Redirekt auf /RDWeb/Pages ist eingerichtet)
Das Schloss im in der Browser Adresszeile zeigt mir, dass das Zertifikat "remote.test.com" von dem "Root CA TEST" ausgestellt wurde und sicher ist. Somit wird das Schloss als geschlossen angezeigt.
Den SHA1 Fingerabdruck vom "remote.test.com" wurde über die Gruppenrichtlinien eingetragen.
(Benutzerkonfiguration - Administrative Vorlagen - Windows Komponenten - Remotedesktopdienste - Remotedesktopverbindungs-Client - SHA1...)
Wenn ich nun die Seite "https://remote.test.com" aufrufe und mich authentifiziere läuft alles nach Plan. Keine Warnungen, alles perfekt.
Ablauf bei einem externen NICHT-Domänenrechner:
Das "Root CA TEST" wird im Internet Explorer unter "Vertrauenswürdige Stammzertifikate" eingespielt.
Der SHA1 Fingerabdruck von "remote.test.com" wird in die lokalen Richtlinien eingetragen.
Wenn ich nun die Seite "https://remote.test.com" aufrufe und mich authentifiziere, sehe ich das geschlossene Schloss.
Zertifikat passt also. Wenn ich aber nun ein RemoteApp oder eine RDP Verknüpfung aufrufe, bekomme ich eine Meldung, dass die Verbindung nicht vertrauenswürdig ist.
Ich habe auch schon versucht, die lokalen Adressen wie server1.test.local im IE unter vertrauenswürdige Seite einzutragen. Aber leider auch kein Erfolg.
Warum klappt das von einem Domänenrechner aber nicht von außen?
habe mir einen Server 2012 installiert und dort eine RemoteApp Umgebung eingerichtet.
(RD-Verbindungsbroker, RD-Sitzungshost, RD-Gateway, RD-Lizensierung und Web Access)
[Alle folgenden Namen sind exemplarisch, spiegeln aber genau im wesentlichen die Konfiguration wieder]
Von der internen "Root CA TEST" habe ich mir ein Zertifikat für "remote.test.com" ausgestellt und dieses in der gesamten RemoteApp Umgebung an den notwendigen Plätzen eingespielt.
Ablauf bei einem Domänenrechner:
Das "Root CA TEST" befindet sich auf dem Rechner da dieser in der Domäne hängt.
Ich verbinde mich auf https://remote.test.com/ (Redirekt auf /RDWeb/Pages ist eingerichtet)
Das Schloss im in der Browser Adresszeile zeigt mir, dass das Zertifikat "remote.test.com" von dem "Root CA TEST" ausgestellt wurde und sicher ist. Somit wird das Schloss als geschlossen angezeigt.
Den SHA1 Fingerabdruck vom "remote.test.com" wurde über die Gruppenrichtlinien eingetragen.
(Benutzerkonfiguration - Administrative Vorlagen - Windows Komponenten - Remotedesktopdienste - Remotedesktopverbindungs-Client - SHA1...)
Wenn ich nun die Seite "https://remote.test.com" aufrufe und mich authentifiziere läuft alles nach Plan. Keine Warnungen, alles perfekt.
Ablauf bei einem externen NICHT-Domänenrechner:
Das "Root CA TEST" wird im Internet Explorer unter "Vertrauenswürdige Stammzertifikate" eingespielt.
Der SHA1 Fingerabdruck von "remote.test.com" wird in die lokalen Richtlinien eingetragen.
Wenn ich nun die Seite "https://remote.test.com" aufrufe und mich authentifiziere, sehe ich das geschlossene Schloss.
Zertifikat passt also. Wenn ich aber nun ein RemoteApp oder eine RDP Verknüpfung aufrufe, bekomme ich eine Meldung, dass die Verbindung nicht vertrauenswürdig ist.
Ich habe auch schon versucht, die lokalen Adressen wie server1.test.local im IE unter vertrauenswürdige Seite einzutragen. Aber leider auch kein Erfolg.
Warum klappt das von einem Domänenrechner aber nicht von außen?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 266938
Url: https://administrator.de/forum/remote-app-2012-verbindung-nicht-vertrauenswuerdig-266938.html
Ausgedruckt am: 22.12.2024 um 11:12 Uhr
14 Kommentare
Neuester Kommentar
http://blogs.technet.com/b/askperf/archive/2008/10/31/unknown-publisher ...
Und für die korrekte Einrichtung des Zertifikats siehe:
https://technet.microsoft.com/en-us/library/dn781533.aspx
Gruß jodel32
Und für die korrekte Einrichtung des Zertifikats siehe:
https://technet.microsoft.com/en-us/library/dn781533.aspx
Gruß jodel32
Hi.
Ich schätze, du hast vergessen, den DC als vertrauenswürdige Stammzertifizierungsstelle einzutragen. Auf Domänenmitgliedern passiert das nämlich automatisch.
Ich schätze, du hast vergessen, den DC als vertrauenswürdige Stammzertifizierungsstelle einzutragen. Auf Domänenmitgliedern passiert das nämlich automatisch.
Ich bin mir nicht sicher ob dich richtig verstehe.
Meinst du, dass ich unter "vertrauenswürdige Stammzertifizierungsstellen" das Zertifikat vom DC einspiele?
Auf meinem Rechner welcher in der Firma in der Domäne hängt, kann ich das Zertifikat unter "vertrauenswürdige Stammzertifizierungsstellen" nicht finden.
Wo sollte ich das sehen können? Oder meinst du das "Root CA"?
Meinst du, dass ich unter "vertrauenswürdige Stammzertifizierungsstellen" das Zertifikat vom DC einspiele?
Auf meinem Rechner welcher in der Firma in der Domäne hängt, kann ich das Zertifikat unter "vertrauenswürdige Stammzertifizierungsstellen" nicht finden.
Wo sollte ich das sehen können? Oder meinst du das "Root CA"?
Du verstehst mich richtig.
Du solltest auf deinem Domänenclient unter Zertifikate (lokaler Computer) ->vertr. Stammz. ein Zert. domainname-DCname-CA finden - davon spreche ich.
Du solltest auf deinem Domänenclient unter Zertifikate (lokaler Computer) ->vertr. Stammz. ein Zert. domainname-DCname-CA finden - davon spreche ich.
Wenn ich mich nun doch entscheide ein Zertifikat von godaddy, oder anderen Anbietern zu kaufen.
Wie wäre hier der richtige Vorgang?
Ich möchte, dass von extern das RDS über remote.xxx.com im Browser erreichbar ist.
(externer DNS Eintrag und Firewall Regel für HTTPS Weiterleitung auf 10.10.10.1 existieren bereits.
Hier die Aufstellung der Bereitstellungsserver im Servermanager:
srv1.xxx.local RD-Verbindungsbroker
srv1.xxx.local RD-Sitzungshost
srv1.xxx.local RD-Gateway
srv1.xxx.local RD-Lizensierung
srv1.xxx.local Web Access für Remotedesktop
srv1.xxx.local DNS Eintrag zeigt auf IP 10.10.10.1
Unter Bereitstellungseigenschaften habe ich beim Remotedesktopgateway eingetragen, dass immer remote.xxx.com als Gateway verwendet werden soll.
remote.xxx.com DNS Eintrag zeigt auf IP 10.10.10.1
Zuerst müsste ich eine CSR Datei erstellen. So wie hier beschrieben:
http://sheeponline.net/rds-certificates.html
Danach bei Godaddy unterzeichnen lassen.
Nun kann ich das Zertifikat überall am Server einspielen wo es gebraucht wird.
Aber was für einen Namen wähle ich beim Zertifikat? remote.xxx.com oder srv1.xxx.local oder ganz was anderes?
Oder brauche ich gleich 2 Zertifikate für remote.xxx.com und srv1.xxx.local?
Irgendwie habe ich auch im Kopf, dass man außen kein .local transparent macht.
Bin eben in Sachen Zertifikaten nicht ganz so sattelfest.
Wie wäre hier der richtige Vorgang?
Ich möchte, dass von extern das RDS über remote.xxx.com im Browser erreichbar ist.
(externer DNS Eintrag und Firewall Regel für HTTPS Weiterleitung auf 10.10.10.1 existieren bereits.
Hier die Aufstellung der Bereitstellungsserver im Servermanager:
srv1.xxx.local RD-Verbindungsbroker
srv1.xxx.local RD-Sitzungshost
srv1.xxx.local RD-Gateway
srv1.xxx.local RD-Lizensierung
srv1.xxx.local Web Access für Remotedesktop
srv1.xxx.local DNS Eintrag zeigt auf IP 10.10.10.1
Unter Bereitstellungseigenschaften habe ich beim Remotedesktopgateway eingetragen, dass immer remote.xxx.com als Gateway verwendet werden soll.
remote.xxx.com DNS Eintrag zeigt auf IP 10.10.10.1
Zuerst müsste ich eine CSR Datei erstellen. So wie hier beschrieben:
http://sheeponline.net/rds-certificates.html
Danach bei Godaddy unterzeichnen lassen.
Nun kann ich das Zertifikat überall am Server einspielen wo es gebraucht wird.
Aber was für einen Namen wähle ich beim Zertifikat? remote.xxx.com oder srv1.xxx.local oder ganz was anderes?
Oder brauche ich gleich 2 Zertifikate für remote.xxx.com und srv1.xxx.local?
Irgendwie habe ich auch im Kopf, dass man außen kein .local transparent macht.
Bin eben in Sachen Zertifikaten nicht ganz so sattelfest.
Einfach mal oben den Link lesen, da steht alles drin
https://technet.microsoft.com/en-us/library/dn781533.aspx
https://technet.microsoft.com/en-us/library/dn781533.aspx
Okay, ich glaube ich habe es verstanden.
Für mich trifft diese Variante zu:
External name: remote.xxx.com
Internal name: srv1.xxx.local
Somit brauche ich keine CSR Datei erstellen und dann bei godaddy signieren lassen.
Ich gehe gleich zu godaddy und lasse mir ein Zertifikat für remote.xxx.com ausstellen.
Und dieses spiele ich dann bei der "Web Access" und "Gateway" Rolle ein, da nur diese nach außen propagiert werden.
Ist das so richtig?
Dann sollte die Meldung aus meinem ersten Post ausbleiben, korrekt?
Für mich trifft diese Variante zu:
External name: remote.xxx.com
Internal name: srv1.xxx.local
Somit brauche ich keine CSR Datei erstellen und dann bei godaddy signieren lassen.
Ich gehe gleich zu godaddy und lasse mir ein Zertifikat für remote.xxx.com ausstellen.
Und dieses spiele ich dann bei der "Web Access" und "Gateway" Rolle ein, da nur diese nach außen propagiert werden.
Ist das so richtig?
Dann sollte die Meldung aus meinem ersten Post ausbleiben, korrekt?
Bitte um kurze Rückmeldung ob diese Vorgehensweise nun so richtig wäre.
Ich dachte mir ich mach mal Learning by Doing.
Wir haben ein SAN Zertifikat ausgestellt auf "mail.xxx.com" (zusätzlich noch terminal, mail, vpn und autodiscover)
Da terminal noch nicht in Verwendung war, habe ich dieses gleich zum Testen verwendet.
Ich habe am ISS und bei der Gateway und Web Access Rolle das .pfx File von mail.xxx.com eingespielt.
Und beim Namen des Gatewayservers "terminal.xxx.com" angegeben.
Wenn ich nun von extern "terminal.xxx.com" aufrufe, dann erkenne ich in der Adresszeile das geschlossene Schloss.
Soweit gut. Dann authentifizieren. Das geht auch noch.
Wenn ich nun aber eine Anwendung starte, dann kommt diese Fehlermeldung, dass "mail.xxx.com" eventuell kein Vertrauenswürdiger Herausgeber sei.
Und ich bin mir fast sicher, dass wenn ich diese Hürde schaffe, dann jammert er, dass "srv1.montavit.lan" auch nicht vertrauenswürdig ist.
Vielleicht könnt ihr mir hier weiterhelfen.
Wir haben ein SAN Zertifikat ausgestellt auf "mail.xxx.com" (zusätzlich noch terminal, mail, vpn und autodiscover)
Da terminal noch nicht in Verwendung war, habe ich dieses gleich zum Testen verwendet.
Ich habe am ISS und bei der Gateway und Web Access Rolle das .pfx File von mail.xxx.com eingespielt.
Und beim Namen des Gatewayservers "terminal.xxx.com" angegeben.
Wenn ich nun von extern "terminal.xxx.com" aufrufe, dann erkenne ich in der Adresszeile das geschlossene Schloss.
Soweit gut. Dann authentifizieren. Das geht auch noch.
Wenn ich nun aber eine Anwendung starte, dann kommt diese Fehlermeldung, dass "mail.xxx.com" eventuell kein Vertrauenswürdiger Herausgeber sei.
Und ich bin mir fast sicher, dass wenn ich diese Hürde schaffe, dann jammert er, dass "srv1.montavit.lan" auch nicht vertrauenswürdig ist.
Vielleicht könnt ihr mir hier weiterhelfen.
Les mal den ersten Link den ich dir gepostet hatte ganz genau, das liegt nicht am Zertifikat sondern an der Signatur des RDP-Files das der Server dem Client on the fly übermittelt:
http://blogs.technet.com/b/askperf/archive/2008/10/31/unknown-publisher ...
http://blogs.technet.com/b/askperf/archive/2008/10/31/unknown-publisher ...
Irgendwie stehe ich echt extrem auf der Leitung.
Habe mir den Artikel jetzt 4 mal durchgelesen, aber komme auf keinen grünen Zweig.
Ich glaube du spielst auf "Szenario 2" an und im speziellen auf diesen Eintrag:
If you are already using an SSL certificate for terminal server or TS Gateway connections, you can use the same certificate to sign .rdp files. However, if users will connect to RemoteApp programs from public or home computers, you must use either of the following:
A: A certificate from a public CA that participates in the Microsoft Root Certificate Program Members program (http://support.microsoft.com/kb/931125)
B: If you are using an enterprise CA, your enterprise CA-issued certificate must be co-signed by a public CA that participates in the Microsoft Root Certification Program Members program.
Zu A: Wir haben ein GoDaddy Zertifikat. GoDaddy ist meines Wissens nach auf bei Microsoft anerkannt. Somit sollte das SAN Zertifikat, welches wir vor einem Jahr gekauft haben, kein Problem darstellen.
Zu B: Betriff uns aktuell nicht, da ich es nun über ein offizielles Zertifikat lösen möchte. (mail.xxx.com)
Wenn ich mir die Microsoft Root Certificate Members anschaue:
http://download.microsoft.com/download/1/5/7/157B29AB-F890-464A-995A-C8 ...
Dann finde ich das "Go Daddy Class 2 Certification Authority" mit dem gleichen Fingerabruck, wie ich auch in meinem von GoDaddy Zertifikat mail.xxx.com
Wenn ich das Zertifikat öffne und auf den Zertifizierungspfad gehe, dann steht dort auch "Go Daddy Class 2 Certification Authority" und der SHA1 Fingerabruck ist der selbe wie aus dem PDF von Microsoft.
Ich steh echt total im Wald bzw. auf der Leitung.
Wäre super wenn du mir hier weiterhelfen könntest.
Oder brauche ich ein extra Zertifikat welches für das Signieren von RDS Zertifikaten gedacht ist?
Oder hat das mail.xxx.com Zertifkat was von GoDaddy ausgestellt ist eine andere Eigenschaft? Hier gibt es ja die Eigenschaften Authentifizierung, Remote Signierung, usw.
Habe mir den Artikel jetzt 4 mal durchgelesen, aber komme auf keinen grünen Zweig.
Ich glaube du spielst auf "Szenario 2" an und im speziellen auf diesen Eintrag:
If you are already using an SSL certificate for terminal server or TS Gateway connections, you can use the same certificate to sign .rdp files. However, if users will connect to RemoteApp programs from public or home computers, you must use either of the following:
A: A certificate from a public CA that participates in the Microsoft Root Certificate Program Members program (http://support.microsoft.com/kb/931125)
B: If you are using an enterprise CA, your enterprise CA-issued certificate must be co-signed by a public CA that participates in the Microsoft Root Certification Program Members program.
Zu A: Wir haben ein GoDaddy Zertifikat. GoDaddy ist meines Wissens nach auf bei Microsoft anerkannt. Somit sollte das SAN Zertifikat, welches wir vor einem Jahr gekauft haben, kein Problem darstellen.
Zu B: Betriff uns aktuell nicht, da ich es nun über ein offizielles Zertifikat lösen möchte. (mail.xxx.com)
Wenn ich mir die Microsoft Root Certificate Members anschaue:
http://download.microsoft.com/download/1/5/7/157B29AB-F890-464A-995A-C8 ...
Dann finde ich das "Go Daddy Class 2 Certification Authority" mit dem gleichen Fingerabruck, wie ich auch in meinem von GoDaddy Zertifikat mail.xxx.com
Wenn ich das Zertifikat öffne und auf den Zertifizierungspfad gehe, dann steht dort auch "Go Daddy Class 2 Certification Authority" und der SHA1 Fingerabruck ist der selbe wie aus dem PDF von Microsoft.
Ich steh echt total im Wald bzw. auf der Leitung.
Wäre super wenn du mir hier weiterhelfen könntest.
Oder brauche ich ein extra Zertifikat welches für das Signieren von RDS Zertifikaten gedacht ist?
Oder hat das mail.xxx.com Zertifkat was von GoDaddy ausgestellt ist eine andere Eigenschaft? Hier gibt es ja die Eigenschaften Authentifizierung, Remote Signierung, usw.
Ich bin auf die Behebung eines anderen Problems gestoßen.
Bei mir war immer als Remotecomputer (srv1.xxx.local) eingetragen, wenn ich versucht habe ein RemoteApp zu öffnen.
Mit diesem MS Beitrag konnte ich den gepublishten Namen ändern:
https://gallery.technet.microsoft.com/Change-published-FQDN-for-2a029b80
Im Browser gebe ich "https://terminal.xxx.com" ein.
Das Schloss ist geschlossen und ich kann mich anmelden.
Nun sieht das Fenster beim Öffnen einer App bei mir so aus:
Herausgeber: mail.xxx.com (blau unterstrichen)
Remotecomputer: terminal.xxx.com
Gatewayserver: terminal.xxx.com
Und die Warnung sagt: "Stellen Sie vor dem Ausführen, bla bla, dass Sie dem HERAUSGEBER vertrauen."
Könnte es in diesem Zusammenhand nicht daran liegen, dass ich ein SAN Zertifikat(GoDaddy) habe welches auf "mail.xxx.com" ausgestellt ist, aber zudem noch über "vpn.xxx.com", "terminal.xxx.com", etc. ansprechbar ist.
Würde für mich logisch klingen.
Oder muss das auch mit einem SAN Zertifikat klappen?
Bitte um Rückmeldung, jetzt kann es nur mehr eine Kleinigkeit sein.
Wenn ich mir ein neues Zertifikat kaufen würde, welches nur auf "terminal.xxx.com" lauten würde, wäre das Problem vermutlich behoben.
Oder was meint ihr?
Bei mir war immer als Remotecomputer (srv1.xxx.local) eingetragen, wenn ich versucht habe ein RemoteApp zu öffnen.
Mit diesem MS Beitrag konnte ich den gepublishten Namen ändern:
https://gallery.technet.microsoft.com/Change-published-FQDN-for-2a029b80
Im Browser gebe ich "https://terminal.xxx.com" ein.
Das Schloss ist geschlossen und ich kann mich anmelden.
Nun sieht das Fenster beim Öffnen einer App bei mir so aus:
Herausgeber: mail.xxx.com (blau unterstrichen)
Remotecomputer: terminal.xxx.com
Gatewayserver: terminal.xxx.com
Und die Warnung sagt: "Stellen Sie vor dem Ausführen, bla bla, dass Sie dem HERAUSGEBER vertrauen."
Könnte es in diesem Zusammenhand nicht daran liegen, dass ich ein SAN Zertifikat(GoDaddy) habe welches auf "mail.xxx.com" ausgestellt ist, aber zudem noch über "vpn.xxx.com", "terminal.xxx.com", etc. ansprechbar ist.
Würde für mich logisch klingen.
Oder muss das auch mit einem SAN Zertifikat klappen?
Bitte um Rückmeldung, jetzt kann es nur mehr eine Kleinigkeit sein.
Wenn ich mir ein neues Zertifikat kaufen würde, welches nur auf "terminal.xxx.com" lauten würde, wäre das Problem vermutlich behoben.
Oder was meint ihr?
Für einen Rat wäre ich sehr dankbar.
Habe mich nun weiter mit der Materie beschäftigt.
Anbei der aktuelle Stand:
Ich habe nun den Powershell Befehl für den "Redirect to an alternative Name" ausgeführt.
Set-RDSessionCollectionConfiguration –CollectionName QuickSessionCollection -CustomRdpProperty "use redirection server name:i:1 `n alternate full address:s:remote.xxx.com"
Ich denke der Befehl ging durch. Er spring in der PowerShell einfach in die nächste Zeile.
Wie oben beschrieben habe ich einen einzelnen RDS 2012 Server in einer .local Domäne(srv1.xxx.local). Auf diesem sind alle Rollen für das RDS installiert. Diesen möchte ich extern(remote.xxx.com) mit einem godaddy Zertifikat zugänglich machen. Das remote.xxx.com Zertifikat habe ich auf allen Rollen installiert.
Ich habe nun folgende zwei Szenarien:
Szenario 1
Wenn ich den FQDN unverändert lasse. Also den Power Shell Befehl ./Set-RDPublishedName.ps1 "remote.xxx.com" NICHT ausführe, dann kann ich mich ohne Probleme von extern via WebBrowser anmelden. Nur erscheint beim anklicken einer RemoteApp diese Fehlermeldung:
http://i62.tinypic.com/2d766ba.png
Wenn ich auf Ja klicke, dann öffnet sich das Programm Paint.
Szenario 2:
Wenn ich den FQDN ändere. Also den Power Shell Befehl ./Set-RDPublishedName.ps1 "remote.xxx.com" ausführe, dann sieht es wie folgt aus:
http://i61.tinypic.com/mb4ops.png
Hat jemand eine Idee was ich hier noch machen könnte?
Ich hätte gern, dass alles von extern mit dem GoDaddy Zertifikat abgesichert ist, obwohl mein RDS Rechner auf .local endet. Und die Zertifikatmeldungen sollen ausbleiben.
Anbei der aktuelle Stand:
Ich habe nun den Powershell Befehl für den "Redirect to an alternative Name" ausgeführt.
Set-RDSessionCollectionConfiguration –CollectionName QuickSessionCollection -CustomRdpProperty "use redirection server name:i:1 `n alternate full address:s:remote.xxx.com"
Ich denke der Befehl ging durch. Er spring in der PowerShell einfach in die nächste Zeile.
Wie oben beschrieben habe ich einen einzelnen RDS 2012 Server in einer .local Domäne(srv1.xxx.local). Auf diesem sind alle Rollen für das RDS installiert. Diesen möchte ich extern(remote.xxx.com) mit einem godaddy Zertifikat zugänglich machen. Das remote.xxx.com Zertifikat habe ich auf allen Rollen installiert.
Ich habe nun folgende zwei Szenarien:
Szenario 1
Wenn ich den FQDN unverändert lasse. Also den Power Shell Befehl ./Set-RDPublishedName.ps1 "remote.xxx.com" NICHT ausführe, dann kann ich mich ohne Probleme von extern via WebBrowser anmelden. Nur erscheint beim anklicken einer RemoteApp diese Fehlermeldung:
http://i62.tinypic.com/2d766ba.png
Wenn ich auf Ja klicke, dann öffnet sich das Programm Paint.
Szenario 2:
Wenn ich den FQDN ändere. Also den Power Shell Befehl ./Set-RDPublishedName.ps1 "remote.xxx.com" ausführe, dann sieht es wie folgt aus:
http://i61.tinypic.com/mb4ops.png
Hat jemand eine Idee was ich hier noch machen könnte?
Ich hätte gern, dass alles von extern mit dem GoDaddy Zertifikat abgesichert ist, obwohl mein RDS Rechner auf .local endet. Und die Zertifikatmeldungen sollen ausbleiben.
