Самопотпишан клиентски сертификат? VPN серверот сѐ уште го одбива

Операторот испраќа адреса и корисничко име, а клиентот бара датотека со CA, сертификат и клуч. Генерирањето на тие три локално изгледа како очигледниот следен чекор. Добивате сертификат во кој верува само вашата машина. Довербата на серверот е вкоренета во CA што не ја контролирате, па ракувањето завршува пред да почне.

Довербата живее на серверот, не во вашиот профил

Автентикацијата со сертификат е споредба. Клиентот претставува сертификат; портата проверува дали го потпишала некоја од CA во нејзината конфигурација.

Вашиот профил ја наведува датотеката со CA што клиентот треба да ја користи за проверка на серверот. Не може да наведе CA што серверот треба да ја користи за да ве провери вас. Таа половина од конфигурацијата не е ваша.

Самиот изработен сертификат паѓа на оваа споредба дури и кога е технички беспрекорен. Има важечки потпис, субјект и датуми, но издавачот е CA за која портата никогаш не слушнала. Грешката се појавува за време на ракувањето, откако серверот веќе побарал сертификат. Ништо во клиентскиот профил не може да го промени одговорот.

Зошто самопотпишан сертификат не може да го замени

Самопотпишаниот сертификат е потпишан со сопствениот клуч. Потписот се проверува против истата датотека, што го прави самоусогласен и бескорисен како акредитив за туѓа порта.

Портата не прашува дали сертификатот е внатрешно усогласен. Прашува дали го потпишал доверлив издавач.

Затоа пораките за грешка збунуваат. Клиентот може да пријави неуспех при проверка што звучи како проблем на серверот, додека серверот евидентира непознат издавач. Двете го опишуваат истото несовпаѓање од спротивни краеви.

Патот преку CSR го чува вашиот приватен клуч

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

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

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

Управуваните услуги често го прескокнуваат CSR и го издаваат целиот пакет. Тоа е разумна размена кога истиот провајдер веќе го завршува тунелот и ја држи CA. Чувањето на клучот не се подобрува со тоа што го задржувате, бидејќи провајдерот може да искова нов во секој момент.

Пакетите се увезуваат, не се инсталираат

Пакетите од продавачи со безбедносни имиња често се OpenVPN профили. Содржат конфигурација и понекогаш сертификати и не инсталираат ништо. Увезете ја датотеката во клиент што го зборува протоколот и врската е конфигурирана.

Правилото за постапување произлегува од содржината. Ако профилот вградува приватен клуч, тоа е акредитив и заслужува иста грижа како лозинка: без е-пошта, без складиште, без споделена папка за преземања. Кога операторот ги доставува ca.crt, client.crt и client.key одделно, чувајте ги заедно со ограничени дозволи и упатете го профилот кон нив.

Додајте ги проверките што операторот можеби ги прескокнал

Профилот генериран од рутер понекогаш нема проверка на партнерот. remote-cert-tls server бара сертификатот на партнерот да ја носи намената за автентикација на сервер, за да не може клиентски сертификат да се репродуцира како сервер. Таа една линија е мала промена со јасно оправдување.

verify-x509-name оди подалеку кога операторот може да го наведе очекуваниот субјект или SAN. Двете се мали додатоци на профил и двете се одбраниви. Проверете што сте добиле пред да го увезете.

openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt

Поставките за проверка не се поправка на скршена верига. Ако издавачот е погрешен, одговорот е сертификат од вистинската CA, не знаменце што ја исклучува проверката. Исклучувањето на проверката претвора неуспех на автентикацијата во неоткриен.

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