OpenVPN-nyckelprompt efter OpenSSL 3: kontrollera leverantören

Ingen har rört profilen, ändå kräver samma klient nu en lösenfras för den privata nyckeln vid varje start. När den ändringen inträffar inom några dagar efter en uppgradering av distributionen är uppgraderingen den sannolika orsaken: OpenSSL 3 organiserade om sitt algoritmstöd, och en nyckel som det gamla biblioteket läste utan problem kan bli oläsbar utan att en enda byte ändras. Gör kontrollerna i ordning, eftersom två av dem ser identiska ut om du bara tittar på prompten.

Den första frågan är om nyckeln är krypterad, och den andra om den här bygget kan dekryptera den. Konfigurationsändringar är bara meningsfulla när båda svaren är kända.

Kontrollera om nyckeln är krypterad

Läs filens första rad och låt sedan biblioteket tolka den, eftersom ett filnamn inte bevisar något. Ett PEM-block märkt ENCRYPTED PRIVATE KEY är krypterad PKCS#8, och ett äldre RSA PRIVATE KEY block som bär Proc-Type: 4,ENCRYPTED är den traditionella formen, och båda förväntar sig en lösenfras. Ett okrypterat PRIVATE KEY block borde inte fråga efter någon alls. Kör tolkningen som kontot som äger filen, eftersom ett behörighetsproblem ger ett annat och mycket mindre intressant fel.

Om nyckeln verkligen är okrypterad och klienten ändå frågar, sluta titta på kryptografi och kontrollera om profilen nämner en askpass-fil som tjänsten fortfarande kan läsa.

Kontrollera om den här bygget kan dekryptera den

OpenSSL 3 delade upp sitt algoritmstöd i leverantörer, och en uppsättning äldre chiffer finns nu i legacy-leverantören i stället för standardleverantören. En nyckel som krypterats med ett av dessa chiffer förblir giltig, men ett bibliotek som laddats utan legacy-leverantören kan inte avkoda den. Hos vissa klienter visar det sig som en prompt som upprepas, hos andra som ett hårt fel direkt efter lösenfrasen.

Tolka samma nyckel två gånger med samma binär: först bara med standardleverantören, sedan med både legacy och standard begärda på kommandoraden. Om det andra försöket lyckas där det första misslyckades vilar diagnosen på bevis och inte på tidpunkten för en uppgradering. Om båda misslyckas identiskt är lösenfrasen fel eller filen skadad, och ingen leverantörsinställning reparerar någon av dem.

Kontrollera den smalaste tillgängliga åtgärden

Föredra en ändring begränsad till klienten framför en systemomfattande. Vissa 2.6-byggen accepterar ett profilval som läser in båda leverantörerna för den daemonprocessen, så bekräfta direktivet i handboken för din exakta version innan du förlitar dig på det; att redigera systemets openssl.cnf i stället påverkar varje OpenSSL-program på värden. Den smalare inställningen är också mycket lättare att rulla tillbaka när nyckeln har kodats om.

Ta inte bort lösenfrasen för att få prompten att försvinna. Det förvandlar en skyddad autentiseringsuppgift till en klartextfil och ändrar tyst risken för varje säkerhetskopia, kopia och supportpaket där den förekommer. Skillnaden som spelar roll är mellan en nyckel som behöver sin lösenfras och en nyckel som det här biblioteket inte kan avkoda.

Kontrollera tjänstens sammanhang och koda sedan om

När nyckeln kan låsas upp, kryptera om den med en aktuell algoritm så att beroendet försvinner. Skriv den nya filen med ett modernt chiffer, verifiera att den tolkas, uppdatera profilen och behåll den gamla kopian bara tills en anslutning lyckas. Lägg aldrig lösenfrasen på en kommandorad, där varje lokal användare kan läsa den från processlistan. Ta bort den gamla filen först efter att den nya har anslutit från tjänstekontot, inte bara från ditt skal.

Kontrollera sedan enheten som faktiskt kör klienten. En nyckel som är läsbar i ditt skal kan vara oläsbar för en tjänst som körs under ett annat konto eller med en härdad inställning för hemkatalogen.

Anteckna leverantörsinställningen bredvid profilen och förvara tvåkommandotestet tillsammans med den. När en senare uppgradering tar bort legacy-leverantören, kör det testet igen för att se om nyckeln fortfarande behöver den eller om profilen kan tas ur kringgåendet.

En prompt är ett symtom med minst tre orsaker, och bara en av dem är en saknad lösenfras.