Додавање VPN клиент без повторна изградба на CA

Ви треба уште еден сертификат за уште еден преносен сметач, но првото упатство во резултатите од пребарувањето започнува со наредба што ја брише PKI папката. Таа наредба припаѓа на првото поставување, не на регистрацијата, и нејзиното извршување ве чини CA, историјата на издавање и секој клиентски профил што му верувал на стариот издавач. Одлуката е потесна: има ли издавачот сè уште употреблива состојба и дали новиот уред се вклопува во вашата политика за регистрација? Три услови одлучуваат, а само еден оправдува повторна изградба.

Што навистина уништува повторната изградба

Повторното иницијализирање на PKI ја заменува папката со празна структура: нов CA клуч и сертификат, празна база за издавање, нов бројач на серии. Клиентите не следат сами; нивните профили го закачуваат стариот CA, па секој уред мора повторно да се регистрира, а недостапните рачно.

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

Копирањето на приватниот клуч на CA покрај серверот што работи е другиот пречица што треба да се одбие: го претвора телото за потпис што треба да стои надвор од мрежата во уште една датотека на домаќин со недоверлив сообраќај.

Прв услов: дали состојбата на издавачот е сè уште достапна?

Пронајдете ја папката на која серверот навистина му верува пред да одлучите. Споредете го сертификатот што серверот го претставува како CA со оној во PKI папката по отпечаток, не по име на датотека:

openssl x509 -in ca.crt -noout -fingerprint -sha256
openssl x509 -in /etc/openvpn/ca.crt -noout -fingerprint -sha256

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

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

Втор услов: кој го држи новиот приватен клуч?

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

Со Easy-RSA 3 против постоечки CA, увозот и потпишувањето барање се две наредби:

./easyrsa import-req /tmp/alice.req alice
./easyrsa sign-req client alice

Изберете го типот на сертификат намерно. Барање потпишано како серверски наместо клиентски сертификат дава датотека што изгледа добро и што партнерот ја одбива, а пораката за грешка ретко кажува зошто. Со openssl ca истиот избор живее во проширувањата што ги пренесувате, не во стандардниот дел.

Трет услов: дали на серверот му треба повеќе од сертификат?

За обичен OpenVPN сервер со автентикација по сертификат, сертификатот е самиот упис: заедничкото име станува идентитет на клиентот, а секоја папка, турната рута или статична адреса зависат од тоа име. Додајте го сертификатот и заборавете ја конфигурацијата, тунелот се поврзува но потребните рути не се појавуваат.

Платформите го менуваат ова. OpenVPN Access Server држи сопствена база на корисници, па потпишаниот сертификат не е сметка; сметката мора да постои и да биде дозволена. Други порти поврзуваат низа за идентитет со група. Регистрацијата на еден уред обично допира два системи, а сертификатот е само првиот.

Инкременталната постапка и кога повторната изградба е точна

Следењето што додава еден уред без штета: потврдете го издавачот по отпечаток, земете свежа копија од PKI папката, увезете и потпишете го барањето за клиентската улога, доставете го сертификатот со ланецот низ одобрениот канал и проверете пред корисникот да се поврзе:

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

Линијата за намена треба да покаже SSL client. Завршете со ажурирање на копијата на CA по издавањето, бидејќи копија направена пред новиот сериски број враќа состојба без уредот што штотуку го додадовте.

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