Archívum

Archive for the ‘PKI’ Category

CA tanúsítvány igénylése – parancssor

július 22, 2021 Hozzászólás

Rengeteg parancssori eszköz létezik, most a Windowsos beépített eszközök használatáról ejtek pár szót (pontosabban már létező .req file CA-nak való átadása a cikk témája). Már az elején tisztáznám, hogy Enterprise környezetben, tehát sablonokkal fogunk dolgozni, ezért tegyük tisztába a sablon “valódi” és megjelenített nevét (spoiler: ezt a tudást egy következő cikkben is fogjuk használni).

Természetesen grafikus felületen is a sablon-kezelő konzolon meg tudjuk nézni a sablonok nevét (“Template name”) (s itt nem a megjelenített névre (“Template display name”) gondolok!), de erre van lehetőségünk parancssorból is:

certutil -config “server.domain.local\CA-Name” -CATemplates

Ez azért fontos, mert amikor a certreq parancsot használjuk, akkor a sablonnak NE a megjelenített nevét használjuk, hanem a “valós”, valószínűleg a megjelenített név szóközök nélküli változatát.

certreq -submit -attrib “CertificateTemplate:Webserver” RequestFile.req

(Súgó: amennyiben a megjelenített nevet használjuk, akkor sajnos a CA nem pontos hibaüzenettel örvendeztet meg bennünket:

Certificate not issued (Denied) Denied by Policy Module 0x80094800, The request was for a certificate template that is not supported by the Active Directory Certificate Services policy: Web server.

The requested certificate template is not supported by this CA. 0x80094800 (-2146875392 CERTSRV_E_UNSUPPORTED_CERT_TYPE)

Hibakeresésnél természetesen ellenőrizzük, hogy létezik a sablon és jó jogokkal, de utána azt is nézzük meg, hogy milyen névvel hivatkoztunk rá 🙂 )

Kategóriák:PKI Címkék: ,

CA tanúsítvány igénylése – webes felület

április 19, 2021 Hozzászólás

Adott helyen bevezetésre került egy CA-infrastruktúra, létrehoztuk a sablonokat, majd felmerült, hogy miként lehet tanúsítványokat kérni egy adott sablon alapján, ha annak verziója >=3. Ez a kitétel azért fontos, mert felkerült a webes komponens is, így első körben böngészőből szerették volna kezelni.

Mivel ez a téma eddig csak érintve volt (a PKI-sorozatban: Public Key Infrastructure (PKI) 2. rész), megpróbálok pár gondolatot összeírni.

Egyik kolléga régebbi kérdésére szeretném tisztázni, hogy már az alap CA-szolgáltatás telepítésekor létrejön a CertEnroll mappa. Ha telepítjük a webes komponenst, akkor az IIS-ben a Default Web Site alatt is megjelenik, de a nevével ellentétben nem az igénylés célját szolgálja, abba a mappába (ami ráadásul fizikailag alapértelmezetten a CertSrv alatt van) általában a CA tanúsítványa, az alap CRL és a Delta-CRL (ahol a < DeltaCRLAllowed> engedélyezett volta esetén egy “+” jel látszik), illetve egy nsrev_CANév.asp állomány található (ami a Netscape (iPlanet) alkalmazás tanúsítvány-visszavonásához köthető).

Tehát akkor maradjunk a https://szervernév/CertSrv oldalon (alapból nincs 443 porton publikálva!), a “Request a certificate” link után kétféle felület fogadhat bennünket, kezdem az alapesettel:

,

majd az ACR-re történő kattintás után jön elő az alábbi:

vagy egyből az ACR-ben találjuk magunkat.

Ez utóbbi akkor történik, ha az adott felhasználónak nincs (vagy tiltva van) az “Enroll” jogosultság a “User” sablonhoz (akár közvetlenül, akár csoporton keresztül).

Technikailag, a weboldal kódja úgy van felépítve, hogy a “User” sablon elérhetőségétől függően a certrqad.asp vagy certrqus.asp (esetleg certrqxt.asp) oldal töltődjön be (=> URL-szerkesztéssel is be lehet hozni a kért oldalt 🙂 ):

