Шта ваш 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 уносима или са разликовним именом, зависно од клијента, а wildcard или %any вредност тихо искључује поређење за које сте мислили да га имате.

Затим следе време и намена. Преносни рачунар чији сат жури неколико сати одбија сертификат који још није важећи, а истекао посредни сертификат руши пут док је лист важећи. Кварови намене долазе од сертификата без serverAuth у проширеној употреби кључа или са keyUsage који не дозвољава потпис руковања, што OpenSSL пријављује као неподржану намену сертификата. Поново издајте из исправног шаблона; ништа у тој поруци није разлог да искључите проверу.

Опозив ради само ако га је неко конфигурисао

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

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

Редослед поправке који задржава проверу укљученом

Сортирајте по симптому пре него што додирнете датотеке, јер вас сваки ред табеле шаље на други објекат.

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