RDP CRL Check non Domain Clients Win8.1

[henryy 12]

Moin,

 

in einer 2K12R2 RDS Umgebung mit interner CA, gibt es eine Außenstelle die mit Windows 8.1 non Domain Clients über RDP durch ein VPN auf eine RDS Farm zugreifen soll.

 

Das Root Zertifikat, wie auch das durch die interne CA ausgestellte SAN Zertifikat (mit den RDS Namen), wurde in die Clients importiert.

 

Die "normalen" Zertifikatswarnungen sind  verschwunden, bis auf eben dieser nervige "Es konnte keine Sperrprüfung für das Zertifikat durchgeführt werden"

 

Ich kann die zertifikatssperrliste vom Client über HTTP runterladen aber für mich sieht es so aus als wenn diese Prüfung nur über LDAP funktioniert, also auch wenn ich einen non Domänen Testclient im selben LAN habe kommt die Fehlermeldung.

 

Auch das herunterdrehen der Sicherheitsstufe auf den RDS Hosts von SSL/Aushandeln auf "RDP-Sicherheitsstufe", welches in einigen Threads als "Lösung" gebracht wird, hat nichts gebracht

 

Hat jemand eine Idee diese Meldung los zu werden?

[testperson 1.674]

Hi,

 

ist denn ein Sperrlistenverteilpunkt per http eingerichtet (https://support.microsoft.com/en-us/kb/232161)?

 

Gruß

Jan

 

Edit: Link gefixt

bearbeitet 23. April 2015 von testperson

[Dunkelmann 96]

Moin,

 

der Client prüft bzw. versucht die im Zertifikat angegebenen CDP abzufragen. Mindestens ein CDP aus dem Zertifikat muss erreichbar sein.

Können die CDP per DNS aufgelöst werden?

 

Mit 'certutil -verify [rds-cert-datei]' könntest Du mal eine manuelle Prüfung durchführen. Die Prüfung sollte im Benutzerkontext erfolgen.

[henryy 12]

Moin,

 

die Clients sind zu testzwecken im gleichen LAN  wie die Domänen Clients und können über DNS eigentlich auch alles auflösen. Zumindest funktioniert der Aufruf über den IE und download der CRL über http://servername.interne.domäne/CertEnroll/domäne-CA.crl

 

certutil -verify http://servername.interne.domäne/CertEnroll/domäne-CA.crl   führt zu einem Fehler "Die Syntax für den Dateinamen ist falsch"

 

@ jan  dein link führt leider ins MS Nirvana, aber ich habe nachträglich einen sperrlistenverteilpunkt eingerichtet auf der internen CA und ein neues RDP Zertifikat erstellt in dem dann auch diese HTTP Adresse aufgeführt wird. allerdings erst unter der Standard LDAP CRL(welche Non Domänen Clients ja nicht erreichen können). Vielleicht wollen die Clients immer LDAP nutzen bei RDP?? Oder muss ich vielleicht auch noch einmal das Root CA neu erstellen, denn dort ist die CRL über HTTP noch nicht eingetragen

[testperson 1.674]

Hi,

 

ließ dir mal den Abschnitt (evtl. auch den ganzen Artikel) durch: http://www.msxfaq.de/signcrypt/crl.htm#crls_mit_einer_privaten_ca

 

Habe den Link oben übrigens angepasst. Da wurde ")?" aus versehen mit an den Link angehangen.

 

Gruß

Jan

[henryy 12]

Hi

 

@Jan, das ist ein wirklich guter Link zu dem Thema. leider komme ich aber der lösung nicht näher

 

über certutil -URL ...... bekomme ich die Ausgabe wie in dem Bildanhang

 

Sieht für mich erstmal so aus, als wenn der Client die CRL über HTTP abrufen kann. Die Warnung über RDP bleibt trotzdem. Prüft der RDP Client vielleicht immer nur über LDAP?

 

IE Einstellungen sind auch korrekt und im IIS auch der anonyme Zugriff auf die HTTP Seite ist erlaubt

 

Übersehe ich noch etwas oder noch eine Idee?

bearbeitet 23. April 2015 von henryy

[Dunkelmann 96]

Sind Delta CRL im Einsatz? Die müssen natürlich auch verfügbar sein. Beim IIS muss dazu double escaping erlaubt werden (wg. 'crlname+.crl')

[henryy 12]

Hi,

 

Delta Sperrlisten ist in den Eigenschaften der Domäne-CA unter Erweiterungen bei LDAP der haken bei "Deltasperren an diesem Ort veröffentlichen" gesetzt. Bei HTTP kann ich den Haken nicht setzen weil ausgegraut. ??

 

IIS Double escaping hatte ich schon erlaubt.

 

Vorübergehende "Lösung": In den Einstellungen des RDP 8.0 Clients unter Erweitert-Serverauthentifizierung den Schalter auf "verbinden und keine Warnung anzeigen" lässt die Zertifikatswarnung nicht mehr aufpoppen, aber glücklich bin ich damit nicht

bearbeitet 23. April 2015 von henryy

[Dunkelmann 96]

Hi,

 

Delta Sperrlisten ist in den Eigenschaften der Domäne-CA unter Erweiterungen bei LDAP der haken bei "Deltasperren an diesem Ort veröffentlichen" gesetzt. Bei HTTP kann ich den Haken nicht setzen weil ausgegraut. ??

Das ist völlig normal. Die Sperrliste wird den Teilnehmern über den Webserver bereitgestellt, aber von der CA im Dateisystem veröffentlicht.

 

Die Option 'Sperrliste an diesem Ort veröffentlichen' gibt an, wohin die CA die *.crl Dateien schreibt.

Die Option 'In CDP Erweiterung ...' gibt an, wo sich die Teilnehmer die Sperrliste holen können.

Die beiden müssen nicht zwangsläufig übereinstimmen. Es ist nicht ungewöhnlich, dass die CA die Sperrliste ins Dateisystem eines Webserver stellt (per CIFS) und die Sperrliste dann vom Teilnehmer über den Webserver (per http) abgerufen wird.

http://blogs.technet.com/b/xdot509/archive/2012/11/26/pki-design-considerations-certificate-revocation-and-crl-publishing-strategies.aspx

[Daniel -MSFT- 129]

Das Root Zertifikat, wie auch das durch die interne CA ausgestellte SAN Zertifikat (mit den RDS Namen), wurde in die Clients importiert.

 

Mal eine blöde Frage: Warum hast DU das SAN-Zertifikat auf den Clients importiert? Doch nicht etwa inklusive privatem Schlüssel? Was spricht dagegen, auf den RDP-Servern offizielle Zertifikate zu verwenden, die die Non-Domain-Clients ohne Zertifikatsimporte überprüfen können?

[henryy 12]

Moin,

 

offizielles Zertifikat scheitert daran, dass die betreffenden non Domain Clients keinen Zugang zum Internet haben und wir eh eine eigene CA nutzen wollten für kommende Projekte.

 

Ich konnte das Problem etwas eingrenzen. Es scheint in Zusammenhang mit der RDS Farm bzw dem RDS SAN Zertifikat aufzutreten. Wenn ich einen RDS Host über seinen srv00... Namen   über RDP vom non Domain Client Aufrufe kommt keine Sperrlisten Warnung.

 

Nehme ich aber den Farm Namen farm.Domäne.de, dann kommt diese Warnung. Obwohl ich ja erst in diesem RDS Farm SAN Zertifikat die Sperrlisten über HTTP erreichbar gemacht habe..??

 

Auch bei anderen Servern(non RDS Hosts) kommt mit einem non Domain Client über RDP keine Sperrlisten Warnung

 

Das erschließt sich mir gerade gar nicht warum das so ist

 

update: über den normalen Server Namen nimmt er ein anderes RDP Zertifikat (RDP Vorlage wird über GPO verteilt und wurde grade erneuert und somit liegt dort auch die Sperrliste über HTTP vor). Liegt wohl an dem SAN Zertifikat...

bearbeitet 24. April 2015 von henryy

[henryy 12]

Moin,

 

update:

 

bei non Domain Clients über gpedit unter WindowsEinstellungen-Sicherheitseinstellungen-Richtlinie für öffentliche Schlüssel-Einstellungen für dir Überprüfung des Zertifikat Pfades gibt es im letzten reiter "Sperrung" den Punkt "längere Gültigkeitsdauer von sperrlisten und OCSP-Antworten zulassen". Wenn  ich diese Richtlinie definiere und einen wert grösser 76 Stunden einstelle dann kommt keine Sperrlisten Warnung mehr.

 

Wenn ich mir die interne CA Sperrliste ansehe dann besitz die eine Gültigkeit von 8 Tagen. Für mich sieht es so aus als wenn das für Windows 8.1 zulange ist....? Allerdings verstehe ich nicht ganz wieso dann bei 76 Stunden keine Warnung mehr kommt, denn meine Sperrliste hat eine Gültigkeit von Montag 27.4 bis Dienstag 5.5, also noch 6 Tage sprich noch ca 144 Stunden. Erwartet hätte ich jetzt das sich das mit den 76 Stunden deckt.

 

2 Stunden später muss man dann von 76 auf 78 stunden im Client ändern um keine Sperrprüfungswarnung zu erhalten. Mir ist nicht klar nach welchem Zeitwert der Client sich da richtet

 

Weiß jemand warum das so ist?

bearbeitet 28. April 2015 von henryy

[Dunkelmann 96]

Ich vermute immer noch ein Problem mit den Delta Sperrlisten. Vielleicht gibt es auch einen (Reverse-)Proxy, der noch eine veraltete Version einer Sperrliste im Cache hat und ausliefert.

 

Öffne mal das MMC Snap In 'pkiview.msc' (Unternehmens PKI)

Da findest Du eine Übersicht der CDP. Die url der CDP lassen sich per Rechtsklick kopieren.

 

Am Besten alle url der Basis und Deltasperrlisten in eine Textdatei kopieren und den Abruf per Browser am Remote Client testen. Wenn alles korrekt funktioniert, wird Dir im Browser der Download der crl-Datei angeboten.

 

Es sollte mindestens ein Satz aus Basis- und Deltasperrliste funktionsfähig sein. Die Basissperrliste enthält einen Verweis auf die Delta CRL und die Delta CRL hat eine Referenz zur Basis CRL.

 

Mit 'certutil -dump [pfad und Name der crl]' kannst Du Dir die relevanten Angaben anschauen.

Z.Bsp Basis CRL:

...
 Diese Aktualisierung: 24.04.2015 09:33
 Nächste Aktualisierung: 04.05.2015 21:33
Einträge der Sperrliste: 6
...
    2.5.29.20: Kennzeichen = 0, Länge = 4
    Sperrlistennummer
        Sperrlistennummer=03 50

    1.3.6.1.4.1.311.21.4: Kennzeichen = 0, Länge = f
    Nächste Sperrlistenveröffentlichung
        Samstag, 2. Mai 2015 09:33:39

    2.5.29.46: Kennzeichen = 0, Länge = 30
    Aktuellste Sperrliste
        [1]Aktuellste Sperrliste
             Name des Verteilungspunktes:
                  Vollst. Name:
                       URL=http:[URL Delta CRL]+.crl
...

In der Delta:

...
 Diese Aktualisierung: 27.04.2015 09:33
 Nächste Aktualisierung: 01.05.2015 09:33
Einträge der Sperrliste: 0
...
    2.5.29.20: Kennzeichen = 0, Länge = 4
    Sperrlistennummer
        Sperrlistennummer=03 53

    1.3.6.1.4.1.311.21.4: Kennzeichen = 0, Länge = f
    Nächste Sperrlistenveröffentlichung
        Mittwoch, 29. April 2015 09:33:44

    2.5.29.27: Kennzeichen = 1(Kritisch), Länge = 4
    Deltasperrlistenanzeige
        Minimale Basissperrlistennummer=03 50
...

bearbeitet 28. April 2015 von Dunkelmann

[henryy 12]

Moin,

 

es sieht wirklich nach einem Problem mit der Delta Sperrliste aus. Die HTTP Delta CRL ist abgelaufen. Mir ist aber nicht klar warum...?

 

Im Anhang ist die abgelaufene Delta und die Sperrlisten "Konfig" zu sehen

bearbeitet 30. April 2015 von henryy

[Dunkelmann 96]

Ist die Delta CRL im Dateisystem unter 'C:\Windows\system32\....' vorhanden?

Wenn ja, nochmal double escaping am IIS für das CertEnroll Verzeichnis prüfen.