Easy-RSA diras, ke la PKI mankas? Ĝi serĉas aliloke

La komando haltas pro mankanta ca.crt aŭ mankanta index.txt, dum la CA eldonas atestilojn jam de monatoj. Nenio ŝanĝiĝis pri la aŭtoritato; la komando simple rigardis aliloke. Easy-RSA 3 derivas PKI-dosierujon el opcio, medivariablo, vars-dosiero kaj enkonstruita defaŭlto, kaj iu ajn el tiuj povas montri for de la aŭtoritato de la deplojo. Kontrolu, kiu venkis, antaŭ ol vi kreu ion ajn.

La eraro nomas dosieron, ne dosierujon

La instal-dosierujo kaj la eldonanta dosierujo estas du malsamaj lokoj. Trovi easyrsa sur la maŝino pruvas nur, ke la ilo estas instalita, ne ke ĝi trovis la aŭtoritaton, kiun via VPN fidas.

Tial reinstali la pakaĵon aŭ relanĉi la init-paŝon ŝajnas produktiva kaj ŝanĝas nenion.

Kontrolu la elektilon antaŭ ĉio alia

En Easy-RSA 3 la elektilo estas EASYRSA_PKI aŭ la kongrua --pki-dir-opcio. Donu absolutan vojon kiel --pki-dir=/srv/pki/office, kaj la respondo ĉesas dependi de tio, kie vi hazarde staris. Tiu unu kutimo forigas tutan klason de ĉi tiu cimo, precipe por skriptoj lanĉitaj el cron aŭ el CI-kontrolejo.

Unue konfirmu la generacion, ĉar la kutimo de Easy-RSA 2 kun vars-dosiero plus build-key estas alia modelo ol tiu, kiun Easy-RSA 3 atendas. easyrsa --version presas la generacion antaŭ ol fari ion alian, kaj ./easyrsa --help listigas la subkomandojn: celo build-key signifas 2.x, dum build-client-full signifas 3.x. Porti malnovan KEY_DIR-vojon en 3.x-vokon ĉar la dosieruja nomo aspektas konata produktas ĝuste ĉi tiun eraron.

Se la versia ĉeno kaj la komanda sintakso malkongruas, haltu kaj legu la dokumentaron de la instalita eldono.

Prioritato klarigas perditan vars-dosieron

La dokumentita prioritato estas komandlinia opcio, poste medio, poste vars-dosiero, poste enkonstruita defaŭlto. Sekve ĝusta valoro en vars perdas al heredita medivariablo, kaj tio estas la silenta versio de ĉi tiu fiasko. Ekzamenu la celitajn variablojn kaj la dosierelektadon anstataŭ verŝi la tutan medion en tickets. La diferenco inter la du kutime estas sekreto.

Trairu la ĉenon laŭorde kaj notu, kiu fonto liveris la vojon, kiun la komando uzis. Post kiam vi tion scias, la solvo estas flago aŭ export, ne nova atestila aŭtoritato.

La konfigura referenco de Easy-RSA difinas la elektilon kaj la prioritaton, kaj ĝi estas la citaĵo por meti en la tickets.

Konfirmu la eldonanton per publika materialo

Ĉe la kutima dosierbazita eldonanto, legu ca.crt kaj kongruigu ĝian fingrospuron kun la eldonanta rikordo, kiun vi aprobis. Kongrua subjekta nomo ne estas identeca pruvo, nek dosierujo nomata production. Nur la fingrospuro ligas la trovitan dosieron al la aŭtoritato, kiun oni diris al viaj samtavolanoj fidi.

Sufiĉas kontrola legado: openssl x509 -in /srv/pki/office/ca.crt -noout -subject -issuer -serial -fingerprint -sha256.

Poste establu la rolon de la dosierujo. Petodosierujo, kiun kliento uzas, ne estas eldonanta datumbazo, kaj subskriba ŝlosilo tenata eksterrete nenion havas en ĉiu VPN-gastiganto. Mankanta ca.key estas dezajna eco en tiu aranĝo, ne permeso elpensi anstataŭan aŭtoritaton.

Se la stato vere malaperis

Kelkfoje la vojo estas ĝusta kaj la stato vere ne estas tie. Malplena index.txt kaj restartigita seria nombrilo donas al vi PKI, kiu aspektas sana kaj povas pruvi nenion pri la atestiloj, kiujn ĝi neniam vidis: renovigoj ne revokos la malnovajn, kaj la novaj numeroj kolizios kun la historio. Restaŭru anstataŭe el la aprobita sekurkopio de la CA, ĉar pravigado de malplena PKI aliloke nur movas la eraron kaj lasas duan, senrilatan aŭtoritaton malantaŭe.

Post kiam la vojo kaj la eldonanto kongruas, traktu la sekvan fiaskon laŭ ĝia esenco. Permission denied, subskriba ŝlosilo bezonanta sian pasfrazon, kaj mankanta eldona rikordo estas tri malsamaj difektoj, kaj nur unu el ili temas pri la dosierujo, kiun vi ĵus riparis.

Neniam forigu ŝlosilan ĉifradon aŭ larĝigu dosierujajn permesojn por kaŝi vojeraron. La eraro estas malmultekosta ripari; la riparo ne.