openssl ca: index.txt માં અમાન્ય સમાપ્તિ તારીખ, અને તેને કેવી રીતે ઠીક કરવી

એક ઇશ્યૂ રન આના પર અટકે છે: entry 22: invalid expiry date, જ્યારે તમારી સામેની વિનંતી સંપૂર્ણ યોગ્ય છે. ફરિયાદ CA ડેટાબેઝના પાર્સર તરફથી આવે છે, CSR તરફથી નહીં અને જે VPN ક્લાયન્ટ અંતે પ્રમાણપત્ર રજૂ કરશે તેની તરફથી પણ નહીં. આ ભેદ પછીનું બધું નક્કી કરે છે: રેકોર્ડ વિકૃત છે, તેથી સુધારો CA ની સ્થિતિમાં છે, વિનંતીમાં કે પીઅર રૂપરેખાંકનમાં નહીં. ક્રમાંકિત એન્ટ્રીને index.txt ની એક લાઇન ગણો, અને સમસ્યા ચકાસી શકાય તેવા જવાબ સાથેના મર્યાદિત ડેટા પ્રશ્નમાં સંકોચાય છે.

ભૂલને ડેટાબેઝની ફરિયાદ તરીકે વાંચો

દરેક openssl ca કૉલ કંઈપણ સહી કરતા પહેલાં તેના ટેક્સ્ટ ડેટાબેઝમાંથી પસાર થાય છે. દરેક લાઇનમાં સ્થિતિ અક્ષર, સમાપ્તિ સમયછાપ, વૈકલ્પિક રદ કરવાનો સમયછાપ, હેક્સમાં ક્રમાંક, ફાઇલનામ અને સબ્જેક્ટ હોય છે. જ્યારે એક ફીલ્ડ પાર્સ થતું નથી, ત્યારે આદેશ લાઇન નંબર જણાવે છે અને બાકીના રેકોર્ડની અટકળ કરવાને બદલે અટકી જાય છે.

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

કંઈપણ સ્પર્શ કરતા પહેલાં CA ની સ્થિતિની નકલ કરો

ફક્ત ડેટાબેઝ ફાઇલ નહીં, આખી CA ડિરેક્ટરીનું સ્નેપશોટ લો. ઇન્ડેક્સ, તેની એટ્રિબ્યુટ ફાઇલ, ક્રમાંક અને CRL નંબરની ફાઇલો, ખાનગી કી અને ઇશ્યૂ કરેલા પ્રમાણપત્રો બધા પછીની કામગીરીમાં ભાગ લે છે, અને એકને પુનઃસ્થાપિત કરીને બાકીના ચૂકી જતો સુધારો બીજી ઘટના ઊભી કરે છે. જ્યાં હોય ત્યાં CA ની પોતાની બેકઅપ પદ્ધતિ વાપરો, અને કામ દરમિયાન નિર્ધારિત ઇશ્યૂ થોભાવો.

નિષ્ફળ ગયેલા આદેશે ખરેખર લોડ કરેલું OpenSSL બિલ્ડ અને રૂપરેખાંકન ફાઇલ નોંધો. ઇન્સ્ટોલેશન ઘણી વાર એક કરતાં વધુ CA ડિરેક્ટરી રાખે છે, અને ભૂલ ફક્ત તે ડેટાબેઝ સામે અર્થપૂર્ણ છે જે પસંદ કરેલું રૂપરેખાંકન નામ આપે છે.

એન્ટ્રી શોધો અને તેનું તારીખ ફીલ્ડ ડિકોડ કરો

જણાવેલ લાઇન નંબર પ્રથમ રેકોર્ડથી ગણાય છે, તેથી sed -n '22p' index.txt તેની ઉપર કોઈ ખાલી કે ટિપ્પણી લાઇન નથી તેની ખાતરી કર્યા પછી જ સમસ્યાવાળી એન્ટ્રી પર આવે છે. એ લાઇન દૃશ્યમાન વિભાજકો સાથે પ્રિન્ટ કરો, કારણ કે ટૅબ અને અંતમાં આવતી જગ્યાઓ સામાન્ય છે અને સામાન્ય એડિટર વિન્ડોમાં અદૃશ્ય રહે છે.

