Абнаўленне сертыфіката VPN без змены яго ідэнтычнасці

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

Тры ўмовы вызначаюць форму абнаўлення

Гэтыя тры ўмовы: ці нешта замацоўвае канцавы сертыфікат, ці змяняецца ланцуг і хто яшчэ правярае імя. Адказвайце на гэта з боку кліента, а не з меркаванняў зручнасці CA, бо менавіта кліент адмаўляе ў тры гадзіны ночы.

Пачніце з агляду сертыфіката, які ў вас ёсць. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName выводзіць суб'ект, эмітэнта, акно сапраўднасці і імёны, для якіх сертыфікат сапраўды дзейны. Апошняе поле найважнейшае і найчасцей мяркуецца: запыт на абнаўленне, які апускае SAN, на які спадзяецца кліент, стварае сертыфікат, тэхнічна сапраўдны і функцыянальна няправільны. Капіруйце спіс SAN са старога сертыфіката ў запыт, а не перапісвайце яго з памяці.

Умова першая: ці нешта замацоўвае канцавы сертыфікат

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

Высветліце, у якім вы выпадку, перш чым штосьці замаўляць. Замацаванне, якога ніхто не дакументаваў, застаецца замацаваннем, калі яно ламаецца.

Умова другая: параўнайце замацаванні і ланцуг

Адбіткі робяць замацаванне прыдатным да праверкі: openssl x509 -noout -fingerprint -sha256 -in server.crt на старым і новым сертыфікаце, і openssl x509 -noout -pubkey каб параўнаць адкрытыя ключы. Калі ў канфігурацыі кліента, мабільным профілі або сховішчы даверу прылады ёсць любое з гэтых значэнняў, у вас ёсць замацаванне. Мабільныя профілі VPN — частае месца хавання, бо профіль распаўсюджваецца аднойчы і больш не агледжваецца.

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

Праверце ланцуг, які сервер насамрэч дасылае, з дапамогай openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, і праверце яго лакальна з дапамогай openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Зрабіце гэта да змены, каб мець базовую лінію для параўнання пасля.

Умова трэцяя: хто яшчэ правярае імя

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

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

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

Разгарніце, праверце свежай аўтэнтыфікацыяй, потым выведзіце з эксплуатацыі

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

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

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