ca md too weak: પ્રમાણપત્ર ફરી ઇશ્યૂ કરવું કે સ્તર નીચે લાવવું?
ભૂલ હવે ક્લાયન્ટ જે સહી-સારાંશ નકારી કાઢે છે તેનું નામ આપે છે, નબળા પાસવર્ડનું નહીં. ચેઇન ફરી ઇશ્યૂ કરવા, ઇશ્યુઅરને પૂછવા કે નીતિ નીચે લાવવા વચ્ચે નિર્ણય કરો.
OpenVPN ક્લાયન્ટ ગયા મહિને કામ કરતો હતો, હવે સ્ટાર્ટઅપ વખતે ca md too weak સાથે નિષ્ફળ જાય છે, જ્યારે ડિસ્ક પરની પ્રોફાઇલ બાઇટ-બાઇટ એ જ છે જે કામ કરતી હતી. સંદેશ પ્રમાણપત્ર ઓથોરિટીના પ્રમાણપત્ર પરની સહી વિશે છે, ડેટા સાઇફર, auth સારાંશ કે ખાતાના પાસવર્ડ વિશે નહીં. ત્રણ શરતો નક્કી કરે છે કે ઉકેલ નવી ઓળખ સામગ્રી, નવી ચેઇન કે જાણી જોઈને કરેલો નીતિ પરિવર્તન છે. તેમને ક્રમમાં કરો, અને હોસ્ટ પરની દરેક TLS કનેક્શન નબળી પાડીને ટનલ પાછી આવવાના સામાન્ય પરિણામ ટાળશો.
ભૂલ ખરેખર શું નામ આપે છે
OpenSSL આ ચકાસણી ભૂલ ત્યારે ઉઠાવે છે જ્યારે તે ચેઇન બનાવે છે, જો CA તરીકે કામ કરતું પ્રમાણપત્ર એવો સહી-સારાંશ ધરાવે જે લાઇબ્રેરીનું સુરક્ષા સ્તર હવે સ્વીકારતું નથી. MD5 ડિફોલ્ટ સ્તરે નકારાય છે, અને સ્તર વધારતાં SHA-1 નકારાય છે. અહીં લીફ પ્રમાણપત્રનો સારાંશ તેને સહી કરતા ઇશ્યુઅરના સારાંશ કરતાં ઓછો મહત્ત્વનો છે. એ જ નીતિ એવા રૂટને પણ નકારી શકે જે તેના ઇશ્યૂના દિવસે સાવ સામાન્ય હતો.
તેથી auth કે data-ciphers સંપાદિત કરવાથી આ નિષ્ફળતા માટે કંઈ થતું નથી. તે સેટિંગ્સ હેન્ડશેક પછી પેકેટ કેવી રીતે સુરક્ષિત થાય તે નિયંત્રિત કરે છે, જ્યારે નકારાયેલ વસ્તુ એ ઓળખપત્ર છે જે ટનલ અસ્તિત્વમાં આવે તે પહેલાં તપાસાય છે. પ્રમાણપત્ર તેની માન્યતા વિન્ડોમાં આરામથી બેસી શકે અને તેમ છતાં એવી સહી ધરાવે જે લાઇબ્રેરી સ્વીકારશે નહીં.
ચકાસણીઓ મનમાં અલગ રાખો અને ભૂલ રહસ્યમય લાગવાનું બંધ કરે છે. માન્યતા તારીખો, કીનો ઉપયોગ અને સહી-સારાંશ સ્વતંત્ર પરીક્ષણો છે, અને તેમાંથી બરાબર એક હમણાં નિષ્ફળ ગયું છે.
પ્રથમ શરત: નકારાયેલ વસ્તુ રૂટ છે?
પ્રોફાઇલમાંનું દરેક પ્રમાણપત્ર છાપો અને subject તથા issuer ક્ષેત્રો વાંચો. સ્વ-સહી કરેલ રૂટ બંનેમાં એ જ મૂલ્ય દર્શાવે છે, અને તેનું સહી અલ્ગોરિધમ એ છે જેના પર આખી ચેઇન ઊભી છે. જો નબળો સારાંશ ત્યાં હોય, તો તેની નીચેનું દરેક લીફ સમસ્યા વારસામાં લે છે. અલ્ગોરિધમને subjectની બાજુમાં લખો જેથી પછીની તુલના યાદશક્તિને બદલે યાંત્રિક થાય.
એકત્રિત CA ફાઇલોમાં ઘણી વાર અનેક બ્લોક હોય છે, તેથી પહેલું જ દોષિત છે એમ માનવાને બદલે ખરેખર લોડ થતો બ્લોક ઓળખો. આદેશ openssl x509 -in ca.pem -noout -subject -issuer -text એક વખતે એક પ્રમાણપત્રનું વર્ણન કરે છે, એટલે બંડલમાં વધુ હોય તો પહેલાં તેને વિભાજિત કરવું પડે. છપાયેલા સહી અલ્ગોરિધમની તુલના રૂટ બન્યાના યુગથી અપેક્ષિત સારાંશ સાથે કરો.
નબળા રૂટ હેઠળ SHA-256 થી સહી કરેલ લીફ પણ નિષ્ફળ જાય છે, કારણ કે ચેઇન ચકાસણી ઉપર સુધી જાય છે. એ જ ક્રમ આગલી શરતને મહત્ત્વની બનાવે છે.
બીજી શરત: ઇશ્યુઅર તમારા નિયંત્રણમાં છે?
જો રૂટ તમારી સંસ્થાનો હોય, તો ટકાઉ ઉકેલ આધુનિક સારાંશ સાથેનો નવો રૂટ અને ફરી ઇશ્યૂ કરેલા લીફ છે, જે એક જ પ્રોફાઇલ અપડેટ તરીકે આપવામાં આવે. તેમાં જાળવણી વિન્ડો અને એવા ઉપકરણો માટે યોજના જોઈએ જે તે જ દિવસે અપડેટ લઈ શકતા નથી.
જો ચેઇન ત્રીજા પક્ષે ઇશ્યૂ કરી હોય, તો ઉકેલ એ ઓપરેટરને વિનંતી છે, અને એકમાત્ર ઉપયોગી સ્થાનિક પગલું જૂની સામગ્રી પર આધાર છોડી દેવો છે. PEM ટેક્સ્ટ સંપાદિત કરવાથી કે ફાઇલ ફરી સાચવવાથી સહી જે ઢાંકે છે તેમાં કંઈ બદલાતું નથી.
એક મધ્યવર્તી કિસ્સો નામને લાયક છે: આંતરિક રૂટ જે હાલના ડિફોલ્ટ કરતાં જૂનો છે પણ હજી એવી સામગ્રીને સહી કરે છે જેના પર બીજી સિસ્ટમો ભરોસો કરે છે. તેને બદલવાનો અર્થ દરેક વપરાશકર્તાનું ઓડિટ છે, જેમાં એવા ઉપકરણોનો સમાવેશ થાય જે જૂના પ્રમાણપત્રને ફિંગરપ્રિન્ટથી પિન કરે છે. ફેરફાર નક્કી કરતાં પહેલાં તે વપરાશકર્તાઓની ગણતરી કરો, કારણ કે એક પણ ચૂકી જતો રૂટ બદલો સ્ટાર્ટઅપ ભૂલને વિક્ષેપ સાથે બદલી નાખે છે.
ત્રીજી શરત: સ્તર નીચે લાવવાથી બીજું શું સ્વીકારાય છે
સુરક્ષા સ્તર નીચે લાવવું, કે OpenVPNની જૂની પ્રમાણપત્ર પ્રોફાઇલ પસંદ કરવી, ક્લાયન્ટને ફરી જૂનો સારાંશ સ્વીકારવા દે છે. તે એ જ લાઇબ્રેરીની બીજી ચકાસણીઓ પણ ઢીલી કરે છે, તે પ્રક્રિયા કરતી દરેક કનેક્શન માટે.
પ્રયોગશાળામાં કે બદલીની સામગ્રી તૈયાર થાય ત્યાં સુધી ટૂંકા સેતુ તરીકે તે વાજબી હોઈ શકે, જો અપવાદ એક જ પ્રોફાઇલ સુધી મર્યાદિત હોય અને અંતિમ તારીખ ધરાવે. વહેંચાયેલા હોસ્ટ પર કાયમી સેટિંગ તરીકે તે શાંતિથી વિસ્તારે છે કે ત્યાંનો દરેક TLS ક્લાયન્ટ શું ભરોસે કરશે.
અપવાદને માલિક અને દૂર કરવાના પગલા સાથે લખો. દસ્તાવેજ ન કરેલો સ્તર ફેરફાર છ મહિના પછી ભૂલથી અલગ પડતો નથી, અને આગલા ઇજનેરને ખબર નહીં હોય કે તે ક્યારેય નિર્ણય હતો.
નિર્ણય, નિયમ તરીકે લખાયેલો
જ્યારે ઇશ્યુઅર તમારા નિયંત્રણમાં હોય અને તેના વપરાશકર્તાઓની યાદી બનાવી શકો ત્યારે ચેઇન બદલો. ન થાય તો ઇશ્યુઅર સુધી એસ્કેલેટ કરો. સ્તર ફક્ત તારીખવાળા, મર્યાદિત અપવાદ તરીકે જ નીચે લાવો, બદલી પહેલેથી નિર્ધારિત હોય. બીજું કંઈ પણ એ જ પ્રમાણપત્ર જગ્યાએ રાખે છે અને જોખમને ઓછું દેખાતી જગ્યાએ ખસેડે છે.
પછી સ્વચ્છ ક્લાયન્ટથી પ્રોફાઇલ ફરી ચકાસો, હેન્ડશેક પૂર્ણ થાય તેની ખાતરી કરો, અને હજી નિષ્ફળ જાય તો નકારનો ચોક્કસ ટેક્સ્ટ રાખો. ચોક્કસ ભૂલ સંદેશ એ આગલા સ્તરનો માલિક છે તેને આપી શકાય તેવી સૌથી સસ્તી વસ્તુ છે.