સમાપ્તિ ફીલ્ડ એ સમયછાપ છે જેની પહોળાઈ વર્ષ પર આધાર રાખે છે. 2049 સુધીની કિંમતો UTCTime માં YYMMDDHHMMSSZ સ્વરૂપે લખાય છે, જ્યારે પછીની કિંમતો ચાર-અંકના વર્ષ સાથે GeneralizedTime માં જાય છે. જે રેકોર્ડ બે સ્વરૂપો ભેળવે છે, અથવા જ્યાં પાર્સર હવે ચાર અંક ધારે છે ત્યાં બે-અંકનું વર્ષ ધરાવે છે, તે બરાબર આ જ જગ્યાએ નિષ્ફળ જાય છે. અટકી ગયેલી લખાણ પછી રહી ગયેલું કપાયેલું ફીલ્ડ પણ એવું જ છે.

રેકોર્ડની સરખામણી બીજા CA ની ફાઇલ સાથે નહીં, પણ જે પ્રમાણપત્રનો તે ઉલ્લેખ કરે છે તેની સાથે કરો. સહી કરેલું પ્રમાણપત્ર એ અધિકાર છે કે માન્યતા શું કહેવી જોઈએ, અને તે પહેલેથી પાર્સ કરી શકાય તેવી વસ્તુ તરીકે હાજર છે.

સહી કરેલા પ્રમાણપત્ર સામે રેકોર્ડ સુધારો

ખરી તારીખો આની સાથે વાંચો: openssl x509 -in issued.pem -noout -dates -serial -subject. notAfter ને તમારું બિલ્ડ તે વર્ષ માટે લખતું સમયછાપની પહોળાઈમાં ફેરવો, અને એક પણ અક્ષર બદલતા પહેલાં ખાતરી કરો કે ક્રમાંક તમે સંપાદિત કરવા જઈ રહ્યા છો તે એન્ટ્રી સાથે મળે છે.

ફક્ત તૂટેલું ફીલ્ડ સંપાદિત કરો, સ્થિતિ અક્ષર અને ક્રમાંક રાખો, અને લાઇનનો બાકીનો ભાગ અકબંધ રાખો. જો રેકોર્ડ કોઈપણ સહી કરેલા પ્રમાણપત્ર સાથે મેળવી શકાય નહીં, તો તેને ભટકતી એન્ટ્રી ગણો અને લાઇન જાતે ભૂંસવાને બદલે CA ના પોતાના રદીકરણ માર્ગે તેને નિવૃત્ત કરો.

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

જતા પહેલાં ઇશ્યૂ અને CRL નિર્માણ ચકાસો

સમાન રૂપરેખાંકન સાથે એક ઇશ્યૂ ચલાવો અને ખાતરી કરો કે તે લાઇન નંબરની ફરિયાદ વિના પૂર્ણ થાય છે. પછી openssl ca -gencrl -config openssl.cnf સાથે CRL બનાવો અને તપાસો કે તે પાર્સ થાય છે, કારણ કે બગડેલો રેકોર્ડ ઘણી વાર સહી કરતી વખતે નહીં, પણ બરાબર ત્યાં જ બહાર આવે છે.

નવું પ્રમાણપત્ર આની સાથે તપાસો: openssl x509 -noout -dates -serial અને CA એ હમણાં લખેલી લાઇન સાથે તેની સરખામણી કરો. ખાતરી કરો કે સ્થિતિ અક્ષર અને સમાપ્તિ તારીખ પ્રમાણપત્ર સાથે મળે છે, અને ખાતરી કરો કે openssl verify -CAfile ca.pem issued.pem ભૂલ વિના પાછું આવે છે. પછી નિર્ધારિત ઇશ્યૂ પુનઃસ્થાપિત કરો અને પ્રથમ રન પર નજર રાખો, કારણ કે બીજી વિકૃત લાઇન તરત જ પોતાની જાહેરાત કરશે.