OpenVPN-nøkkelforespørsel etter OpenSSL 3: sjekk leverandøren

Ingen har rørt profilen, likevel krever den samme klienten nå en passfrase for den private nøkkelen hver gang den starter. Når den endringen kommer innen få dager etter en oppgradering av distribusjonen, er oppgraderingen den sannsynlige årsaken: OpenSSL 3 omorganiserte algoritmestøtten sin, og en nøkkel som det gamle biblioteket leste uten problemer, kan bli uleselig uten at en eneste byte endres. Utfør kontrollene i rekkefølge, fordi to av dem ser identiske ut hvis du bare ser på forespørselen.

Det første spørsmålet er om nøkkelen er kryptert, og det andre er om denne byggen kan dekryptere den. Konfigurasjonsendringer gir bare mening når begge svarene er kjent.

Sjekk om nøkkelen er kryptert

Les den første linjen i filen og la deretter biblioteket parse den, fordi et filnavn beviser ingenting. En PEM-blokk merket ENCRYPTED PRIVATE KEY er kryptert PKCS#8, og en eldre RSA PRIVATE KEY blokk som bærer Proc-Type: 4,ENCRYPTED er den tradisjonelle formen, og begge forventer en passfrase. En ukryptert PRIVATE KEY blokk bør ikke spørre etter en i det hele tatt. Kjør parsingen som kontoen som eier filen, fordi et tillatelsesproblem gir en annen og langt mindre interessant feil.

Hvis nøkkelen virkelig er ukryptert og klienten likevel spør, slutt å se på kryptografi og sjekk om profilen nevner en askpass-fil som tjenesten fortsatt kan lese.

Sjekk om denne byggen kan dekryptere den

OpenSSL 3 delte algoritmestøtten sin opp i leverandører, og et sett eldre chiffere ligger nå i legacy-leverandøren i stedet for standardleverandøren. En nøkkel som er kryptert med en av disse chiffrene, forblir gyldig, men et bibliotek som lastes uten legacy-leverandøren kan ikke dekode den. Hos noen klienter viser det seg som en forespørsel som gjentas, hos andre som en hard feil rett etter passfrasen.

Pars den samme nøkkelen to ganger med samme binærfil: først bare med standardleverandøren, deretter med både legacy og standard forespurt på kommandolinjen. Hvis det andre forsøket lykkes der det første feilet, hviler diagnosen på bevis og ikke på tidspunktet for en oppgradering. Hvis begge feiler identisk, er passfrasen feil eller filen skadet, og ingen leverandørinnstilling reparerer noen av delene.

Sjekk den smaleste tilgjengelige rettelsen

Foretrekk en endring begrenset til klienten fremfor en systemomfattende. Noen 2.6-bygger godtar et profilvalg som laster begge leverandørene for den daemonprosessen, så bekreft direktivet i håndboken for din nøyaktige versjon før du stoler på det; å redigere systemets openssl.cnf i stedet påvirker alle OpenSSL-programmer på verten. Den smalere innstillingen er også langt lettere å rulle tilbake når nøkkelen er rekodet.

Ikke slett passfrasen for å få forespørselen til å forsvinne. Det gjør en beskyttet legitimasjon om til en klartekstfil og endrer stille risikoen for hver sikkerhetskopi, kopi og støttepakke den forekommer i. Forskjellen som betyr noe, er mellom en nøkkel som trenger passfrasen sin, og en nøkkel som dette biblioteket ikke kan dekode.

Sjekk tjenestekonteksten, og rekod deretter

Når nøkkelen kan låses opp, krypter den på nytt med en gjeldende algoritme slik at avhengigheten forsvinner. Skriv den nye filen med en moderne chiffer, verifiser at den parses, oppdater profilen, og behold den gamle kopien bare til en tilkobling lykkes. Legg aldri passfrasen på en kommandolinje, der enhver lokal bruker kan lese den fra prosesslisten. Fjern den gamle filen først etter at den nye har koblet til fra tjenestekontoen, ikke bare fra skallet ditt.

Sjekk deretter enheten som faktisk kjører klienten. En nøkkel som er lesbar i skallet ditt, kan være uleselig for en tjeneste som kjører under en annen konto eller med en herdet hjemmekataloginnstilling.

Noter leverandørinnstillingen ved siden av profilen og oppbevar tokommando-testen sammen med den. Når en senere oppgradering fjerner legacy-leverandøren, kjør den testen på nytt for å se om nøkkelen fortsatt trenger den, eller om profilen kan tas ut av omveien.

En forespørsel er et symptom med minst tre årsaker, og bare én av dem er en manglende passfrase.