Три различита питања добијају одговор од три различита дела OpenVPN профила, и управо њихово спајање доводи до тога да људи на крају искључе проверу која је радила. Да ли је сертификат друге стране потписан од стране органа коме верујем? Да ли тај сертификат декларише улогу TLS сервера? Да ли је то баш онај сервер коме сам желео да приступим? remote-cert-tls server одговара само на средње питање и то чини читајући екстензије унутар сертификата.

Три провере које је лако спојити у глави

Сидро поверења живи у директиви ca. Провера улоге припада remote-cert-tls. Провера идентитета припада verify-x509-name, када је профил користи, или било којој провери имена коју распоређивање дода.

Оне покривају различите отказе:

QuestionDirectiveFailure it catches
Who signed this?caCertificate from an unrelated authority
Is this a server?remote-cert-tlsClient certificate presented by a peer
Is this my server?verify-x509-nameAnother valid server from the same CA

Профил може имати све три и ипак бити слаб ако је CA подељен прешироко, што је питање управљања кључевима, а не директиве.

Шта провера улоге чита

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

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

Директива је асиметрична по дизајну: клијенти носе remote-cert-tls server, а сервери носе remote-cert-tls client. Замените их и свака веза пада са грешком улоге која изгледа као покварен сертификат.

Старији профили понекад користе ns-cert-type за исту сврху. Тренутне странице приручника третирају ту опцију као замењену, па профил који се још ослања на њу вреди мигрирати, а не отклањати грешке.

Зашто искључивање изгледа као поправка

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

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

Провера имена је засебна директива

Задовољавање провере улоге значи да је друга страна неки сервер потписан од вашег органа. То не говори ништа о томе који, што је важно када исти CA издаје сертификате за неколико мрежних пролаза и један од њих је компромитован или пренамењен.

verify-x509-name упоређује субјекат сертификата са вредношћу коју конфигуришете, са режимима подударања за тачан субјекат, префикс или једно поље. Користите поље које стварно идентификује пролаз и очекујте да ћете га намерно ажурирати када се име промени.

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

Прегледајте сертификат пре него што уредите профил

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

Ове команде штампају екстензије коришћења и линије верификације из детаљне везе:

openssl x509 -in server.crt -noout -text | grep -A1 -E "Key Usage|Extended Key Usage"
sudo openvpn --config client.ovpn --verb 4 2>&1 | grep -i verify

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

Повезани чланци