If “Enterprise”=sServerType Then

    If IsUserTemplateAvailable()=False Then

    fShowRQAD = True %>

    <TD><LocID ID=locLblRequestCert><A Href=”certrqad.asp“><Font Face=”Arial”>Request a certificate</Font></A></LocID></TD>

<%    End If

End If

If fShowRQAD=False Then %>

    <TD><LocID ID=locLblRequestCert><A <%If “Text”=sBrowser Then%> Href=”certrqxt.asp” <%Else%> Href=”certrqus.asp” <%End If%>><Font Face=”Arial”>Request a certificate</Font></A><LocID></TD>

<%End If%>

Nézzük akkor tételesen az ACR oldalon található két linket.

A Submit oldalon egyértelmű a történet, egy már meglévő tanúsítvány-igényt tudunk beadni:

De adott helyen az első opció (Create and submit) volt fontos, ahol “lokálisan” tudjuk elkészíteni az igényt (tehát nem már létező req-et nyújtunk be):

Itt szerettek volna tanúsítványt igényelni – ehhez viszont szükséges, hogy megjelenjen a sablon. Ugyanis a bevezetőben említett sablon-verziók a webes részen nem jelennek meg.

Kerülő-megoldásként egyrészt megpróbálhatjuk a rendszert “átverni” – természetesen, mint ahogy a cikk is említi, fokozott figyelemmel és csomó teszteléssel, másrészt más (nem böngésző-alapú) módszert használunk tanúsítvány-igénylésre. Jelen cikk az előbbit járja körül: az “átverésnek” több módja is van, a végeredmény ugyanaz:

  • létrehozunk egy v1 vagy v2 sablont, majd utólag módosítjuk “nagyobbra”
  • egy már létrehozott sablon verzió-értékét írjuk át az AD-ban (mint a cikk teszi)

Nem lehet elégszer hangsúlyozni, hogy ezt tesztelni kell! Sőt, a weboldal bizonyos esetekben nem is töltődik be jól minden böngészőben, néha érdemes IE-t használni (nos igen, itt is látszik, hogy MS kicsit hanyagolja). Ráadásként IE-ben is lehetnek gondok, pl. ez.

Személy szerint van ennél jobban kedvelt igénylési módszerem (a grafikus mmc-konzol használata szinte gyerekjáték, ha tudjuk, hogy milyen tanúsítványt akarunk 🙂 ), de tervezem, hogy egy következő cikkben megnézzük az egyik leggyakrabban használt parancssoros opciót.

Számítógép-tanúsítvány igénylése

december 28, 2020 Hozzászólás

Az utóbbi időben néhány cégnél beüzemelésre került pár tanúsítvány-kiszolgáló. Ezek kapcsán a kollégák feltettek néhány kérdést, amelyek közül kettőt megpróbálok egy-egy cikkben körbejárni.

Kezdjük azzal, hogy telepítés és konfigurálás után szeretnénk, ha minden számítógép kérne a CA-tól egy saját tanúsítványt. Fontos, hogy tudjuk, ha valaha történtek-e változtatások a sablonokon (ezek khm… boríthatnak mindent), hiszen ezek AD-ban kerülnek tárolásra; ezért a továbbiakban alap-telepítés, beállítást feltételezek – ebben kapunk alap v1 és v2 (sőt, egyetlen v3) sablonokat.

A kolléga arra kérdezett rá, hogy számára nem teljesen világos, hogy az alábbi két beállítás esetén melyik mit takar (zárójelben megjegyzés tőlem):

(Computer/User) Configuration\Windows Settings\Security Settings\Public Key Policies \ Certificate Service Client – Auto-enrollment (Windows 2003 idején Autoenrollment Settings)

és

Automatic Certificate Request Settings (“mappa”).

