openssl ca: nevalida findato en index.txt kaj kiel ripari ĝin

Eldona kuro haltas ĉe entry 22: invalid expiry date, kaj la peto antaŭ vi tute bonas. La plendo venas de la analizilo de la CA-datumbazo, ne de la CSR kaj ne de la VPN-kliento, kiu fine prezentos la atestilon. Tiu distingo decidas ĉion post ĝi: rikordo estas misformita, do la riparo apartenas al la stato de la CA, ne al la peto nek al la agordo de la samtavolano. Traktu la numeritan rikordon kiel linion en index.txt, kaj la problemo ŝrumpas al limigita datuma demando kun kontrolebla respondo.

Legu la eraron kiel plendon pri la datumbazo

Ĉiu openssl ca alvoko trapasas sian tekstdatumbazon antaŭ ol subskribi ion ajn. Ĉiu linio enhavas statusliteron, findatan tempostampon, laŭvolan revoktempostampon, serian numeron en deksesuma formo, dosiernomon kaj la subjekton. Kiam unu kampo ne analizeblas, la komando raportas la linnumeron kaj haltas anstataŭ diveni la reston de la rikordo.

Tiu halto estas protekta, ne pedanta. Rikordo, kiun la ilo ne povas legi, lasas ĝin nekapabla decidi ĉu la petita subjekto jam ekzistas, ĉu seria numero jam estis donita, aŭ kion la sekva CRL enhavu. Daŭrigo preter malbona linio produktus ĝuste tiun silentan malkoherecon, kiu aperas monatojn poste, kutime dum revoko, kiun neniu povas klarigi. Legu la mesaĝon kiel plendon pri la datumoj, kaj la esploro restas ene de la CA-adresaro.

Kopiu la staton de la CA antaŭ ol tuŝi ion

Faru momentkopion de la tuta CA-adresaro, ne nur de la datumbaza dosiero. La indekso, ĝia atributa dosiero, la dosieroj de seria numero kaj de CRL-numero, la privata ŝlosilo kaj la eldonitaj atestiloj ĉiuj partoprenas en postaj operacioj, kaj riparo, kiu restarigas unu kaj preterlasas la aliajn, kreas duan incidenton. Uzu la propran sekurkopiadan rutinon de la CA, kie ĝi ekzistas, kaj paŭzigu la planitan eldonadon dum la laboro.

Notu la OpenSSL-buildon kaj la agordan dosieron, kiujn la malsukcesinta komando efektive ŝargis. Instalaĵoj ofte tenas pli ol unu CA-adresaron, kaj la eraro signifas ion nur rilate al la datumbazo, kiun nomas la elektita agordo.

Trovu la rikordon kaj malĉifru ĝian datuman kampon

La raportita linnumero kalkuliĝas de la unua rikordo, do sed -n '22p' index.txt falas sur la malbonan rikordon post kiam vi konfirmis, ke ne estas malplenaj linioj aŭ komentoj supre. Presu tiun linion kun videblaj disigiloj, ĉar taboj kaj finaj spacoj oftas kaj estas nevideblaj en ordinara redaktila fenestro.

La findata kampo estas tempostampo, kies larĝo dependas de la jaro. Valoroj ĝis 2049 skribiĝas en UTCTime kiel YYMMDDHHMMSSZ, dum pli postaj valoroj transiras al GeneralizedTime kun kvarcifera jaro. Rikordo, kiu miksas la du formojn, aŭ kiu portas duciferan jaron tie, kie la analizilo nun atendas kvar, malsukcesas ĝuste ĉe tiu punkto. Same kiel tranĉita kampo, kiun postlasis interrompita skribo.

Komparu la rikordon kun la atestilo, al kiu ĝi rilatas, ne kun la dosiero de alia CA. La subskribita atestilo estas la aŭtoritato pri tio, kion la valideco devus diri, kaj ĝi jam ekzistas kiel analizebla objekto.

Riparu la rikordon laŭ la subskribita atestilo

Legu la verajn datojn per openssl x509 -in issued.pem -noout -dates -serial -subject. Konvertu notAfter al la stampa larĝo, kiun via buildo skribas por tiu jaro, kaj konfirmu, ke la seria numero kongruas kun la rikordo, kiun vi baldaŭ redaktos, antaŭ ol ŝanĝi unu signon.

Redaktu nur la rompitan kampon, konservu la statusliteron kaj la serian numeron, kaj lasu la reston de la linio trankvila. Se la rikordo ne kongruigeblas kun iu ajn subskribita atestilo, traktu ĝin kiel erarvagan rikordon kaj eligu ĝin per la propra revokvojo de la CA anstataŭ forigi la linion permane.

Ne ripari per tondado de dato por konformiĝi al konjekto pri la jaro. Du-signa tranĉo ne porteblas inter buildoj, kaj ĝi silente ŝanĝas la validecon, kiun la datumbazo raportas al estontaj kontroloj de duobla subjekto kaj CRL. Kiam la origina valoro nereakireblas, reeldonu sub nova seria numero kaj skribu, kial la malnova estis forlasita. La revizia spuro estas parto de la riparo, ne paperaĵoj ĉirkaŭ ĝi.

Kontrolu eldonadon kaj CRL-generadon antaŭ ol foriri

Rulu unu eldonadon kun la sama agordo kaj konfirmu, ke ĝi finiĝas sen plendo pri linnumero. Poste generu CRL per openssl ca -gencrl -config openssl.cnf kaj kontrolu, ke ĝi analizeblas, ĉar difektita rikordo ofte montriĝas ĝuste tie, ne dum la subskribado.

Inspektu la novan atestilon per openssl x509 -noout -dates -serial kaj komparu ĝin kun la linio, kiun la CA ĵus skribis. Konfirmu, ke la statuslitero kaj la findato kongruas kun la atestilo, kaj konfirmu, ke openssl verify -CAfile ca.pem issued.pem revenas sen eraro. Poste restarigu la planitan eldonadon kaj observu la unuan kuron, ĉar dua misformita linio anoncos sin tuj.