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

Отворате .ovpn датотека за да смените една линија и наоѓате три блока base64 што сите изгледаат како акредитиви. Едниот е безбеден за објавување, другиот е чувствителен како лозинка, а третиот е јавен клуч што не значи ништо ако нешто друго не е потпишано со неговиот пар. Луѓето ја лепат целата датотека во тема за поддршка затоа што блоковите изгледаат заменливи, и така клиентскиот клуч завршува во јавен архив. Разликувањето кој блок што прави го објаснува најголемиот дел од забуната околу овие профили и ви кажува кои дефекти вие треба да ги поправите.

Една датотека, три блока, различни задачи

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

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

Директивите околу блоковите одлучуваат како се користат. Сменете ca и клиентот верува на друг орган; сменете cert без да го смените key и ракувањето откажува со несовпаѓање што нема никаква врска со довербата.

Блокот CA е јавен, клучот CA никогаш

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

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

Довербата во орган е и потесна отколку што звучи. Клиент што прифаќа кој било сертификат потпишан од CA сепак ќе прифати сертификат издаден за друга услуга на истиот CA. Опциите што ја фиксираат очекуваната улога или име на серверот ја затвораат таа празнина, а Референцата за TLS опции ги наведува директивите за проверка што го прават тоа.

Серверскиот и клиентскиот сертификат покажуваат во спротивни насоки

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

Адресата не е идентитет. Стигнувањето до точната IP адреса не докажува ништо за тоа кој одговорил, затоа проверката на име на домаќин или име на сертификат сѐ уште му припаѓа на профилот. Ни лозинката на сметката тивко не го заменува бараниот клиентски сертификат, бидејќи двете се проверуваат во различни фази и распоредувањето може да бара и двете.

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

Два барања што изгледаат идентични и не се

Клуч зачуван во шифрирана форма бара лозинка-фраза пред клиентот да може да го користи. VPN услугата може одделно да побара лозинка за сметка, и двете барања можат да се појават со секунди разлика со речиси исти зборови. Фразата штити датотека на вашиот диск; лозинката докажува сметка пред сервер. Нивното мешање ги праќа луѓето кон ресетирања на лозинка што никако не можат да помогнат.

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

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

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

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

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