Ĉu vi revokis la malĝustan VPN-atestilon? Ripagaj ebloj kaj limoj

Iu revokis atestilon en la CA-konzolo, kaj nun uzanto ne povas konektiĝi. La unua instinkto estas serĉi la malfaron, kaj por la plej multaj PKI-oj ĝi ne ekzistas: revoko estas deklarita fakto pri seria numero, kaj la subtenata vojo reen estas nova atestilo, ne inversigita rikordo. Trapasu la subajn kontrolojn laŭorde, ĉar kiun riparon vi rajtas uzi dependas de la kialkodo kaj de tio, ĉu la ŝlosilo iam estis malkaŝita.

Identigu la atestilon, ne la personon

Komunaj nomoj ripetiĝas. Uzanto, kiu reenregistriĝis pasintan kvaronon, povas havi du atestilojn kun la sama CN kaj malsamaj seriaj numeroj, kaj revoki unu lasas la alian funkcii. Unue establu la precizan objekton:

openssl x509 -in client.crt -noout -serial -issuer -subject -dates
openssl crl -in ca.crl -noout -text | head -40

Notu la serian numeron, la eldonanton, la revokan daton kaj la kialon registritan en la CRL. Poste konfirmu, kiuj aparatoj prezentas tiun serian numeron, ĉar revokita atestilo povas ankoraŭ esti instalita sur tekkomputilo, telefono kaj rezerva enkursigilo, kaj anstataŭo, kiu atingas nur unu el ili, produktas duan incidenton.

Rapida konduta kontrolo konfirmas la staton sen ŝanĝi ion ajn:

openssl verify -crl_check -CAfile ca.crt -CRLfile ca.crl client.crt

Se ĝi raportas la atestilon kiel revokita, la CRL kaj la kliento konsentas; se ĝi validigas pure, la kliento, kiun vi tenas, ne estas la revokita, kaj la serĉado daŭras.

Kontrolu, ĉu la CA uzis haltigon aŭ permanentan revokon

RFC 5280 difinas certificateHold kiel provizoran staton, kaj removeFromCRL kiel la signalon, kiu ĝin liberigas. Tiu vivociklo estas reala, sed ĝi ne estas ĝenerala malfar-butono. Legado de la kialkodo diras al vi, ĉu la eldonanto iam intencis subteni liberigon.

La kaptilo estas supozi, ke provizora intenco implicas provizoran rikordon. Se la CA-rikordo portas keyCompromise aŭ cessationOfOperation, la atestilo estas permanente revokita, sendepende de tio, kion la persono, kiu premis la butonon, intencis. Male, rikordo markita certificateHold sur CA, kiu ne implementas haltoliberigon, estas permanenta en praktiko, ĉar nenio iam publikigos la liberigon.

CA-oj bazitaj sur OpenSSL ilustras la limon. La komando ca akceptas valorojn de -crl_reason, inkluzive de certificateHold kaj removeFromCRL, sed ĝi ne generas deltajn CRL-ojn — la dokumentaro de OpenSSL CA indikas tiun limigon por sia CRL-eligo. Plena CRL, kiu simple preterlasas la serian numeron, estas malsama publikiga modelo ol delto, kiu diras "ĉi tiu rikordo estas liberigita", do enmeti removeFromCRL en OpenSSL-bazan VPN-CA ne produktas la norme difinitan liberigon.

Se la ŝlosilo eble malkaŝiĝis, anstataŭigu ĝin

Revokita atestilo estas deklaro, ke ĉi tiu ŝlosilo eble ne plu estas fidinda. Se la revoko estis esence ĝusta — tekkomputilo perdiĝis, ŝlosilo kopiita al komuna disko, privata ŝlosilo enmetita en bileto — restarigo de la sama atestilo inversigas sekurecan decidon, kiu funkciis laŭintence.

Eldonu novan ŝlosilparon per la registriĝa procezo, disdonu la novan profilon, kaj lasu la malnovan serian numeron revokita por ĝia tuta vivodaŭro. Ĝisdatigu ĉion, kio fiksas identecon per seria numero aŭ fingropremo, inkluzive de akceptolistoj, aparataraj inventaroj kaj monitorado, kiu atendas specifan atestilon.

La komforta argumento por restarigi la malnovan estas reala, sed ĝi devas esti respondita eksplicite, ne sekrete. "La uzanto bezonas aliron hodiaŭ" estas kialo por akceli eldonadon, ne kialo por malrevoki ŝlosilon, pri kiu vi ne povas respondeci.

Se ĝi estis administra eraro, anstataŭigu sub kontrolo

Kiam la revoko estis simple malĝusta kaj la ŝlosilo neniam malkaŝiĝis, la riparo estas ankoraŭ kontrolita anstataŭo, ne redakto. Uzu la subtenatan procezon de la eldonanto, konservu la serian numeron kaj eldonan historion sendifektaj, kaj evitu la du allogajn mallongigojn: renversi la statan signon en index.txt de R reen al V, kaj forigi la eldonan vicon tiel, ke nova atestilo povu reuzi la serian numeron.

Sur OpenSSL-CA la datumbazo estas tab-separita kaj facile mislegebla, kio faras manan redaktadon alloga:

awk -F'\t' '$1=="R" {print $4, $3, $6}' index.txt

Legu ĝin, ne skribu ĝin. Redaktado de la dosiero ŝanĝas la sekvan CRL sen ia ajn revizia postsigno, kaj ajna dua CA-instancaĵo aŭ sekurkopio, kiu ankoraŭ tenas la originalan vicon, malkonsentos kun ĝi poste.

Post eldono de la anstataŭo, publikigu freŝan CRL per la normala mekanismo kaj lasu la klientojn preni ĝin. Forigi CRL, mallongigi ĝian vivodaŭron al nenio aŭ malŝalti revokan kontroladon en la klienta profilo riparas unu uzanton malfortigante ĉiun alian revokon, kiun la CA iam publikigis.

Konfirmu freŝan akcepton kaj konservu la rikordon

Testu per nova konekto, ne per la seanco, kiu jam estis malfermita. Vivanta tunelo eble ne reekzekutos la akceptokontrolojn, kiujn faras freŝa manpremo, kaj CRL-kaŝmemoroj signifas, ke kliento povas daŭre konektiĝi ĝis ĝi refreŝiĝos. Malkonektiĝu, rekonektiĝu, kaj konfirmu en la servila protokolo, kiu seria numero estis akceptita.

Registru, kio okazis dum ĝi estas ankoraŭ freŝa: kiu seria numero estis revokita, de kiu, kun kiu kialo, kiu anstataŭo estis eldonita, kaj kiam la CRL estis republikigita. Tiu rikordo ebligas la sekvan revokan revizion, kaj ĝi ankaŭ estas la pruvo, ke la eraro estis traktita anstataŭ kaŝita.

Por mallongaj haltoj estonte, uzu akceptopaŭzan mekanismon se la deplojo havas unu — konto malŝaltita ĉe la identeca tavolo, forigita grupaneco, retenita klienta profilo. Tio tenas provizoran politikan decidon aparte de la demando, ĉu eldonita atestilo ankoraŭ estas fidinda, kaj ĝuste tiu distingo perdiĝis la unuan fojon.