OpenVPN-sleutelaanvraag ná OpenSSL 3: ondersoek die provider

Niemand het aan die profiel geraak nie, tog vra dieselfde kliënt nou elke keer wanneer dit begin om ’n wagfrase vir die private sleutel. Wanneer daardie verandering binne dae ná ’n verspreidingsopgradering plaasvind, is die opgradering die waarskynlike oorsaak: OpenSSL 3 het sy algoritmeondersteuning herorganiseer, en ’n sleutel wat die ou biblioteek geredelik gelees het, kan onleesbaar word sonder dat ’n enkele greep verander. Werk die kontroles in volgorde deur, want twee van hulle lyk van die aanvraag af identies.

Die eerste vraag is of die sleutel geïnkripteer is, en die tweede is of hierdie build dit kan ontsleutel. Konfigurasieveranderinge maak eers sin nadat albei antwoorde bekend is.

Kontroleer of die sleutel geïnkripteer is

Lees die eerste reël van die lêer en laat die biblioteek dit dan ontleed, want ’n lêernaam bewys niks. ’n PEM-blok met die etiket ENCRYPTED PRIVATE KEY is geïnkripteerde PKCS#8, en ’n ouer RSA PRIVATE KEY-blok met Proc-Type: 4,ENCRYPTED is die tradisionele vorm; albei verwag ’n wagfrase. ’n Ongeïnkripteerde PRIVATE KEY-blok behoort glad nie een te vra nie. Voer die ontleding uit as die rekening wat die lêer besit, want ’n regteprobleem lewer ’n ander en veel minder interessante fout.

As die sleutel regtig ongeïnkripteer is en die kliënt vra steeds, hou op om na kriptografie te kyk en kontroleer of die profiel ’n askpass-lêer noem wat die diens nog kan lees.

Kontroleer of hierdie build dit kan ontsleutel

OpenSSL 3 het sy algoritmeondersteuning in providers verdeel, en ’n stel ouer versleutelings sit nou in die legacy-provider eerder as in die standaard een. ’n Sleutel wat met een van daardie versleutelings geïnkripteer is, bly geldig, tog kan ’n biblioteek wat sonder die legacy-provider gelaai is dit nie dekodeer nie. By sommige kliënte wys dit as ’n aanvraag wat herhaal, by ander as ’n harde mislukking reg ná die wagfrase.

Ontleed dieselfde sleutel twee keer met dieselfde binary: eers met net die standaard-provider, dan met legacy en standaard albei op die opdragreël versoek. As die tweede poging slaag waar die eerste misluk het, rus die diagnose op bewyse eerder as op die tydsberekening van ’n opgradering. As albei identies misluk, is die wagfrase verkeerd of die lêer beskadig, en geen provider-instelling herstel enige van die twee nie.

Kontroleer die nouste beskikbare oplossing

Verkies ’n verandering wat op die kliënt gemik is bo een vir die hele stelsel. Sommige 2.6-builds aanvaar ’n profielopsie wat albei providers vir daardie daemon se proses laai, so bevestig die richtlijn in die handleiding vir jou presiese weergawe voordat jy daarop staatmaak; om eerder die stelsel se openssl.cnf te redigeer, raak elke OpenSSL-program op die gasheer. Die nouer instelling is ook baie makliker om terug te draai sodra die sleutel herkodeer is.

Moenie die wagfrase verwyder om van die aanvraag ontslae te raak nie. Dit verander ’n beskermde geloofsbrief in ’n gewone-teks-lêer en verander stilweg die risiko van elke rugsteun, kopie en ondersteuningsbundel waarin dit voorkom. Die onderskeid wat saak maak, is tussen ’n sleutel wat sy wagfrase nodig het en ’n sleutel wat hierdie biblioteek nie kan dekodeer nie.

Kontroleer die dienskonteks en herkodeer dan

Sodra die sleutel ontsluit kan word, herversleutel dit met ’n huidige algoritme sodat die afhanklikheid verdwyn. Skryf die nuwe lêer met ’n moderne versleuteling, verifieer dat dit ontleed, werk die profiel by en hou die ou kopie net totdat ’n verbinding slaag. Moet nooit die wagfrase in ’n opdragreël plaas nie, waar enige plaaslike gebruiker dit uit die proseslys kan lees. Verwyder die ou lêer eers nadat die nuwe een vanaf die diensrekening verbind het, nie net vanaf jou shell nie.

Kontroleer dan die eenheid wat die kliënt werklik bestuur. ’n Sleutel wat in jou shell leesbaar is, kan onleesbaar wees vir ’n diens wat onder ’n ander rekening of met ’n verharde tuisgidsinstelling loop.

Teken die provider-instelling langs die profiel aan en hou die twee-opdragtoets daarby. Wanneer ’n latere opgradering die legacy-provider laat val, voer daardie toets weer uit om te sien of die sleutel dit nog nodig het of of die profiel van die tydelike oplossing onttrek kan word.

’n Aanvraag is ’n simptoom met minstens drie oorsake, en net een daarvan is ’n ontbrekende wagfrase.