Профилът 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 са по-късни етапи на връзката, затова недостъпен интранет хост след успешен вход е проблем на свързаността, а не на сертификата. Работете по този слой, вместо да сменяте идентификационни данни, и дръжте произхода на профила, частния му материал и проверките му на идентичност заедно, когато го предавате на някого.