Webes tanúsítvány hiba az Access Serveren: az üres CA-csomag

Az üres ca_bundle érték vagy a sérült PEM megállítja az Admin felületet. A tanúsítványt, kulcsot és láncot egy készletként ellenőrizze újraindítás előtt, és hagyja békén a VPN PKI-t.

A webes bejelentkező oldal, amely nem töltődik be, miközben a DNS helyesen oldódik fel, általában nem DNS-probléma. Ha a szolgáltatás naplója üres tanúsítványcsomag-útvonalat vagy a webes tanúsítvány és a titkos kulcs PEM-elemzési hibáját említi, a HTTPS-figyelőnek nincs használható anyaga, és semmilyen névfeloldás nem segít. A javítás három konfigurációs kulcsban van, és nem igényel egyetlen VPN-ügyféltanúsítvány újrakibocsátását sem.

Mire mutat valójában a három kulcs

Az egyéni webes tanúsítványkészletet a cs.cert, cs.priv_key és cs.ca_bundle írja le. Mindegyik egy fájl útvonalát tárolja, és a webes szolgáltatás mindhármat együtt használja. A rossz kulcsú tanúsítvány, vagy az a láncfájl, amely valójában a levéltanúsítvány, ugyanúgy meghiúsul, mint egy üres érték: a figyelő nem tud olyan láncot építeni, amelyet a böngésző elfogad.

Ezek a kulcsok az Admin és a Client webes felülethez tartoznak. Elkülönülnek attól a PKI-tól, amely a VPN-ügyfeleknek tanúsítványt ad ki, ezért cseréjük nem érinti az ügyfélprofilokat, a kiszolgálókulcsot vagy a tanúsítványhatóságot. A webes TLS-hibát a teljes PKI újjáépítése okának tekinteni a legdrágább tévedés itt.

Egy megkülönböztetés időt takarít meg: a kifejezetten üres egyéni érték nem ugyanaz az állapot, mint a felülírás teljes hiánya. Az első üres útvonalat ad az elemzőnek, ezt mondja a naplósor. A második a saját anyagán hagyja az Access Servert, ezért indulnak egyes gazdagépek frissítés után jól, mások pedig nem.

Miért nem elemezhető a létező fájl

Az elemző a fájlon belüli címkézett blokkokat olvassa, nem a fájlnevet. A titkos kulcsot tartalmazó .crt, az egyetlen tanúsítvány helyén egyetlen összefűzött blokként írt lánc, vagy a csonkolt utolsó sorral mentett fájl mind elutasításra kerül. Az RFC 7468 azért definiálja ezeket az olvasható címkéket, mert egyedül ezek mondják meg az olvasónak, milyen típusú objektum következik.

Az objektumokat vizsgálja, nem a kiterjesztéseket. Linux-gazdagépen a openssl x509 -noout -subject -issuer -in server.pem és a openssl pkey -noout -check -in key.pem válaszol a két fontos kérdésre, és a modulus vagy a nyilvános kulcs összehasonlítása bizonyítja, hogy összetartoznak. Tartsa a titkos kulcs kimenetét jegyeken és csevegésnaplókon kívül; az ellenőrzéshez ujjlenyomat kell, nem a kulcs.

Az üres útvonal ugyanannyi gyanút érdemel, mint a sérült fájl, mert mindkettő homályos további hibákat okoz. Ha a napló szerint a csomag útvonala üres, olvassa ki a tárolt értéket, mielőtt a fájlt hibakeresné.

Szándékosan lépjen vissza a tartalékra

Az Access Server CLI-je tartalmaz egy ellenőrzést, amely a három útvonalat argumentumként veszi, és jelzi, hogy a készlet használható-e. Az alábbi útvonalak szemléltetőek; cserélje ki őket a gazdagép védett helyeire:

sacli --ca_bundle=/secure/webcerts/chain.pem \
      --cert=/secure/webcerts/server.pem \
      --priv_key=/secure/webcerts/key.pem TestWebCerts

Olvassa el az eredményt, mielőtt hozzányúlna a futó szolgáltatáshoz, és csak ezután importálja az értékeket, majd alkalmazza őket a telepített verzió dokumentált műveletével. A hivatalos CLI-útmutató lefedi az ellenőrzést, a konfigurációs adatbázisba történő importálást és az alkalmazás lépését, és a verziója többet számít minden összefoglalónál.

Ellenőrizze a nevet, amit a felhasználók beírnak

Ha az egyéni anyag sérült, és még létezik érvényes beépített tartalék, a dokumentált helyreállítás a három egyéni felülírás eltávolítása, és az Access Server használhatja a tartalékot. Előbb biztosítson konzolhozzáférést és biztonsági mentést a jelenlegi konfigurációról, mert a szolgáltatás, amelyet újraindít, az adminisztrációs felületet szolgálja ki.

sacli ConfigDel --key "cs.cert"
sacli ConfigDel --key "cs.priv_key"
sacli ConfigDel --key "cs.ca_bundle"
# then the supported apply/restart step for this version

A teljes konfigurációs adatbázis törlése nem tanúsítvány-javítás. Célozza meg azt a három kulcsot, alkalmazza, és erősítse meg, hogy a webes felület válaszol. A web-ssl könyvtárban lévő önaláírt fájlok a tartalék erőforrás, nem munkaterület: felülírásuk vagy újragenerálásuk eltávolíthatja az egyetlen működő anyagot.

Számítson rá, hogy a böngésző más tanúsítványt mutat, miután a tartalék érvénybe lép. Ez a helyes eredmény, és a válasz az, hogy a megbízható adminisztratív folyamatán keresztül ellenőrizze, ne pedig arra tanítsa a felhasználókat, hogy minden figyelmeztetést átkattintsanak.

A helyreállítás csak sikeres bejelentkezés után ér véget

A helyreállítás nem ér véget, amikor megjelenik egy TCP-figyelő. Ellenőrizze a DNS-nevet, a tanúsítvány identitását és a névhez tartozó láncot, majd töltse be az Admin és a Client webes felületet, és fejezzen be egy bejelentkezést. A portellenőrzés ezek egyikét sem bizonyítja.

Az Access Server 3.1 és újabb verziói SNI-gazdagépnévenként eltérő webes tanúsítványokat is kiszolgálhatnak. Ha ez be van állítva, az alapértelmezett kulcsok és a névspecifikus bejegyzések külön készletek, és az IP-cím szerinti tesztelés könnyen más tanúsítványt mutat, mint amit a felhasználók kapnak. Javítsa és ellenőrizze a meghiúsult név készletét, majd ismételje meg a bejelentkezési tesztet az incidens lezárása előtt.

Kapcsolódó cikkek