P12 માંથી ખાનગી કી વિના પ્રમાણપત્રો નિકાસ કરો

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

કન્ટેનર ખાલી કરવાને બદલે વાંચવાથી શરૂ કરો.

PKCS12 ફાઇલ ખરેખર શું રાખે છે

PKCS12 કન્ટેનરમાં એક અથવા વધુ પ્રમાણપત્રો, કદાચ ખાનગી કી, અને સામગ્રી પર message authentication code હોય છે. પ્રમાણપત્રોમાં તમારી ક્લાયન્ટ ઓળખનું લીફ પ્રમાણપત્ર અને તેને CA સાથે જોડતાં મધ્યવર્તી પ્રમાણપત્રો સામેલ હોઈ શકે. કી, જ્યારે હોય, તે જ ફાઇલને દસ્તાવેજને બદલે રહસ્ય બનાવે છે.

આ જ તફાવત -nokeys હોવાનું અને આ જ તે ફ્લેગ હોવાનું કારણ છે જેની આ કામને જરૂર છે.

કી ન લખીને બંડલ વાંચો

તપાસનું સ્વરૂપ રચના અને અલ્ગોરિધમની વિગતો છાપે છે અને કંઈ લખતું નથી: openssl pkcs12 -in client.p12 -info -noout. તે આયાત પાસવર્ડ માગે છે, જે તે મૂલ્ય માટે યોગ્ય જગ્યા છે, અને ફાઇલમાં કી છે કે નહીં તે કહે છે. પાસવર્ડ ટાઇપ ન કરી શકાય ત્યારે -passin env:PKCS12_PASS વાપરો, કારણ કે shell આદેશમાંનો પાસવર્ડ પ્રક્રિયા યાદીમાંનો પાસવર્ડ છે. આ પગલું કંઈ નિકાસ કરતું નથી, અને આ જ આખી વાત છે.

આઉટપુટ ત્રણ વસ્તુઓ માટે વાંચો: કેટલાં પ્રમાણપત્રો, કી છે કે નહીં, અને કયા અલ્ગોરિધમ તેનું રક્ષણ કરે છે.

-nokeys વાપરો અને તેને -nocerts સાથે ન ભેળવો

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

પ્રમાણપત્ર ફાઇલ અને CA ફાઇલ બનાવતું, અને બીજું કંઈ નહીં, બે લીટીનું સ્વરૂપ આ છે:

openssl pkcs12 -in client.p12 -nokeys -clcerts -out client-certificates.pem
openssl pkcs12 -in client.p12 -nokeys -cacerts -out ca-certificates.pem

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

આઉટપુટ તપાસો, નિકાસ કોડ નહીં

શૂન્ય નિકાસ સ્થિતિ કહે છે કે આદેશ ચાલ્યો, એ નહીં કે ફાઇલમાં તમારી અપેક્ષા મુજબ છે. આઉટપુટમાં પ્રમાણપત્રો ગણો અને subject તથા તારીખો વાંચો: openssl x509 -in client-certificates.pem -noout -subject -dates -fingerprint. ફિંગરપ્રિન્ટની સરખામણી સહાય ટીમ જેની અપેક્ષા રાખે છે તેની સાથે કરો, કારણ કે બે ક્લાયન્ટ પ્રમાણપત્રોવાળું બંડલ બે બ્લોકવાળી ફાઇલ બનાવે છે અને મોટાભાગનાં સાધનો ફક્ત પહેલું વાંચે છે. હેતુ, વિશ્વાસ અને કી મેળ ફરી અલગ પરીક્ષણો છે.

જે પ્રમાણપત્ર પાર્સ થઈ શકે તે પ્રમાણપત્ર પાર્સ થઈ શકે. તે એ પ્રમાણપત્ર નથી જે VPN સ્વીકારે છે.

તમને ખરેખર ફાઇલોની જરૂર છે કે નહીં તે નક્કી કરો

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

જાહેર પ્રમાણપત્રોમાં ખાનગી કી હોતી નથી, પણ તેમાં નામ અને સંસ્થાની વિગતો હોય છે. ફાઇલને બદલે ટિકિટે માગેલા ફીલ્ડ શેર કરો, સિવાય કે ફાઇલ જ માગવામાં આવી હોય.