Који 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, а тунел који гради није онај који је оператер намеравао.