Kā OpenVPN atrisina sertifikātu un atslēgu: iegultais PEM vai ceļš

Ziņojums saka, ka OpenVPN nevar ielādēt iegultu sertifikātu, bet jūsu galvā glabātais faila nosaukums saka pretējo. Svarīgāk ir tas, ko saņēma parsētājs, nevis tas, kas ir failu sistēmā, jo direktīva cert pieņem divus pilnīgi atšķirīgus vērtību veidus. Viens ir ceļš, ko tā atver; otrs ir PEM teksts, kas pienāca konfigurācijas iekšienē. Kamēr nezināt, kādu formu saņēma darbojošais klients, katrs labojums ir minējums.

Divas glabāšanas formas, viena direktīva

Direktīvas cert, key un ca katra pieņem ceļu vai iegultu bloku. Ja vērtība ir ceļš, OpenVPN atver šo failu un nolasa objektu no diska. Ja konfigurācijā ir bloks, ko norobežo cert tagi, tā pati direktīva tā vietā izmanto saturu starp šiem tagiem, un atsevišķs fails tajā nepiedalās.

Abas formas galu galā rada viena veida objektu, tāpēc strādājošs izvietojums var pāriet starp tām bez jebkādas citas izmaiņas. Profils, kas nes iegultu klienta sertifikātu un privāto atslēgu, ir pašpietiekams, un tā kopēšana uz citu mašīnu darbojas arī tad, ja netiek kopēta sertifikātu mape.

Pretējais nav taisnība. client.crt novietošana blakus profilam, kas iegulst savus datus, neko nemaina, jo nekas konfigurācijā neatsaucas uz šo failu. Tas ir visbiežākais iemesls, kāpēc fails, kas acīmredzami pastāv, šķiet ignorēts.

Kā iegults bloks kļūst par objektu

Iegultais saturs tiek izvilkts no konfigurācijas un nodots PEM parsētājam kā teksts. Šis parsētājs gaida ierastās robežas: BEGIN rindu, base64 kravu un atbilstošu END rindu. Ja bloks tika apgriezts neveiksmīgas kopēšanas laikā, ietīts HTML lejupielādes lapas dēļ vai atvērts redaktorā, kas normalizēja domuzīmes, parsētājs neizdodas uz saturu, kas izskatās esošs.

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

Tāpēc arī kļūdas formulējums ir maldinošs. Vārds iegults apraksta, kur skatījās ielādētājs, nevis ko tas tur atrada. Failam, kas nosaukts konfigurācijā, un tajā iegultam objektam var būt viena un tā pati sūdzība, ja pamata baiti nav lietojami.

Pārbaudiet, kuru formu ielādētais profils patiešām izmanto, nevis kuru failu nejauši atvēra jūsu redaktors:

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

Kā tiek atrisināta ceļa atsauce

Ceļa vērtība tiek atvērta attiecībā pret klienta darba direktoriju, nevis direktoriju, kurā ir konfigurācija. Sistēmā systemd šī darba direktorija ir tas, ko nosaka unit, un interaktīva palaišana no jūsu čaulas manto ko pavisam citu. Tāpēc viens un tas pats konfigurācijas fails var darboties, pārbaudot to ar roku, un neizdoties kā pakalpojums.

Relatīvie ceļi manto to pašu neskaidrību. Ieraugot kailu faila nosaukumu, pajautājiet, kāda ir procesa pašreizējā direktorija ražošanā, nevis pieņemiet, ka tā atbilst jūsu terminālim.

Atsevišķi glabātam sertifikātam bezsaistes parsēšana apstiprina objektu, pirms atkļūdojat kaut ko virs tā:

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

Šīs komandas pierāda, ka faili ir lasāmi un strukturāli derīgi. Tās nepierāda, ka partneris uzticas izdevējam, ka sertifikāts joprojām ir derīguma logā vai ka atslēga tam pieder.

Ko parsētāja kļūda var un ko nevar pateikt

Parsēšanas neveiksme lokalizē problēmu vienā ievadā un vienā posmā. Tā nepasaka, kuru no divām glabāšanas formām klients izmantoja, un nepasaka, vai objekts būtu pieņemts. Tie ir atsevišķi jautājumi ar atsevišķiem pierādījumiem.

Kad parsēšana izdodas, nākamā neveiksme pieder vēlākam posmam. Uzticības noraidījumu, mērķa neatbilstību vai atslēgas neatbilstību ziņo partneris vai TLS slānis, nevis ielādētājs. Tā paša faila atkārtota aizstāšana šo kļūdu nepārvietos.

Izmeklēšanas laikā jutīgo pusi turiet ārpus publiskiem ziņojumiem. Kopīgojiet direktīvu nosaukumus, kļūdas tekstu un bloka struktūru, noņemot atslēgas materiālu un jebkuru identificējošu kravu. openvpn(8) rokasgrāmata dokumentē abas faila direktīvu formas un darba direktorijas uzvedību aiz tām.