Röviden a későbbiekben CSC-AE és ACR -ként fogok rájuk hivatkozni. S még mielőtt válaszolnék a kérdésre, pár infó, amit érdemes tudni:

  • a tartományvezérlők esetén “hardveresen” bele van kódolva, hogy abban az esetben, ha az erdőbe telepítettünk egy CA-t, automatikusan igényeljenek maguknak egy “Domain Controller” tanúsítványt (természetesen akkor kapják meg, ha ez a sablon – mint alapból – publikálva van). Ez a működés megváltozik, amennyiben engedélyezzük akármelyik GPO-beállítást. Tehát a DC-k esetén nem 2, hanem 3 “módja” létezik: “beégetett”, hagyományos és aktuális.
  • az ACR a hagyományos (régebbi) verzió, nála csak v1-alapú tanúsítványokat lehet kiválasztani. Mivel V1 sablonok esetén nincs AutoEnroll jogosultság, a gépeknek Read és Enroll jogot kell adni – alapból ezek megvannak a (most érintett) két v1 sablonra az illetékes csoportoknak, tehát tartományvezérlők “Domain Controller”, minden más gép “Computer” sablonra jogosultak. V1-sablon alapú tanúsítvány-kiosztás esetén nincs “Superseded” (felülírt) mód, illetve (belegondolva, értelemszerűen) lokálisan nincs ilyen házirend-opció
  • a CSC-AE esetén minimum v2 sablonok játszanak, a két opció magyarázata:
    • Renew expired certificates, update pending certificates, and remove revoked certificates: bepipált állapotban azokat a tanúsítványokat újítja meg, amelyek
      nincsenek beállítva az automatikus regisztrációhoz, például amelyekhez több aláírás szükséges (pl. Enrollment Agent-et igényelnek), vagy amelyeknek a kérésben kell megadni a tanúsítvány tárgyának adatait (pl. webkiszolgálók). Ezenkívül ez a beállítás fogja betölteni a függőben lévő kérelmeket, amelyeket a CA-manager kellett elfogadjon (Figyelem: ha ez nincs bepipálva, s nem töltjük be a kiállított tanúsítványt (akár “manuálisan”), folyamatosan generálja az újabb kéréseket!).
    • Update certificates that use certificate templates: bepipált állapotban AutoEnroll joggal rendelkező sablonok alapján új és megújítási kérelmek jönnek létre a CA-n.
  • a “Superseded” (felülírt) állapot csak CSC-AE és AutoEnroll jogok közös metszetében értelmezendő, alapból a Domain Controller sablont csak Directory Email Replication és a Domain Controller Authentication írja felül, a Kerberos Authenticationokkal – nem!
  • a különböző jogosultságok szabályozzák, hogy mikor milyen tanúsítvány kerül kiosztásra, egy gép akár több tanúsítványt is kaphat egyszerre (s ez igaz a v1 sablon-alapúakra is, ott is tudunk plusz jogokat adni!)
  • egyes MS-cikkek (pl. ez) nem elég pontosak, ez elég lehet ugyanis egy DC esetén (sőt, lásd feljebb, még ez sem kell), de egy munkaállomáshoz nem

S akkor a válasz: mindkettő jó, ésszel használva, a CA beüzemelése után az alábbi lépések szükségesek:

  • hagyományos verzió:
    • felvesszük az ACR-be a kiosztandó sablon(oka)t
  • aktuális verzió, amikor is két dolgot kell tennünk:
    • beállítjuk a CSC-AE-t (érdemes mindkét pipát betenni)
    • engedélyezzük az AutoEnroll jogosultságot a szükséges sablonokon (pl. Workstation) és publikáljuk őket (alapértelmezetten a Directory Email Replication, Domain Controller Authentication, Kerberos Authentication sablonok már ilyenek)

A fentiek alapján összegezzük:

– a DC-k alapból vagy 1 (“beégetett” és hagyományos beállításkor), vagy 3 (a CSC-Auto-enrollment beállítása után), de automatikusan kapnak tanúsítványokat. Utóbbi esetben Domain Controller azért nem jár nekik, mert azt felülírja más sablon – de manuálisan természetesen kérhetünk.

– amennyiben engedélyezzük az AutoEnroll-t, a rá jogosultak keresni fogják (ugye, AD-ból tudják), tehát ne felejtsük publikálni is

