લીફ સર્ટિફિકેટ માન્ય, ચેઇન સમાપ્ત: ઊંડાણ વાંચો

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

ઊંડાણ નિષ્ફળ ગયેલા સર્ટિફિકેટનું નામ આપે છે

OpenSSL નિદાનમાં ઊંડાણ 0 એ લક્ષ્ય સર્ટિફિકેટ છે અને ઊંડાણ 1 એ તેને સહી કરનાર ઇશ્યુઅર છે, જ્યારે મોટા આંકડા ટ્રસ્ટ એન્કર તરફ ચાલુ રહે છે. ઊંડાણ 1 પર નોંધાયેલી સમાપ્તિ લીફ પરના વર્તમાન notAfter દ્વારા ખંડિત થતી નથી, તેથી દૃશ્ય સર્ટિફિકેટ ફરી તપાસવાથી ભૂલ કદી સમજાશે નહીં.

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

એક કરતાં વધુ સર્ટિફિકેટ ભૂમિકા ધરાવતા ઉત્પાદનો પર પણ ધ્યાન આપો. OpenVPN Access Server પર, વેબ ઇન્ટરફેસનું રક્ષણ કરતા સર્ટિફિકેટ VPN કનેક્શન માટે વપરાતા સર્ટિફિકેટથી અલગ છે, તેથી એડમિન પૃષ્ઠ ખોલતું બ્રાઉઝર ટનલના પાથ વિશે કંઈ સાબિત કરતું નથી.

ટ્રસ્ટ ઇનપુટ અને ચેઇન ઉમેદવારો એક નથી

ચકાસનારને બંને ઇનપુટ અલગ અને સ્પષ્ટ રીતે આપો. ટ્રસ્ટ ફાઇલ તમે સ્વીકારેલા એન્કર રાખે છે; અવિશ્વસનીય બંડલ પાથ બનાવવા માટે ઓફર કરાયેલા મધ્યવર્તી સર્ટિફિકેટ રાખે છે. તેમને ભેળવવાથી લોકો ભૂલથી મધ્યવર્તી સર્ટિફિકેટને રૂટમાં બઢતી આપે છે અને પછી આશ્ચર્ય પામે છે કે એ જ ભૂલ મશીનો વચ્ચે તેમની પાછળ કેમ ચાલે છે.

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

ડિફોલ્ટ પાથ અને સ્ટોરને -no-CApath -no-CAstore સાથે નિષ્ક્રિય કરવાથી પરીક્ષણ પ્રામાણિક રહે છે: પરિણામ પછી તમે નામ આપેલી ફાઇલો પર આધાર રાખે છે, વર્કસ્ટેશન આકસ્મિક રીતે જેના પર ભરોસો કરે તેના પર નહીં. OpenSSL ચકાસણી સંદર્ભ આ વિકલ્પો અને તેઓ જે નિદાન ઉત્પન્ન કરે છે તેનું દસ્તાવેજીકરણ કરે છે.

ચકાસણી સફળ થાય ત્યારે -show_chain બનેલી ચેઇન છાપે છે, જે પાથ તમે ઇચ્છ્યો હતો તે જ છે તેની પુષ્ટિ કરવા ઉપયોગી છે. જ્યારે નિષ્ફળ જાય, ત્યારે નોંધાયેલું ઊંડાણ અને સબ્જેક્ટ રાખો; એ બે ક્ષેત્રો આગલા વાચકને કહે છે કે કયું સર્ટિફિકેટ તપાસવું.

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

ચકાસણી શું સાબિત કરે છે અને શું છોડી દે છે

આ તમે આપેલી ટ્રસ્ટ ફાઇલ સામે પાથ અને હેતુની ચકાસણી છે. HTTPS નામ-ચકાસણી માટે યોગ્ય વિકલ્પ દ્વારા અપેક્ષિત હોસ્ટનામ ઉમેરો; VPN કનેક્શન માટે ક્લાયન્ટના ગોઠવેલા ઓળખ ચકાસણી રાખો અને તે ક્લાયન્ટ ખરેખર જે ટ્રસ્ટ સામગ્રી વાંચે છે તે વાપરો.

સર્વર જે મોકલે છે તે ઉમેદવારોનો સમૂહ છે, તમારો ક્લાયન્ટ અંતે જે પાથ બનાવશે તે નહીં. સ્થાનિક ટ્રસ્ટ અને લાઇબ્રેરીના બાંધકામ નિયમો બંને પરિણામ ઘડે છે, તેથી એ જ જવાબ એક મશીન પર ચકાસાય અને બીજા પર નિષ્ફળ જાય. સમાન મૂલ્યાંકન ધારવા પહેલાં નિષ્ફળ ક્લાયન્ટના જાળવાયેલા ટ્રસ્ટ સ્ટોર અને TLS અમલીકરણની સરખામણી કાર્યકારી ક્લાયન્ટ સાથે કરો. ત્યાંનો તફાવત „ફક્ત આ લેપટોપ નિષ્ફળ જાય છે“ જેવા ઘણા અહેવાલો સમજાવે છે.

દરેક સર્ટિફિકેટની વિંડો એક-એક કરતાં સમૂહ તરીકે જોવા માટે તેમને આ રીતે છાપો:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

બીજો આદેશ દરેક ફાઇલને હાથથી ડીકોડ કર્યા વિના સબ્જેક્ટ અને ઇશ્યુઅરની યાદી આપે છે, એ રીતે તમને એ મધ્યવર્તી સર્ટિફિકેટ દેખાય છે જેની તારીખ વીતી ગઈ છે જ્યારે લીફ હજુ ઠીક દેખાય છે.

ચકાસણી નબળી કર્યા વિના પાથ સુધારો

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

રૂટ હેન્ડલિંગ નોંધને લાયક છે, કારણ કે સારાંશ ઘણી વાર તેને વધારે ચઢાવે છે. RFC 5280 એન્કરને ભાવિ પાથની બહાર રહેલા ઇનપુટ તરીકે ગણે છે, જ્યારે OpenSSL તેના રૂટ CA સર્ટિફિકેટને સમાવતી માન્યતા ચકાસણીઓનું દસ્તાવેજીકરણ કરે છે. બંને વિધાન તેમની પોતાની સિસ્ટમો માટે સાચાં છે; એક લાઇબ્રેરીના રૂટ-સમાપ્તિ વર્તનને દરેક ક્લાયન્ટ પર સામાન્યીકરણ કરવાથી આત્મવિશ્વાસપૂર્ણ ખોટા જવાબો મળે છે.

ફેરફાર પછી, અસરગ્રસ્ત ક્લાયન્ટ પર નવી પ્રમાણીકરણ ફરજિયાત કરો અને ખાતરી કરો કે ચોક્કસ સમાપ્તિ સંદેશ ગયો છે. લીફ જાતે અયોગ્ય હોય તો જ લીફ નવીકરણ કરો. સમય ચકાસણી નિષ્ક્રિય કરવી અથવા ઐતિહાસિક ક્રોસ-સર્ટિફિકેટ પુનઃસ્થાપિત કરવું માન્ય વર્તમાન પાથ બનાવતું નથી; તે ફક્ત આગલી નિષ્ફળતા મુલતવી રાખે છે.