Upit za OpenVPN ključ nakon OpenSSL 3: provjerite provajdera

Niko nije dirao profil, a isti klijent sada traži pristupnu frazu za privatni ključ pri svakom pokretanju. Kada se ta promjena dogodi u roku od nekoliko dana nakon nadogradnje distribucije, vjerovatni uzrok je sama nadogradnja: OpenSSL 3 je preuredio podršku za algoritme, a ključ koji je stara biblioteka čitala bez problema može postati nečitljiv bez promjene ijednog bajta. Izvršite provjere po redu, jer dvije od njih izgledaju identično ako gledate samo upit.

Prvo pitanje je da li je ključ šifrovan, a drugo da li ga ovaj build može dešifrovati. Promjene konfiguracije imaju smisla tek kada su oba odgovora poznata.

Provjerite da li je ključ šifrovan

Pročitajte prvi red datoteke i zatim pustite biblioteku da je parsira, jer naziv datoteke ništa ne dokazuje. PEM blok s oznakom ENCRYPTED PRIVATE KEY je šifrovani PKCS#8, a stariji RSA PRIVATE KEY blok koji nosi Proc-Type: 4,ENCRYPTED je tradicionalni oblik; oba očekuju pristupnu frazu. Nešifrovani PRIVATE KEY blok ne bi trebalo da je traži uopšte. Pokrenite parsiranje kao račun koji posjeduje datoteku, jer problem s dozvolama daje drugačiju i mnogo manje zanimljivu grešku.

Ako je ključ zaista nešifrovan, a klijent i dalje pita, prestanite gledati u kriptografiju i provjerite navodi li profil askpass datoteku koju servis još može čitati.

Provjerite može li ga ovaj build dešifrovati

OpenSSL 3 je podijelio podršku za algoritme na provajdere, a skup starijih šifri sada stoji u legacy provajderu umjesto u podrazumijevanom. Ključ šifrovan jednom od tih šifri ostaje valjan, ali biblioteka učitana bez legacy provajdera ne može ga dekodirati. Kod nekih klijenata to se pojavljuje kao upit koji se ponavlja, kod drugih kao tvrdi neuspjeh odmah nakon pristupne fraze.

Parsirajte isti ključ dvaput istim binarnim fajlom: prvo samo s podrazumijevanim provajderom, zatim s legacy i podrazumijevanim zatraženim zajedno na komandnoj liniji. Ako drugi pokušaj uspije tamo gdje je prvi pao, dijagnoza počiva na dokazu, a ne na trenutku nadogradnje. Ako oba padnu identično, pristupna fraza je pogrešna ili je datoteka oštećena, i nikakvo podešavanje provajdera ne popravlja ni jedno ni drugo.

Provjerite najože dostupno rješenje

Preferirajte promjenu ograničenu na klijent umjesto one na nivou sistema. Neki 2.6 buildovi prihvataju opciju profila koja učitava oba provajdera za proces tog daemona, pa provjerite direktivu u priručniku za vašu tačnu verziju prije nego se na nju oslonite; uređivanje sistemskog openssl.cnf umjesto toga pogađa svaki OpenSSL program na hostu. Uža postavka je takođe mnogo lakša za vraćanje nakon što se ključ ponovo kodira.

Ne brišite pristupnu frazu da bi upit nestao. Time štiteći akreditiv pretvarate u običnu tekstualnu datoteku i tiho mijenjate rizik svakog backupa, kopije i paketa za podršku u kojem se pojavi. Bitna razlika je između ključa kojem treba njegova pristupna fraza i ključa koji ova biblioteka ne može dekodirati.

Provjerite kontekst servisa, pa ponovo kodirajte

Kada se ključ može otključati, ponovo ga šifrujte savremenim algoritmom tako da zavisnost nestane. Napišite novu datoteku modernom šifrom, potvrdite da se parsira, ažurirajte profil i držite staru kopiju samo dok veza ne uspije. Nikada ne stavljajte pristupnu frazu u komandnu liniju, gdje je svaki lokalni korisnik može pročitati iz liste procesa. Uklonite staru datoteku tek nakon što se nova poveže iz servisnog računa, ne samo iz vašeg shella.

Zatim provjerite jedinicu koja stvarno pokreće klijent. Ključ čitljiv u vašem shellu može biti nečitljiv servisu koji radi pod drugim računom ili sa ojačanom postavkom matičnog direktorija.

Zapišite postavku provajdera pored profila i držite test s dvije komande uz nju. Kada kasnija nadogradnja izbaci legacy provajder, ponovo pokrenite taj test da vidite treba li ključu još uvijek ili se profil može izvući iz zaobilaznog rješenja.

Upit je simptom s najmanje tri uzroka, a samo jedan od njih je nedostajuća pristupna fraza.