Bár kicsit hosszú lett, végszóként nézzük kicsit a hibakeresést/naplózást. Ehhez érdemes létrehozni a registryben egy AEEventLogLevel duplaszót (értéke lehet 0), számítógép esetén HKLM (felhasználó esetén HKCU) \Software\Microsoft\Cryptography\Autoenrollment alatt, ezután minden sikeres vagy sikertelen esemény a kliens Alkalmazás naplójába hoz létre bejegyzést.

Ja, s természetesen ne felejtsük el, hogy kézzel miként “triggereljük” az automatikus tanúsítvány-igénylést: pl. házirend-frissítéssel* vagy certutil -pulse paranccsal.

*Bár a gpupdate parancsról általában mindenkinek a GPO-k újbóli érvényesítése ugrik be, tanúsítványoknál tudjuk, hogy nem kell feltétlenül GPO-nak léteznie (pl. Enterprise CA-k automatikus terítése, amit bár szintén ezzel a paranccsal lehet kierőltetni, GPO nem társul hozzá)


 

Saját CA által kiállított tanúsítványok vs böngészők

október 7, 2020 Hozzászólás

Nem új keletű a történet háttere, de gondolom az új Edge bevezetésével mind több helyen elő fog jönni, ezért úgy döntöttem, elébe megyek a dolgoknak.

Adott cégnél felmerült, hogy az eddigi http alapú intranet kommunikációt áthelyezik https-re. Ennek érdekében első körben történt egy CA-bevezetés, majd a kiszolgálóra igényeltek egy web-kiszolgálói tanúsítványt.

A tesztelés során kiderült, hogy azok, akik IE vagy “régi” Edge-ről töltik be az oldalt, nem tapasztalnak gondokat, viszont akik Chrome vagy Chromium alapú Edge-ből, azoknak

ERR_CERT_COMMON_NAME_INVALID

hibaüzenettel, a Firefox-ból vonulóknak pedig egy

SEC_ERROR_UNKNOWN_ISSUER

üzenettel kedveskedik a rendszer.

Itt akkor felmerült a kérdés: most akkor mi van? Jó a tanúsítvány vagy nem? Illetve miért függ egy tanúsítvány megítélése a böngészőtől?

Nos, Firefox esetén a böngészőnek saját tanúsítvány-tára (is) van, de esetében mondhatni könnyű dolgunk van: egy házirend segítségével megadjuk, hogy a böngésző az oprendszertől kérje el a megbízható tanúsítványok listáját. S tudjuk, hogy a CA automatikusan lekerült a gépekhez, tehát ez nem lehet gond (erre amúgy másodlagos bizonyíték az is, hogy az MS régebbi böngészői sem reklamálnak). Itt “csak” egy dolog nem teljesen világos számomra: miért szükséges, hogy egyes programok (pl. Adobe, Java, stb) saját tanúsítványtárat használjanak? Értem én, hogy így akár szolgáltatásonként külön tanúsítványt lehet használni – de személy szerint ezt már túlzásnak érzem…

A Chrome / Chromium alapú Edge esetében a megértéshez szükséges a Google böngészőjének működését figyelembe venni. Kb. 3 éve ugyanis a Chrome nem fogadja el a belső CA-k által kiállított tanúsítványokat, csak akkor, ha azok rendelkeznek érvényes SAN-mezővel. Ezzel a gondolattal lehet vitatkozni, ugyanis elvileg az RFC előírja, hogy másodlagos opcióként a CN-t is ellenőrizni kell – de ez figyelmen kívül van hagyva. Egy ideig egy registry-kulccsal lehetett egy kerülő-megoldást alkalmazni, viszont ezt a lehetőséget is már rég megszüntették. Jelen esetben megoldásként az a döntés született, hogy rendben, akkor létrehoznak egy új, célnak megfelelő tanúsítvány-sablont, majd azzal igényelnek tanúsítványt. Ennek szétszedése (Cert, Key, CA) már gond nélkül lezajlott, majd az élesítés után már valóban nem reklamált a böngésző. De hogy mit tesznek azok a cégek, ahol tömegesen használnak web-kiszolgálókat, saját CA-val, s tömegesen akarják lecserélni a tanúsítványokat az újabb sablonból eredőnek – hát, lehet, hogy nem mindenki lesz boldog.

