Miten OpenVPN ratkaisee varmenteen ja avaimen: inline-PEM vai tiedostopolku

Viesti sanoo, että OpenVPN ei voi ladata upotettua varmennetta, ja päässäsi oleva tiedostonimi väittää muuta. Se, mitä jäsentäjä sai, merkitsee enemmän kuin se, mitä tiedostojärjestelmä sisältää, koska direktiivi cert hyväksyy kahta täysin erilaista arvotyyppiä. Toinen on polku, jonka se avaa; toinen on PEM-teksti, joka saapui konfiguraation sisällä. Kunnes tiedät, minkä muodon käynnissä oleva asiakas sai, jokainen korjaus on arvaus.

Kaksi tallennusmuotoa, yksi direktiivi

Direktiivit cert, key ja ca hyväksyvät kukin polun tai upotetun lohkon. Kun arvo on polku, OpenVPN avaa kyseisen tiedoston ja lukee objektin levyltä. Kun konfiguraatio sisältää cert-tunnisteilla rajatun lohkon, sama direktiivi kuluttaa sen sijaan näiden tunnisteiden välisen sisällön, eikä erillinen tiedosto ole mukana.

Molemmat muodot tuottavat lopulta samanlaista objektia, minkä vuoksi toimiva käyttöönotto voi siirtyä niiden välillä ilman mitään muuta muutosta. Profiili, joka kantaa upotetun asiakasvarmenteen ja yksityisen avaimen, on itsenäinen, ja sen kopioiminen toiselle koneelle toimii ilman varmennehakemiston kopioimista.

Päinvastainen ei pidä paikkaansa. client.crt-tiedoston pudottaminen oman datansa upottavan profiilin viereen ei muuta mitään, koska mikään konfiguraatiossa ei viittaa tuohon tiedostoon. Tämä on tavallisin syy siihen, että selvästi olemassa oleva tiedosto näyttää jäävän huomiotta.

Miten upotettu lohko muuttuu objektiksi

Upotettu sisältö poimitaan konfiguraatiosta ja annetaan PEM-jäsentäjälle tekstinä. Tämä jäsentäjä odottaa tavallisia rajoja: BEGIN-rivi, base64-hyötykuorma ja vastaava END-rivi. Jos lohko katkesi epäonnistuneen kopioinnin takia, käärittiin lataussivun toimesta HTML:ään tai avattiin editorissa, joka normalisoi viivat, jäsentäjä epäonnistuu sisällössä, joka näyttää olevan läsnä.

<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>

Siksi myös virhesanamuoto on harhaanjohtava. Sana upotettu kuvaa, mihin latain katsoi, ei sitä, mitä se sieltä löysi. Konfiguraatiossa nimetty tiedosto ja siihen upotettu objekti voivat tuottaa saman valituksen, kun taustalla olevat tavut ovat käyttökelvottomia.

Tarkista, mitä muotoa ladattu profiili todella käyttää, älä sitä, minkä tiedoston editorisi sattui avaamaan:

grep -nE '^(ca|cert|key) |^<(ca|cert|key)>' client.ovpn

Miten polkuviittaus ratkaistaan

Polkuarvo avataan asiakkaan työhakemistoon nähden, ei konfiguraation sisältävään hakemistoon nähden. systemd:n alla tuo työhakemisto on se, minkä yksikkö asettaa, ja komentotulkistasi käynnistetty interaktiivinen ajo perii jotain aivan muuta. Siksi sama konfiguraatiotiedosto voi toimia, kun testaat sitä käsin, ja epäonnistua palveluna.

Suhteelliset polut perivät saman epäselvyyden. Kun näet paljaan tiedostonimen, kysy, mikä on prosessin nykyinen hakemisto tuotannossa, sen sijaan että olettaisit sen vastaavan päätettäsi.

Erikseen tallennetun varmenteen osalta offline-jäsennys vahvistaa objektin ennen kuin korjaat mitään sen yläpuolella:

openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -check

Nämä komennot todistavat, että tiedostot ovat luettavissa ja rakenteellisesti kelvollisia. Ne eivät todista, että vastapuoli luottaa myöntäjään, että varmenne on yhä voimassaoloaikansa sisällä tai että avain kuuluu sille.

Mitä jäsentäjän virhe voi kertoa ja mitä ei

Jäsennysvirhe paikantaa ongelman yhteen syötteeseen ja yhteen vaiheeseen. Se ei kerro, kumpaa kahdesta tallennusmuodosta asiakas käytti, eikä kerro, olisiko objekti hyväksytty. Ne ovat erillisiä kysymyksiä, joilla on erilliset todisteet.

Kun jäsennys onnistuu, seuraava virhe kuuluu myöhemmälle vaiheelle. Luottamuksen hylkäämisen, käyttötarkoituksen poikkeaman tai avaimen poikkeaman ilmoittaa vastapuoli tai TLS-kerros, ei latain. Saman tiedoston toistuva korvaaminen ei siirrä tätä virhettä.

Pidä arkaluonteinen puolisko julkisten raporttien ulkopuolella tutkinnan aikana. Jaa direktiivien nimet, virheteksti ja lohkon rakenne, kun avainmateriaali ja kaikki tunnistava hyötykuorma on poistettu. openvpn(8)-käsikirja dokumentoi tiedostodirektiivien molemmat muodot ja niiden taustalla olevan työhakemistokäyttäytymisen.