VCSA tanúsítványok – három opció

Ez megint egy olyan poszt, amely a frissebb megbízásaim és tapasztalataim alapján íródik.

A VMware infrastuktúra kiemelt komponense a vCenter Server, amely az idők folyamán egy Microsoft Windows Server alapú szolgáltatásból, átalakul – és a vSphere 7 megérkezésével lehet hogy be is fejezi – egy appliance formátumú, meglehetősen blackbox elemmé. Az átalakulás során először a PSC jelent meg mint kihasítható komponens, majd most az már „deprecated”, ezáltal megint visszatérünk oda hogy egy appliance van és abban létezik minden szervíz ami a funkcióját adja.

Mint ilyen, fontos hogy mikor a vCenter-hez csatlakozunk, legyen az böngésző vagy valamilyen API-n keresztül, akkor azt biztonságosan tehessük. Tapasztalatból mondom, hogy igen sok esetben ez kimerül abban, hogy elfogadjuk a VCSA self signed tanúsítványát és ezzel lényegében le is tudjuk a dolgot. Ezzel nem az a baj, hogy ezáltal nem titkosított és bizalmas vele a forgalmunk, mert az, hanem lényegében az hogy észre sem vennénk ha a VCSA egy másikat kezdene prezentálni. Szóval arról nem győződhetünk meg, hogy tényleg ugyanaz az entitás-e, mint akit már ismerünk.

Milyen opciók vannak saját SSL használatára?

Három lehetőséget kínál és ezek kompexitása nagyságrendekkel nő.

1. Ca signed Machine SSL és VMCA self signed: A VCSA-n a saját vállalati certification authority által aláírt tanúsítványt használjuk, így benne minden kliens megbízik – a tartományi kliensek mindenképpen, illetve ahol trusted root-ként ott van a vállalati CA – viszont a belső certificate-eket (ESXi, solution user-ek) a VMCA állítja ki, méghozzá a saját self signed tanúsíványával.
2. CA signed Machine SSL és a VMCA mint intermediate CA: Az előzőhöz képest annyi a különbség, hogy a VMCA-nak aláírunk egy olyan tanúsíványt, amely őt a vállalati CA rendszerében tanúsíványkiállító szervernek determinálja. Innentől kezdve a VMCA képes lesz kiállítani az összes ESXi-nek és solution user-nek, olyan tanúsítványokat, amelyekben az összes kliens megbízik.
3. Hardcore – én csak így hívom. Minden tanúsíványt a vállalati CA állít elő és nem a VMCA.

Átfogalmazom a komplexitással kapcsolatos megoldást és inkább ezzel az ábrával jellemzem:

Az első az esetek 90%-ban elegendő minden rendszerben, hiszen biztosítja mind a biztonságos kommunikációt, mind az identitás validálhatóságát és mivel úgyis a vCenter-hez kapcsolódik minden adminisztrátor és a legtöbb rendszer. Ez az a megoldás amit a VMware egyébként javasol.

A második opció nem csak szerintem, hanem általában az ügyfelek részéről is minimum rizikósnak vélhető, mivel a vállalati CA egy jól védett és minden módon magasan biztosított környezet. Függetlenül attól hogy egyszintű – szerencsére kevés helyen van ilyen – vagy offline root és issuing CA – kétszintű – megoldás van, ráadásul egyre több helyen Hardware Security Module (HSM) tárolja a privát kulcsokat. Na ebben a második opcióban a VMCA is intermediate issuing CA lesz, azaz képes kiállítani olyan tanúsíványokat, amelyekben minden kliens majd vakon megbízik, viszont a privát kulcsa marad a VCSA-ban, nem a HSM-en lesz. Az által kiállított cert-ekről, a vállalati CA üzemeltetője semmit sem lát, nincs single pane of glass.

A harmadik pedig a legelvetemültebb megoldás, soha semmiféle esetben nem javaslom. Ez tényleg mérhetetlen mennyiségű certificate-et jelent.

Első eset bemutatása

Bár lehetséges csak GUI-n elvégezni, de az ilyen módon mutatott részletes információk a folyamatról eléggé hiányosak, szerencsésebb SSH-n dolgozni.

