none
RDP certifikát

    Dotaz

  • Zdravím,

     narazil jsem na problém u SBS(a server Foundation) s RDP, nejde pravděpodobně o vlastnost SBS, ale obecně nastavení certifikátů pro RDP. Odeslal jsem dotaz na US forum, ale zatím nikdo nepřišel s řešením/vysvětlením, tak se třeba někdo najde tady :-)

     Jde o to, že při nastavení SBS(resp. nastavení TS/RDS Gateway) se při připojování klienta objeví hláška, že certifikát nelze ověřit, což je v pořádku, jelikož se jedná o self-signed certifikát, který si pro RDP vystavil počítač sám. V případě, že bych chtěl aby byl důvěryhodný certifikát nejen TS Gateway, ale i samotného stroje, tak ho buď mohu importovat do Trusted CAs na klientovi nebo vystavit certifikát pomocí interní CA, což se mi nepodařilo korektně nastavit.

     Pokud vystavím certifikát interní CA dle návodů na internetu(tj. duplikace computer template, modifikace extensions pro RDP only), tak klient tvrdí, že tento Extension nezná a navíc: " revocation check could not be performed". Domníval jsem se, že je to chybným nastavením template, takže jsem jako extension dal Server Auth., která je přítomná i self-signed certifikátu a zkoušel jsem i zaškrtnout "do not include revocation info", ale to také nepomohlo. Na vnitřní síti, kde je dostupná CA, tak připojení proběhne bez problémů, ale při připojení zvenku se stále objevuje hláška " revocation check could not be performed", což je v zásadě správně, jelikož AIA není dostupná, OCSP nepoužívám a CDP nejsou v certifikátu ani obsaženy. Lze nějak donutit klienta aby se nepokoušel o zjištění platnosti certifikátu? Popř. jak se tato situace řeší? Lepší by bylo tuto možnost obsáhnout rovnou v certifikátu, jelikož nastavení klienta nemusí být vždy snadné. Díky za odpověď.

    B.


    sfs

    pondělí 27. srpna 2012 9:21

Odpovědi

  • Velmi spatne. CRL v RDP je peklo :(

    Podle nekterych zdroju muzete:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Terminal Server Client\ a HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server Client\ pridat DWORD CertChainRevocationCheck a nastavit na 0 (nulu)

    v HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\ pridat DWORD UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors a nastavit na 1

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\SstpSvc\Parameters pridat/nastavit DWORD NoCertRevocationCheck a nastavit na 1

    Vsechno tohle jsem delal a vysledek byl stejne tristni. Nakonec jsem to vzdal. Vyresil jsem distribuci CRL na nejaky verejny zdroj (napr. firemni WEB server) = je treba nastavit interni CA a pak vygeneroval RDP certififikat znovu, aby obsahoval spravne umisteni CRL, CRL pak na to spravne jmeno dat, aby byl platny.

    !! A pozor na delta CRL, ktere obsahuji znak +, ktery IIS7 defualtne nepovoluje http://blogs.technet.com/b/pki/archive/2008/02/25/how-to-avoid-delta-crl-download-errors-on-windows-server-2008-with-iis7.aspx

    A kdyz jsem si jen hral a chtel mit pokoj, vygeneroval jsem si CRL s platnosti 10 let. A je pokoj :) Neni to uplne korektni, nicmene je to v podstate stejne, jako mit CRL kontrolu vypnutou - a navic nemusim nikde nic nastavovat.



    • Upravený Miroslav Tiser pondělí 27. srpna 2012 11:32
    • Označen jako odpověď fandango71 pondělí 27. srpna 2012 12:46
    pondělí 27. srpna 2012 11:29

