Cheti cha VPN bado ni halali: sababu tatu, mpangilio mmoja wa ukaguzi

Unafungua mteja, unachagua wasifu ambao umeutumia kwa miezi, na inasimama na "certificate is not yet valid". Hakuna kilichobadilika katika kuingia kwako, na hifadhi ya uaminifu ina uwezekano mkubwa iko sawa: cheti kilichowasilishwa kwenye kupeana mkono kina dirisha la uhalali linaloanza baadaye kuliko wakati unaotumiwa na mkaguzi. Hali tatu tofauti huzalisha ujumbe huo huo, na zinahitaji hatua tofauti. Mpangilio ulio hapa chini unakuambia ni upi ulio nao kabla ya kugusa saa au faili la cheti.

Ni sababu ipi kati ya tatu unayoiona

Sababu ya kwanza ni ya ndani: kifaa kinachofanya ukaguzi kina saa iliyo mapema kuliko tarehe ya kuanza ya cheti. Unakiona kwenye maunzi yenye betri ya CMOS iliyokufa, kwenye mashine pepe zilizorejeshwa kutoka picha ya zamani, kwenye vifaa vilivyokuwa vimezimwa kwa muda wa kutosha kupoteza wakati, na kwenye mitandao ambapo NTP ya kutoka imezuiwa na hakuna aliyegundua. Cheti kinaweza kuwa halali kabisa na bado kishindwe kwa njia hii.

Sababu ya pili ni ya mtoaji, kwa sababu cheti kweli huanza katika siku zijazo: kilitolewa mapema, kilizalishwa kwa muda maalum wa kuanza, au kilisainiwa kama sehemu ya hatua ya uanzishaji ambayo bado haijafanyika. Sababu ya tatu hupoteza muda mwingi zaidi, kwa sababu jani ni la sasa wakati cheti kingine katika mnyororo uliowasilishwa si la sasa, kwa hivyo kosa hutaja nyenzo ambazo hukuwahi kuzisakinisha.

Swali moja linawatenganisha. Je, kushindwa kunafuata kifaa au huduma? Mashine mbili kwenye mtandao mmoja zinazofanya tofauti zinaelekeza kwenye saa. Ikiwa kila mteja anashindwa kwa namna moja, hiyo inaelekeza kwenye dirisha la cheti na mnyororo ulio nyuma yake.

Soma dirisha kutoka kwenye cheti kilichowasilishwa kweli

Usikague faili la PEM lililobaki kutoka usambazaji wa awali; omba huduma mnyororo inaotuma sasa. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts huchapisha kila cheti katika mnyororo. Hifadhi kizuizi unachohitaji na uendeshe openssl x509 -noout -subject -issuer -dates; cha mwisho huchapisha notBefore na notAfter, na ni thamani hizo mbili zinazoamua. Kwenye Windows, mazungumzo ya cheti ya muunganisho na certutil -dump kwenye faili lililosafirishwa huonyesha sehemu hizo hizo.

Soma ncha zote mbili za dirisha, si mwanzo tu. Cheti kinachofunguka baada ya saa mbili na kile kinachofunga baada ya saa mbili hushindwa kwa ujumbe tofauti na huhusisha timu tofauti. Kumbuka ni cheti kipi kosa linataja — jani, cha kati au mzizi — kwa sababu hiyo huamua kama kitu chochote upande wa mteja kinaweza kurekebishwa.

Unaweza pia kujaribu dirisha bila kulingoja. Uthibitishaji hukubali muda maalum: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem hutathmini mnyororo katika muhuri huo wa muda. Iendeshe kwa muda wa sasa ili kuzalisha tena kushindwa, kisha kwa muda wa kuanza wa cheti ili kuthibitisha kwamba mnyororo huo huo hupita dirisha linapofunguka. RFC 5280 hufafanua sehemu ya uhalali na kanuni kwamba cheti hakipaswi kutumika nje yake, na hiyo ndiyo kanuni ambayo mteja wako alitumia hivi punde.

Saa yako, au yao

Linganisha saa ya kifaa na mwanzo wa cheti katika UTC, kutoka chanzo unachoamini. date -u hutoa wakati huo, na timedatectl status kwenye mwenyeji wa systemd pia huripoti kama saa imesawazishwa. Kwenye Windows, w32tm /query /status huonyesha chanzo cha sasa na usawazishaji wa mwisho uliofaulu. Eneo la muda linaloonyeshwa kwenye trei ni chaguo la maonyesho, si saa isiyo sahihi; mkaguzi hulinganisha wakati wa UTC.

