Што проверува вашиот VPN клиент пред да му верува на сертификат

Вашиот VPN клиент вели дека сертификатот не можел да се потврди, и дијалогот застанува таму. Датотеката е присутна, серверот работи, и истиот профил работел на друг преносен компјутер минатиот месец. Под тоа предупредување од еден ред клиентот го поминал сертификатот на партнерот низ четири порти: сертификационата власт што ја конфигуриравте гарантира за патеката на потписот, таа патека стигнува до власта, името на партнерот е тоа што го баравте, и сертификатот сега е употреблив за оваа намена. Најдете ја портата што се затворила и поправката обично е една датотека; прескокнете го тој чекор и ќе увезувате пакети повторно цело попладне.

Прочитајте го дијалогот пред да го уредите профилот

Грешките за сертификати ги формулира библиотеката подолу, а не VPN производот што го инсталиравте, затоа точниот текст е вашиот прв доказ. „Не може да се добие сертификат на локалниот издавач“ укажува на патеката или на сидрото на доверба. „Сертификатот е истечен или сѐ уште не е валиден“ укажува на времето. „Неподдржана намена на сертификатот“ укажува на продолжената употреба на клучот. Несовпаѓањето на името ви кажува кое име го сакал. Ниту една од четирите не се поправа со повторно инсталирање на клиентот.

Подигнете го нивото на дневникот пред да смените нешто. OpenVPN го пријавува неуспехот на проверката околу ракувањето кога ќе го стартувате со --verb 4, а strongSwan ги запишува своите одлуки за идентитет и синџир во дневникот charon. Потоа потврдете кој сертификат го прегледувате, бидејќи луѓето обично ја тестираат датотеката на дискот додека профилот вградува постара копија. Кога профилот вградува PEM блокови, се тестира вградениот сертификат.

Сертификационата власт потпишува идентитети, не дозволи

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

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

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

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

openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crt

Излезниот статус нула значи дека патеката е изградена од тие датотеки; неуспехот го именува сертификатот до кој не стигнал. Ако openssl verify успее додека клиентот сѐ уште одбива, разликата е во тоа што серверот навистина го испраќа или во кој датотека на доверба ја вчитува профилот. Во OpenVPN средните сертификати можат да патуваат со датотеката на серверскиот сертификат или да се достават одделно со --extra-certs, а пакет со два корена напишани под исто име на субјект ќе испрати еден од вашите клиенти во погрешна гранка.

Името и намената се одделни порти

Изградбата на синџир никогаш не прашува дали името е ваше. OpenVPN го проверува само кога профилот поставува --verify-x509-name, а старата навика да се совпаѓа само заедничкото име се крши на сертификати чии идентитети живеат во subjectAltName. Распоредувањата IKEv2 го совпаѓаат конфигурираниот идентитет со SAN записи или со разликувачкото име, зависно од клиентот, а вредност со џокер или %any тивко ја исклучува споредбата за која мислевте дека ја имате.

Следно доаѓаат времето и намената. Преносен компјутер чиј часовник оди неколку часа напред го одбива сертификатот што сѐ уште не е валиден, а истечен среден сертификат ја урнува патеката додека листот е валиден. Неуспесите на намената доаѓаат од сертификат без serverAuth во продолжената употреба на клучот или со keyUsage што не го дозволува потписот на ракувањето, што OpenSSL го пријавува како неподдржана намена на сертификатот. Издадете повторно од правилниот шаблон; ништо во таа порака не е причина да ја исклучите проверката.

Отповикувањето работи само ако некој го конфигурирал

CRL или одговор на OCSP не се проверуваат автоматски. На сервер OpenVPN клиентските сертификати се споредуваат со список само кога --crl-verify покажува на него. Проверката на серверскиот сертификат од страната на клиентот зависи од имплементацијата и често ја нема. strongSwan бара својот приклучок за отповикување и политика пред да погледне CRL за партнер.

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

Редослед на поправка што ја држи проверката вклучена

Подредете по симптом пред да допрете датотеки, бидејќи секој ред од табелата ве испраќа до различен објект.

Поминете го списокот во еден премин: потврдете ја датотеката што ја вчитува профилот, изградете ја патеката сами, проверете дали серверот го испраќа средниот сертификат, споредете го часовникот, прочитајте го SAN, прочитајте го EKU, потоа поврзете се повторно и гледајте како истиот ред од дневникот исчезнува. Ако на уред воопшто не може да му се даде CA, прицврстувањето е чесна алтернатива, бидејќи OpenVPN 2.6 прифаќа --peer-fingerprint и ја стеснува довербата на еден клуч наместо да ја отстрани проверката. RFC 5280 е референцата за значењето на секое од тие полиња.