દરેક VPN ક્લાયન્ટ પર ca.key કૉપી કરવાથી CA કેમ તૂટે છે
ક્લાયન્ટ CAનું જાહેર પ્રમાણપત્ર ચકાસે છે; તેને સહી કરતી કીની ક્યારેય જરૂર પડતી નથી. ca.key દરેક ઉપકરણ પર કૉપી કરવાથી એક પણ નકલ લેનારને જારી કરવાનો અધિકાર મળી જાય છે.
સેટઅપની સૂચનાઓમાં ક્યાંક, એક ડિરેક્ટરી દરેક લેપટોપ પર આખી કૉપી કરવામાં આવે છે, કારણ કે કઈ ફાઇલો ત્યાં હોવી જોઈએ તે નક્કી કરવા કરતાં એ સરળ હતું. તે ડિરેક્ટરીમાં ca.key છે, અને તે બીજા ઉપકરણ પર પહોંચે તે ક્ષણે પ્રમાણપત્ર સત્તાધિકારી સત્તાધિકારી રહેતી નથી. હવે દરેક ધારક એવી ઓળખ જારી કરી શકે છે જેના પર બાકીનું નેટવર્ક ભરોસો કરશે.
આ ગૂંચવણ એક વાર ઉકેલવા જેવી છે, કારણ કે બંને ફાઇલો એકસરખી દેખાય છે અને વિરોધી કામ કરે છે.
ચકાસણીની સામગ્રી અને સહી કરવાની સામગ્રી
ક્લાયન્ટને CAનું જાહેર પ્રમાણપત્ર જરૂરી છે જેથી ચકાસી શકે કે સામેનો પક્ષ જે પ્રમાણપત્ર રજૂ કરે છે તે તે સત્તાધિકારીએ સહી કરેલું છે. આ ચકાસણીનું કામ છે અને તેને કોઈ રહસ્યની જરૂર જ નથી. સામેના પક્ષના પ્રમાણપત્ર પર સહી કરવી એ બીજું કામ છે, જે CA ચલાવનાર એક વાર કરે છે, તે ખાનગી કી સાથે જે ક્યારેય તેના સુરક્ષિત ભંડારમાંથી બહાર નીકળતી નથી. આ બે કામ અલગ રાખવા એ જ બે ફાઇલો મોકલવાનો આખો હેતુ છે.
તેથી ca.crt પ્રોફાઇલમાં આવે છે અને ca.key તેની નજીક ક્યાંય આવતું નથી. ફાઇલના નામ એક પરંપરા છે, બાંયધરી નહીં, તેથી પ્રકાર નામ પરથી અનુમાન કરવાને બદલે તપાસવો પડે.
મધ્યવર્તી CA અથવા ઓનલાઇન જારી સેવા ધરાવતી રચના આનો અપવાદ નથી. મોટા પાયે ઉપકરણ પ્રમાણપત્રો જારી કરતી વખતે સહી કરવાની ક્ષમતા અંતિમ બિંદુઓથી દૂર રાખવાની આ પ્રમાણભૂત રીત છે.
ક્લાયન્ટે પોતાની કી સાથે શું સાબિત કરવું જોઈએ
દરેક ઉપકરણને પોતાની કી જોડી અને પોતાનું પ્રમાણપત્ર મળે છે, જે CA એક વાર સહી કરે છે. ક્લાયન્ટ તે પ્રમાણપત્ર રજૂ કરે છે અને અનુરૂપ ખાનગી કી તેની પાસે હોવાનું સાબિત કરે છે, અને સર્વર તેને સ્વીકારવું કે નહીં તે નક્કી કરે છે. લેપટોપ ખોવાય ત્યારે જે ઓળખ રદ થાય છે તે આ જ છે.
ચોરી પછી આ તફાવત સૌથી વધુ મહત્ત્વનો છે. દરેક ઉપકરણ માટે અલગ ઓળખ હોય ત્યારે એક ખુલ્લો ક્લાયન્ટ રદ કરીને અથવા સામેનો પક્ષ દૂર કરીને હટાવી શકાય છે, અને બાકીનો કાફલો કામ કરતો રહે છે.
લીક થયેલી સત્તાધિકારીની કી સાથે આમ કરી શકાતું નથી. તેણે આજ સુધી સહી કરેલું અથવા કરી શકે તેવું દરેક પ્રમાણપત્ર શંકાસ્પદ બને છે, તેથી પ્રતિભાવ એક નિરસન નહીં પણ ભરોસાની બદલી છે. આ એક પ્રોજેક્ટ છે, ટિકિટ નહીં.
| File | Role | Belongs on |
|---|---|---|
ca.crt | Public certificate used to verify signatures | Every client profile |
ca.key | Private key that issues certificates | Protected CA storage only |
| client key pair | Proves one device's identity | That device alone |
ફાઇલને ક્યાંય પણ કૉપી કરતા પહેલાં વાંચો
બે આદેશો કોઈ રહસ્ય છાપ્યા વિના તમને કહે છે કે તમારા હાથમાં કયા પ્રકારની વસ્તુ છે. પહેલો પ્રમાણપત્ર પરનો વિષય અને CA ધ્વજ જણાવે છે; બીજો કીની માન્યતા ચકાસે છે અને તેનો પ્રકાર જણાવે છે. તમે વિતરણ કરવા જઈ રહ્યા છો તે બંડલની ફાઇલો પર બંને ચલાવો. ખાનગી કી તરીકે માન્ય ઠરતું કંઈ પણ ક્લાયન્ટ ડિરેક્ટરીમાં ન હોવું જોઈએ.
openssl x509 -in ca.crt -noout -subject -ext basicConstraints openssl pkey -in ca.key -noout -check
જો ક્લાયન્ટ બંડલમાં પડેલી ફાઇલ પર બીજો આદેશ સફળ થાય, તો થોભો અને બંડલને ચેડાં થયેલું માનો. જે આઉટપુટ કહે છે કે કી માન્ય છે તે એ પણ કહે છે કે તે હાજર છે, અને હાજરી એ જ આખી સમસ્યા છે.
બીજી દિશા પણ ધ્યાનમાં લો: ક્લાયન્ટ પ્રોફાઇલમાં તે ક્લાયન્ટની પોતાની ખાનગી કી કાયદેસર રીતે હોય છે. જે પણ કી મળે તે બધી ભૂંસી નાખવાથી કંઈ સુધર્યા વિના જોડાણ તૂટે છે, તેથી દૂર કરતા પહેલાં વસ્તુની ઓળખ કરવી પડે.
તમે પહેલેથી વિતરિત કરેલી કીને કાબૂમાં રાખવી
એમ ન માનો કે સ્થાનિક નકલ ભૂંસી નાખવાથી જાહેર થવું ઉલટાવી જાય છે. જેની પાસે ફાઇલ હતી તે કોઈ પણ તેની નકલ કરી શકે, અને સુરક્ષિત ધારણા એ છે કે તેણે કરી. ઓપરેટરની ઘટના પ્રક્રિયા અનુસરો અને ભરોસાના લંગરને બદલો, નવી CA હેઠળ ઉપકરણ પ્રમાણપત્રો ફરી જારી કરીને.
પછી જે પેકેજિંગે સમસ્યા ઊભી કરી તે બદલો. ફાઇલોની સ્પષ્ટ પરવાનગી યાદી સાથે ડિરેક્ટરી સૂચિ મોકલો, CAની કી એવી મશીન પર રાખો જે ક્યારેય ક્લાયન્ટ કાફલામાં જોડાતી નથી, અને કઈ સિસ્ટમ તેને રાખે છે તે નોંધો.
જો સત્તાધિકારીએ વારંવાર જારી કરવું પડે, તો સહી કરવાનું કામ સાંકડી ક્ષેત્ર અને ટૂંકી માન્યતા ધરાવતી સેવા કે મધ્યવર્તી સત્તાધિકારી પાછળ ખસેડો. એમ ભવિષ્યની ભૂલ આખા તૈનાતીના ભરોસાના મૂળને બદલે જારીના એક ભાગને જ જાહેર કરે છે.