Renovigi VPN-atestilon sen ŝanĝi ĝian identecon

Atestila renovigo, kiu ŝanĝas la identecon, ne estas renovigo, ĝi estas migrado portanta bontenadan bileton. La kliento kontrolas nomon, ĉenon kaj foje specifan ŝlosilon, kaj ĉiuj tri povas ŝanĝiĝi sen ŝanĝo de la findato. Antaŭ ol peti anstataŭaĵon, skribu, kion la kliento fakte kontrolas: la gastignomon aŭ la identecon de la kunulo, la celon de la atestilo, la ŝlosilan politikon kaj la eldonan ĉenon. La renovigo estas rutina aŭ kunordigita laŭ tio, kion el tiuj ŝanĝas la anstataŭaĵo.

Tri kondiĉoj decidas la formon de la renovigo

La tri kondiĉoj estas ĉu io fiksas la folian atestilon, ĉu la ĉeno ŝanĝiĝas, kaj kiu alia validigas la nomon. Respondu tion de la klienta flanko anstataŭ el la oportuno de la CA, ĉar la kliento estas tio, kio fiaskas je la tria matene.

Komencu per inspektado de la atestilo, kiun vi havas. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName presas la subjekton, la eldoninton, la validecan fenestron kaj la nomojn, por kiuj la atestilo vere validas. La lasta kampo plej gravas kaj plej ofte estas supozata: renoviga peto, kiu preterlasas SAN, kiun la kliento fidas, produktas atestilon teknike validan kaj funkcie malĝustan. Kopiu la SAN-liston el la malnova atestilo en la peton anstataŭ retajpi ĝin el memoro.

Kondiĉo unu: ĉu io fiksas la folian atestilon

Se klientoj fidas prizorgatan CA kaj validigas la nomon, renovigo de la folia atestilo kun nova ŝlosilo estas nevidebla por ili. Se iu kliento fiksas la folian atestilon, ĝian fingrospuron aŭ ĝian publikan ŝlosilon, la anstataŭaĵo estas kunordigita ŝanĝo kun malmola transiro, ĉar la malnova fiksilo ne povas validigi la novan atestilon.

Konstatu, en kiu kazo vi estas, antaŭ ol mendi ion. Fiksilo, kiun neniu dokumentis, restas fiksilo, kiam ĝi rompiĝas.

Kondiĉo du: komparu la fiksilojn kaj la ĉenon

Fingrospuroj igas la fiksilon kontrolebla: openssl x509 -noout -fingerprint -sha256 -in server.crt ĉe la malnova kaj la nova atestilo, kaj openssl x509 -noout -pubkey por kompari publikajn ŝlosilojn. Se la klienta agordo, poŝtelefona profilo aŭ fidujo de aparato enhavas iun el la du valoroj, vi havas fiksilon. Poŝtelefonaj VPN-profiloj estas ofta kaŝejo, ĉar la profilo disdoniĝas unufoje kaj neniam plu inspektiĝas.

Se la anstataŭaĵo venas de la sama pera atestilo kaj la kliento jam havas ĝin aŭ povas akiri ĝin, nenio ŝanĝiĝas ĉe la fida flanko. Nova pera atestilo, malsama eldoninto aŭ ĉeno liverita en malĝusta ordo ĉiuj ŝanĝas renovigon en fidŝanĝon, kaj la fiasko aspektas kiel nekonata eldoninto anstataŭ kiel eksvalidiĝinta atestilo.

Kontrolu la ĉenon, kiun la servilo fakte sendas, per openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, kaj kontrolvalidigu ĝin loke per openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Fari tion antaŭ la ŝanĝo donas al vi bazlinion por kompari poste.

Kondiĉo tri: kiu alia validigas la nomon

VPN-koncentrilo, ŝarĝbalancilo, monitorada sondilo, RADIUS- aŭ SAML-integriĝo kaj poŝtelefona profilo povas ĉiu teni sian propran kopion de la atendata nomo aŭ fida ankro. Renovigo estas la momento, kiam tiuj kopioj diverĝas, ĉar la atestilo ŝanĝiĝas kaj la kopioj ne.

Listigu ĉiun konsumanton antaŭ la ŝanĝo kaj decidu por ĉiu, ĉu ĝi bezonas ĝisdatigon. Tiu, kiun vi forgesos, estas tiu, kiu vokos vin.

Estas ankaŭ tempokaptilo. Inspektu la komencon de valideco same kiel la findaton, ĉar atestilo preparita por posta aktivigo estas malakceptata, se instalita tro frue, kaj la eraro aspektas kiel horloĝa problemo anstataŭ kiel prepara problemo. openssl x509 -noout -dates ĉe la nova dosiero antaŭ ol deploji ĝin estas duseekunda kontrolo. Tenu ankaŭ subtenatan restaŭran vojon kaj la konatan bonan agordon, por ke renovigo, kiu misfunkcias, estu malfarebla per restarigo de la antaŭa atestilo kaj ŝlosilo.

Deploju, kontrolvalidigu per freŝa aŭtentigo, poste retiru

Establita tunelo spegulas la validigon, kiu okazis kiam ĝi estis konstruita, do ĝi povas aspekti sana dum ĉiu nova konekto fiaskas. Testu per freŝa aŭtentigo uzante la faktan servonomon, kiun uzas la klientoj.

Kompletigu la aplikaĵnivelan kontrolon, kiu gravas al la uzanto, kaj konfirmu la ĉenan liveradon el la perspektivo de la kliento anstataŭ de la servilo. Ne subpremu nomajn aŭ atestilajn kontrolojn por teni la transiron kvieta; tio igas provizoran kongruecproblemon daŭra.

Retiru malaktualan materialon nur post kiam la deplojo estas kontrolvalidigita, kaj traktu kompromititan ŝlosilon kiel tute alian kazon: renovigo sola revokas nenion, do la tuŝita identeco bezonas la revokan kaj seanadministran procezon de la deplojo. RFC 5280 difinas la atestilajn kaj vojo-validigajn regulojn sub ĉio ĉi. Tenu rutinan folian renovigon aparte de CA-anstataŭigo, por ke klientoj ne estu petataj fidi novan eldoninton sen kialo.