неподржана намена сертификата: зашто посредни CA не успева
Када OpenVPN пријави неподржану намену сертификата, крајњи сертификат може бити невин. Упоредите намену крајњег сертификата са политиком ланца пре него што било шта поново издате.
Намена сертификата сервера изгледа исправно, кључ се подудара, датуми су у реду, а веза и даље не успева са unsupported certificate purpose. Детаљ који то решава обично је у истом реду као и грешка: вредност дубине и subject који именују сертификат више у ланцу. Изводе се два различита теста, а само се један односи на крајњи сертификат. Њихово поређење објашњава зашто замена сертификата сервера ништа не мења.
Који је сертификат верификатор заиста одбио
Ланац није један објекат поновљен три пута. Крајњи сертификат носи име и кључ сервера, посредни га повезују са кореном, и сваки има свој период важења, ограничења и намене. Када грешка наведе дубину, тај број означава позицију у ланцу који је верификатор изградио, а то можда није позиција коју очекујете ако сервер шаље неочекивани ланац.
Читајте поља сертификата на тој дубини, а не сертификата за који сте претпоставили да је крив. Затражите два проширења која ограничавају издавање уместо да исписујете сва поља, јер је одговор готово увек у једном од њих. Излаз проширења је безбедан за дељење; приватни кључеви никада.
openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage
Ако је наведени сертификат посредни чија проширена употреба кључа помиње нешто неповезано са аутентификацијом TLS сервера, остатак неуспеха следи механички. Ланац не може да се користи за намену коју је OpenVPN затражио.
Намена крајњег сертификата и политика ланца су два теста
Тест крајњег сертификата поставља уско питање: да ли овај сертификат крајњег ентитета дозвољава аутентификацију сервера за ово име? Тест ланца поставља шире: сме ли сваки сертификат на путу да служи тој намени? Сертификационо тело коме је дозвољено да издаје само клијентске сертификате проћи ће сопствене провере потписа и ипак пасти на другом тесту, јер пут који одобрава не укључује намену која је потребна апликацији. Два теста падају са истим речима и имају потпуно различите поправке.
Зато новоиздати крајњи сертификат, исправан у сваком видљивом пољу, може одмах да падне. Зато поправка обично припада профилу тела које издаје, а не VPN конфигурацији.
Одсутан EKU није ограничавајући EKU
RFC 5280 чини проширење проширене употребе кључа опционим и, када постоји, ограничавајућим. Зато CA сертификат без проширења није рекао „не“ аутентификацији сервера, док је онај који наводи само неповезану намену рекао нешто веома конкретно. Третирање ова два стања као еквивалентних даје погрешну дијагнозу и, још горе, погрешну поправку. Разлика такође објашњава зашто се два тела која у конзоли изгледају слично у ланцу понашају сасвим другачије.
Понашање библиотека такође није једнолико овде. документ OpenSSL-а о опцијама провере описује сопствени приступ проверама намене на CA сертификатима, и тај приступ је политика имплементације, а не правило које сваки TLS стек следи идентично. Опишите шта ваш верификатор ради, а затим то потврдите на верзији коју заиста извршавате.
Репродукујте неуспех офлајн пре поновног издавања
Офлајн провера уклања апликацију из једначине. Ако ланац не успева на исти начин под истом наменом, проблем је у сертификату и никаква конфигурација сервера то неће сакрити. Ако ланац прође офлајн док услуга још одбија, апликација тражи другу намену или користи други ланац од оног који сте тестирали.
openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem
-show_chain је важан јер штампа пут који је алат изградио, а он често није редослед датотека који сте дали. Тај излаз је најбржи начин да откријете да се други посредни сертификат вуче из складишта поверења, да сервер шаље унакрсно потписану варијанту коју нисте намеравали, или да заставица намене копирана из упутства припада другој улози од оне која се опслужује.
Поправите политику издавања, не позив за проверу
Трајна поправка је посредни сертификат издат по политици која дозвољава намене којима мора да служи, са ограничењем записаним и прегледаним. Додавање сваке намене сваком телу није политика; оно уклања ограничење које је проширењу дало смисао и обично надживи инцидент који га је изазвао. Кратка белешка у профилу која описује које улоге тело сме да сертификује спречава следеће поновно издавање да понови исту расправу.
Искључивање провере је други примамљив пречица и претвара проблем сертификата у проблем поверења. Задржите проверу намене, поправите ланац и поново покрените исту офлајн проверу да потврдите да пут сада служи предвиђеној улози пре него што поново додирнете услугу.