એકલું CSR નોંધણી નથી: VPN CA એ શું ચકાસવું જોઈએ

પ્રમાણપત્ર સહી કરવાની વિનંતીમાં જાહેર કી અને માંગેલો વિષય હોય છે, જે મેળ ખાતી ખાનગી કી સાથે સહી કરેલો હોય છે. તે સહી સાબિત કરે છે કે વિનંતીકર્તા પાસે કી છે. તે સાબિત કરતી નથી કે વિનંતીકર્તાને માંગેલા નામ, ઉપકરણ કે VPN ભૂમિકા પર હક છે, અને તેમ કરે છે એમ ગણીને વર્તવું એ જ રીતે હેલ્પ-ડેસ્કની ટિકિટ ઍક્સેસ આપવામાં ફેરવાય છે.

બે નોંધણી મોડેલોને તેઓ શું બાંધે છે તેના આધારે સરખાવવા યોગ્ય છે, તેઓ કયો પ્રોટોકોલ બોલે છે તેના આધારે નહીં.

વિનંતી નામનો દાવો કરે છે, તેને સાબિત કરતી નથી

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

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

મોડેલોને તેઓ શું બાંધે છે તેના આધારે સરખાવો

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

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

તમે અપેક્ષા રાખો છો તે નોંધણીઓની સંખ્યા અને ઉપકરણોના ફેરફાર પ્રમાણે મોડેલ પસંદ કરો. વર્ષે થોડા સર્વર લેખિત ચેકલિસ્ટ સાથે જાતે સમીક્ષા ટકી શકે છે. લેપટોપનો કાફલો ટકી શકતો નથી.

પ્રથમ જારીકરણથી જીવનચક્ર નોંધો

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

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

જારી કરેલું પ્રમાણપત્ર ચકાસો, પછી ઍક્સેસ

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

openssl req -in client.csr -noout -verify -subject
openssl x509 -in client.crt -noout -subject -issuer -dates -ext extendedKeyUsage
openssl verify -CAfile ca.crt client.crt

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

ખોટા કારણથી કામ કરતી પ્રોફાઇલ, જેમ કે મેળ ખાતું સામાન્ય નામ અને કોઈ ઓળખ ચકાસણી નહીં, તમે ધાર્યું હતું તે નિયંત્રણ દૂર થયા પછી પણ કામ કરતી રહેશે.