Lépjünk is be rá, majd „shell”.

Indítsuk el a „/usr/lib/vmware-vmca/bin/certificate-manager” parancssal a varázslót, ami igen nagy segítség a folyamatban. A menüjében egyébként látszik, hogy akár a hardcore verziót is implementálni lehet vele.

Mivel mi csak egy CA által aláírt SSL certet szeretnénk a vCenter szolgálatába adni, ezért üssünk be egy „1”-et. Be kell ütni az SSO admin nevét és jelszavát is.

A megnyiló almenüben két opció van és mindkettőre szükség lesz, de az első lépésben kezdjük a certificate signing request létrehozásával, azaz itt szintén írjunk be „1”-et.

A kitöltés magától értetődik,talán a legutolsó lépésben kérdezett VMCA name a kérdéses, itt ebben a megoldásban az légyegében a vCenter Server FQDN-je. Ha ezzel készen vagyunk, akkor válasszuk a „2”-t és ezzel ki is lép a cert manager-ből. Ahhoz, hogy le tudjuk másolni a CSR és a generált privát kulcsot, szerezzünk jogot a „chsh -s /bin/bash root” begépelésével.

Másoljuk le a /tmp könyvtárból a CSR-t és opcionálisan elmenthetjük a privát kulcsot is. A CSR-t kell csak felhasználni a CA-ban, ami ha Windows alapú, akkor egészen egyszerűen a nyissuk meg a certreq oldalt vagy mmc-ből kérjünk.

A megnyiló ablakban a „Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.” kiválasztása után én a webserver template felhasználásával készítek egyet.

Ha kész, akkor Base 64-ben szedjük le csak a certificate-et, majd lépjünk vissza a kezdőlapra.Innen szedjük le a CA chain-t a „Download a CA certificate, certificate chain, or CRL”, majd a „Download CA certificate chain” kiválasztásával.

Utóbbi p7b formátumú lesz. Ez utóbbit importáljuk be egy Windows gépre és exportáljuk ki őket (akkor van több ha nem egyszintű a CA) ki ezt is Base 64-ben, cer formátumba.

A két kimentett fájl így a vcenter-dev.cer és issuing_path.cer nevekkel szerepel a példában.

Ha ez kész, akkor másoljuk fel ezt a két fájlt a VCSA-ra a /tmp-be és indítsuk el újra a certificate manager-t.

Ezútal is az „1”-es menüt választjuk, majd a „2”-est, mivel már aláírtuk a CSR-t.

Nem kér be csak három paramétert:

1. Az aláírt certificate-et cer formátumba – ez az amit letöltöttünk a CA-ról, nálam vcenter-dev.cer.
2. A certhez tartozó privát kulcsot – ez amúgy is a /tmp-ben van már, mivel a CSR létrehozásakor ide tette „vmca_issued_key.key” néven.
3. A certificate chain-t, amit nem oly régen exportáltunk és lényegében a CA-ink publikus kulcsai vannak egymást követően benne, nálam issuing_path.cer névvel.

A vCenter szolgáltatás az „Y” lenyomása után meg fog állni és maga a folyamat úgy körülbelül öt perc, bár függ a vCenter extension-ök számától.

És akkor 90% az esély arra, hogy hibára is futott

Ennek több oka lehet, de ha Veeam mentést használunk vagy például be van regisztrálva egy Nimble tárolóba a vCenter Server és így fent van rajta a plug-in, akkor ilyen üzenet vár látható:

Ez azért van, mert van pár olyan plug-in, amelyeknél a nem tudja kicserélni a tanúsítványt, mert nincs használnak olyat. Hivatalosan „This issue occurs when there are third party extensions like nimble storage, veeambackupUI etc. with no valid certificates registered to vCenter Server.” a hiba.

Ideiglenesen ki kell regisztrálni az érinttett plug-int a MOB segítségével. Irányadó VMware KB: https://kb.vmware.com/s/article/1025360

Utolsó lépés

Jegyezd fel a naptárba az SSL cert lejárati dátumát, lapozz vissza két hetet és oda hozz létre egy feladatot, emlékeztetővel!