OpenVPN-avaimen kysely OpenSSL 3:n jälkeen: tarkista palveluntarjoaja

Kukaan ei koskenut profiiliin, ja silti sama asiakasohjelma pyytää nyt yksityisavaimen salalausetta joka käynnistyksellä. Kun muutos ilmaantuu muutama päivä jakelun päivityksen jälkeen, päivitys on todennäköinen syy: OpenSSL 3 järjesti algoritmitukensa uudelleen, ja avain, jonka vanha kirjasto luki vaivatta, voi muuttua lukukelvottomaksi ilman, että yksikään tavu muuttuu. Tee tarkistukset järjestyksessä, sillä kaksi niistä näyttää samalta, jos katsoo vain kyselyä.

Ensimmäinen kysymys on, onko avain salattu, ja toinen, pystyykö tämä build purkamaan sen. Kokoonpanomuutoksissa on järkeä vasta, kun molemmat vastaukset tunnetaan.

Tarkista, onko avain salattu

Lue tiedoston ensimmäinen rivi ja anna sitten kirjaston jäsentää se, sillä tiedostonimi ei todista mitään. PEM-lohko, jonka merkintä on ENCRYPTED PRIVATE KEY on salattu PKCS#8, ja vanhempi RSA PRIVATE KEY lohko, joka sisältää Proc-Type: 4,ENCRYPTED on perinteinen muoto, ja molemmat odottavat salalausetta. Salaamaton PRIVATE KEY lohko ei pitäisi pyytää sitä lainkaan. Suorita jäsennys tiedoston omistavan tilin tunnuksilla, sillä käyttöoikeusongelma tuottaa erilaisen ja paljon tylsemmän virheen.

Jos avain todella on salaamaton ja asiakasohjelma silti kysyy, lopeta kryptografiaan tuijottaminen ja tarkista, nimeääkö profiili askpass-tiedoston, jonka palvelu voi yhä lukea.

Tarkista, pystyykö tämä build purkamaan sen

OpenSSL 3 jakoi algoritmitukensa palveluntarjoajiin, ja joukko vanhempia salauksia on nyt legacy-palveluntarjoajassa oletuspalveluntarjoajan sijaan. Yhdellä noista salauksista salattu avain pysyy kelvollisena, mutta ilman legacy-palveluntarjoajaa ladattu kirjasto ei pysty purkamaan sitä. Joillakin asiakasohjelmilla se näkyy toistuvana kyselynä, toisilla kovana epäonnistumisena heti salalauseen jälkeen.

Jäsennä sama avain kahdesti samalla binäärillä: ensin vain oletuspalveluntarjoajalla, sitten legacy ja oletus molemmat komentoriviltä pyydettyinä. Jos toinen yritys onnistuu siellä, missä ensimmäinen epäonnistui, diagnoosi perustuu todisteisiin eikä päivityksen ajankohtaan. Jos molemmat epäonnistuvat samalla tavalla, salalause on väärä tai tiedosto on vaurioitunut, eikä mikään palveluntarjoaja-asetus korjaa kumpaakaan.

Tarkista kapein mahdollinen korjaus

Suosi asiakasohjelmaan rajattua muutosta järjestelmänlaajuisen sijaan. Jotkin 2.6-buildit hyväksyvät profiilivalinnan, joka lataa molemmat palveluntarjoajat kyseisen daemonin prosessille, joten varmista direktiivi tarkan versionsi käsikirjasta ennen siihen luottamista; järjestelmän openssl.cnf muokkaaminen sen sijaan vaikuttaa jokaiseen isäntän OpenSSL-ohjelmaan. Kapeampi asetus on myös paljon helpompi perua, kun avain on koodattu uudelleen.

Älä poista salalausetta, jotta kysely katoaisi. Se muuttaa suojatun tunnistetiedon pelkäksi tekstitedostoksi ja muuttaa hiljaa jokaisen varmuuskopion, kopion ja tukipaketin riskiä, jossa se esiintyy. Merkitsevä ero on avaimen, joka tarvitsee salalauseensa, ja avaimen, jota tämä kirjasto ei pysty purkamaan, välillä.

Tarkista palvelun konteksti ja koodaa sitten uudelleen

Kun avain voidaan avata, salaa se uudelleen nykyaikaisella algoritmilla jotta riippuvuus katoaa. Kirjoita uusi tiedosto nykyaikaisella salauksella, varmista että se jäsennetään, päivitä profiili ja pidä vanha kopio vain kunnes yhteys onnistuu. Älä koskaan laita salalausetta komentoriville, josta kuka tahansa paikallinen käyttäjä voi lukea sen prosessiluettelosta. Poista vanha tiedosto vasta, kun uusi on yhdistänyt palvelutililtä, ei vain omasta kuorestasi.

Tarkista sitten yksikkö, joka todella käynnistää asiakasohjelman. Kuoressasi luettava avain voi olla lukukelvoton palvelulle, joka toimii toisella tilillä tai kovennetulla kotihakemistoasetuksella.

Kirjaa palveluntarjoaja-asetus profiilin viereen ja pidä kahden komennon testi sen mukana. Kun myöhempi päivitys poistaa legacy-palveluntarjoajan, aja testi uudelleen nähdäksesi, tarvitseeko avain sitä yhä vai voidaanko profiili poistaa kiertotiestä.

Kysely on oire, jolla on ainakin kolme syytä, ja vain yksi niistä on puuttuva salalause.