OpenVPN-sleutelprompt na OpenSSL 3: controleer de provider

Niemand heeft het profiel aangeraakt, toch vraagt dezelfde client nu bij elke start een wachtwoordzin voor de privésleutel. Wanneer die verandering binnen enkele dagen na een distributie-upgrade optreedt, is de upgrade de waarschijnlijke oorzaak: OpenSSL 3 heeft zijn algoritmeondersteuning gereorganiseerd, en een sleutel die de oude bibliotheek moeiteloos las, kan onleesbaar worden zonder dat er één byte verandert. Voer de controles op volgorde uit, want twee ervan lijken identiek als je alleen naar de prompt kijkt.

De eerste vraag is of de sleutel versleuteld is, en de tweede of deze build hem kan ontsleutelen. Configuratiewijzigingen hebben pas zin als beide antwoorden bekend zijn.

Controleer of de sleutel versleuteld is

Lees de eerste regel van het bestand en laat de bibliotheek het dan parseren, want een bestandsnaam bewijst niets. Een PEM-blok met het label ENCRYPTED PRIVATE KEY is versleutelde PKCS#8, en een ouder RSA PRIVATE KEY blok met Proc-Type: 4,ENCRYPTED is de traditionele vorm, en beide verwachten een wachtwoordzin. Een onversleuteld PRIVATE KEY blok zou er helemaal geen moeten vragen. Voer het parseren uit als het account dat het bestand bezit, want een rechtenprobleem geeft een andere en veel minder interessante fout.

Als de sleutel echt onversleuteld is en de client blijft vragen, stop dan met naar cryptografie te kijken en controleer of het profiel een askpass-bestand noemt dat de dienst nog kan lezen.

Controleer of deze build hem kan ontsleutelen

OpenSSL 3 heeft zijn algoritmeondersteuning opgesplitst in providers, en een reeks oudere cijfers zit nu in de legacy-provider in plaats van de standaardprovider. Een sleutel die met een van die cijfers is versleuteld, blijft geldig, maar een bibliotheek die zonder de legacy-provider is geladen, kan hem niet decoderen. Bij sommige clients uit zich dat als een prompt die zich herhaalt, bij andere als een harde fout direct na de wachtwoordzin.

Parseer dezelfde sleutel twee keer met hetzelfde binaire bestand: eerst alleen met de standaardprovider, daarna met legacy en standaard beide op de opdrachtregel gevraagd. Als de tweede poging slaagt waar de eerste faalde, rust de diagnose op bewijs en niet op het moment van een upgrade. Als beide identiek falen, is de wachtwoordzin verkeerd of is het bestand beschadigd, en geen enkele providerinstelling herstelt een van beide.

Controleer de smalst mogelijke oplossing

Geef de voorkeur aan een wijziging die tot de client beperkt blijft boven een systeembrede. Sommige 2.6-builds accepteren een profieloptie die beide providers laadt voor het proces van die daemon, dus controleer de richtlijn in de handleiding voor jouw exacte versie voordat je erop vertrouwt; het bewerken van de systeem-openssl.cnf in plaats daarvan raakt elk OpenSSL-programma op de host. De smallere instelling is ook veel makkelijker terug te draaien zodra de sleutel opnieuw is gecodeerd.

Verwijder de wachtwoordzin niet om de prompt te laten verdwijnen. Dat maakt van een beschermd toegangsbewijs een bestand met platte tekst en verandert stilzwijgend het risico van elke back-up, kopie en ondersteuningsbundel waarin het voorkomt. Het onderscheid dat ertoe doet, is tussen een sleutel die zijn wachtwoordzin nodig heeft en een sleutel die deze bibliotheek niet kan decoderen.

Controleer de dienstcontext en codeer daarna opnieuw

Zodra de sleutel kan worden ontgrendeld, versleutel hem opnieuw met een actueel algoritme zodat de afhankelijkheid verdwijnt. Schrijf het nieuwe bestand met een moderne cijfer, verifieer dat het parseert, werk het profiel bij en houd de oude kopie alleen totdat een verbinding slaagt. Zet de wachtwoordzin nooit op een opdrachtregel, waar elke lokale gebruiker hem uit de proceslijst kan lezen. Verwijder het oude bestand pas nadat het nieuwe vanaf het dienstaccount verbinding heeft gemaakt, niet alleen vanaf je shell.

Controleer daarna de unit die de client daadwerkelijk start. Een sleutel die in je shell leesbaar is, kan onleesbaar zijn voor een dienst die onder een ander account of met een verharde instelling voor de thuismap draait.

Noteer de providerinstelling naast het profiel en bewaar de twee-opdrachtentest erbij. Wanneer een latere upgrade de legacy-provider laat vallen, voer die test opnieuw uit om te zien of de sleutel hem nog nodig heeft of dat het profiel uit de omweg kan worden gehaald.

Een prompt is een symptoom met minstens drie oorzaken, en slechts één daarvan is een ontbrekende wachtwoordzin.