openssl ca: érvénytelen lejárati dátum az index.txt fájlban, és hogyan javítsuk

Egy kiállítási futás itt áll meg: entry 22: invalid expiry date, pedig az előtted lévő kérés teljesen rendben van. A panasz a CA adatbázisának elemzőjétől jön, nem a CSR-től és nem attól a VPN-kliensből, amely végül bemutatja majd a tanúsítványt. Ez a megkülönböztetés határoz meg minden utána következőt: a rekord hibás, ezért a javítás a CA állapotába tartozik, nem a kérésbe vagy a partner konfigurációjába. Tekintse a számozott bejegyzést az index.txt egy sorának, és a probléma leszűkül egy körülhatárolt adatkérdésre, amelyre ellenőrizhető válasz adható.

Olvassa a hibát az adatbázis panaszaként

Minden openssl ca hívás végigfut a szöveges adatbázisán, mielőtt bármit aláírna. Minden sor tartalmaz egy állapotbetűt, egy lejárati időbélyeget, egy opcionális visszavonási időbélyeget, egy sorszámot hexadecimálisan, egy fájlnevet és a tárgyat. Amikor egy mező nem elemezhető, a parancs jelenti a sorszámot, és megáll ahelyett, hogy a rekord többi részére találgatna.

Ez a megállás védő, nem pedáns. Egy rekord, amelyet az eszköz nem tud elolvasni, képtelenné teszi annak eldöntésére, hogy a kért tárgy már létezik-e, kiadtak-e sorszámot, vagy mit kell tartalmaznia a következő CRL-nek. Egy rossz soron túllépve pontosan az a csendes ellentmondás keletkezne, amely hónapokkal később, rendszerint egy megmagyarázhatatlan visszavonás során bukkan fel. Olvassa az üzenetet az adatokra vonatkozó panaszaként, és a vizsgálat a CA könyvtárán belül marad.

Másolja le a CA állapotát, mielőtt bármihez hozzányúlna

Készítsen pillanatképet a teljes CA könyvtárról, ne csak az adatbázisfájlról. Az index, annak attribútumfájlja, a sorszám- és CRL-számfájlok, a privát kulcs és a kiadott tanúsítványok mind részt vesznek a későbbi műveletekben, és az a javítás, amely egyet helyreállít, a többit pedig kihagyja, második incidenst teremt. Használja a CA saját biztonsági mentési rutinját, ahol van ilyen, és a munka idejére szüneteltesse az ütemezett kiállítást.

Jegyezze fel az OpenSSL-buildet és a konfigurációs fájlt, amelyet a sikertelen parancs ténylegesen betöltött. A telepítések gyakran egynél több CA könyvtárat tartanak, és a hiba csak ahhoz az adatbázishoz képest jelent valamit, amelyet a kiválasztott konfiguráció megnevez.

Keresse meg a bejegyzést, és fejtse vissza a dátummezőjét

A jelzett sorszámot az első rekordtól számoljuk, ezért a sed -n '22p' index.txt akkor esik a hibás bejegyzésre, ha megerősítette, hogy felette nincsenek üres sorok vagy megjegyzések. Nyomtassa ki azt a sort látható elválasztókkal, mert a tabulátorok és a záró szóközök gyakoriak, és egy hétköznapi szerkesztőablakban láthatatlanok.

A lejárati mező egy időbélyeg, amelynek szélessége az évtől függ. A 2049-ig tartó értékeket UTCTime formában írják, így: YYMMDDHHMMSSZ, a későbbi értékek pedig áttérnek a négyszámjegyű évet használó GeneralizedTime formára. Az a rekord, amely keveri a két formát, vagy kétjegyű évet hordoz ott, ahol az elemző most négyet vár, pontosan ezen a ponton bukik el. Ugyanígy a megszakadt írás nyomán maradt csonka mező is.

Hasonlítsa a rekordot ahhoz a tanúsítványhoz, amelyre hivatkozik, ne egy másik CA fájljához. Az aláírt tanúsítvány a mérvadó abban, hogy mit kell mondania az érvényességnek, és már elemezhető objektumként létezik.

Javítsa a rekordot az aláírt tanúsítvány alapján

Olvassa ki a valódi dátumokat ezzel: openssl x509 -in issued.pem -noout -dates -serial -subject. Alakítsa át a notAfter értékét arra az időbélyeg-szélességre, amelyet a buildje arra az évre ír, és még egyetlen karakter megváltoztatása előtt erősítse meg, hogy a sorszám megegyezik a szerkesztésre váró bejegyzéssel.

Csak a hibás mezőt szerkessze, tartsa meg az állapotbetűt és a sorszámot, a sor többi részét pedig hagyja békén. Ha a rekord egyetlen aláírt tanúsítvánnyal sem egyeztethető, tekintse tévelygő bejegyzésnek, és a CA saját visszavonási útvonalán keresztül vonja ki, ahelyett hogy kézzel törölné a sort.

Ne úgy javítsa, hogy levágja a dátumot egy évre vonatkozó találgatáshoz. A kétkarakteres vágás nem hordozható a buildek között, és csendesen megváltoztatja azt az érvényességet, amelyet az adatbázis a jövőbeli duplikált tárgy- és CRL-ellenőrzéseknek jelent. Amikor az eredeti érték nem állítható helyre, adja ki újra új sorszámmal és jegyezze fel, miért hagyták el a régit. Az auditnyom a javítás része, nem a körülötte lévő papírmunka.

Ellenőrizze a kiállítást és a CRL generálását, mielőtt elmegy

Futtasson egy kiállítást ugyanazzal a konfigurációval, és erősítse meg, hogy sorszámpanasz nélkül végződik. Ezután generáljon CRL-t ezzel: openssl ca -gencrl -config openssl.cnf és ellenőrizze, hogy elemezhető, mert a sérült rekord gyakran éppen ott bukkan fel, nem az aláíráskor.

Vizsgálja meg az új tanúsítványt ezzel: openssl x509 -noout -dates -serial és hasonlítsa össze azzal a sorral, amelyet a CA éppen írt. Erősítse meg, hogy az állapotbetű és a lejárati dátum egyezik a tanúsítvánnyal, és azt is, hogy a openssl verify -CAfile ca.pem issued.pem hiba nélkül tér vissza. Ezután állítsa vissza az ütemezett kiállítást, és figyelje az első futást, mert egy második hibás sor azonnal jelentkezni fog.