Mit ellenőriz a VPN-kliense, mielőtt megbízik egy tanúsítványban

A VPN-kliense azt írja, hogy a tanúsítványt nem sikerült ellenőrizni, és a párbeszéd ott véget ér. A fájl megvan, a szerver fut, és ugyanez a profil múlt hónapban egy másik laptopon működött. Az egysoros figyelmeztetés alatt a kliens négy kapun engedte át a társ tanúsítványát: az Ön által beállított tanúsítványhatóság jótáll az aláírási útvonalért, az útvonal eléri a hatóságot, a társnév az, amit kért, és a tanúsítvány most erre a célra használható. Keresse meg a bezárult kaput, és a javítás általában egy fájl; hagyja ki ezt a lépést, és egész délután csomagokat importál újra.

Olvassa el a párbeszédet, mielőtt szerkeszti a profilt

A tanúsítványhibák szövegét az alatta lévő könyvtár fogalmazza meg, nem a telepített VPN-termék, ezért a pontos karakterlánc az első bizonyítéka. A „Nem sikerült beszerezni a helyi kibocsátó tanúsítványát” az útvonalra vagy a bizalmi horgonyra mutat. A „A tanúsítvány lejárt, vagy még nem érvényes” az időre mutat. A „Nem támogatott tanúsítványcél” a kiterjesztett kulcshasználatra mutat. A néveltérés megmondja, melyik nevet akarta. A négy közül egyiket sem javítja a kliens újratelepítése.

Emelje a naplózási szintet, mielőtt bármit módosít. Az OpenVPN a kézfogás környékén jelenti az ellenőrzési hibát, ha --verb 4 kapcsolóval futtatja, a strongSwan pedig identitás- és láncdöntéseit a charon naplóba írja. Ezután erősítse meg, melyik tanúsítványt vizsgálja, mert az emberek rutinszerűen a lemezen lévő fájlt tesztelik, miközben a profil egy régebbi példányt ágyaz be. Amikor a profil PEM-blokkokat ágyaz be, a beágyazott tanúsítvány az, amelyet tesztelnek.

A tanúsítványhatóság identitásokat ír alá, nem engedélyeket

A hatóság egy nevet és egy aláírókulcsot tart. Saját szabályzata szerint olyan tanúsítványokat ad ki, amelyek nyilvános kulcsot kötnek ehhez a névhez, érvényességi ablakkal és használati korlátokkal együtt. Az Ön kliense csak a hatóság tanúsítványára van szüksége a kibocsátó felismeréséhez; soha nincs szüksége az aláírókulcsra, és e kulcs elküldése a klienseknek megadná nekik a képességet bármely identitás létrehozására, amelyben a telepítés megbízik.

A hatóságba vetett bizalom minden általa aláírt tanúsítványt jelöltté tesz, nem a megfelelő társat. Egy ugyanazon belső CA-tól származó webszerver-tanúsítvány is jelölt. Ezért léteznek a név- és célkapuk, és ezért fontosabb egy kompromittált CA-kulcs bármely egyetlen szervernél: eléri minden identitást, amelyet a hatóság valaha kiadott. Eszközönként adjon ki kliens-tanúsítványokat, hogy egy elveszett laptop egyetlen visszavonás legyen a teljes telepítés kulcscseréje helyett.

Építse újra az útvonalat, amelyet a kliens építeni próbál

Az útvonal a társ tanúsítványától indul, nulla vagy több köztes tanúsítványon át a bizalmi tárolója gyökeréig tart. A hiányzó köztes tanúsítvány a leggyakoribb lánchiba, és a kliens oldaláról pontosan úgy néz ki, mint egy nem megbízható gyökér. Először olvassa el a levelet, majd hagyja, hogy az OpenSSL a küldeni kívánt anyagból építse fel az útvonalat.

openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crt

