Krucsignita CA: la ŝlosilo kongruas, la AKI-ligo ne

Du CA-atestiloj povas porti la saman publikan ŝlosilon kaj la saman subjekton kaj tamen ne esti interŝanĝeblaj. Unu estas memsubskribita, la alia estas krucsignita de la malnova radiko, kaj iliaj eldonintaj nomoj, seriaj numeroj kaj subskriboj diferencas. Folio povas ligiĝi specife al unu el ili per sia Authority Key Identifier. Tiu ligo restas nevidebla ĝis kliento elektas la malĝustan ĉenon kaj la handshake malsukcesas sen evidenta kialo.

Plenumu ĉi tiujn kvin kontrolojn laŭorde: ĉiu el ili ekskludas malsaman fiaskon.

Kontrolo 1: desegnu ambaŭ ĉenojn antaŭ ol tuŝi la ŝablonon

Skribu la vojojn. La malnova populacio fidas Malnovan Radikon A, kiu eldonis CA B, kiu eldonis la folion de la servilo. La nova populacio fidas la memsubskribitan CA B rekte. Ambaŭ B-atestiloj portas la saman ŝlosilon kaj subjekton, kaj ĝuste tial homo leganta subjektan linion vidas unu CA tie, kie la kliento vidas du.

La krucsignita kopio ankaŭ devas esti vera CA-atestilo, kun basic constraints kaj key usage kiuj permesas subskribadon.

Kontrolo 2: komparu la AKI-kampojn, ne nur la ŝlosilon

La eldoninta nomo de la folio devas kongrui kun la subjekto de B, kaj tiu parto kutime validas. La Authority Key Identifier estas kie la du kopioj disiĝas, ĉar ĝi povas porti ŝlosilan identigilon, eldonintan atestilon kaj serian numeron. La ŝlosila identigilo kongruas kun ambaŭ kopioj, ĉar la ŝlosilo estas identa. La kampoj eldoninto kaj seria numero kongruas kun precize unu, kaj tial ĉeno konstruata kontraŭ la memsubskribita kopio povas malsukcesi kontraŭ la krucsignita.

Inspektu la folion anstataŭ diveni: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

Poste komparu ambaŭ kandidatojn per openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier", kaj la saman komandon kontraŭ la memsubskribita kopio.

Se la folio portas eldoninton kaj serian numeron, nur la atestilo, kiun tiuj valoroj priskribas, kompletigas la ĉenon, kiun ajn kopion kliento hazarde ŝarĝis.

Kontrolo 3: ŝanĝu eldonan politikon, neniam subskribitajn bitokojn

Etendaĵoj vivas ene de la subskribo. Aldoni, forigi aŭ redakti unu en ekzistanta folio ne estas riparo, ĝi estas malsama atestilo, kaj ĝi postulas reeldonon. La ŝanĝo apartenas al la eldona politiko: authorityKeyIdentifier = keyid,issuer:always igas novajn foliojn porti la atestil-specifan ligon, dum keyid sola konservas la pli lozan formon taŭgan por intenca krucsignada transiro. Decidu, kiun via PKI volas, antaŭ ol la sekva aro estos subskribita.

Redakti komunan ŝablonon ankaŭ ŝanĝas ĉiun estontan atestilon, ne nur la servilon antaŭ vi.

Kontrolo 4: kontrolu ĉiun fidan populacion aparte

Testu la malnovan vojon kaj la novan vojon kiel apartajn rultojn. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem ekzercas la krucsignitan itineron, kaj la sama komando kun la nova radiko kaj sen untrusted-dosiero ekzercas la memsubskribitan itineron. Miksi ambaŭ radikojn en unu pakaĵon kaŝas, kiun ĉenon oni elektis. Ripetu poste kun realaj klientoj, ĉar VPN-malantaŭo povas preferi ĉenon aŭ fiksi atestilon per manieroj, kiujn openssl ne faras.

Liveru la mezan atestilon per la serva agordo, kiun la kliento efektive legas, ne per vikia paĝo.

Kontrolo 5: tenu la malnovan vojon sur malmuntada horloĝo

Krucsignado tenas malnovan fidan vojon viva laŭ la dezajno, kio estas samtempe la celo kaj la risko. Ĝi ne sanigas kompromititan malnovan radikon, kaj ĝi ne forigas tiun radikon el iu ajn kliento. Skribu, kiam la malnova vojo ĉesos doni fidon, kaj konfirmu, ke tiu tago efektive alvenas.

Se ĉiu kliento povas preni la novan radikon antaŭ ol la folioj moviĝas, simpla duobla-fida lanĉo estas pli simpla ol krucsignado, kaj ĝi lasas unu aferon malpli por malmunti.