પ્રમાણપત્રો તેમની માન્યતા અવધિમાં હોઈ શકે છે જ્યારે VPN હજી પ્રમાણીકરણ નિષ્ફળતાની જાણ કરે છે, અને કોઈ તારણ કાઢે છે કે પ્રમાણપત્ર રદ થયું છે. આ ત્રણ અલગ તથ્યો છે. રદ કરવાનો ડેટા જે ઉપકરણ માન્યતા આપે છે તેણે પ્રમાણપત્રની અંદર જ નામ આપેલા પ્રકાશન બિંદુ પરથી મેળવવો પડે. જ્યારે તે ઉપકરણ બિંદુ સુધી પહોંચી શકતું નથી, ત્યારે ચકાસણી એવા કારણોસર નિષ્ફળ જાય છે જેનો પ્રમાણપત્રની સ્થિતિ સાથે કોઈ સંબંધ નથી.

ફરી મેળવવાનો માર્ગ માન્યકર્તા પાસે છે

માન્યકર્તાને ઓળખીને શરૂ કરો. જ્યારે લેપટોપ ગેટવેનું પ્રમાણપત્ર ચકાસે છે, ત્યારે ફરી મેળવવાનું કામ લેપટોપ કરે છે; જ્યારે ગેટવે ક્લાયન્ટ પ્રમાણપત્ર ચકાસે છે, ત્યારે તે ગેટવે કરે છે. બેક-એન્ડ પ્રમાણીકરણ સેવા પોતાની નેટવર્ક સ્થિતિ સાથે ત્રીજો માન્યકર્તા ઉમેરી શકે છે. દરેકનો ઇન્ટરનેટ સુધીનો માર્ગ અલગ અને પ્રોક્સી ગોઠવણી અલગ હોય છે. એડમિનિસ્ટ્રેટરના વર્કસ્ટેશન પર એકત્રિત પુરાવા DMZ ની અંદરના સર્વર વિશે કંઈ કહેતા નથી.

કંઈપણ બદલતા પહેલાં પ્રમાણપત્ર, માન્યકર્તા, પ્રયાસનો સમય અને ચોક્કસ સ્થિતિ કોડ લખી લો.

પ્રમાણપત્રમાંથી પ્રકાશન બિંદુ વાંચો

પ્રમાણપત્ર જણાવે છે કે તેની સ્થિતિ ક્યાં રહે છે. CA સરનામું અનુમાન કરવાને બદલે તે ફીલ્ડ વાંચો.

openssl x509 -in gateway.cer -noout -text | grep -A3 "CRL Distribution Points"
openssl x509 -in gateway.cer -noout -text | grep -A2 "Authority Information Access"

પ્રથમ એક્સ્ટેન્શન CRL વિતરણ બિંદુઓની સૂચિ આપે છે, અને બીજું ઓથોરિટી માહિતી ઍક્સેસ પદ્ધતિઓની સૂચિ આપે છે, જે OCSP સ્થિતિ અને ઇશ્યુઅર પ્રમાણપત્ર મેળવવાનું આવરી શકે છે. આ અલગ પદ્ધતિઓ છે, અને OCSP પ્રતિસાદક CRL ફાઇલ નથી. પ્રકાશન હોસ્ટ ઘણી વાર CA મશીન નહીં પરંતુ સામાન્ય વેબ સર્વર હોય છે, કારણ કે ઑફલાઇન ઇશ્યુઅર એવું CRL સહી કરી શકે છે જે બીજું સર્વર વિતરિત કરે. તેથી CA સુધીની ઍક્સેસ તરીકે વર્ણવાયેલ ફાયરવોલ નિયમ અમલમાં મૂકવા કે સમીક્ષા કરવા માટે ખૂબ અસ્પષ્ટ છે.

જે ઉપકરણ માન્યતા આપે છે તેનાથી ફરી મેળવવાનું ચકાસો

ફરી મેળવવાની કસોટી એ જ પર્યાવરણમાં ચલાવો જે ખરેખર માન્યતા આપે છે, મંજૂર પ્રમાણપત્ર સામગ્રી સાથે અને ખાનગી કી વિના.

certutil -urlfetch -verify .\client-test.cer
curl -sS -o /dev/null -w "%{http_code}\n" http://crl.example.com/ca.crl

certutil ચલાવવું સાંકળ ચકાસે છે અને કઈ URL ફરી મેળવવાની ક્રિયાઓ સફળ કે નિષ્ફળ ગઈ તે જણાવે છે, જ્યારે curl કૉલ એ જ હોસ્ટ પરથી એક પ્રકાશન સરનામું ચકાસે છે અને ફક્ત સ્થિતિ કોડ પરત આપે છે. પહોંચી શકાય તેવા સરનામેથી નિષ્ફળ થયેલી પ્રાપ્તિ સામગ્રી કે સહીની સમસ્યા તરફ ઇશારો કરે છે; કનેક્શન ભૂલ રૂટિંગ, DNS કે પ્રોક્સી તરફ ઇશારો કરે છે. બંને પરિણામ રાખો, કારણ કે એક સફળ પ્રાપ્તિ સાબિત કરતી નથી કે આખી સાંકળ વાપરી શકાય તેવી છે. ઉદાહરણનું હોસ્ટ અને પાથ પ્રમાણપત્રમાં મળેલા વિતરણ બિંદુથી બદલો.

ખૂટતા ડેટાને રદ થયેલી સ્થિતિથી અલગ કરો

ચાર પરિણામો બહારથી સરખા દેખાય છે: બિંદુ પહોંચમાં નથી, સૂચિ જૂની છે, સૂચિ પર ખોટા ઇશ્યુઅરની સહી છે, અથવા પ્રમાણપત્ર ખરેખર રદ થયું છે. ફક્ત છેલ્લું જ સ્થિતિનું પરિણામ છે, અને ફક્ત તે જ ઍક્સેસ દૂર કરવાનું વાજબી ઠેરવે છે. કૅશિંગ ચિત્રને વધુ જટિલ બનાવે છે, કારણ કે પહેલાં મેળવેલો ડેટા આગલા રિફ્રેશ સુધી તૂટેલા પ્રકાશન માર્ગને છુપાવી શકે છે. રદ કરવાની ચકાસણી બંધ કરવી, અસંબંધિત પ્રમાણપત્રો કાઢી નાખવા કે ગેટવે ફરી ચાલુ કરવું, બધા નિદાનની જગ્યાએ પ્રવૃત્તિ મૂકે છે.

સુધારા પછી નવું પ્રમાણીકરણ ફરજિયાત કરો અને ખાતરી કરો કે ઇચ્છિત સ્થિતિ પ્રાપ્તિ સફળ છે. જ્યાં નિયંત્રિત પરીક્ષણ ઓળખ હોય ત્યાં ખાતરી કરો કે તે હજી પણ નકારાય છે, કારણ કે ચકાસણી દૂર કરતી ઉપલબ્ધતા સમારકામ નથી.

સંબંધિત લેખો