Az üzemeltető küld egy címet és egy felhasználónevet, a kliens pedig CA-fájlt, tanúsítványt és kulcsot kér. Ezek helyi előállítása kézenfekvő következő lépésnek tűnik. Olyan tanúsítvány születik, amelyben csak a saját géped bízik. A kiszolgáló bizalma egy olyan CA-ban gyökerezik, amelyet nem te irányítasz, ezért a kézfogás véget ér, mielőtt elkezdődne.

A bizalom a kiszolgálón él, nem a profilodban

A tanúsítványos hitelesítés összehasonlítás. A kliens bemutat egy tanúsítványt; az átjáró ellenőrzi, hogy a konfigurációjában szereplő CA-k egyike írta-e alá.

A profilod megnevezi azt a CA-fájlt, amelyet a kliensnek a kiszolgáló ellenőrzéséhez használnia kell. Nem nevezhet meg olyan CA-t, amelyet a kiszolgálónak kellene téged ellenőrizni. A konfigurációnak ez a fele nem a tiéd.

A saját készítésű tanúsítvány elbukik ezen az összehasonlításon akkor is, ha technikailag hibátlan. Van érvényes aláírása, tárgya és dátumai, de a kibocsátó olyan CA, amelyről az átjáró soha nem hallott. A hiba a kézfogás során jelenik meg, miután a kiszolgáló már kért tanúsítványt. A kliensprofilban semmi sem változtathatja meg a választ.

Miért nem helyettesítheti az önaláírt tanúsítvány

Az önaláírt tanúsítványt a saját kulcsa írja alá. Az aláírás ugyanazzal a fájllal ellenőrizhető, ami önkonzisztenssé és hasznavehetetlenné teszi más átjárójához való hitelesítő adatként.

Az átjáró nem azt kérdezi, hogy a tanúsítvány belsőleg konzisztens-e. Azt kérdezi, hogy egy megbízható kibocsátó írta-e alá.

Ezért zavarosak a hibaüzenetek. A kliens olyan ellenőrzési hibát jelenthet, amely kiszolgálóproblémának hangzik, miközben a kiszolgáló ismeretlen kibocsátót naplóz. Mindkettő ugyanazt az eltérést írja le ellentétes végekről.

A CSR-útvonal megőrzi a privát kulcsodat

A munka nagy részét még mindig helyben végezheted. Hozz létre kulcspárt, építs tanúsítvány-aláírási kérelmet a nyilvános fél köré, és küldd el a kérelmet az üzemeltetőnek. Csak a kérelem hagyja el a gépedet. A privát fél ott marad, ahol előállítottad.

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

Az üzemeltető a saját CA-jával aláírja a kérelmet, és visszaküld egy tanúsítványt. A privát kulcsod soha nem utazott, és az eredmény ahhoz a horgonyhoz láncolódik, amelyben az átjáró megbízik.

A felügyelt szolgáltatások gyakran kihagyják a CSR-t, és az egész csomagot kiadják. Ez ésszerű csere, ha ugyanaz a szolgáltató fejezi be az alagutat, és nála van a CA. A kulcs őrzése nem javul attól, hogy megtartod, mert a szolgáltató bármikor újat verhet.

A csomagokat importálják, nem telepítik

A biztonságosan hangzó nevű szállítói csomagok gyakran OpenVPN-profilok. Konfigurációt és néha tanúsítványokat tartalmaznak, és semmit nem telepítenek. Importáld a fájlt egy olyan kliensbe, amely beszéli a protokollt, és a kapcsolat be van állítva.

A kezelési szabály a tartalomból következik. Ha a profil privát kulcsot ágyaz be, az hitelesítő adat, és ugyanazt a gondosságot érdemli, mint egy jelszó: nincs e-mail, nincs tároló, nincs megosztott letöltési mappa. Amikor az üzemeltető külön adja a ca.crt, client.crt és client.key fájlokat, tárold őket együtt szigorú jogosultságokkal, és mutasson rájuk a profil.

Add hozzá azokat az ellenőrzéseket, amelyeket az üzemeltető kihagyhatott

A router által generált profilból néha hiányzik a partner ellenőrzése. A remote-cert-tls server megköveteli, hogy a partner tanúsítványa hordozza a kiszolgálóhitelesítés célját, így a kliens-tanúsítvány nem játszható vissza kiszolgálóként. Az az egy sor kis változás világos indoklással.

A verify-x509-name tovább megy, ha az üzemeltető meg tudja nevezni az elvárt tárgyat vagy SAN-t. Mindkettő kis kiegészítés egy profilhoz, és mindkettő védhető. Vizsgáld meg, mit kaptál, mielőtt importálod.

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

Az ellenőrzési beállítások nem a törött lánc javításai. Ha a kibocsátó rossz, a válasz a megfelelő CA-tól származó tanúsítvány, nem egy kapcsoló, amely kikapcsolja az ellenőrzést. Az ellenőrzés kikapcsolása a hitelesítési hibát észrevétlenné teszi.

Egy csomagot kérj: a hatóság tanúsítványát PEM formátumban, az általa aláírt kliens-tanúsítványt, egy kulcsot, amelyet te állítottál elő, vagy amely olyan csatornán érkezett, amelyben megbízol, valamint a kiszolgáló pontos nevét, amelyet a tanúsítványnak be kell mutatnia. Jegyezd fel a lejárati dátumot ugyanabban az üzenetben, mert a lejárt tanúsítvány hónapokkal később hálózati hibának látszik.

Kapcsolódó cikkek