Megújított VPN-tanúsítvány: egyes kliensek még mindig elutasítják

A környezet fele újracsatlakozik a megújítás után, három eszköz pedig elutasít, mindegyik figyelmeztetéssel az átjáró identitásáról. Maga a megújítás rutinmunka. Amit ez a három eszköz tart, az a régi objektumhoz rögzített ujjlenyomat, és a rögzítés nem CA-lista, nem névellenőrzés és nem bizalmi tároló bejegyzés. Hasonlítsa össze a három mechanizmust, mielőtt bármelyik klienshez nyúl.

Egy megújítás, két viselkedés

Az újracsatlakozó kliensek bizalmi döntése még átmegy, az elutasítók viszont olyan követelménnyel rendelkeznek, amelyet az új tanúsítvány nem teljesít. Ez a különbség információ, nem zaj. Olvassa el pontosan a hibát jelző kliens üzenetét. A névütközés, az ismeretlen kibocsátó és a megváltozott ujjlenyomat három különböző ítélet, és csak az utolsó mutat rögzítésre.

Azt is ellenőrizze, melyik profilt választotta a hibát jelző kliens. A saját tárolóban élő importált másolat nem változik, amikor az adminisztrátor máshol szerkeszti az eredeti fájlt.

A megújítás az objektumot cseréli, nem csak a dátumot

Az ujjlenyomat a kódolt tanúsítványtartalmat azonosítja. A megújítás új tanúsítványt hoz létre, ezért az ujjlenyomat akkor is megváltozik, ha a tulajdonos neve és a nyilvános kulcs azonos marad. Ez várható és ártalmatlan azoknál a klienseknél, amelyek megbíznak egy CA-ban és ellenőrzik a nevet. Végzetes viszont annál a kliensnél, amelyet pontosan egy tanúsítvány elfogadására állítottak be, és annál is, amelynek bizalmi tárolója sosem kapta meg az új kibocsátót.

openssl x509 -in server.pem -noout -subject -issuer -dates -fingerprint -sha256
openssl x509 -in server.pem -noout -pubkey | openssl sha256

A második sor más kérdésre válaszol: túlélte-e a kulcspár. Az a megújítás, amely újrahasznosítja a kulcsot, megtartja ezt az értéket, és csak a tanúsítványt cseréli, és éppen ez az az eset, amikor az adminisztrátor hajlamos azt feltételezni, hogy semmi sem változott. A telepített tanúsítványt vizsgálja, ne a build hoszton lévőt. Egy tárolóban lévő fájl összehasonlítása azt bizonyítja, mit állítottak elő, nem azt, mit mutat éppen egy figyelő.

Olvassa el, mit rögzít a kliens

Egyes kliensek a profiljukban tartanak ujjlenyomatot, és minden kapcsolatnál összehasonlítják. Mások platform bizalmi tárolóban tárolják, megint mások csak egy CA-ra támaszkodnak. A javítás minden esetben más, ezért először azonosítsa a mechanizmust.

grep -n 'peer-fingerprint' /etc/openvpn/client/*.conf
openssl s_client -connect gw.lab.example.net:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -fingerprint -sha256

Az első parancs egy hagyományos profilban lévő rögzítést mutat; a második azt az ujjlenyomatot, amelyet a végpont éppen most kiszolgál. Ha a kettő eltér, kitalálás nélkül megtalálta a hibát. Ne illessze be az új értéket minden panaskodó kliensbe. A kibocsátó miatt elutasító kliens továbbra is el fog utasítani, és Ön azt tanulta meg, hogy az ujjlenyomat volt a probléma, amikor nem az volt.

Hasonlítsa össze az egyes backendek által kiszolgált tanúsítványt

A szakaszos eredmények általában egynél több végpontot jelentenek, és az egyik csomópontra alkalmazott megújítás a többieket a régi objektumot bemutatva hagyja. Hasonlítsa össze az egyes backendeket cím szerint, ne a közös név szerint.

for h in 10.30.0.11 10.30.0.12; do echo "$h"; openssl s_client -connect $h:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -subject -dates -fingerprint -sha256; done

Az a pool, amelyben az egyik csomópont lemarad, megmagyarázza azt a klienst, amely a második próbálkozásra csatlakozik, és az elsőre elbukik. Azt a monitorozási ellenőrzést is megmagyarázza, amely átmegy, miközben a felhasználók panaszkodnak. Először a lemaradást javítsa. A bizalmi konfiguráció átforgatása azelőtt, hogy minden csomópont az új tanúsítványt szolgálná ki, olyan ablakot teremt, amelyben semmi sem működik, az utána történő átforgatás pedig kiszámíthatatlanul hibázó klienseket hagy.

A bizalmat a kezelt úton változtassa meg

Megerősítse a cserét egy már megbízható adminisztratív csatornán, mielőtt bárhol elfogadná. A hihető lejárati dátum nem tulajdonjogi bizonyíték. A kezelt konfigurációt az azt birtokló folyamaton keresztül frissítse, az elfogadható identitások tervezett átfedésével, és tartsa meg a telepítés által megkövetelt névellenőrzést. A névellenőrzés nélküli rögzítés gyengébb kialakítás, mint az a CA-bizalom, amelyet felváltott.

Ezután kliensenként ellenőrizze: csatlakozzon, erősítse meg az elfogadott identitást, és jegyezze fel a tanúsítványverziót, amelyben most megbízik. Az egyszer elutasított figyelmeztetés hajlamos visszatérni a következő megújításnál.