Кој CA фајл влегува во OpenVPN профил само со лозинка?

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

Редоследот е важен: последните две прашања имаат смисла само кога знаете каков материјал треба да постои.

Почнете од она што профилот веќе го носи

Отворете го профилот во текстуален уредувач и побарајте блок ca пред да барате фајл. Вграден блок ca со јавниот CA на операторот значи дека профилот е самостоен, а клиентот што сѐ уште бара CA фајл можеби чита друг профил или нецелосен увоз. Ако профилот наместо тоа има ред ca што покажува на патека, таа патека е релативна во однос на работниот директориум на клиентот во некои интеграции, а апсолутна во други. Запишете кој облик го имате пред да промените нешто.

ca /absolute/path/operator-ca.crt
auth-user-pass
remote-cert-tls server

Проверете го доставениот пакет за фајловите на кои профилот се повикува: CA сертификат, понекогаш одделен клиентски сертификат и клуч и можно фајл tls-auth или tls-crypt. Профил што се повикува на четири фајла, а доаѓа со два, е нецелосен и никакво покажување на полиња не го поправа тоа. Побарајте го од операторот делот што недостасува наместо да го замените со сертификат што случајно го имате.

Разделете четири вида материјал

CA сертификатот е јавен материјал што се користи за проверка на идентитетот на серверот. Клиентскиот сертификат го идентификува корисникот или уредот пред серверот. Приватниот клуч е тајната половина од тој клиентски сертификат и никогаш не смее да биде клучот за потпис на CA или серверски клуч. Материјалот tls-auth или tls-crypt е одделна заедничка тајна што го штити контролниот канал. Овие четири не се заменливи, а насочувањето на полето CA кон клиентски сертификат предизвикува неуспех при проверка што изгледа како проблем со довербата.

Автентикација само со лозинка го менува тоа кој од четирите ви е потребен, а не што значат. Со auth-user-pass и remote-cert-tls server клиентот сѐ уште го проверува серверот наспроти CA, затоа полето CA се појавува дури и кога нема клиентски сертификат. Политиката на операторот одлучува дали е потребен и клиентски сертификат и ниту еден дијалог не може да ви го каже тоа.

Насочете го клиентот кон фајлот за доверба

Изберете го самиот CA сертификатен фајл, а не папката што го содржи и не пакетот .p12 што содржи клиентски идентитет. Во Windows синтаксата на патеката и избирачот на фајлови се однесуваат поинаку од Linux примерите во повеќето водичи, затоа користете го она што го прифаќа инсталираниот клиент и потврдете дека фајлот е читлив за сметката што го извршува. Проблем со дозволи и фајл што недостасува изгледаат исто во дијалогот, но даваат различни редови во дневникот. По изборот отворете ги повторно поставките на профилот за да потврдите дека клиентот го задржал изборот.

<ca>
-----BEGIN CERTIFICATE-----
...operator-provided public CA...
-----END CERTIFICATE-----
</ca>

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

Прочитајте ја следната грешка, а не истата

Смислата на испорачување на правилниот CA е да се промени грешката, а не да се направи да исчезне. Неуспех на идентитетот на серверот по вчитувањето на CA значи дека сертификатот не се совпаѓал со очекуваното име или со очекувањето remote-cert-tls, што е различно поправање од одбивање на лозинка. Одбивањето на лозинка значи дека TLS слојот успеал, а акредитивот е погрешен. Задржете ја првата нова порака; таа е корисната.

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

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