Management konzol és tanúsítvány

augusztus 7, 2020 3 hozzászólás

Egy adott cégnél feltették adott (egyik általam is kedvelt) végpontvédelmi alkalmazás központi kezelőfelületét. A telepítés rendben lezajlott, viszont a következő lépés során hiába keresték a program nyilvántartásában a kliens-gépeket, a lista üres volt.

A hibafeltárás során először is megnéztük, hogy lefutott-e az AD-ból történő import. Mivel a feladat hibát jelzett, így egyértelmű lett, hogy “csak” ennyi a baj. No de miért futott hibára?

Nos, a nemrég, júniusban kiadott legújabb verzió tartalmaz egy elég fontos változást ezen a téren – így vélhetően lesznek még néhányan, akik konzol-frissítés után szintén belefuthatnak a sikertelen műveletbe. Kissé kettős érzéssel vagyok, ugyanis érzem, hogy az elképzelés, alapötlet nem rossz, de sajnos a kivitelezés nem sikerült a legjobban.

Hogy konkrétan az okot nézzük: bevezették, hogy az AD-import LDAPS segítségével történjen. Ez szuper, hiszen ez a biztonságot erősíti, nem? De igen, de mi van azoknál a cégeknél, ahol még nincs PKI rendszer bevezetve, a DC-knek nincs megfelelő tanúsítványa? Nos, itt csúszott el a történet. Idézem a támogatói oldal erre vonatkozó cikkét: a DC-n Server Manager segítségével telepítsük az AD CS szerepkört, azon belül a CA-t. Ezután a Helyi számítógép tanúsítványai ablakban jobb klikk segítségével kérjünk DC-tanúsítványt. S kész.

Aki nem foglalkozott soha tanúsítványokkal, talán az is érzi, hogy ez elég foghíjas. Kezdve attól, hogy egy tanúsítvány-kiszolgálót nem vezetünk “csak úgy” be egy tartományba, arról nem beszélve, hogy a binárisok telepítése (Server Manager, ugye) után még van a CA élesítése. Erről a cikk mélyen hallgat, tehát aki a varázslót lefuttatja, az törheti a fejét, hogy Enterprise (default) vagy Standard, Root (default) vagy Subordonate, új privát kulcs vagy nem (ennek minden finomságával) szükséges – vagy csak rányom a Next-Next-Finish gombra, de attól még nem tudja, hogy mit csinál.

Amennyiben sikerül a CA-t telepíteni, jöhet a következő lépés, ami valóban nem annyira bonyolult: a DC-nek tanúsítványt kérni. Még itt is elbizonytalanodhat a szomszéd Pistikéje, ugyanis két tanúsítvány-sablonban is szerepel a “Domain Controller” szópáros

Csak, hogy teljes legyen a lista, egy másik apróság is kibukott (ez már csak helyi “specialitás”): az előbbiek abszolválása után még mindig nem tudott a kiszolgáló LDAPS kapcsolatot létesíteni a DC-vel. Ennek okának kiderítése kicsit kacifántosabb volt, a semmitmondó hibaüzenet (ami ráadásul ugyanaz volt, mint a CA telepítése előtt) nem segített semmit. Bár tudjuk, hogy Ent CA esetén a kiszolgáló tanúsítványa automatikusan bekerül a megfelelő helyre, így nem GPO-val kell kiszórni a tartományi gépekre, adott gépen ez nem valósult meg, így kerülő-megoldásként kézzel került be a megfelelő konténerbe – ezzel végre kerekké (és sikeressé) téve a történetet.

A teljesség kedvéért meg kell említeni, hogy egy másik opció segítségével maradhatunk LDAP csatlakozásnál is, sőt, megfelelő sablon segítségével a szükséges Active Directory attribútumokat is ki tudjuk töltetni – de szerintem első körben elég lett volna egy pipa-beállítás, hogy aki szeretné, tudjon használni LDAPS-ot, majd később szigorítani, s alapértelmezetté tenni.

