અસમર્થિત પ્રમાણપત્ર હેતુ: મધ્યવર્તી CA કેમ નિષ્ફળ થાય છે

સર્વર પ્રમાણપત્રનો હેતુ યોગ્ય દેખાય છે, કી મેળ ખાય છે, તારીખો ઠીક છે, અને કનેક્શન તેમ છતાં unsupported certificate purpose સાથે નિષ્ફળ જાય છે. આને ઉકેલતી વિગત સામાન્ય રીતે ભૂલની એ જ લાઇનમાં હોય છે: એક ઊંડાઈ મૂલ્ય અને એક subject જે સાંકળમાં ઉપરના પ્રમાણપત્રનું નામ આપે છે. બે અલગ પરીક્ષણો ચાલી રહ્યાં છે, અને તેમાંથી ફક્ત એક જ લીફ વિશે છે. તેમની સરખામણી સમજાવે છે કે સર્વર પ્રમાણપત્ર બદલવાથી કંઈ કેમ બદલાતું નથી.

ચકાસનારે ખરેખર કયું પ્રમાણપત્ર નકાર્યું

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

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

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

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

લીફનો હેતુ અને સાંકળની નીતિ બે પરીક્ષણો છે

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

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

ગેરહાજર EKU એ પ્રતિબંધક EKU નથી

RFC 5280 વિસ્તૃત કી ઉપયોગ એક્સ્ટેન્શનને વૈકલ્પિક બનાવે છે અને, જ્યારે હાજર હોય ત્યારે પ્રતિબંધક. તેથી એક્સ્ટેન્શન વગરનું CA પ્રમાણપત્ર સર્વર પ્રમાણીકરણને 'ના' કહ્યું નથી, જ્યારે ફક્ત અસંબંધિત હેતુની યાદી આપતું પ્રમાણપત્ર કંઈક ખૂબ ચોક્કસ કહ્યું છે. આ બે સ્થિતિઓને સમાન ગણવાથી ખોટું નિદાન અને, તેનાથી ખરાબ, ખોટો ઉપાય મળે છે. આ તફાવત એ પણ સમજાવે છે કે કન્સોલમાં સરખા દેખાતા બે સત્તાધિકારીઓ સાંકળમાં સંપૂર્ણપણે અલગ વર્તન કેમ કરે છે.

લાઇબ્રેરીઓનું વર્તન અહીં પણ એકસમાન નથી. OpenSSL નું ચકાસણી-વિકલ્પો અંગેનું દસ્તાવેજ CA પ્રમાણપત્રો પર હેતુ ચકાસણીઓની પોતાની રીત વર્ણવે છે, અને તે રીત અમલીકરણ નીતિ છે, એવો નિયમ નહીં જે દરેક TLS સ્ટેક એકસરખી રીતે અનુસરે. તમારું ચકાસનારું શું કરે છે તે વર્ણવો, પછી તમે ખરેખર ચલાવો છો તે આવૃત્તિ સામે તેની પુષ્ટિ કરો.

ફરી બહાર પાડતા પહેલાં નિષ્ફળતા ઑફલાઇન પુનઃઉત્પન્ન કરો

ઑફલાઇન ચકાસણી એપ્લિકેશનને સમીકરણમાંથી બહાર કાઢે છે. જો સાંકળ એ જ હેતુ હેઠળ એ જ રીતે નિષ્ફળ જાય, તો સમસ્યા પ્રમાણપત્રમાં જ છે અને કોઈ સર્વર રૂપરેખાંકન તેને છુપાવી શકશે નહીં. જો સાંકળ ઑફલાઇન પાસ થાય અને સેવા હજી ઇનકાર કરે, તો એપ્લિકેશન બીજો હેતુ માંગી રહી છે અથવા તમે ચકાસેલી સાંકળ કરતાં બીજી સાંકળ વાપરી રહી છે.

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

-show_chain મહત્વનું છે કારણ કે તે સાધન બનાવેલો પથ છાપે છે, જે ઘણી વાર તમે આપેલો ફાઇલ ક્રમ હોતો નથી. તે આઉટપુટ એ શોધવાની સૌથી ઝડપી રીત છે કે બીજું મધ્યવર્તી પ્રમાણપત્ર વિશ્વાસ સંગ્રહમાંથી ખેંચાઈ રહ્યું છે, સર્વર તમે ન ઇચ્છેલો ક્રોસ-સાઇન્ડ પ્રકાર મોકલી રહ્યું છે, અથવા ટ્યુટોરિયલમાંથી કૉપિ કરેલો હેતુ ફ્લેગ સેવા પામી રહેલી ભૂમિકા કરતાં બીજી ભૂમિકાનો છે.

ઇશ્યુ નીતિ સુધારો, ચકાસણી કૉલ નહીં

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

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