Všechny reakce

  • Dobrý den,

    a není problém v tom že zvenku je jiná adresa severu než zevnitř?

    Pokud ano tak potom potřebujete vystavit certifikát se všemi možnými jmény.


    JCH

    pondělí 27. srpna 2012 9:54
  • Velmi spatne. CRL v RDP je peklo :(

    Podle nekterych zdroju muzete:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Terminal Server Client\ a HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server Client\ pridat DWORD CertChainRevocationCheck a nastavit na 0 (nulu)

    v HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\ pridat DWORD UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors a nastavit na 1

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\SstpSvc\Parameters pridat/nastavit DWORD NoCertRevocationCheck a nastavit na 1

    Vsechno tohle jsem delal a vysledek byl stejne tristni. Nakonec jsem to vzdal. Vyresil jsem distribuci CRL na nejaky verejny zdroj (napr. firemni WEB server) = je treba nastavit interni CA a pak vygeneroval RDP certififikat znovu, aby obsahoval spravne umisteni CRL, CRL pak na to spravne jmeno dat, aby byl platny.

    !! A pozor na delta CRL, ktere obsahuji znak +, ktery IIS7 defualtne nepovoluje http://blogs.technet.com/b/pki/archive/2008/02/25/how-to-avoid-delta-crl-download-errors-on-windows-server-2008-with-iis7.aspx

    A kdyz jsem si jen hral a chtel mit pokoj, vygeneroval jsem si CRL s platnosti 10 let. A je pokoj :) Neni to uplne korektni, nicmene je to v podstate stejne, jako mit CRL kontrolu vypnutou - a navic nemusim nikde nic nastavovat.



    • Upravený Miroslav Tiser pondělí 27. srpna 2012 11:32
    • Označen jako odpověď fandango71 pondělí 27. srpna 2012 12:46
    pondělí 27. srpna 2012 11:29
  • Dobrý den,

     to ne, bavíme se čistě o RDP certifikátu za TS branou.

    B.


    sfs

    pondělí 27. srpna 2012 12:07
  • Diky za odpoved, na + už jsem taky narazil :-), každopádně to vidím tak, že je nejjednodušší je odklepnout hlášku, aby se upozornění už nezobrazovalo, jelikož kvůli jedné hlášce je potřeba mít v zásadě publikované všechny prvky CA vč. CRL/OCSP. Jinak nechápu, proč server rozpozná RDP extension a klient ne, to je také poněkud nedotažené.

    Každopádně díky.

    P.S.: pokud bych otázku položil jinak: Je možnévytvořit ve Win CA takový certifikát, který např. nebude obsahovat žádné informace o AIA a bude to klient brát jako "nikdy se nedívej pro další info o tomto certifikátu a "chainu"" nebo to vůbec nezávisí na informacích v certifikátu, ale pouze na těch regitrech?

    B.


    sfs


    • Upravený fandango71 pondělí 27. srpna 2012 12:55
    pondělí 27. srpna 2012 12:46
  • Pokud se nepletu, je v X.509 certifikaty informaci o CRL povinna = rozumnej "kolonka" CRL. Co v ni je, je na tvurci CA. Je na vuli uzivatele/aplikace, zda informaci  o CRL vyuzije a kontroluje validitu certifikatu i podle CRL (krome datumu, jmena apod).

    Chapu, ze vas to prudi, ale to pak nemusime certifikaty pouzivat, pokud budeme svevolne jejich principy blokovat.

    Udelat CRL funcni neni v principu nijak slozite. Proste v CA nastavte, aby ukladala CRL na nejaky interni souborovy system (server share) a nejakym zpusobem (treba scriptovanym FTP) ho publikujte do verejneho mista. Nic, co by neslo vyresit.

    Teto vasi vete nerozumim: proč server rozpozná RDP extension a klient ne, to je také poněkud nedotažené.

    RDP soubor je podepsany certifikatem terminal serveru, nebo gatewaye. Klient validitu podpisu kontroluje. Co je na tom zvlastniho?



    pondělí 27. srpna 2012 15:01
  • Mate pravdu, ale to uz je spis akademicka debata, o tom jestli v tomto pripade je bezpecnejsi otevrit do Internetu dalsi sluzbu nebo spise nepouzit CRL, navic neni jasne, co hrozi v pripade, ze se klient snazi pripojit jiz na server ve vnitrni siti, kdy uz prosel AA(A) a nebezpeci hrozi spise serveru - tj. bude se na nej pripojovat clovek, který např. včera dostal výpověď, a pak je to o jiných mechanismech. Jinými slovy, je to spíše roubování schemat původně vymyšlených pro něco trochu jiného.

    "...Klient validitu podpisu kontroluje. Co je na tom zvlastniho?"

    Měl jsem na mysli, že klient nepozná policy extension 1.3.6.1.4.1.311.54.1.2(RDP), resp. nedokáže ho přeložit na nějaké "friendly name", resp. tvrdí, že takové použití nezná.


    sfs

    pondělí 27. srpna 2012 17:41
  • Jeste jednou: nemusite pouzivat "moderni" metody zjistovani zneplatneni certifikatu zalozene na specialnich protokolech - ocsp = nemusite otevirat dalsi "vratka" do internetu. Muzete pouzit obycejny firemni WEB server, ktery jiste uz mate. Jen je treba zajistit, aby se tam pravidelne CRL ukladalo/obnovovalo a v certifikatu bylo zapsane spravne URL s umistenim CRL.

    Policy extension 1.3.6.1.4.1.311.54.1.2 je jen TYP certifikatu. Pro RDP podepisovani muzete pouzit BUD standardni typ Server Authentication, NEBO v CA vytvorit specialni typ certifikatu primo pro RDP - tj. 1.3.6.1.4.1.311.54.1.2. Nema nic spolecneho se jmenem.


    úterý 28. srpna 2012 6:47
  • Jasne, uz chapu, nevím proč, domníval jsem se, že jde o vnitřní IIS.

    Co se týká toho typu, tak to je právě ono. Klient mi tvrdil(teď tu hlášku nevím přesně) něco ve smyslu, že extension je neznámý, pokud je tam RDP. Tím friendly name jsem myslel, že v certifikátu je vždy zapsán typ číselně a systém ho přeloží na čitelný, např. "Server Authentication", což se u RDP ale nestane - alespoň ne na Win 7, nebo se pletu? Díky.

    B.


    sfs


    • Upravený fandango71 čtvrtek 30. srpna 2012 10:52
    čtvrtek 30. srpna 2012 10:51
  • Typ OID lze na lokalni stanici zaregistrovat viz http://en-us.sysadmins.lv/Lists/Posts/Post.aspx?List=332991f0%2Dbfed%2D4143%2D9eea%2Df521167d287c&ID=67 - primo v navode zminen prave RDP OID.

    Ale uprimne nevidim duvod, proc pro RDP pouzivat specialni typ oproti standardnimu Server Authentication. IMHO mi to nic navic neprinese.

    pátek 31. srpna 2012 7:05
  • Díky za odkaz, to bylo spíš jen tak pro úplnost, když už to v těch návodech je. Každopádně díky za odpovědi.

    P.S.: CRL povinné není, pouze validity period (http://www.jensign.com/JavaScience/GetTBSCert/index.html)

    B.


    sfs


    • Upravený fandango71 pondělí 3. září 2012 14:37
    pondělí 3. září 2012 14:19