Kategóriák:General, PKI Címkék: ,

RDP tanúsítvány

május 24, 2017 Hozzászólás

Egy régi félkész cikket próbálok befejezni… A témát réges-rég is említettem, minimálisan, de azóta rengeteg víz lefolyt a Dunán 🙂

Nos, akkor kezdjük átismételni, mi történik, amikor RDP-vel csatlakozni próbálunk egy géphez (leírás, értékek). Első körben van egy biztonsági ellenőrzés, amelynek során a rendszer ellenőrzi a registry-ben, hogy van-e már mentett kapcsolatunk a távoli kiszolgálóhoz, s abban mit engedélyeztünk (HKCU\Software\Microsoft\Terminal Server Client\LocalDevices\<Név> – ha csak most engedélyezzük az elsőt, létrehozza a LocalDevices kulcsot is). Ennek fényében kapunk egy sárga, vagy, ha “online” csatlakozunk (nem RDP-állomány), akkor a változatosság kedvéért kék ablakot (hogy még bonyolultabb legyen, a kék ablak sem mindig pattan elénk, csak az 1, 2, 32 értékek hiányában):

 

A kék ablak (ha nem RDP-állományból, esetleg ha a LocalDevices értéke 12 (1100) – amennyiben betesszük a pipát, akkor az érték 77 (0100 1101) lesz):

Továbbjutva az első akadályon, máris egy másik registry-kulcs által szabályozott területre érünk. Ekkor a rendszer ellenőrzi a HKCU\Software\Microsoft\Terminal Server Client\Servers kulcs tartalmát, s amennyiben van, úgy alapértelmezés szerint felajánlja az itt található UsernameHint felhasználót s kéri a jelszavát. Amennyiben nincs, egy választó-ablakot dob fel, az aktuális felhasználónak kérve a jelszavát vagy lehetőséget adva másik felhasználónév/jelszó megadására. Ha van mentett jelszavunk, akkor természetesen kiolvastathatjuk a Hitelesítőadat-kezelőből is. Sikeres hitelesítés esetén megérkeztünk az aktuális témához, a második sárga ablakhoz:

Ennek megfejtése: szintén az előbb említett registry-kulcsban előfordulhat egy tanúsítvány-kivonat (hash) – ha ez érvényes, azaz megegyezik a gépen tárolt tanúsítvány lenyomatával, észrevétlenül csatlakozunk a kiszolgálóhoz – ellenkező esetben jön elő a jelzett, második sárga ablak. Ha utánajárunk az alapértelmezett, önaláírt tanúsítványnak, kiderül, hogy a számítógép tanúsítvány-tároló Remote Desktop mappájában található, így könnyen gondolhatnánk, hogy azt lecserélve hátradőlhetünk – de ez nem így van. Elkeseredésre azért nincs ok, mert azért a megoldás egyszerű: miután a “jó” tanúsítványt betesszük a számítógép tanúsítvány-tároló Personal mappájába , le kell cseréljük a WMI-ban tárolt tanúsítvány-kivonat értékét (szaknyelven a root\cimv2\TerminalServices névtér Win32_TSGeneralSetting osztály beállításaiban a SSLCertificateSHA1Hash értékét kell cserélni ).  Visszalépni nem lehet (de minek is kellene?).

Biztos, ami biztos, előbb lekérdezzük a jelenlegi értéket:

wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Get SSLCertificateSHA1Hash

Ugyanezt az eredményt kell találjuk a grafikus felületen megnyitott tanúsítvány ujjlenyomat-értékében is (“Thumbprint”).

Szintén pl. a grafikus felület segítségével kiderítjük a számítógép “rendes” tanúsítványának lenyomatát, majd a cseréhez a következő utasítást kell végrehajtani:

wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash=”THUMBPRINT”

Vagy aki inkább Powershell-t használna (Set-WmiInstance helyett lehetne swmi, hasonlóan a Get-WmiObject helyett gwmi):

# Lekérdezzük a jelenlegi lenyomatot

