Kial kopii ca.key al ĉiu VPN-kliento detruas la CA

Ie en la instalaĵaj instrukcioj tuta dosierujo estas kopiata senŝanĝe al ĉiu tekkomputilo, ĉar tio estis pli facila ol decidi, kiuj dosieroj apartenas tien. Tiu dosierujo enhavas ca.key, kaj en la momento, kiam ĝi atingas duan aparaton, la atestiga aŭtoritato ĉesas esti aŭtoritato. Ĉiu posedanto nun povas eldoni identecojn, kiujn la resto de la reto fidos.

Indas unufoje malimpliki tiun konfuzon, ĉar la du dosieroj aspektas similaj kaj faras malajn aferojn.

Kontrola materialo kaj subskriba materialo

Kliento bezonas la publikan atestilon de la CA por kontroli, ke la atestilo prezentita de la alia flanko estis subskribita de tiu aŭtoritato. Tio estas kontroltasko kaj tute ne postulas sekreton. Subskribi atestilon de la alia flanko estas alia tasko, plenumata unufoje de tiu, kiu administras la CA, per la privata ŝlosilo, kiu neniam forlasas sian protektitan konservejon. Teni tiujn du taskojn apartaj estas la tuta senco de du alsenditaj dosieroj.

Do ca.crt apartenas al la profilo, kaj ca.key apartenas nenie proksime al ĝi. La dosiernomoj estas konvencio, ne garantio, kaj tial la tipo devas esti ekzamenata anstataŭ deduktata el la nomo.

Arkitekturo kun meza CA aŭ reta eldonservo ne estas escepto de tio. Ĝi estas la norma maniero teni subskriban kapablon for de finpunktoj dum aparataj atestiloj estas eldonataj grandskale.

Kion kliento devas pruvi per sia propra ŝlosilo

Ĉiu aparato ricevas sian propran ŝlosilparon kaj sian propran atestilon, subskribitan unufoje de la CA. La kliento prezentas tiun atestilon kaj pruvas posedon de la kongrua privata ŝlosilo, kaj la servilo decidas, ĉu akcepti ĝin. Tio estas la identeco, kiu estas revokata, kiam tekkomputilo perdiĝas.

La kontrasto plej gravas post ŝtelo. Kun identecoj po aparato, unu elmontrita kliento estas forigata per revoko aŭ per forigo de la alia flanko, kaj la resto de la floto daŭre funkcias.

Elfluinta ŝlosilo de aŭtoritato ne povas esti traktata tiel. Ĉiu atestilo, kiun ĝi iam subskribis aŭ povus subskribi, fariĝas suspektinda, do la respondo estas anstataŭigo de fido, ne unuopa revoko. Tio estas projekto, ne bileto.

Legu dosieron antaŭ ol kopii ĝin ie ajn

Du komandoj diras al vi, kian objekton vi tenas, sen presi iun sekreton. La unua nomas la subjekton kaj la CA-flagon ĉe atestilo; la dua validigas ŝlosilon kaj raportas ĝian tipon. Rulu ambaŭ je la dosieroj en la pakaĵo, kiun vi estas disdononta. Ĉio, kio validiĝas kiel privata ŝlosilo, ne apartenas al klienta dosierujo.

openssl x509 -in ca.crt -noout -subject -ext basicConstraints
openssl pkey -in ca.key -noout -check

Se la dua komando sukcesas je dosiero, kiu kuŝas en klienta pakaĵo, haltu kaj traktu la pakaĵon kiel kompromititan. Eligo diranta, ke ŝlosilo estas valida, ankaŭ diras, ke ĝi ĉeestas, kaj ĉeesto estas la tuta problemo.

Rimarku ankaŭ la alian direkton: klienta profilo laŭleĝe enhavas la privatan ŝlosilon de tiu kliento. Forigi ĉiun trovitan ŝlosilon rompas la konekton sen plibonigi ion, do la objekto devas esti identigita antaŭ ol esti forigata.

Enlimigo de ŝlosilo, kiun vi jam disdonis

Ne supozu, ke forigo de la loka kopio inversigas la elmetiĝon. Ĉiu, kiu havis la dosieron, povis kopii ĝin, kaj la sekura supozo estas, ke li faris. Sekvu la incidentan procedon de la operatoro kaj anstataŭigu la fidkernon, reeldonante aparatajn atestilojn sub nova CA.

Poste ŝanĝu la pakadon, kiu kreis la problemon. Sendu dosierujan liston kun eksplicita permeslisto de dosieroj, tenu la CA-ŝlosilon sur maŝino, kiu neniam aliĝas al la klienta floto, kaj registru, kiu sistemo tenas ĝin.

Se la aŭtoritato devas ofte eldoni, movu la subskribadon malantaŭ servon aŭ mezan aŭtoritaton kun mallarĝa amplekso kaj mallonga valideco. Tiel estonta eraro elmontras subaron de la eldonado anstataŭ la fidradikon de la tuta deplojo.