none
[2008] TS RemotApp/Gateway und Windows 7 RRS feed

  • Allgemeine Diskussion

  • Guten Tag,

    ich habe einen SBS2008 Premium, eine Domain remote.firma.tld mit vertrauenswürdigem Zertifikat und einen Windows 2008 Standard Server auf dem die Terminal Services installiert sind und User per TS Gateway und TS RemoteApp über das Internet auf ein Programm zugreifen können. Das funktioniert Grundsätzlich mit XP und Vista auch reibungslos, jedoch gibt es mit Windows 7-Clients ein Problem.

    Und zwar kann bei allen Windows 7-PCs keine Verbindung hergestellt werden, es kommt beim Verbinden die Meldung: "Bei der Remote desktopverbindung ist ein Fehler aufgetreten. da der Remotecomputer nicht authentifiziert werden kann.". Als Zertifikatname steht der FQDN des TerminalServers (also nicht die die von außen ereichbare Adresse) und bei Zertifikatfehler steht das dieser Fehler aufgetreten ist: "Das Zertifikat stammt nicht von einer vertrauenswürdigen Zertifizierungsstelle."

    Das Problem besteht auch weiterhin, wenn ich das Zertifikat anzeigen und im Zertifikatspeicher installieren lasse.

    Irgendetwas muss sich also mit Windows 7 geändert haben, die Frage ist wie stelle ich das auf Vista/XP-Niveau? :)


    Besten Dank und Grüße,
    Michael

     

    Mittwoch, 2. Juni 2010 09:33