$TSGeneralSetting = Get-WmiObject -class “Win32_TSGeneralSetting” -Namespace root\cimv2\terminalservices -Filter “TerminalName=’RDP-tcp'”

# A számítógép tanúsítvány-tárából kiválasztjuk az SSL-tanúsítvány lenyomatát (ha több tanúsítványunk van, akkor ellenőrizzük a kapott eredményt)

$thumb = (gci -path cert:/LocalMachine/My | select -first 1).Thumbprint

# Beállítjuk az új értéket Set-WmiInstance -Path $TSGeneralSetting.__path -argument @{SSLCertificateSHA1Hash=”$thumb”}

Ezt tovább tudjuk fokozni, hogyha más néven csatlakoztunk, további adatok lesznek a sárga ablakon:

 

Ha viszont egy olyan kiszolgálóra csatlakozunk, amelyik nem támogatja az NLA-t (például alábbi esetben Windows 2003), akkor az alábbi ablakok jönnek:

 

Huhh, elég volt a sárga ablakokból. Uff.

Tanúsítványok és Windows Phone / Mobile

augusztus 1, 2016 Hozzászólás

Egy jó ideje velünk van az IKEv2 típusú VPN, amit úgy szoktunk „reklámozni”, hogy a mobilokra lett kifejlesztve, s csak „másodlagosan” számítógépre. Nos, ezzel kapcsolatban osztanék meg két apróságot, amire érdemes figyelni:

– a Windows Phone (7 – 8.1) / Mobile (10) telefonokon nem lehet törölni a tanúsítványt (létezik egy Certificates app, de az csak megtekintésre jó)

– egyes helyeken olvasható az, hogy a VPN kiszolgálón a root tanúsítványok között csak a miénk legyen, ellenkező esetben minden mást is elfogad. Nos, ez nem állja meg a helyét, hiszen nem véletlenül kell a tanúsítvány tartalmazza a „Server Authentication” és „IP Security IKE intermediate” felhasználási módokat (EKU/AppPolicies*).

* Windows 2000-ig EKU, 2003-tól Application Policies néven található meg az utód, ami viszont MS-specifikus, s bár legtöbbször használatuk megegyezik, nem ugyanaz az EKU-val.

Kategóriák:PKI Címkék: ,

Engedélyhez kötött tanúsítványok

június 6, 2016 3 hozzászólás

Ha bármely tanúsítványsablonon bekapcsoljuk, hogy valakinek kell engedélyeznie a tanúsítvány-kiállítást, akkor pár dologra érdemes figyelnünk az igénylés során. A legegyszerűbb, ha ilyenkor webes felületet használunk a kérelem benyújtásához, ugyanis elbírálás után ugyanezen a felületen tudjuk lekérni a kapott tanúsítványt.

Amennyiben mégis mmc-t (vagy bármilyen más módszert) használunk, akkor a kliens-gépen ott lesz a Request, de az engedélyezés után kapott tanúsítvány kézhezvételéhez a leggyakrabban használt módszerek:

  1. exportáljuk a CA-n,
  2. kliensen kérjük le a tanúsítványt, a certreq segítségével (Figyelem: bármelyik tanúsítványt le tudjuk kérni a CA-tól, ha tudjuk a CA-ban található RequestID azonosítóját, így mindenképp jegyezzük meg, hogy melyiket akarjuk letölteni)
  • interaktív módon:

          certreq -retrieve RequestID

ezután kiválasztjuk a CA-t, illetve, hogy milyen néven/hova kerüljön mentésre a tanúsítvány, alapértelmezetten .cer lesz

  • automata üzemmódban:

          certreq.exe -retrieve -config <CAConfig> <RequestID> <OutPutCertFile.cer>

ekkor fontos, hogy a paraméterek ilyen sorrendben legyenek (az ID-t ne tegyük a -config elé, ne tegyük paraméter-megnevezési sorrendbe), a CAConfig pedig lehet pl. Server_Neve\CA_Neve (de certreq -retrieve /? természetesen mindig súg 😉 )

