Eljut a VPN-beállítás tanúsítványoldalára, lát egy ingyenes önaláírt lehetőséget egy fizetős nyilvános CA mellett, és a kérdés biztonsági választásnak hangzik. Valójában közönségválasztás. Mindkét lehetőség ugyanazokkal az alapvető primitívekkel titkosítja az alagutat, és mindkettő értéktelenné válik, ha a titkos kulcs kiszivárog. Az különbözteti meg őket, hogy ki teszi az állítást a kiszolgáló identitásáról, és ki van abban a helyzetben, hogy ezt az állítást ellenőrizze.

A tanúsítvány két munkát végez, amelyeket összekevernek

A tanúsítvány egy nyilvános kulcsot névhez köt, a kulcs pedig a titkosítási és aláírási munkát végzi. A tanúsítványon lévő aláírás külön nyilatkozat: valamely hatóság ellenőrizte, hogy a név ehhez a kulcstulajdonoshoz tartozik. Az önaláírt tanúsítvány ezt a nyilatkozatot önmagáról teszi, ami egyáltalán nem harmadik fél állítása.

A nyilvános webhelyeknek a harmadik féltől származó változatra van szükségük, mert a látogatók előzetes kapcsolat nélkül érkeznek, és a böngésző bizalmi tárolójára támaszkodnak. A VPN-kliens nem idegen. Ön átadja neki a CA-tanúsítványt, vagy rögzíti a kiszolgáló tanúsítványát a telepített profilban, így az ellenőrzés pontosan az ön által választott hatósággal szemben fut. Nem kell kereskedelmi CA-nak részt vennie ahhoz, hogy ennek az ellenőrzésnek bármi értelme legyen.

A létrejövő munkamenet ereje a kulcsmérettől és a titkosítási csomagtól függ, nem az aláírótól. Ezért az önaláírt tanúsítvány "kevésbé titkosítottnak" nevezése egyszerűen téves; kevésbé széles körben garantált, ami más tulajdonság.

Ahol a nyilvános CA megkeresi a díját

A legvilágosabb eset az adminisztrációs oldal. Ha a kollégáknak, vállalkozóknak vagy bárki másnak, akinek nincs előkészített profilja, böngészőfigyelmeztetés nélkül kell megnyitnia a VPN-kiszolgáló webes felületét, egy nyilvánosan megbízható tanúsítvány megszünteti ezt a súrlódást. A böngésző már megbízik az aláíróban, tehát nincs mit importálni és nincs mit megmagyarázni.

Ennek a kényelemnek ára van, amelyet érdemes megnevezni a vásárlás előtt. A megújítást automatizálni kell, különben az oldal ütemterv szerint elromlik, a nyilvános tanúsítványok feltárják a gazdagépnevet a tanúsítvány-átláthatósági naplókban, és a kibocsátási sebességkorlátok büntetik a túl buzgón újrapróbálkozó szkriptet. Ezek egyike sem ok a nyilvános CA elkerülésére, de olyan üzemeltetési munka, amelyet a privát CA máshová helyez.

Amit a nyilvános tanúsítvány nem tesz meg, az a felhasználók hitelesítése. Az ügyfélidentitás külön döntés, amelyet ügyféltanúsítványokkal, jelszavakkal vagy második tényezővel hoznak, és a kiszolgálót aláíró CA semmit sem mond arról, ki csatlakozhat hozzá.

Hol illik a privát CA a VPN-hez

Egy ismert ügyfélkörű privát VPN esetében a saját CA üzemeltetése a szokásos választás. A CA-t egyszer hozza létre, aláírja a kiszolgáló tanúsítványát azzal a névvel, amelyet az ügyfelek használni fognak, és minden profilban terjeszti a CA-tanúsítványt. Ezután minden ügyfél az ön hatóságával szemben ellenőrzi a kiszolgálót, és külső fél nem tudja meg a gazdagépnevet.

A költségek valódiak, de korlátozottak. A böngészők figyelmeztetni fognak, amikor valaki közvetlenül megnyitja az adminisztrációs oldalt, mert a böngészőnek nincs oka megbízni az ön CA-jában. A profilok terjesztése az előkészítés részévé válik, a CA cseréje pedig minden ügyfél megérintését jelenti. Ezek elfogadható árak egy tíz vagy ötven ismert felhasználós szolgáltatásnak, és fájdalmasak egy több ezres nyilvános végpontnak.

Egy feltétel teszi érvényessé az egész elrendezést: az ellenőrzésnek meg kell történnie. A tanúsítványhibák figyelmen kívül hagyására beállított ügyfél bármely kiszolgálót elfogad, amely bármilyen tanúsítványt bemutat, így az identitásgarancia eltűnik, miközben a titkosítás megmarad. Ez a beállítás a valódi gyengeség a legtöbb "az önaláírt nem biztonságos" történetben.

A CA titkos kulcsa dönti el, mit tehet később

A meglepetés általában hónapokkal később érkezik, amikor eszközt szeretne hozzáadni. Az ügyféltanúsítvány kibocsátásához a CA titkos kulcsa kell, és a visszavonási lista elkészítéséhez is. Ha olyan kiszolgálót örökölt, amely rendelkezik a tanúsítvány- és kulcsfájlokkal, de a CA-kulccsal nem, semmi újat nem tud aláírni. Lehetőségei: újraépíti a PKI-t, és minden ügyfélnek új CA-tanúsítványt ad, vagy jelszavas hitelesítésre vált, ami más biztonsági modell, és nem állítja helyre az elveszettet.

Két kisebb csapda él ugyanazon a területen. Az easy-rsa szkriptek feltételezik, hogy abban a könyvtárban áll, amely tartalmazza őket, ezért a hiányzó fájl hibája általában a rossz helyet jelenti, nem a sérült telepítést. És a csak tanúsítványokra épülő tervezés teljesen legitim: megkövetelhet ügyféltanúsítványokat előre megosztott kulcs nélkül, feltéve, hogy minden ügyfélnek van egy, és a kiszolgáló ellenőrzi a láncot.

Eszközönként egy tanúsítványt adjon ki, ne egy közös ügyféltanúsítványt az egész csapatnak. Egy elveszett laptop akkor egyetlen visszavonásba kerül ahelyett, hogy mindenkinek újat kellene kiállítani.

Ellenőrizze, mit örökölt

Mielőtt bármilyen változást tervezne, olvassa el a meglévő tanúsítványt:

$ openssl x509 -in server.crt -noout -subject -issuer -dates
subject=CN = vpn.example.net
issuer=CN = vpn.example.net
notAfter=Nov  3 09:00:00 2027 GMT
$ openssl verify -CAfile ca.crt server.crt
server.crt: OK

Ha a kibocsátó megegyezik a tárggyal, a tanúsítvány önaláírt, ami tervezési döntés, nem hiba. A dátumok megmondják, mikor válik a megújítás valaki problémájává, és a szállítani kívánt CA-val szembeni sikeres ellenőrzés megerősíti, hogy a lánc működik, mielőtt egyetlen ügyfél is kipróbálná.

Ezután közönség és terjesztés szerint válasszon: nyilvános CA, amikor ismeretlen böngészőknek meg kell bízniuk az adminisztrációs oldalban, privát CA, amikor minden ügyfél az ön által ellenőrzött profilt kap. Egyik válasz sem titkosítottabb a másiknál.

Kapcsolódó cikkek