неподдржана намена на сертификатот: зошто средниот CA не успева

Намената на серверскиот сертификат изгледа правилно, клучот се совпаѓа, датумите се во ред, а врската и понатаму не успева со 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 е важен затоа што ја печати патеката што алатката ја изградила, а таа често не е редоследот на датотеки што сте го дале. Тој излез е најбрзиот начин да откриете дека втор среден сертификат се влече од складиште на доверба, дека серверот праќа вкрстено потпишана варијанта што не сте ја намериле, или дека знаменцето за намена копирано од туторијал припаѓа на друга улога од онаа што се служи.

Поправете ја политиката на издавање, не повикот за проверка

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

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