Што се случува кога ќе го замените издавачот на сертификати за VPN

Замената на издавачот на сертификати за VPN не е замена на датотека. Во моментот кога новиот CA го потпишува својот прв сертификат, секој валидатор што сѐ уште и верува само на старата мора да донесе одлука, а домаќините што никогаш не ја добиваат новата котва продолжуваат да ги одбиваат добрите партнери. Сум го видел како се расипува во двете насоки: портата го научи новиот CA, а клиентите не, па новите врски паѓаа, додека веќе кренатите тунели останаа и направија прекинот да изгледа како проблем со рутирање. Еве што се менува, по редоследот по кој се појавуваат дефектите.

Една замена, две одделни промени

Издавачот на сертификати е име, јавен клуч и приватниот клуч што потпишува. Валидаторите никогаш не ѝ веруваат на „CA“ апстрактно. Тие веруваат на еден конкретен сертификат што веќе стои во складиште за доверба, и го прифаќаат издавачот само ако синџирот на потписи стигне до таа зачувана копија. Затоа замената на CA менува две работи што откажуваат независно: кои котви се прифаќаат и кои идентитети на партнерите се издадени под нив.

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

Што проверува валидаторот, по ред

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

За да ја повторите таа прошетка офлајн, насочете го -CAfile кон точно таа група што ќе ја распоредите, а не кон системското складиште. Инаку го тестирате домаќинот, а не промената:

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

Таа команда работи само против едноставен TLS слушател како административната страница HTTPS на портата; контролниот канал на OpenVPN претходи на TLS, па s_client не може да го испита ракувањето на тунелот.

Правилата за изградба на патека зад тие грешки се во RFC 5280 дел 6. Тие ги објаснуваат дефектите што инаку изгледаат произволни: истечен посредник што никој не го помнеше, сертификат чија употреба на клуч забранува потпишување или ограничување на име што го исклучува домаќинот што го тестирате.

Зошто стариот тунел продолжува да работи

TLS и OpenVPN и двата држат воспоставена сесија жива откако ќе заврши ракувањето. Ништо не го ревалидира сертификатот на партнерот по пакет, па клиентот што се поврзал пред промената продолжува да пренесува сообраќај додека повторно не преговара, не се поврзе или тунелот не падне. Токму таа празнина прави замената на CA да изгледа добро еден час, а потоа да откаже во најлошиот момент: преносник се буди од сон, NAT мапирањето истекува, портата се рестартира.

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

Држете го слојот на статичен клуч одделно од ова. tls-auth додава HMAC на контролниот канал, tls-crypt го шифрира и автентицира, и ниедно од двете не носи сертификатен материјал, па ротацијата на кое било од нив е одделна промена со сопствен режим на дефект. Распоредувањата што ги мешаат двете завршуваат со клиент чиј статичен клуч е во ред, сертификатот е застарен, а пораката за грешка не споменува ниту едно.

Стапицата на повторна употреба на името на субјектот

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

Тогаш изградбата на патека може да го избере погрешниот, да пријави „не може да се добие сертификат на локалниот издавач“ додека правилната котва е присутна, или да успее на еден домаќин и да откаже на друг со истата група, зашто редоследот на кандидатите се разликувал. Ако името мора да се употреби повторно, држете ги двете котви во одделни датотеки за време на преминот и вчитајте ги експлицитно, а спојте ги само кога секој партнер го претставува новиот издавач. Инаку дајте ѝ на замената различно општо име — суфикс на генерација или датум е доволен — за да кажат дневниците и текстовите за грешки под кој орган е издаден партнерот што откажува.

Ротација што не ја соборува мрежата

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

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

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

Проверете го резултатот, а не списокот на датотеки

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

Потврдете дека нова врска со нов идентитет успева, па потврдете дека идентитет издаден од повлечениот CA се одбива. Токму тој втор тест луѓето го прескокнуваат и тој е единствениот што покажува дека стариот орган повеќе не дава пристап. Каде распоредувањето се потпира на CRL или OCSP, проверете дали точките за дистрибуција во новите сертификати се решаваат и дали одговарачот е достапен од партнерите што го прашуваат.

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