Amennyiben sikerült megkapnunk a tanúsítványt, az igénylő gépen importáljuk (akár grafikus felületen, dupla klikkel, akár certreq -accept <OutPutCertFile.cer> paranccsal), itt összerendelődik a privát kulccsal, így „teljessé” válik a tanúsítvány.

Bár néhány internetes fórumon szoktak rájuk hivatkozni, de a tanúsítvány-áttöltéshez se a „certutil -pulse” nem járható út, se a házirendben engedélyezett Auto-enrollment (User Configuration / Windows Settings / Security Settings / Public Key Policies / Certificate Services Client – Auto-Enrollment – erről majd egy következő cikkben még ejtek szót) nem hatásos, mint a hivatalos cikk is jelzi.

Split-DNS vs .local

május 9, 2016 2 hozzászólás

Az utóbbi időben két olyan rendezvényen is részt vettem, ahol felmerült a belső tartományi név TLD-kérdésköre: local vs. publikus (split DNS-el). Egyik helyen elfogadták JoeP-el közösen kinyilvánított álláspontunkat, másik helyen kevésbé. Nos, a tanfolyamokon el szoktam mondani ezzel kapcsolatosan a véleményem, a tapasztalataimra alapozva – de ez mindenképp mérlegelés kérdése. Pontosabban csak akkor, ha nem kis cégről beszélünk; ugyanis ahol SBS-t telepítenek, ott „gyárilag” eldöntik helyettünk (ez most az utolsó verziókra vonatkozik, régebben ott is megvolt a döntési szabadságunk).

A válasz ugyanis nagyon nem egyértelmű, ki-ki maga kell eldöntse, hogy mit választ, de ne én mondjam meg a tutit, itt van egy összefoglaló egy MVP-től (maga a cikk régi, de időnként frissítve van új információkkal, s itt felhívnám a figyelmet a legutolsó, 2014-es bejegyzésre, így talán egyértelműbb a kategóriába való besorolás oka is):

http://blogs.msmvps.com/acefekay/2009/09/07/what-s-in-an-active-directory-dns-name-choosing-a-domain-name/

Kategóriák:PKI, Windows Server Címkék: ,

SHA1 elavul

május 2, 2016 6 hozzászólás

Páran jelezték, hogy elég régóta nem írtam kedvenc témámról, a tanúsítványokról. Nos, kezdjük is egyből egy közérdekű közleménnyel: a Microsoft, eredeti terveihez képest, előbbre hozta az SHA1 nyugdíjazását: eredetileg 2017 januári hónapja volt becélozva az SHA1 kivonatolási (hash) mód elavult (deprecated) státuszba kerüléséhez, de már 2016 júniusától nem támogatott. A helyét az SHA2 (SHA256, SHA384, SHA512) veszi át – ehhez a CA kriptográfiai módszerének Key Storage Provider (KSP) kell legyen. Ha valaki Cryptographic Service Provider (CSP)-t használ, mivel az nem tud SHA2-t, szükség lesz még egy kis CA-átalakításra (KSP/CSP témát érintettük itt is, kissé más vonatkozásban; CNG (Cryptography Next Gen) érintett része itt).

Aki le akarja cserélni az új tanúsítványok kivonatolását, annak nincs nehéz dolga: egy emelt szintű parancssorban lefuttatja az alábbi sort, majd újraindítja a CA-kiszolgálót:

certutil -setreg ca\csp\CNGHashAlgorithm SHA256

net stop certsvc

net start certsvc

Fontos, hogy ez csak a mostantól kiállított tanúsítványokra fog vonatkozni, a meglévőkre (beleértve a CA sajátját is!) nem.

Mint látszik, nem a „szokásos” (Next-Next-Finish kategória) kivitelezés a gond, hanem a tervezés – ugyanis kivitelezés után egy pár operációs rendszer nem tudja majd kezelni az új tanúsítványokat: az XP SP3, illetve Win2003 (+patch)-től felfele tudja a Windows az SHA2-t. Ha van egy olyan hálózatunk, ami ennél régebbi oprendszereket (pl. Win2000) futtat, amelyek nem lecserélhetőek, akkor egyik kerülőút a két CA használata lehet.

Kategóriák:PKI Címkék: , , ,