Az NSX 4.X annó rengeteg új funkciót hozott és bár volt olyan verzió amit végül azonnal visszavontak, a 4.1.0.0, de általánosan elmondható, hogy érdemes rá frissíteni. Később lesz poszt pár ilyen új képességről.
Ebben a bejegyzésben azonban a tanúsíványokról lesz szó. Az NSX maga is használ több ilyen tanúsívtányt, amelyek egy telepítés során természetesen önaláírt tanúsítványok. Ezeket – verziótól függően kivétellel – ki lehet cserélni a vállalati CA által aláírtra vagy igazából akármilyenre, amilyenre szeretnénk. A csere egyébként a GUI-ról jelenleg nem végrehajtható, API-n kell megtenni.
Viszont jelentős különbség van a 4.0 és a 4.1 verziók között.
NSX 4.0
A 4.0 dokumentációjában mindössze négy sor szerepel, bár az utolsó kettő igazából egy csoport, na meg a negyedik sorban hivatkozott cert-ek le sem cserélhetők.
- Tomcat cert: Az GUI és API elérés által használt cert, NSX appliance-enként egy. Mivel produktív környezetben a három appliance javasolt, így három ilyen cert lesz látható.
- mp-cluster: Az előzőhöz képest az a különbség, hogy ez a közös VIP által használt cert.
- NSX Federation: ha használjuk a Federation-t, ha nem, ezek a cert-ek akkor is létrejönnek.
- Not visible in the UI.
Az első két tanúsítványt 825 napra írja alá, tehát ha a telepítést követően nem cseréljük le őket, akkor a telepítés időpontjától számítva 825 nap múlva lejárnak.
NSX 4.1
Ebben a verzióban a korábban is a rendszerben lévő és általa használt tanúsíványok a GUI-n is megjelennek. Ez a frissítést követően meglepő lehet, mert eddig a 9 cert helyett, most legalább 50 darab lesz ott. A dokumentáció vonatkozó része is jelentősen megváltozott.
Nézzük meg kicsit jobban. Alább az összes NSX által használt cert látható. Az API és GUI elérések által használtakat láttuk, 825 napra vannak aláírva.
De a többi, a nagyobb részük 10 éves lejárattal jön létre, ami szintén a telepítés időpontjától indul. Ez jelentős különbség a korábbi verziókhoz képest.
Egy frissítés során a tanúsítványok nem változnak, azok érintetlenül maradnak. Ezen a ponton futottam bele egy hibába, egy ilyen frissítés után. Mégpedig, hogy a fenti kép alapján a 4.1 esetén, sőt igazából a 4.0 esetén is – bár ugye ott API-n lehet megnézetetni az érvényességet – 100 évre kellene aláírva lenniük az általa belül használt cert-eknek, négy kivétellel.
Csak éppen a 3.X-ről, 4.1.0.2-re frissített rendszeren ez nem volt így. Az API-Corfu Client és AR-Corfu Client tanúsítványok maradtak 825 napra aláírtak, holott a fenti értelmében 100 évre kellene szólniuk. A VMware GSS erre azt mondta, hogy ez van, nem mindegy hogy greenfield 4.X a telepítés vagy csak 4.X-re frissített valamelyik korábbi verzióról.
Nincs dokumentálva sehol, pedig ennek fényében jelentős különbség van greenfield és brownfield rendszer között. A fentebb említett API-Corfu Client és AR-Corfu Client tanúsítványokból három-három van.
Összefoglaló
3.X-től 4.1.0.2-re történő frissítés után ha hirtelen rengeteg alarm keletkezik a lejáró/lejárt tanúsíványok miatt, akkor nem kell izgulni. Ha ezek a 100 év helyett csak 825 napra aláírtak lejárnak, akkor sem áll meg semmi, csak jön róla alarm.
Feltettem a kérdéseket a VMware GSS-nek is és azt is kértem, hogy bizony adjanak egy szkriptet, ami lecserélni ezeket az úgymond hibás cert-eket, újabb önaláírt, de 100 éves lejárattal, mert majdnem biztos, hogy API-n én nem fogom ezt 50-szer végigütni, sem szkriptet írni rá.
A kövektező hiba miatt én jelenleg azt javaslom, hogy amennyiben elkerülhető, tolja el mindenki a frissítést, ha teheti.
NSX UI becomes unavailable on NSX 4.1.0 or 4.1.0.2 (92728): https://kb.vmware.com/s/article/92728?lang=en_US&source=email
