Ugyanaz a ca.crt fájlnév, más tanúsítvány: mit kell összehasonlítani
Két profil eltérő tartalmú ca.crt-t hozhat. Vegyük a folyamat által betöltött tanúsítvány ujjlenyomatát, majd ellenőrizzük, hogy valóban a szándékolt bizalmi horgony-e.
Két profil is hoz egy ca.crt nevű fájlt, az egyik alagút feljön, a másik lánchibával elbukik. A két fájl egymás melletti megnyitása ritkán dönti el, az ellenőrzés kikapcsolása pedig a rossz irányba dönti el. A hiba valójában feltett kérdése szűkebb: melyik tanúsítványt tölti be az egyes folyamat bizalmi horgonyaként, és a kettő ugyanaz az objektum-e? Erre válaszoljunk először, és a diagnózis többi része irányt kap. A fájlnév csomagolási címke, és a profilban írt útvonal sem mérvadó, tehát minden attól függ, mit olvas a folyamat valójában.
Keressük meg a tanúsítványt, amelyet az ügyfél valójában betölt
OpenVPN két formában fogadja el a hatóságot, és a forma dönti el, mely bájtok számítanak. Egy profil hivatkozhat külső fájlra ca használatával, vagy beágyazhatja a tanúsítványt a profil saját <ca> blokkjába. Ha mindkettő létezik, a beágyazott blokk nyer, és a profil mellett lévő fájl soha nem nyílik meg.
Olvassuk el a hibás profilt, és derítsük ki, melyik formát használja, mielőtt bármit összehasonlítanánk. Egy szomszédos könyvtárból vagy abból a csomagból vett másolat, amelyből a másik profil jött, semmit nem mond arról, miben bízik ez a folyamat. Ugyanez vonatkozik a konfigurációban szereplő útvonalra: ahhoz képest oldódik fel, ahol az ügyfél elindult, és ez nem mindig az a könyvtár, amelyet nézünk. A profilt olvassuk, ne a mappát.
A tanúsítványokat a tartalmuk azonosítja: a nyilvános kulcs, a tulajdonos és a kiállító, az érvényességi ablak és a minderre vonatkozó aláírás. Két azonos bájtú fájl ugyanaz a tanúsítvány, bármi is a nevük, és két azonos nevű fájl lehet egymástól független hatóság. A név csomagolási címke, nem identitás.
Vegyük mindkét példány ujjlenyomatát openssl-lel
Az ujjlenyomat a tanúsítvány DER-kódolása feletti hash, az a forma, amelyet az aláírás lefed, így a sorvégek és a fejlécszöveg nem befolyásolhatják. Számítsuk ki minden fájlra, és két kettősponttal elválasztott hexadecimális karakterláncot kapunk, amelyek vagy egyeznek, vagy nem. A tanúsítványban semmi mást nem kell olvasni az összehasonlítás kérdésének megválaszolásához.
openssl x509 -in /etc/openvpn/office/ca.crt -noout -fingerprint -sha256
openssl x509 -in ~/profiles/lab-ca.pem -noout -fingerprint -sha256
Csábító a openssl programot magára a profilra irányítani, de az a fájlban elsőként előforduló tanúsítványblokkot olvassa, és a profil általában <cert> blokkot tartalmaz <ca> előtt. Bontsuk ki a hatóság blokkját, majd vegyük a kinyert fájl ujjlenyomatát, mert az az a példány, amelyet az ügyfél valóban használni fog.
sed -n '/^<ca>$/,/^<\/ca>$/p' office.ovpn | sed '1d;$d' > /tmp/office-ca.pem
openssl x509 -in /tmp/office-ca.pem -noout -fingerprint -sha256
Az azonos ujjlenyomatok azt jelentik, hogy a bizalmi anyag ugyanaz, és a lánchibának más oka van, ami más vizsgálat. A különböző ujjlenyomatok különböző tanúsítványokat jelentenek, és itt kezdődik a következő szakasz.
Olvassuk el az eltérést, mielőtt támadást feltételeznénk
A különböző ujjlenyomatok különböző tanúsítványokat jelentenek, és semmi többet. Az újrakiadás, a rotáció, az átnevezett hatóság vagy az elavult köteg mind más fájlokat eredményez teljesen legitim előzményekkel. Hogy melyik tartozik a telepítéshez, az az üzemeltető vagy a telepítési nyilvántartás kérdése, nem a fájl módosítási idejéé. Az archívumok másolják az időbélyegeket, ezért egy újabb fájl nem automatikusan a helyes horgony.
Az önmagát aláíró gyökér normális, ezért egy ilyen megtalálása nem bizonyíték problémára. Az ellenőrző feladata, hogy utat építsen a szerver tanúsítványától a kapott horgonyig, és a lánchiba általában azt jelenti, hogy ez az út nem volt befejezhető.
Ellenőrizzük, hogy a hibás profil horgonya olyan hatóság-e, amelyből a telepítés még kiad. Ha az ujjlenyomat semmivel nem egyezik a telepítési nyilvántartásban, a profil egyszerűen elavult, és semmilyen ügyféloldali hangolás nem javítja ezt.
Javítsuk a bizalmat az ellenőrzés kikapcsolása nélkül
A rövid távú megoldás az ellenőrzés kikapcsolása vagy a lánc minden tanúsítványának horgonyként való hozzáadása. Mindkettő eltünteti az üzenetet, és mindkettő megváltoztatja, hogy az ügyfél ezentúl mely szervereket fogadja el. Kapcsoljuk vissza az ellenőrzést, telepítsük a szándékolt horgonyt, és teszteljünk újra.
Ha a lánc most felépül, de más hiba jelenik meg, az előrelépés: a névellenőrzés, az érvényességi dátumok és a visszavonás külön ellenőrzések külön üzenetekkel. Tartsuk az ujjlenyomat-párt és az eredeti hibaszöveget együtt a jegyben, hogy a következő ember lássa, melyik horgony töltődött be és melyiket várták. Egy ujjlenyomat-pár elég kicsi ahhoz, hogy beillesszük egy átadási feljegyzésbe, és a következő eset akkor öt percet vesz igénybe egy délután helyett.
A megfelelő hatóságot ugyanazon hitelesített csatornán szerezzük be, amely a profilt szállította. Tanúsítványt lehúzni a szerverről, mert a tulajdonosa ismerősnek tűnik, más cselekedet, és csendesen kiterjeszti, miben fog bízni az ügyfél.