OpenVPN-nøgleprompt efter OpenSSL 3: undersøg udbyderen

Ingen har rørt profilen, og alligevel kræver den samme klient nu en adgangsfrase til den private nøgle, hver gang den starter. Når den ændring sker inden for få dage efter en opgradering af distributionen, er opgraderingen den sandsynlige årsag: OpenSSL 3 organiserede sin algoritmestøtte anderledes, og en nøgle, som det gamle bibliotek læste uden problemer, kan blive ulæselig, uden at en enkelt byte ændres. Udfør kontrollerne i rækkefølge, fordi to af dem ser ens ud, når man kun kigger på prompten.

Det første spørgsmål er, om nøglen er krypteret, og det andet er, om dette build kan dekryptere den. Konfigurationsændringer giver kun mening, når begge svar er kendt.

Kontrollér, om nøglen er krypteret

Læs filens første linje, og lad derefter biblioteket parse den, fordi et filnavn ikke beviser noget. En PEM-blok mærket ENCRYPTED PRIVATE KEY er krypteret PKCS#8, og en ældre RSA PRIVATE KEY blok med Proc-Type: 4,ENCRYPTED er den traditionelle form, og begge forventer en adgangsfrase. En ukrypteret PRIVATE KEY blok bør slet ikke spørge efter en. Kør parsningen som den konto, der ejer filen, fordi et tilladelsesproblem giver en anden og langt mindre interessant fejl.

Hvis nøglen virkelig er ukrypteret, og klienten stadig spørger, så hold op med at kigge på kryptografi og kontrollér, om profilen angiver en askpass-fil, som tjenesten stadig kan læse.

Kontrollér, om dette build kan dekryptere den

OpenSSL 3 delte sin algoritmestøtte op i udbydere, og et sæt ældre ciphers ligger nu i legacy-udbyderen i stedet for standardudbyderen. En nøgle, der er krypteret med en af disse ciphers, forbliver gyldig, men et bibliotek, der indlæses uden legacy-udbyderen, kan ikke afkode den. Hos nogle klienter viser det sig som en prompt, der gentages, hos andre som en hård fejl lige efter adgangsfrasen.

Parse den samme nøgle to gange med den samme binære fil: først kun med standardudbyderen, derefter med både legacy og standard anmodet på kommandolinjen. Hvis det andet forsøg lykkes, hvor det første fejlede, hviler diagnosen på bevis i stedet for på tidspunktet for en opgradering. Hvis begge fejler identisk, er adgangsfrasen forkert, eller filen er beskadiget, og ingen udbyderindstilling reparerer nogen af delene.

Kontrollér den snævrest mulige løsning

Foretræk en ændring, der er afgrænset til klienten, frem for en systemdækkende. Nogle 2.6-builds accepterer en profilindstilling, der indlæser begge udbydere for den daemons proces, så bekræft direktivet i manualen til din præcise version, før du stoler på det; at redigere systemets openssl.cnf i stedet påvirker alle OpenSSL-programmer på værten. Den snævrere indstilling er også langt lettere at rulle tilbage, når nøglen er blevet genkodet.

Slet ikke adgangsfrasen for at få prompten til at forsvinde. Det forvandler en beskyttet legitimationsoplysning til en klartekstfil og ændrer stille risikoen for hver backup, kopi og supportpakke, den optræder i. Den forskel, der betyder noget, er mellem en nøgle, der har brug for sin adgangsfrase, og en nøgle, som dette bibliotek ikke kan afkode.

Kontrollér tjenestekonteksten, og genkod derefter

Når nøglen kan låses op, genkrypter den med en aktuel algoritme så afhængigheden forsvinder. Skriv den nye fil med en moderne cipher, bekræft, at den parser, opdater profilen, og behold den gamle kopi kun, indtil en forbindelse lykkes. Anbring aldrig adgangsfrasen på en kommandolinje, hvor enhver lokal bruger kan læse den fra proceslisten. Fjern først den gamle fil, efter at den nye har forbundet fra tjenestekontoen, ikke kun fra din shell.

Kontrollér derefter den enhed, der faktisk kører klienten. En nøgle, der er læsbar i din shell, kan være ulæselig for en tjeneste, der kører under en anden konto eller med en hærdet hjemmekatalogindstilling.

Notér udbyderindstillingen ved siden af profilen, og opbevar to-kommando-testen sammen med den. Når en senere opgradering fjerner legacy-udbyderen, skal du køre den test igen for at se, om nøglen stadig har brug for den, eller om profilen kan udgå af omvejen.

En prompt er et symptom med mindst tre årsager, og kun én af dem er en manglende adgangsfrase.