Ikiwa saa iko nyuma, sawazisha tena na ujaribu tena kabla ya kubadilisha nyenzo yoyote ya cheti. Kifaa kilicho na makosa ya dakika au saa hukataa kila cheti kilichotolewa hivi karibuni kinachokutana nacho, si huduma moja tu, kwa hivyo maelezo ya huduma moja kwa kawaida ni yale yasiyo sahihi. Ikiwa saa ni sahihi na imesawazishwa, acha kuangalia kifaa: dirisha ni la mtoaji, na hakuna mpangilio wa ndani unaopaswa kubadilishwa ili lipite.

Jedwali hilo ni uamuzi wote. Kusogeza saa hadi kile cheti kinachotarajia si ukarabati, na kuzima ukaguzi wa muda pia si ukarabati, kwa sababu zote mbili huficha hali iliyozalisha kosa.

Kwa nini mnyororo hushindwa wakati jani linaonekana vizuri

Majani yaliyohuishwa na vyeti vya kati vya kubadilisha kwa kawaida husafirishwa pamoja, na huwa havifiki kwa wakati mmoja. Huduma inaweza kutuma jani jipya lililosainiwa na cha kati ambacho dirisha lake mwenyewe huanza baadaye, au kuendelea kutoa cha kati cha zamani chini ya jani jipya. Kwa vyovyote mnyororo hushindwa wakati tarehe za jani lenyewe zinaonekana za kuridhisha.

Ncha za mzigo zilizosawazishwa hubadilisha hii kutoka kuvunjika hadi kutokuwa na uwiano. Ikiwa jaribio jipya linafaulu, au mtandao mmoja unafanya kazi wakati mwingine haufanyi, kumbuka ni rika gani lilijibu na ni mnyororo gani lililotuma kabla ya kubadilisha mipangilio. openssl s_client huchapisha anwani iliyounganishwa, kwa hivyo majaribio machache hufichua kama kila nodi inatoa mnyororo huo huo.

Njia za ukarabati zinazohifadhi uthibitishaji

Tatizo la saa hurekebishwa kwenye kifaa huku uthibitishaji ukiachwa umewashwa. Tatizo la cheti hurekebishwa na mwendeshaji kwa nyenzo zilizotolewa kwa dirisha ambalo tayari linajumuisha sasa. Hakuna mpangilio wa mteja unaofanya cheti ambacho bado si halali kuwa halali; bendera zinazoruka ukaguzi wa muda zipo ili kuthibitisha utambuzi, si kuzisambaza kwenye uzalishaji.

Wakati cheti kimeandaliwa kwa uanzishaji uliopangwa, fuata mpango wa mabadiliko. Kisakinishe dirisha lake linapofunguka, au tumia utaratibu wa kuingiliana ambao mtoa huduma ameandika, badala ya kukisakinisha mapema na kuwafundisha watumiaji kubofya kupitia maonyo. Maonyo ambayo watu hujifunza kupuuza hugharimu zaidi kuliko kuchelewa kidogo.

Mwishowe, jaribu tena jinsi kushindwa kulivyotokea: kikao kipya, mteja yule yule, rasilimali unayohitaji kweli. Maktaba za TLS zinaweza kuhifadhi mnyororo uliothibitishwa kwa maisha yote ya muunganisho, na kikao kilichofufuliwa si lazima kiukague tena, kwa hivyo kikao cha zamani kinaweza kuendelea kushindwa baada ya ukarabati au kuendelea kufanya kazi baada ya kurudi nyuma. Faili linalofunguka kwenye kionyeshi linathibitisha tu kwamba faili linaweza kusomwa; kupeana mkono kumalizika kunathibitisha kwamba mnyororo unathibitishwa.

Kabla ya kufunga tikiti, thibitisha mambo manne: muda wa UTC na hali ya usawazishaji wa kifaa kilichoshindwa, notBefore na notAfter za kila cheti katika mnyororo uliowasilishwa, mnyororo huo huo kutoka kwa mteja wa pili, na jina ambalo kosa hulipa cheti. Ikiwa saa ni sahihi na dirisha halijafunguka, kilichobaki ni kazi ya mwendeshaji, na hatua sahihi kwa upande wako ni kusubiri dirisha badala ya kudhoofisha ukaguzi.