A nulla kilépési állapot azt jelenti, hogy az útvonal ezekből a fájlokból épült fel; a hiba megnevezi a tanúsítványt, amelyet nem ért el. Ha a openssl verify sikeres, miközben a kliens továbbra is elutasít, a különbség abban van, amit a szerver ténylegesen küld, vagy abban, melyik bizalmi fájlt tölti be a profil. Az OpenVPN-ben a köztes tanúsítványok a szerver tanúsítványfájljával együtt utazhatnak, vagy külön adhatók meg a --extra-certs kapcsolóval, és az azonos tárgynév alá írt két gyökeret tartalmazó csomag az egyik kliensét a rossz ágra küldi.

A név és a cél külön kapuk

A láncépítés soha nem kérdezi, hogy a név az Öné-e. Az OpenVPN csak akkor ellenőrzi, amikor a profil beállítja a --verify-x509-name kapcsolót, és a csak a közös névre való illesztés régi szokása azokon a tanúsítványokon törik meg, amelyek identitása a subjectAltName alatt él. Az IKEv2-telepítések a beállított identitást SAN-bejegyzésekhez vagy a megkülönböztető névhez illesztik, a klienstől függően, és egy helyettesítő karakteres vagy %any érték csendesen kikapcsolja az összehasonlítást, amelyről azt hitte, hogy megvan.

Ezután jön az idő és a cél. Az a laptop, amelynek órája néhány órát siet, elutasít egy még nem érvényes tanúsítványt, és egy lejárt köztes tanúsítvány meghiúsítja az útvonalat, miközben a levél érvényes. A célhibák olyan tanúsítványból származnak, amelyben nincs serverAuth a kiterjesztett kulcshasználatban, vagy olyan keyUsage-ból, amely nem engedi a kézfogás aláírását, amit az OpenSSL nem támogatott tanúsítványcélként jelent. Adjon ki újat a megfelelő sablonból; semmi abban az üzenetben nem ok arra, hogy kikapcsolja az ellenőrzést.

A visszavonás csak akkor fut, ha valaki beállította

Egy CRL-t vagy OCSP-választ nem kérdeznek le automatikusan. OpenVPN-szerveren a kliens-tanúsítványokat csak akkor vetik össze egy listával, ha a --crl-verify egyre mutat. A szerver tanúsítványának kliensoldali ellenőrzése a megvalósítástól függ, és gyakran hiányzik. A strongSwannek szüksége van a visszavonási bővítményére és egy szabályzatra, mielőtt egy társ CRL-jét megnézné.

Ez magyarázza a jegyet, amelyet végül kapni fog: egy visszavont kliens-tanúsítvány továbbra is csatlakozik, és mindenki arra jut, hogy a visszavonás elromlott. Semmi nem ellenőrzött. Tegye közzé és frissítse a CRL-t, vagy tartsa a kliens-tanúsítványokat elég rövid életűnek ahhoz, hogy egy elavult visszavonás rövid ideig számítson, és gyakorolja a visszavonási útvonalat egy laboratóriumi tanúsítványon, mielőtt egy incidens során szüksége lenne rá.

Javítási sorrend, amely bekapcsolva tartja az ellenőrzést

Tünet szerint rendezze, mielőtt fájlokhoz nyúl, mert a táblázat minden sora más objektumhoz küldi.

Egy menetben végezze el a listát: erősítse meg a profilt betöltő fájlt, építse fel maga az útvonalat, ellenőrizze, hogy a szerver küldi-e a köztes tanúsítványt, hasonlítsa össze az órát, olvassa el a SAN-t, olvassa el az EKU-t, majd csatlakozzon újra, és figyelje, ahogy ugyanaz a naplósor eltűnik. Ha egy eszköznek egyáltalán nem adható CA, a rögzítés az őszinte alternatíva, mert az OpenVPN 2.6 elfogadja a --peer-fingerprint kapcsolót, és egy kulcsra szűkíti a bizalmat ahelyett, hogy eltávolítaná az ellenőrzést. RFC 5280 a referencia arra, mit jelentenek ezek a mezők.