VPN-kliens hozzáadása a CA újjáépítése nélkül

Még egy tanúsítvány kell még egy laptophoz, de a találatok első útmutatója egy olyan paranccsal kezdődik, amely törli a PKI könyvtárat. Az a parancs az első telepítéshez tartozik, nem a regisztrációhoz, és a futtatása a CA-ba, a kibocsátási előzményekbe és minden kliensprofilba kerül, amely a régi kibocsátóban bízott. A döntés szűkebb: van-e a kibocsátónak még használható állapota, és illeszkedik-e az új eszköz a regisztrációs szabályzatához? Három feltétel dönt, és csak egy indokol újjáépítést.

Mit pusztít el valójában az újjáépítés

A PKI újraindítása üres szerkezettel helyettesíti a könyvtárat: új CA-kulcs és tanúsítvány, üres kibocsátási adatbázis, új sorszám-számláló. A kliensek nem követik csendben; profiljaik a régi CA-hoz rögzülnek, ezért minden meglévő eszközt újra kell regisztrálni, az elérhetetleneket pedig kézzel.

A halkabb veszteség a nyilvántartás. A visszavonás ahhoz kötődik, hogy tudja, mely sorszámokat kinek adta ki. Törölje az indexet, és még aláírhat, de már nem mondhatja biztosan, mely kiadott tanúsítványokat akarta visszavonni. A kibocsátó állapota nélküli tanúsítványokat tartalmazó CA-könyvtár olyan biztonsági mentés, amely a rendszer rossz felét állítja vissza.

A CA privát kulcsának másolása a futó kiszolgáló mellé a másik kerülendő rövidítés: a hálózaton kívül tartandó aláíró hatóságot egy nem megbízható forgalmú gazdagép újabb fájljává teszi.

Első feltétel: elérhető-e még a kibocsátó állapota?

Döntés előtt keresse meg a könyvtárat, amelyben a kiszolgáló valóban bízik. Hasonlítsa össze a kiszolgáló által CA-ként bemutatott tanúsítványt a PKI-könyvtárban lévővel ujjlenyomat alapján, nem fájlnév szerint:

openssl x509 -in ca.crt -noout -fingerprint -sha256
openssl x509 -in /etc/openvpn/ca.crt -noout -fingerprint -sha256

Ha az ujjlenyomatok egyeznek, a regisztráció növekményes, és semmit sem kell újjáépíteni. Ha eltérnek, olyan CA-val ír alá, amelyben a kiszolgáló nem bízik: a tanúsítvány tisztán települ, és a kézfogásnál elbukik, ezt a hibát pedig órákig klienshibaként diagnosztizálják.

Ezután keresse a kibocsátási állapotot: az indexfájlt, a sorszám-számlálót és a CRL-szám fájlját. Ha az index eltűnt, de a kulcs megvan, kibocsáthat, de örökli a visszavonások rögzítésének problémáját. Jegyezze fel a változásnaplóba, mert a következő visszavonási kérés felszínre hozza.

Második feltétel: kinél van az új privát kulcs?

Ezt a döntést a felhasználók érzik, ezért hozza meg kifejezetten. Az ügyfélen generált, kérésként benyújtott kulcs a privát felet az első parancstól az eszközön tartja, és az adminisztrátor soha nem nyúl hozzá. A kiszolgálón generált kulcs egyszerűbb a szerszámokkal nem rendelkező eszközöknek, de az adminisztrátort minden kulcs őrzőjévé teszi, és szélesíti a kiszolgáló kompromittálásának hatását.

Az Easy-RSA 3-mal egy meglévő CA ellen a kérés importálása és aláírása két parancs:

./easyrsa import-req /tmp/alice.req alice
./easyrsa sign-req client alice

Válassza meg szándékosan a tanúsítvány típusát. A kliens helyett kiszolgáló-tanúsítványként aláírt kérés olyan fájlt ad, amely jól néz ki, és a partner elutasítja, a hibaüzenet pedig ritkán mondja meg, miért. Az openssl ca-val ugyanez a választás az átadott kiterjesztésekben él, nem az alapértelmezett szakaszban.

Harmadik feltétel: többre van szüksége a kiszolgálónak egy tanúsítványnál?

Egy szokásos, tanúsítvány-hitelesítésű OpenVPN kiszolgálónál a tanúsítvány maga a regisztráció: a közös név lesz a kliens identitása, és minden klienskönyvtár, kényszerített útvonal vagy statikus cím ehhez a névhez kötődik. Adja hozzá a tanúsítványt, és felejtse el a konfigurációt: az alagút csatlakozik, de a szükséges útvonalak nem jelennek meg.

A platformok ezt megváltoztatják. Az OpenVPN Access Server saját felhasználói adatbázist tart, így az aláírt tanúsítvány nem fiók; a fióknak léteznie kell, és engedélyezve kell lennie. Más átjárók identitásláncot rendelnek csoporthoz. Egy eszköz regisztrálása általában két rendszert érint, és a tanúsítvány csak az első.

A növekményes eljárás és mikor helyes az újjáépítés

A sorrend, amely egy eszközt kár nélkül hozzáad: erősítse meg a kibocsátót ujjlenyomat alapján, készítsen friss mentést a PKI-könyvtárról, importálja és írja alá a kérést a kliensszerephez, adja át a tanúsítványt a láncával a jóváhagyott csatornán, majd ellenőrizze, mielőtt a felhasználó csatlakozik:

openssl verify -CAfile ca.crt alice.crt
openssl x509 -in alice.crt -noout -subject -issuer -dates -purpose

A cél sorban SSL client szerepeljen. Fejezze be a CA-mentés frissítésével a kibocsátás után, mert az új sorszám rögzítése előtt készült mentés olyan állapotot állít vissza, amelyből hiányzik az imént hozzáadott eszköz.

Az újjáépítés három esetben helyes: a CA kulcsa kompromittálódott, a kibocsátási állapot helyrehozhatatlanul elveszett, vagy szándékosan módosítja a kulcsalgoritmust vagy a tanúsítványpolitikát. Mindhárom projekt, amely minden kliensre kiterjedő újraregisztrálási tervet igényel, nem egyetlen eszköz kérésének lépései. Ha egyik sem áll fenn, regisztráljon növekményesen, és hagyja békén a kibocsátót.