Alle Antworten

  • Hi,

    Am 02.06.2010 11:33, schrieb mhedv:
    [...] Das Problem besteht auch weiterhin, wenn ich das Zertifikat
    > anzeigen und im Zertifikatspeicher installieren lasse.

    Wenn du das bei eingeschaltetem UAC machst, wird das wahrscheinlich
    nichts werden.

    Bester Weg bei eigenen Zertifikaten:
    - grundsätzlich in die Vertrauenswürdigen StammZerts des COMPUTERS
       integrieren
    - per GPO
       CompKonf\Win-.Einst\Lokale Sirili\Richtlinien Öffentlicher Schlüssel
       -> Import *.cer Datei

    Tschö
    Mark
    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:    www.gruppenrichtlinien.de - deutsch
    Discuss :    www.freelists.org/list/gpupdate
    Mittwoch, 2. Juni 2010 11:08
  • Hi Michael,
     
    > ich habe einen SBS2008 Premium, eine Domain remote.firma.tld mit
    > vertrauenswürdigem
    > Zertifikat und einen Windows 2008 Standard Server auf dem die Terminal
    > Services
    > installiert sind und User per TS Gateway und TS RemoteApp über das
    > Internet auf ein
    > Programm zugreifen können. Das funktioniert Grundsätzlich mit XP und Vista
    > auch
    > reibungslos, jedoch gibt es mit Windows 7-Clients ein Problem.
    >
    > Und zwar kann bei allen Windows 7-PCs keine Verbindung hergestellt werden,
    > es kommt
    > beim Verbinden die Meldung: "Bei der Remote desktopverbindung ist ein
    > Fehler aufgetreten.
    > da der Remotecomputer nicht authentifiziert werden kann.". Als
    > Zertifikatname steht der FQDN
    > des TerminalServers (also nicht die die von außen ereichbare Adresse) und
    > bei Zertifikatfehler
    > steht das dieser Fehler aufgetreten ist: "Das Zertifikat stammt nicht von
    > einer vertrauenswürdigen
    > Zertifizierungsstelle."
    >
    > Das Problem besteht auch weiterhin, wenn ich das Zertifikat anzeigen und
    > im Zertifikatspeicher
    > installieren lasse.
    >
    > Irgendetwas muss sich also mit Windows 7 geändert haben, die Frage ist wie
    > stelle ich das auf
    > Vista/XP-Niveau? :)
     
    mehrere Probleme die Dich hier vermutlich treffen:
     
    1. Das TS-Zertifikat wird ein Leaf- und kein Root-Zertifikat sein, deswegen
    musst Du das ROOT-Zertifikat (hier: zu 99,99999% das SBS 2008 CA-Cert - s.
    *) als vertrauenswürdig dem (externen) Client hinzufügen
    2. Windows 7 Fehlverhalten bei CRL-Abfragen (s.
    http://www.msxfaq.net/signcrypt/crl.htm -> CRL und RDP 7)
    3. Erhöhte Sicherheit des Windows Server 2008 für neuere Clients (RDP 6.1)
     
     
    Abhilfe:
     
    Entweder: Schalte die erhöhte Sicherheit auf dem Windows Server 2008
    Terminal Dienst ab:
     
    -> Server Manager <TerminalServerName>
    -> Roles
    -> Terminal Services
    -> Terminal Services Configuration: <TerminalServerName>
    -> Connections
    -> RDP-Tcp (Microsoft RDP 6.1)
    -> Properties
    -> Security Layer
    -> RDP Security Layer
     
    Oder: Generiere entweder ein self-signed Certificate mittels dem lokalen (!)
    Wizzard der Windows Server 2008 Terminal Dienste (ein Zertifikat der SBS
    2008 CA wird wegen einer fehlerhaften CRL Implementation seitens des
    RDP-Client 7.0 von extern NICHT befriedigend funktionieren, ausser man
    installiert die Web-Komponente der CA auf dem SBS und "manipuliert" die
    Cert-Extentions (Stichwort: CDP and AIA for HTTP only) - s.a.:
    http://www.msxfaq.net/signcrypt/crl.htm -> CRL und RDP 7) und verteile
    dieses als vertrauenswürdiges Stammzertifikat an interne und externe Clients
    bzw. kaufe ein passendes Zertifikat für die Windows Server 2008 Terminal
    Dienste Serverauthentifizierung (hier: Servername des Windows Server 2008
    Terminal Servers) zum Aktivieren des RDP Security Layer "SSL (TLS 1.0)".
     
     
    * When should I distribute the self-signed certificate to clients?
    Once the Windows Small Business Server 2008 server is configured the root
    certificate can be distributed. All domain clients require the self-signed
    certificate in order to connect to the network. Domain-joined machines will
    trust the self-signed certificate automatically. For remote clients or
    mobile devices, you must distribute the self-signed certificate to them
    using the certificate installation package
    [\\SBS2008\Public\Downloads\Install Certificate Package.zip] or manually
    install the certificate on computers or devices.
    Source: http://technet.microsoft.com/en-us/sbs/cc817589.aspx
     
     
    --
    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net
     
     
     
    Mittwoch, 2. Juni 2010 11:51
  • Hallo Tobias,

    zu 1.: Habe ich erledigt.
    zu 2.: Okay, aber ändern muss ja hier nichts?
    zu 3.: Ich habe versucht ein selfsigned certificate zu erstellen und zu importieren. Habe das nach dieser Anleitung gemacht http://www.netometer.com/video/tutorials/server-2008-self-signed-certtificate/ hat aber nicht funktioniert. Darauf hin habe ich versucht die erhöhte Sicherheit zu deaktivieren, habe aber den Punkt "RDP Security Layer" nicht gefunden. Unter allgmein habe ich den Haken "Verbindungen nur von Computern zulassen, die Remotedesktop mit Authentifizierung auf Netzwerkebene verwenden", aber das hat auch nicht geholfen.

    Hab ich was falsch gemacht oder liegt das Problem wo anders?

     

    Schöne Grüße,
    Michael

    Mittwoch, 2. Juni 2010 14:10
  • Hi Michael,
     
    >> 1. Das TS-Zertifikat wird ein Leaf- und kein Root-Zertifikat sein,
    >> deswegen musst Du das
    >> ROOT-Zertifikat (hier: zu 99,99999% das SBS 2008 CA-Cert - s. *) als
    >> vertrauenswürdig
    >> dem (externen) Client hinzufügen
    [..]
    > zu 1.: Habe ich erledigt.
     
    D.h.? Leaf oder Root oder welches Zertifikat vom welchen Austeller mit
    welchen Werten verwendest Du überhaupt?
     
    Mit welcher URL greifst Du mit welchen RDP-Client bei welchen Einstellungen
    zu?
     
     
    >> 2. Windows 7 Fehlverhalten bei CRL-Abfragen (s.
    >> http://www.msxfaq.net/signcrypt/crl.htm
    >> -> CRL und RDP 7)
    [..]
    > zu 2.: Okay, aber ändern muss ja hier nichts?
     
    Solange Du ein Root-Zertifikat einer internen CA verwendest, welches von
    extern mittels Windows 7 auf die CRL-Liste abgefragt wird (Voraussetzung:
    Sicherheitsstufe SSL (TLS 1.0)), wirst Du in diesen Fehler laufen
     
     
    >> 3. Erhöhte Sicherheit des Windows Server 2008 für neuere Clients (RDP
    >> 6.1)
    [..]
    > zu 3.: Ich habe versucht ein selfsigned certificate zu erstellen und zu
    > importieren. Habe das nach
    > dieser Anleitung gemacht
    > http://www.netometer.com/video/tutorials/server-2008-self-signed-certtificate/
    > hat aber nicht funktioniert.
     
    Hierbei geht es ja auch um Webzertifikate und nicht um Zertifikate für die
    Serverauthentifizierung.
     
     
    > Darauf hin habe ich versucht die erhöhte Sicherheit zu deaktivieren,
    > habe aber den Punkt "RDP Security Layer" nicht gefunden. Unter allgmein
    > habe ich den Haken
    > "Verbindungen nur von Computern zulassen, die Remotedesktop mit
    > Authentifizierung auf
    > Netzwerkebene verwenden", aber das hat auch nicht geholfen.
    >
    > Hab ich was falsch gemacht oder liegt das Problem wo anders?
     
    Hier noch einmal in Deutsch:
     
    -> Server Manager <TerminalServerName>
    -> Rollen
    -> Terminaldienste
    -> Terminaldienstekonfiguration: <TerminalServerName>
    -> Verbindungen
    -> RDP-Tcp (Microsoft RDP 6.1)
    -> Eigenschaften
    -> Reiter Allgemein
    -> Abschnitt Sicherheit
    -> Sicherheitsstufe. (RDP-Sicherheitstufe | Verhandeln | SSL (TLS 1.0))
    -> RDP-Sicherheitstufe
     
    "RDP-Sicherheitstufe" bedeutet: Die Kommunikation zwischen Server und Client
    verwendet systemeigene RDP-Verschlüsselung [ohne Verwendung von
    Zertifikaten]
     
    "Verhandeln" bedeutet: Die sicherste vom Client unterstütze Stufe wird
    verwendet. Sofern unterstützt, wird "SSL (TLS 1.0)" verwendet [z.B. bei
    Windows 7 bzw. RDP-Client 6.1]
     
    "SSL (TLS 1.0)" wird für die Serverauthentifizierung und für die
    Verschlüsselung aller Daten, die zwischen Server und Client übertragen
    werden, verwendet [dazu werden SSL-Zertifikate verwendet die vom Client auf
    Gültigkeit hin überprüft werden]
     
     
    --
    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net
     
     
     
    Mittwoch, 2. Juni 2010 14:51
  • Hi Tobias,

     

    zu 1.: Bei den RDP-Tcp-Eigenschaften steht "Zertifikat: Automatisch erstellt", also wohl Root-Zertifikat, welches ich mit dem Install Certificate Package hinzugefügt habe.

    zu 2.: Dann wird das ja mit der stärkeren Sicherheit nie funktionieren, da man diese Überprüfung für den Remotedesktop scheinbar nicht abschalten kann?

    zu 3.: Wenn ich RDP-Sicherheitsstufe verwende bekomme ich diesen Fehler biem Verbinden: http://img405.imageshack.us/i/fehlersn.png/

    Montag, 7. Juni 2010 08:23
  • Hi Michael,
     
    > zu 1.: Bei den RDP-Tcp-Eigenschaften steht "Zertifikat: Automatisch
    > erstellt", also wohl Root-Zertifikat, welches ich mit dem Install
    > Certificate Package hinzugefügt habe.
    >
    > zu 2.: Dann wird das ja mit der stärkeren Sicherheit nie funktionieren, da
    > man diese Überprüfung für den Remotedesktop scheinbar nicht abschalten
    > kann?
    >
    > zu 3.: Wenn ich RDP-Sicherheitsstufe verwende bekomme ich diesen Fehler
    > biem Verbinden: http://img405.imageshack.us/i/fehlersn.png/
     
    ich bitte Dich mit einem Experten Deiner Wahl in Verbindung zu setzen, da
    Deine Fragen/Antworten (nicht persönlich nehmen) ein Fehlen des benötigten
    Hintergrundwissen erahnen lassen und dieses nicht im Rahmen eines Threads
    erörtert werden kann.
     
    --
    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net
     
     
     
    Dienstag, 8. Juni 2010 08:26
  • Hallo Michael,

     

    Ich hatte das gleiche Problem und konnte die Lösung ausfindig machen:

    Falls man ein selbstsigniertes Zertifikat verwendet, muss man unter windows 7 eine Anpassung vornehmen, sonst erlaubt es eine rdc über ssl nicht.
    Gruppenrichtlinie bearbeiten -> gpedit.msc
    Nun unter Computerkonfiguration/Administrative Vorlagen/Windows-Komponenten/Remotedesktopdienste/Remotedesktopverbindungs-Client
    
    Den Punkt "Serverauthentifizierung für Client konfigurieren" bearbeiten.
    Und da dann "Aktiviert" anwählen und unter "optionen" entweder "Immer verbinden, auch wenn Authentifizierung fehlschlägt" oder "Warnung anzeigen, falls Authentifizierung fehlschlägt" auswählen.
    
    Nun kann man auch mit windows7 über rdc ssl auf den TS-Gateway zugreifen.

     

    MfG

     

    maulbongo

     

     

    Dienstag, 8. Februar 2011 15:43
  • Moin,

    Am 08.02.2011 16:43, schrieb maulbongo:

    Nun unter Computerkonfiguration/Administrative
    Vorlagen/Windows-Komponenten/Remotedesktopdienste/Remotedesktopverbindungs-Client
     Den Punkt "Serverauthentifizierung für Client konfigurieren
    bearbeiten.

    Wenn das SelfSigned SSL Zertifikat in die Vertrauenswürdigen Stammzerts
    aufgenommen wurde (am besten per GPO) dann ist dieser Schritt auf keinen
    Fall notwendig.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:    www.gruppenrichtlinien.de - deutsch
    GPO Tool:    www.reg2xml.com - Registry Export File Converter
    NNTP Bridge: http://communitybridge.codeplex.com/releases

    Dienstag, 8. Februar 2011 21:05
  • Doch ist es.

    Und hier auch die Erläuterung:

    Ich habe hier folgende Konstellation:

    Ein W2008 TS mit TS-Gateway Konfiguriert, hiermit auch das Zertifikat erstellt.

    Nun Starte ich eine erstellte Remotapp und es kommt zuerst diese Meldung (dies ist das Zertifikat des TS-Gateways):

    http://img152.imageshack.us/f/tsgateway01.png/

    Nun speicher ich das Zertifikat erstmal auf dem Desktop um es anschließend zu installieren.

    Dann installiere ich es:

    http://img39.imageshack.us/f/tsgateway03.png/

    Natürlich unter "Vertrauenswürde Stammzertifizierungsstellen"

    http://img714.imageshack.us/f/tsgateway04.png/

    Nun kann ich mich Verbinden:

    http://img812.imageshack.us/f/tsgateway05.png/

    Nun kommt diese Meldung (dies ist das Zertifikat des Servers):

    http://img831.imageshack.us/f/tsgateway06.png/

    Das installiere ich auch und auch unter "Vertrauenswürde Stammzertifizierungsstellen"

    Verbinde ich anschließend erneut kommt wieder diese Meldung und zwar jedesmal, es sei denn ich bearbeite die Richtlinie.

    http://img41.imageshack.us/f/tsgateway07.png/

    Nun kann ich mich auf dem Server anmelden:

    http://img62.imageshack.us/f/tsgateway08.png/

     

    Dies ist eine Hilfe für alle, die eben keine Vertrauenswürdige Zertifizierungsstellen haben, es nicht mit ADS erstellen wollen und auch kein Geld für ein Zertifikat ausgeben wollen.

    Das vom TS-Server erstellte Zertifikat soll bei mir nur für die Verschlüsselung sorgen (was ja dann auch prima funktioniert), deshalb ist unter Win7 eben dieser Eingriff von Nöten.

    Mittwoch, 9. Februar 2011 07:38
  • Hi,

    Am 09.02.2011 08:38, schrieb maulbongo:

    Doch ist es.

    Nö, ist es nicht.

    Und hier auch die Erläuterung: Dann installiere ich es:

    Wenn du es als Benutzer isntallierst, landet es in den
    Vertrauenswürdigen Zertifikaten des Zertifikatsspeichers des
    Benutzers. Es muss aber in den des Computers und das geht nicht
    "per Klick Installation"

    Entweder per MMC -> Zertifikate -> Computer -> import
    Oder über GPO -> ComkKonf\Sicherheit\Richtlinien Öffentliche Schlüssel

    Dies ist eine Hilfe für alle, die eben keine Vertrauenswürdige
    Zertifizierungsstellen haben, es nicht mit ADS erstellen wollen

    Da liegst du leider flasch, deine Beobachtung ist richtig, aber deine
    Schlüsse daraus nicht. Der Grund warum die AD intigrierte CA direkt
    funktioniert ist, weil sie automatisch im ZertStore des Computers
    landet und nicht im BenutzerStore.

    Ehrlich kein Scherz, ich habe schon x-hundert SelfSigned SSL
    Zertifikate an Computer verteilt und genutzt. Landen sie im
    "Vertrauenswürdige Stammzertifizierungsspeicher" des Computers
    ist alles in Butter.

    Als Benutzer kommt noch eine weitere Sauerei hinzu:
    Mit UAC und IE ProtectedMode, werden die Zertifikat niemals gespeichert,
    auch, wenn der Wizard keinen Fehler meldet ...

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:    www.gruppenrichtlinien.de - deutsch
    GPO Tool:    www.reg2xml.com - Registry Export File Converter
    NNTP Bridge: http://communitybridge.codeplex.com/releases

    Mittwoch, 9. Februar 2011 23:21
  • Hi Mark,
     
    > Da liegst du leider flasch, deine Beobachtung ist richtig, aber deine
    > Schlüsse daraus nicht. Der Grund warum die AD intigrierte CA direkt
    > funktioniert ist, weil sie automatisch im ZertStore des Computers
    > landet und nicht im BenutzerStore.
    >
    > Ehrlich kein Scherz, ich habe schon x-hundert SelfSigned SSL
    > Zertifikate an Computer verteilt und genutzt. Landen sie im
    > "Vertrauenswürdige Stammzertifizierungsspeicher" des Computers
    > ist alles in Butter.
     
    nein, da muss ich Dir leider wiedersprechen.
     
    Es gibt ein "Bug" seitens Windows 7, bei dem Zertifikate, die mit einer
    Unternehmens-CA ausgestellt und NICHT in dem Eintrag der
    Certificate-Revoke-List (CRL) als ersten einen HTTP, sondern wie üblich ein
    LDAP-Eintrag stehen haben, Windows 7 in den Standardeinstellungen (s.u.)
    diesen Eintrag solange abfragt, bis entweder ein Ergebnis oder der Timeout
    kommt. Der HTTP-Abfrage wird somit gar nicht berücksichtig.
     
    Das ist für Windows 7 Client, die direkt an der Domäne angebunden und via
    LDAP auf den DC und CA Zugriff haben, kein Problem.
     
    Ein Problem ist es jedoch, wenn diese Windows 7 Clients extern (z.B. über
    ein TS/RD-Gateway) UND keine Verbindung zum eigentlichen LDAP-Verzeichnis
    haben.
     
    Dann verwirft, mit den Standard-Einstellungen von TS/RD Windows Server 2008:
     
    -> Terminaldienstekonfiguration (respektive: Konfiguration des
    Remotedesktop-Sitzungshosts)
    -> Verbindungen
    -> RDP-Tcp
    -> Eigenschaften
    -> Allgemein
    -> Sicherheitsstufe Verhandeln (<- Bei RDP-Clients ab v7 heisst das default
    SSL TLS 1.0)
     
    und Windows 7:
     
    -> Internetoptionen
    -> Erweitert
    -> Sicherheit
    -> Auf gesperrte Zertifikate überprüfen
     
    der Windows 7 RDP-Client die Zertifikatsanfrage und quittiert mit
    beschriebener Fehlermeldung den Zugriff.
     
    Witzigerweise fehlt bei direkt auf dem TS/RD-Server mittels
    Terminaldienstekonfiguration-Console ausgestellten bzw. mittels selfcert
    generierten Zertifikaten der CRL-Eintrag - Windows 7 kann gar nicht nach
    CRL-Listen abfragen - und lässt diese Art von Zertifikaten (wie wie von Dir
    richtigerweise beschrieben vorab erst als Vertrauenswürdige
    Stammzertifikate - Root === Leaf - hinzugefügt) ungefragt als gültig
    passieren.
     
    Deswegen hattest Du vermutlich noch nie das Problem damit.. ;)
     
    Frank Carius, ich u.a. schon:
     
    http://www.msxfaq.de/signcrypt/crl.htm
    -> CRL und RDP 7
     
    Ein Workaround wäre z.B. im Template der austellenden CA HTTP (Stichwort:
    Split-DNS) als erstes (und/oder einziges) in der CRL-List eintragen zu
    lassen, sich ein öffentliches Zertifikats von einem großen Anbieter zu
    bedienen oder folgende (unsichere) Einstellung:
     
    -> Terminaldienstekonfiguration (respektive:
    Remotedesktop-Sitzungshostkonfiguration)
    -> Verbindungen
    -> RDP-Tcp
    -> Eigenschaften
    -> Allgemein
    -> Sicherheitsstufe RDP-Sicherheitsstufe
     
    --
    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net
     
     
    Donnerstag, 10. Februar 2011 10:35
  • Hallo Tobias,

     

    Danke für deine ausführliche Antwort, die Infos über den Bug habe ich zwischenzeitlich auch gefunden.

    Ich habe es auch mit dem Hinzufügen über mmc getestet und dies funktioniert auch global.

    Nur gibt es damit natürlich auch ein Problem ;)

    Unsere User haben natürlich in der Domain keine Adminrechte und können somit die Zertifikate auch nicht über mmc einbinden.

    Da die Zertifikate ja ca. alle halbe Jahr neu erstellt werden ist es nicht so vorteilhaft, denn unsere Außendienstmitarbeiter sind dann natürlich auch weltweit unterwegs und eine administrative Einbindung der Zertifikate ist dadurch nicht machbar.

    Das "gewöhnliche" Importieren der Zertifikate beherschen unsere Außendienstmitarbeiter und mit WindowsXP war das ja auch nie problematisch.

    Durch die Umstellung auf Windows7 ist dies nun natürlich problematisch, aber immerhin kann man meine Vorgehensweise ja als Workaround nutzen.

    Oder hat jemand noch ein anderes Workaround? Gibt es da schon ein Bugreport seitens Microsoft? Ist es absehbar, wann dies wieder gewohnt nutzbar ist?

    Donnerstag, 10. Februar 2011 10:58
  • Hi <realname please>
     
    Vorab: Es gehört weiterhin zum guten Ton, sich mit Namen vorzustellen.
     
     
    > Oder hat jemand noch ein anderes Workaround?
     
    Jepp: 5 Jahres SSL-Zertifikat von z.B. godaddy.com für ca. 30,- EUR pro Jahr
     
    --
    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net
     
     
     
    Donnerstag, 10. Februar 2011 11:31
  • Hi,

    Am 10.02.2011 11:58, schrieb maulbongo:

    denn unsere Außendienstmitarbeiter sind dann natürlich auch weltweit
    unterwegs und eine administrative Einbindung der Zertifikate ist
    dadurch nicht machbar.

    Nur des Interesses wegen, sind sie denn niemals per VPN mit euch
    verbunden? Die GPO kommt auch im Hintergrund bei Verbindungsherstellung.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:    www.gruppenrichtlinien.de - deutsch
    GPO Tool:    www.reg2xml.com - Registry Export File Converter
    NNTP Bridge: http://communitybridge.codeplex.com/releases

    Donnerstag, 10. Februar 2011 20:12
  • Hi Tobias,

    Am 10.02.2011 11:35, schrieb Tobias Redelberger [MVP - SBS]:

    nein, da muss ich Dir leider wiedersprechen.

    Das ist ja nett, daß Win7 ein Problem mit den MS eigenen Zertifikaten
    hat, was nur bestätigt, daß die MS Zertifkatsgeschichte in keinsterweise
    konsequent durchdacht ist.

    Zeig mir ein einziges SSL Zertifikat, daß mit OpenSSL oder auch
    mit der simplen selfssl.exe aus dem IIS ResKit erstellt wurde, daß
    dieses Problem hat, CACert geht übrigens auch, du wirst keins finden.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:    www.gruppenrichtlinien.de - deutsch
    GPO Tool:    www.reg2xml.com - Registry Export File Converter
    NNTP Bridge: http://communitybridge.codeplex.com/releases

    Donnerstag, 10. Februar 2011 20:19
  • Moin,

    Am 10.02.2011 11:35, schrieb Tobias Redelberger [MVP - SBS]:

    nein, da muss ich Dir leider wiedersprechen.

    Nur, um da noch einmal "nachzutreten":
    Der Bug von Win7 jat irgendwie garnichts mit dem Problem zu
    tun, um das es geht. Der Rechner meldet ja, das das Zertifikat
    nicht vertrauenswürdig ist und das ist es nicht, weil das
    Zertifikat oder dessen Root nicht im Speicher des Computers liegt.
    Die CRL ist dem System in dem Moment egal, oder die Fehlermeldung
    taugt mal wieder nichts.

    Daß Stammzerts im Benutzerspeicher nicht funktionieren kann ich nicht
    erklären, daß hat einfach die Praxis gezeigt und da der Wizard beim
    Durchklicken/installieren diesen wälht gehts eben nicht.
    Microsoft und Zertifkate besitzen keine druchgängige Logik, das sieht
    mal alleine an den diversen Möglichkeiten die je nach Produktgruppe
    im jeweiligen Werkzeug möglich sind. MS hat das das Konzept nicht
    verstanden, oder vielleicht doch, aber dann nicht umgesetzt.

    Also: Zert pro Computer hinterlegen, dött.

    Die Lösung von maulbongo halte ich für unglücklich, oder sogar
    gefährlich, denn sie unterdrückt ja nur die Sicherheitswarnung,
    aber löst nicht sie Vertrauensproblematik.
    Ich würde ungern jedem Vertrauen, nur weil ich keine Fehlermeldung
    sehe.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:    www.gruppenrichtlinien.de - deutsch
    GPO Tool:    www.reg2xml.com - Registry Export File Converter
    NNTP Bridge: http://communitybridge.codeplex.com/releases

    Freitag, 11. Februar 2011 08:57
  • Die Lösung von maulbongo halte ich für unglücklich, oder sogar
    gefährlich, denn sie unterdrückt ja nur die Sicherheitswarnung,
    aber löst nicht sie Vertrauensproblematik.
    Ich würde ungern jedem Vertrauen, nur weil ich keine Fehlermeldung
    sehe.

    Ich denke für ein Gateway kann es nur eine Lösung geben.
    Und zwar die, dass die Authentifizierung funktionieren MUSS.

    Alles andere wäre grob fahrlässig (auch wenn z.B. noch ein NAP-Policy hinterlegt ist).

    Wird die Verbindung dann überhaupt in irgendeiner Weise verschlüsselt, wenn die Authentifizierung fehlschlägt?
    (meiner Logik nach nicht).

    Freitag, 11. Februar 2011 09:28
  • Hi Mark,
     
    > Zeig mir ein einziges SSL Zertifikat, daß mit OpenSSL oder auch
    > mit der simplen selfssl.exe aus dem IIS ResKit erstellt wurde, daß
    > dieses Problem hat, CACert geht übrigens auch, du wirst keins finden.
     
    Die von Dir verwendeten (Workaround-)Tools lassen einfach den CRL-Eintrag im
    Zertifikat weg, da ja keine CA-Infrastruktur dahinter steckt, welche eine
    CRL anbieten könnte (s.a. http://www.ietf.org/rfc/rfc3280.txt - Page 7 and
    11ff )
     
    Nichts desto trotz sollte ein X.509v3 Zertifikat auch einen CRL-Eintrag nach
    X.509v2 besitzen, da sonst nicht gewährleistet werden kann, das auch das
    Zertifikat vor Ablauf im eigentlichen Gültigkeitszeitraum von der
    austellenden CA zurückgezogen werden kann.
     
    --
    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net
     
     
     
    Freitag, 11. Februar 2011 12:41
  • Hi,

    Am 11.02.2011 13:41, schrieb Tobias Redelberger [MVP - SBS]:

    Die von Dir verwendeten (Workaround-)Tools lassen einfach den CRL-Eintrag im
    Zertifikat weg,

    Ich sag ja, ein MS Problem.
    CACert verwendet einen OCSP Eintrag, tuts.

    Den Streit CRL vs. OCSP möchte ich jetzt nicht führen, da ich die CRL
    weniger relevant einschätze, als das Thema des grundsätzlichen
    Vertrauens, wenn ICH! für MICH! ein Zertifkat ausstelle, dann gehe ich
    davon aus, das ICH MIR! vertrauen kann.
    Dieses eine einzige Zertifikat werde ich in den nächsten 10 Jahren auch
    nicht widerrufen, sondern simple ersetzen.

    Mit anderen Worten: MS Bug? Druffjeschi**sen.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:    www.gruppenrichtlinien.de - deutsch
    GPO Tool:    www.reg2xml.com - Registry Export File Converter
    NNTP Bridge: http://communitybridge.codeplex.com/releases

    Freitag, 11. Februar 2011 13:47