OpenVPN verify-x509-name: subject, name és name-prefix

Először olvassa el az egyeztetés típusát, aztán a szöveget: egy verify-x509-name direktíva helyesnek tűnhet, és mégis elfogadhat olyan tanúsítványt, amelyben nem szándékozott megbízni. Két sor azonos várt szöveggel, de eltérő típussal két különböző követelmény. Először a típust olvassa, aztán a szöveget. Kezelje a direktívát a kapcsolat további feltételeként, nem a teljes ellenőrzésként.

Mit állít valójában az opció

A direktíva megnevez egy identitást, amelyet a másik fél tanúsítványának hordoznia kell. Ha az összehasonlítás meghiúsul, OpenVPN az OpenVPN megszakítja a kézfogást, és nem jön létre alagút. A profil minden más eleme továbbra is érvényes: a tanúsítványnak megbízható CA-hoz kell láncolódnia, és a szerepkör-ellenőrzésnek át kell mennie, tehát ez további feltétel, nem helyettesítő. Egy profil, amely teljesíti a névelvárást, de elbukik a szerepkör-ellenőrzésen, továbbra is hibás, és a napló ezt általában meg is mondja.

Abban is különbözik a böngésző hosztnév-ellenőrzésétől. A böngésző a neveket a subject alternatív neveivel egyezteti a TLS-verem szabályai szerint, míg az OpenVPN egyetlen tanúsítvány-mezőt hasonlít össze az Ön által választott típussal. Ezért a böngésző stílusú hosztnév beillesztése a direktívába eltérést okozhat akkor is, ha a tanúsítvány valóban lefedi a szolgáltatást.

subject: a teljes megkülönböztető név, karakterről karakterre

Ha nincs típus megadva, az alapértelmezett subject esetén a várt értéknek a tanúsítvány teljes subject-DN-jét vissza kell adnia. A mezősorrend, az elválasztók, a szóközök és az escaping mind számítanak, mert az összehasonlítás a kódolt karakterláncon fut. Ha kihagyja a típust, a három összehasonlítás közül a legszigorúbbat választotta. Nincs normalizálási lépés, amely megmentene egy kozmetikai különbséget. Ezt az első megújítás előtt érdemes tudni, nem utána.

Ez a szigorúság megújításról megújításra törékeny. Egy CA, amely átrendezi az attribútumokat, extra mezőt szúr be, vagy megváltoztatja egy érték escapingjét, új karakterláncot állít elő ugyanahhoz a géphez, és egy évekig működő direktíva a következő kiadásnál elkezd elbukni. Az elfogadott DN változási naplóban tartása a következő megújítást egyszerű különbséggé teszi. Ahol az üzemeltető teljes DN-t tesz közzé és garantálja annak formáját, ott a subject ésszerű választás; másutt egy szűkebb mező könnyebben tartható igaznak.

name: egy mező, általában a köznapi név

A típus name egyetlen subject-mezőt hasonlít össze. Hacsak a profil mást nem mond, ez a mező a köznapi név, és a várt érték pontosan ez a mező, nem a körülötte lévő DN.

A csapda az, hogy a modern tanúsítványok nem mindig a CN-be teszik a szolgáltatás nevét. Sokuk a subject alternatív nevében hordozza, és a CN-t üresen vagy általánosan hagyja, így egy böngésző által elfogadott tanúsítvány mégis elbukhat ezen az összehasonlításon. Az elvárás megírása előtt vizsgálja meg a ténylegesen kiállított tanúsítványt, és erősítse meg, melyik mezőt választja a profil. Az üres CN és egy név összehasonlítása eltérés, nem konfigurációs baleset.

name-prefix: szándékosan széles, ezért határolja be

Egy name-prefix típusú elvárás a kiválasztott mező elejére illeszkedik. Ez kényelmes egy elnevezési sémához, és veszélyes mindenhez, ami megosztott.

Ha az elvárás vpn.example, akkor mind a vpn.example.com, mind a vpn.example.net átmenne, feltéve hogy a lánc többi része megbízható. A szélesség a funkció, és egyben az a rész, amelyet írásban indokolni kell. Az előtag ésszerű, ha a CA és az elnevezési séma az Öné, és sokkal gyengébb, ha egy nyilvános CA ugyanabba a mintába állít ki. Ha a sémának rugalmasságra van szüksége, a CA-nál korlátozza, ne a kliensoldali ellenőrzést szélesítse.

Az azonosítóból válassza ki a típust, aztán bizonyítsa be

Az üzemeltető által szándékolt identitástól induljon visszafelé. Ha teljes DN-t tesz közzé és stabilan tartja, subject ezt fejezi ki. Ha a szolgáltatást a köznapi névvel nevezi meg, használja a name. Ha elnevezési sémával rendelkezik és annak teljes terét elfogadja, name-prefix ezt egyértelműen kimondja.

A megújítások azok, ahol a direktíva vizsgázik. A jóváhagyott identitást az új tanúsítványhoz hasonlítsa, ne a régi fájlhoz, mert egy új végpontcím nem jelent új tanúsítvány-identitást. Ne törölje a direktívát csak azért, mert egy ismerős cím válaszol: az elérhetőség és a szándékolt másik fél két különböző tény, és a cím csak azt bizonyítja, hogy valami válaszolt. Rögzítse a pontos hibát és a név nyilvános adatait egy tisztított jelentésben, mert a névegyezés hiánya minden privátkulcs-anyag nélkül kimutatható.

Támogatott javítás után kapcsolódjon újra minden szándékolt ellenőrzéssel, és ellenőrizze az erőforrást, amelyre valóban szüksége van. A siker azt jelenti, hogy a szándékolt kiszolgálót elfogadták, nem azt, hogy valamilyen tanúsítványt átpréseltek. A hivatalos kézikönyv OpenVPN 2.6 manual dokumentálja a három típust és azok megbízhatósági megjegyzéseit, és ez az a hivatkozás, amelyet idézni kell, amikor egy szállítói felület vitatkozik a profillal.