Што адбываецца, калі замяніць цэнтр сертыфікацыі VPN

Замяніць цэнтр сертыфікацыі VPN — гэта не проста падмена файла. У той момант, калі новы ЦС падпісвае першы сертыфікат, кожны валідатар, які давярае толькі старому, мусіць прыняць рашэнне, а хасты, што не атрымаюць новы якар, працягваюць адхіляць добрых партнёраў. Я бачыў, як гэта ламалася ў абодва бакі: шлюз даведаўся пра новы ЦС, а кліенты не, таму новыя злучэнні падалі, а ўжо ўзнятыя тунелі заставаліся і рабілі збой падобным на праблему маршрутызацыі. Вось што змяняецца — у тым парадку, у якім з'яўляюцца збоі.

Адна замена, дзве асобныя змены

Цэнтр сертыфікацыі — гэта імя, адкрыты ключ і закрыты ключ, які падпісвае. Валідатары не давяраюць «ЦС» увогуле. Яны давяраюць канкрэтнаму сертыфікату, які ўжо ляжыць у сховішчы даверу, і прымаюць эмітэнта, толькі калі ланцуг подпісаў дасягае гэтай захаванай копіі. Таму замена ЦС змяняе дзве рэчы, якія адмаўляюць незалежна: якія якары прымаюцца і якія асобы партнёраў былі выдадзены пад імі.

Большасць разгортванняў VPN правярае ў абодва бакі. Кліент аўтэнтыфікуе сертыфікат шлюза, а шлюз — сертыфікат кліента. Пераход, які абнаўляе толькі кліенцкі пакет, пакідае сервер адхіляць кожнага кліента, што ўсё яшчэ падае асобу ад старога ЦС, і зваротнае сустракаецца гэтак жа часта. Спачатку пералічыце пункты кантролю: сховішчы даверу кліентаў, файл 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 трымаюць усталяваную сесію жывой пасля завяршэння рукапаціску. Нішто не пераправярае сертыфікат партнёра на кожны пакет, таму кліент, што падключыўся да змены, працягвае перадаваць трафік, пакуль не перазамовіць, не перападключыцца або тунель не абрывецца. Менавіта гэтая шчыліна робіць так, што замена ЦС можа гадзіну выглядаць добра, а потым адмовіць у найгоршы момант: ноўтбук прачынаецца ад сну, адлюстраванне NAT сканчаецца, шлюз перазапускаецца.

Аднаўленне сесіі расцягвае ілюзію далей. Білет сесіі TLS дазваляе кліенту вярнуцца без паўторнай адпраўкі сертыфікатаў, а аднаўленне прапускае праверку шляху, бо першы рукапаціск ужо зрабіў яе. Таму сумленны тэст — поўны рукапаціск у новым працэсе. Перазапусціце кліент, а не перападключыце тунель, і на тэставым профілі паспрабуйце адключыць білеты, каб шлях аднаўлення не мог схаваць пабіты ланцуг.

Трымайце слой статычнага ключа асобна ад гэтага. tls-auth дадае HMAC у кантрольны канал, tls-crypt шыфруе яго і аўтэнтыфікуе, і ніводзін не нясе матэрыял сертыфіката, таму ратацыя любога з іх — асобная змена са сваім рэжымам збою. Разгортванні, што змешваюць абое, атрымліваюць кліента, у якога статычны ключ у парадку, сертыфікат састарэлы, а паведамленне пра памылку не згадвае ні аднаго.

Пастка паўторнага выкарыстання імя суб'екта

Спакусліва паўторна выкарыстаць адметнае імя папярэдніка, каб нічога ніжэй па патоку не давялося мяняць. Гэта трымае радок эмітэнта стабільным у інтэрфейсе і знішчае адзіны сігнал, які вам патрэбны. Два сертыфікаты з аднолькавымі суб'ектамі і рознымі ключамі немагчыма адрозніць па імені, таму пакет з абодвума якарамі дае валідатару двух кандыдатаў і ніякага правіла выбару.

Тады пабудова шляху можа выбраць няправільны, паведаміць «не ўдалося атрымаць сертыфікат мясцовага эмітэнта», калі правільны якар прысутнічае, або дасягнуць поспеху на адным хосце і збаіць на іншым з тым самым пакетам, бо парадак кандыдатаў адрозніваўся. Калі імя трэба паўтарыць, трымайце абодва якары ў асобных файлах на час пераходу і загружайце іх яўна, а аб'ядноўвайце толькі тады, калі кожны партнёр прадстаўляе новага эмітэнта. Інакш дайце замене адрознае агульнае імя — суфікса пакалення або даты дастаткова, — каб журналы і тэксты памылак казалі, пад якой уладай выдадзены збойны партнёр.

Пераход, які не валіць сетку

Для планаванай замены прымайце абодва якары на абмежаваны час, а не перамыкайце адным крокам. Выдайце новы ЦС і яго прамежкавыя, пакладзіце новы якар у пакет кожнага валідатара побач са старым і толькі потым пачніце выдаваць з яго сертыфікаты партнёраў. Партнёры са старымі асобамі правяраюцца супраць старога якара; новыя працуюць супраць новага.

Калі рабіць у гэтым парадку, кожны крок зваротны. Збой, якога вы пазбягаеце, — гэта адначасовае перамыканне, калі кліент, што прапусціў абнаўленне пакета, сустракае шлюз, які ўжо адправіў стары якар на спачын, рукапаціск памірае, і ніводзін журнал не кажа, які бок састарэлы.

Згортвайце ў адваротным кірунку. Перайвыдайце кожную асобу, якая мусіць застацца, пацвердзіце, што кожная прадстаўляе новы ланцуг, і тады прыбярыце стары якар з пакетаў. Вывядзіце закрыты ключ старога ЦС з эксплуатацыі, бо эмітэнт, які ўсё яшчэ можа падпісваць, значыць, што пераход не завершаны. Захавайце сертыфікаты і запісы выдачы для аўдыту. Страчаны эмітэнт аднаўляецца да таго ж даверу; выкрыццё патрабуе новых асоб і не дапускае вяртання да старога якара.

Правярайце вынік, а не спіс файлаў

Файл даверу ў чаканым каталогу мала што даказвае. Праграма можа чытаць іншы шлях, іншы фармат або копію ўнутры пакета, які замяняе абнаўленне. Правярайце паводзіны на абодвух канцах, а не існаванне файла.

Пацвердзіце, што свежае злучэнне з новай асобай паспяховае, а потым — што асоба, выдадзеная знятым ЦС, адхіляецца. Другі тэст людзі прапускаюць, і толькі ён паказвае, што старая ўлада больш не дае доступу. Там, дзе разгортванне абапіраецца на CRL або OCSP, праверце, што пункты размеркавання ў новых сертыфікатах развязаваюцца і адказнік дасяжны для партнёраў, якія яго запытваюць.

Скончыце кліентам, які ніколі не падключаўся: ачысціце стан яго профілю, падключыцеся і прачытайце ўзгоднены ланцуг. Партнёр, што аднаўляе кэшаваную сесію, радасна паведаміць, што міграцыя ўдалася, хоць ён нічога не правяраў.