Cheti cha VPN kilichofutwa bado kinaunganisha? Angalia utekelezaji wa CRL

Ulifuta cheti, ukatengeneza orodha mpya, na profaili ya zamani bado inainua handaki. Ufutaji wenyewe haujavunjika: CRL ni tamko lililosainiwa kwamba nambari ya mfululizo haitumiki tena, na hubadilisha ufikiaji tu wakati kipengele kinachomaliza TLS kinapakia, kwa mtoaji sahihi, kabla ya kufanya uamuzi wa kukubali. Hapo ndipo kesi nyingi za aina hii zilipo, na ndiyo sababu ufutaji na kukataliwa ni mambo mawili tofauti.

Pitia ukaguzi watano hapa chini kwa mpangilio, na usimame kwenye ule wa kwanza ambao haushiki, kwa sababu kila ukaguzi unaofuata unadhani ule uliopita ni kweli.

Angalia ni kipengele kipi kinafanya uamuzi wa kukubali

Taja mchakato unaothibitisha cheti cha mteja, kwa sababu ni mchakato huo pekee unaoweza kutekeleza orodha. Kwenye seva ya OpenVPN ni daemon yenyewe, iliyosanidiwa na crl-verify. Kwenye ocserv ni mstari crl katika ocserv.conf. Kwenye strongSwan pembejeo ni CRL zilizopakiwa pamoja na strictcrlpolicy. Proksi au kifaa kinachomaliza TLS mbele ya VPN kinaweza pia kuwa kihakiki halisi, na ikiwa ndivyo, daemon iliyo nyuma yake haioni cheti cha mteja kamwe.

WireGuard ni katika kundi lingine. Haina vyeti na haina orodha ya ufutaji; peer hukubaliwa kwa ufunguo wake wa umma katika usanidi, kwa hivyo kumaliza ufikiaji kunamaanisha kuondoa ufunguo huo. Ikiwa unatafuta CRL katika usambazaji wa WireGuard pekee, utaratibu huo haupo.

Jihadharini pia na mtego wa upande wa mteja. Mteja anayekataa kuunganisha kwa sababu hapendi cheti cha seva anatekeleza mnyororo wa seva, hafuti vitambulisho vyake mwenyewe. Cheti cha mtumiaji hufutwa tu pale ambapo cheti hicho cha mtumiaji kinathibitishwa, na hiyo ni karibu kila mara upande wa seva.

Angalia orodha ilisainiwa kwa mtoaji gani

CRL imezuiwa kwa CA moja inayotoa. Kukiwa na mzizi na CA ya kati, vyeti vya jani hutoka kwa ya kati, kwa hivyo orodha muhimu ni CRL ya ya kati; orodha ya mzizi haisemi chochote kuhusu majani hayo. Kihakiki kinachoelekezwa kwenye faili isiyo sahihi huichanganua kwa furaha, hakipati ingizo linalolingana na hukubali kila kitu.

Thibitisha ulinganifu kabla ya kugusa daemon. Mtoaji kwenye cheti lazima alingane na subject ya orodha:

openssl x509 -in client.crt -noout -issuer -serial
openssl crl  -in intermediate.crl -noout -issuer -lastupdate -nextupdate

Wakati zote mbili zinatoka kwa CA moja, nambari ya mfululizo iliyochapishwa kwa cheti ni thamani ambayo lazima ionekane kwenye orodha. Ikiwa hazilingani, unashikilia CRL isiyo sahihi au nakala isiyo sahihi yake.

Uhalali ni wa ukaguzi huo huo. nextUpdate iliyopita hufanya orodha kuwa ya zamani, na kihakiki kinachoshindwa kwa kufungwa kitakataa kila mteja badala ya ule uliofutwa pekee.

Angalia kwamba nambari ya mfululizo iko kwenye nakala iliyopakiwa na daemon

Ufutaji huandika ingizo katika hifadhidata ya CA, na kuzalisha upya huandika faili mpya. Hakuna hatua yoyote inayofikia daemon inayofanya kazi iliyopakia nakala ya zamani wakati wa kuanza. Toa orodha na utafute nambari ya mfululizo:

openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crl

Kisha angalia jinsi utekelezaji wako unavyochukua faili. OpenVPN husoma njia iliyotolewa kwa crl-verify mara moja wakati wa kuanza, kwa hivyo orodha mpya inahitaji kuanza upya au ishara ya kuanza upya; chaguo hilo hilo linaloelekezwa kwenye saraka husomwa upya kwa kila muunganisho, na ndiyo sababu hali ya saraka ipo. strongSwan lazima ipakie upya vitambulisho vyake, kwa mfano kwa swanctl --load-creds. Faili kuwa sahihi kwenye diski na kihakiki kuitumia ni mambo mawili tofauti.

Angalia sera ya orodha inayokosekana au iliyoisha muda

Huu ni uamuzi ambao usambazaji mwingi haufanyi kamwe kwa uwazi, na huamua kama ufutaji unakulinda au unafunga kila mtu nje. Fail-closed inamaanisha kwamba bila taarifa ya ufutaji inayoweza kutumika, kukataliwa hutokea; fail-open inamaanisha kwamba kihakiki huendelea bila hiyo. strongSwan hutoa chaguo kama strictcrlpolicy. OpenVPN na crl-verify hukataa kuanza kwenye faili ambayo haiwezi kuisoma au kuichanganua, na orodha iliyoisha muda huonekana kama hitilafu ya uthibitishaji wa TLS kuhusu CRL iliyoisha muda badala ya kukubali kwa kimya.

Uchague mwelekeo upi, uendeshaji wa kiotomatiki ni muhimu zaidi kuliko uchaguzi: kazi inayozalisha upya CRL kabla ya nextUpdate, na tahadhari wakati nakala iliyosambazwa inazeeka, huzuia sera zote mbili kuwa tukio. Ukaguzi wa mtandao kwa OCSP huhamisha ubichi kwa mjibu, lakini sheria hiyo hiyo inatumika, kwa sababu kihakiki kisichosanidiwa kukagua jibu hakibadilishi chochote.

Angalia kikao kinachotumika, kisha nakala za ufunguo

Ufutaji hutathminiwa wakati wa uthibitishaji wa cheti, unaotokea wakati wa kuunganisha na wakati wa kujadiliana upya. Kikao kilichoanzishwa huendelea hadi kijadiliane upya, na chaguo-msingi la OpenVPN ni mara moja kwa saa na reneg-sec 3600. Ikiwa mtu lazima atoke kwenye mtandao sasa, maliza kikao pamoja na kuchapisha orodha, kisha thibitisha kwamba kuunganisha upya kunakataliwa.

Tenganisha vitambulisho na nakala zake. Kufuta profaili kwenye kompyuta mpakato moja hakuzuii nakala nyingine ya ufunguo huo wa kibinafsi kuthibitisha; ufutaji ndio hufanya kila nakala kuwa bure, na ni pale tu ukaguzi wa awali unaposhika. Mpe kifaa mbadala cheti chake mwenyewe ili kimoja kiweze kufutwa bila kugusa kingine.

Kabla ya kukuita kumekamilika: kipengele cha uthibitishaji kimetambuliwa, mtoaji wa orodha analingana na mtoaji wa jani, nambari ya mfululizo iliyofutwa iko kwenye nakala ambayo daemon ilipakia kweli, sera ya orodha zinazokosekana au zilizoisha muda ni ya kukusudia na inafuatiliwa, na kikao kinachotumika kilimalizwa badala ya kusubiriwa. Miundo iliyo nyuma ya haya yote imebainishwa katika RFC 5280.