Easy-RSA-registreringsfeil i Windows: kontroller registreringsvisningen

Batchfilen stopper med meldingen «Systemet fant ikke den angitte registreringsnøkkelen eller -verdien», og alle antar at sertifiseringsmyndigheten er ødelagt. Det er den ikke, eller i det minste ikke ennå: skriptet feilet mens det lette etter programvare, før det ba Easy-RSA gjøre noe som helst med en nøkkel. Den rekkefølgen betyr noe, fordi den betyr at reparasjonen er et søkeproblem og at PKI-et bare er tilskuer. Å lese linjen som feiler er hele diagnosen, og det tar kortere tid enn noen av omveiene.

Feilen oppstår før CA-en berøres

Gamle Easy-RSA 2-batchfiler finner OpenSSL eller installasjonen av OpenVPN ved å spørre registeret, og setter deretter variabler ut fra det de finner. Når spørringen ikke returnerer noe, avbryter skriptet før noen sertifikatoperasjon kjøres.

En melding om en registreringsnøkkel er derfor bevis om skriptets miljø, ikke om CA-mappen.

To registreringsvisninger, én batchfil

En 32-bit-prosess og en 64-bit-prosess kan se ulike registreringsvisninger, og en batchfil som forutsetter den ene, kan overse oppføringen som finnes i den andre. Disse skrivebeskyttede sammenligningene viser forskjellen for den gamle nøkkelen som noen gamle skript bruker:

reg query "HKLM\SOFTWARE\OpenVPN" /reg:32
reg query "HKLM\SOFTWARE\OpenVPN" /reg:64

Referansen for reg query dokumenterer visningsvelgerne. Kjør begge i samme kontekst som skriptet som feilet, fordi visningen avhenger av hvordan prosessen startes, og av flaggene. Hvis oppføringen bare finnes i én visning, sammenlign stien den peker på med de installerte verktøyene før du endrer noe. En nøkkel som finnes, men peker på en gammel installasjonsmappe, er en annen feil enn en nøkkel som mangler.

Hvis ingen av visningene har oppføringen, har installasjonsprogrammet aldri opprettet den, og en håndlaget verdi får ikke verktøyene til å virke.

Ikke legg til /reg:64 ubetinget

Den fristende rettelsen er å legge 64-bit-velgeren til hver spørring og gå videre. På noen installasjoner er det riktig, på andre sender det skriptet til en visning som virkelig ikke har noe.

Endre søket først etter at du har sett hvilken visning som har den forventede verdien.

Å finne frem er ikke PKI-reparasjon

Denne feilen beviser ikke at CA-sertifikatet, signeringsnøkkelen, serienummerfilen eller tilbakekallingsdatabasen er skadet. Å kjøre en clean-all kopiert fra en gammel veiledning ville ødelagt et helt annet sett med objekter og latt søket være ødelagt. Hold de to aktivitetene adskilt i hodet og i saken. Hvis en sertifikatoperasjon senere feiler, vurder den ut fra sine egne bevis.

Ta sikkerhetskopi av CA-mappen før ethvert eksperiment, også et du er sikker på bare leser.

Å flytte til Easy-RSA 3 er en migrering

En vedlikeholdt installasjon bør bruke den gjeldende pakkens egen oppstarter og konfigurasjonsmodell, og Easy-RSA 3 er ikke samme batchfil-arbeidsflyt som Easy-RSA 2. Hurtigstarten for et nytt PKI er ikke en migreringsinstruks for en eksisterende myndighet. Før du bytter versjon, bevar CA-materialet samt utstedelses- og tilbakekallingsregistrene, og følg oppgraderingsveiledningen for den versjonen. Å initialisere en erstatnings-CA inne i den autoritative mappen for å få en verktøysøkefeil til å forsvinne er det dårligste alternativet på listen.

En versjonsendring er et prosjekt; registreringsfeilen er en ettermiddag.

Sammenligningen som faktisk løser det

Skriv ned fire ting og sammenlign dem direkte:

• Hvilket skript som kjørte, og hvilken linje som feilet.
• Hvilken registreringsvisning den linjen spurte.
• Hvilken kjørbar sti skriptet forventet.
• Hvilken installasjon som faktisk finnes på maskinen.

Når de fire stemmer, er feilen borte, og ethvert gjenværende sertifikatproblem kan leses ut fra sine egne bevis i stedet for å gi CA-en skylden.