OpenVPN профил има три блока сертификата: који је тајни?

Отворите .ovpn датотеку да промените једну линију и нађете три блока base64 који сви изгледају као акредитиви. Један је безбедан за објављивање, један је осетљив као лозинка, а један је јавни кључ који ништа не значи ако нешто друго није потписано његовим паром. Људи залепе целу датотеку у тему подршке јер блокови изгледају заменљиво, и тако клијентски кључ заврши у јавном архиву. Разврставање који блок шта ради објашњава већину забуне око ових профила и говори вам које кварове треба сами да поправите.

Једна датотека, три блока, различити послови

Типичан профил уграђује блок ca, блок cert и блок key између ознака BEGIN и END или упућује на иста три као на засебне датотеке. Неки профили додају четврти блок за кључ tls-auth или tls-crypt, који је заједничка тајна, а не сертификат. Клијент чита сваки блок према директиви која га именује, па су ознаке важније од редоследа појављивања.

Третирајте састављени профил као осетљив док заиста не погледате унутра. Јавни сертификат и приватни кључ могу стајати неколико редова један од другог у истој датотеци, а снимак екрана који укључује заглавље може укључивати обоје. Ручно замућивање видљивог base64 такође је непоуздано, јер делимичан блок ипак одаје метаподатке сертификата који именују вашу инсталацију. Копирање три директиве без њихових вредности обично је довољно за корисно питање.

Директиве око блокова одлучују како се користе. Промените ca и клијент верује другом телу; промените cert без промене key и руковање пада уз неpodudarnost која нема везе с поверењем.

CA блок је јаван, CA кључ никад

Сертификационо тело потписује сертификате који вежу јавни кључ за идентитет, а његов сопствени сертификат је сидро помоћу ког клијент одлучује да ли је ланац поуздан. Тај сертификат је јаван по дизајну: слање унутар сваког профила је нормално и управо зато само-потписана инсталација може радити без комерцијалног тела.

Оно што никада не сме стајати у клијентском профилу је приватни кључ за потписивање тела. Клијенту не треба ни за какву проверу, а његово присуство значи да свако ко држи профил може стварати нове идентитете за целу инсталацију.

Веровање телу је уже него што звучи. Клијент који прихвата било који сертификат који је потписао CA прихватиће и сертификат издат за другу услугу на истом CA. Опције које фиксирају очекивану улогу или име сервера затварају ту празнину, а Преглед TLS опција наводи директиве провере које то раде.

Серверски и клијентски сертификати показују у супротним смеровима

Серверски сертификат је оно што клијент прегледа да потврди да је стигао на праву крајњу тачку. Ваш клијентски сертификат ради обрнуто: сервер га користи да одлучи да је овај уређај или корисник онај који је уписао. Исти формат, супротан смер поверења.

Адреса није идентитет. Долазак на праву IP адресу ништа не доказује о томе ко је одговорио, зато провера имена хоста или имена сертификата и даље припада профилу. Ни лозинка налога не замењује тихо потребан клијентски сертификат, јер се обоје проверава у различитим фазама и инсталација може захтевати обоје.

Приватни кључ клијента је део који мора остати приватан. Ако је могао бити изложен, брисање датотеке са вашег лаптопа не мења ништа на серверу, који ће наставити да прихвата одговарајући сертификат док га оператер не опозове. Молба оператеру да замени или опозове тај идентитет једини је поправак који путује с вама.

Два захтева која изгледају идентично и нису

Кључ сачуван у шифрованом облику тражи фразу за приступ пре него што га клијент може користити. VPN услуга може одвојено тражити лозинку налога, а два захтева могу се појавити у размаку од неколико секунди са готово истом формулацијом. Фраза штити датотеку на вашем диску; лозинка доказује налог серверу. Мешање њих двоје води људе на ресетовања лозинке која никако не могу помоћи.

Прочитајте захтев пре него што било шта ресетујете. Ресетовање лозинке налога не чини ништа за заборављену фразу кључа, опозван или истекао сертификат, а ресетовање лозинке када је квар валидација сертификата претвара двоминутни поправак у случај за подршку. Ако жалба помиње датуме важности, прво проверите сат уређаја, а затим сопствени прозор наведеног сертификата.

Када је сертификат заиста истекао, замена мора доћи од онога ко га је издао. Кључ који припада неком другом није пут обнове, као ни позајмљивање исправног профила од колеге.

Шта чисто руковање доказује, а шта не

Долазак до завршеног TLS руковања значи да је конфигурисани однос идентитета издржао: серверски сертификат се везао на ваш CA и ваш сертификат је прихваћен. То не говори ништа о политици евидентирања оператера, нити о томе хоће ли ваше апликације радити када тунел буде подигнут.

Руте и DNS су касније фазе везе, па је недоступан интранет домаћин после успешне пријаве проблем повезивања, а не сертификата. Радите на том слоју уместо да мењате акредитиве и држите заједно порекло профила, његов приватни материјал и његове провере идентитета када га предајете некоме.