VPN கிளையன்ட் விசையை உருவாக்கி கையொப்பத்திற்கு CSR சமர்ப்பிப்பது எப்படி

விரைவில் அல்லது பிறகு, ஒரு VPN பயனர் தனிப்பட்ட விசையை மின்னஞ்சலில் அனுப்ப முன்வருகிறார், அதனால் நிர்வாகி ஒரு சான்றிதழை உருவாக்க முடியும், மற்றும் நிராகரிக்க வேண்டியது அதே சலுகைதான். வேலை செய்யும் ஓட்டம் முதல் கட்டளையிலிருந்தே விசையை கிளையன்ட்டிடம் வைத்திருக்கிறது: கிளையன்ட் அதை உருவாக்குகிறது, சான்றிதழ் கையொப்பக் கோரிக்கையை அனுப்புகிறது, வழங்குபவர் அதை சரிபார்த்து அனுமதிக்கிறார், கையொப்பமிடப்பட்ட சான்றிதழ் திரும்பி வந்து அதை உருவாக்கிய விசையின் அருகில் அமர்ந்திருக்கிறது. கீழே உள்ள சரிபார்ப்புப் பட்டியல் ஒவ்வொரு படியிலும் மூடிய வகையில் தோல்வியடைகிறது, அதுதான் முக்கிய அம்சம், ஏனெனில் ஐந்து படிகளில் இரண்டு மக்கள் அவசரப்படும்போது தவிர்க்கும் படிகளாகும்.

படி 1: விசை வாழப்போகும் இடத்திலேயே அதை உருவாக்குங்கள்

விசையை வைத்திருக்கும் இயந்திரத்திலேயே உருவாக்கி அங்கேயே விடுங்கள். மென்பொருள் விசை கடுமையான அனுமதிகளுடன் கூடிய கோப்புக்குச் செல்கிறது; வன்பொருள் ஆதரவு அல்லது நிர்வகிக்கப்பட்ட சேமிப்பகத்தில் உள்ள விசை ஒருபோதும் கோப்பாக மாறாது, அதன் பதிவுப் பாதை பொதுவாக OpenSSL கட்டளை அல்ல, தனி கருவியாகும். எப்படியிருந்தாலும், தனிப்பட்ட பாதியை யாரும் பார்க்க வேண்டியதில்லை.

மென்பொருள் ஓட்டம் இப்படி இருக்கும், விசையும் கோரிக்கையும் ஒரே அமர்வில் உருவாக்கப்படுகின்றன:

umask 077
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out client.key
openssl req -new -key client.key -out client.csr -subj "/CN=alice-vpn/O=Example"

umask வரி தோற்றத்தை விட முக்கியமானது. அது இல்லாமல் இயல்பாக அனுமதிக்கும் அமைப்பில் விசை அனைவரும் படிக்கக்கூடியதாக எழுதப்படுகிறது, பின்னர் கோப்பை நகலெடுப்பது அதைப் பரப்புகிறது. ஏற்கனவே உள்ள விசையை மீண்டும் பயன்படுத்துவது அது ஏற்கனவே பாதுகாக்கப்பட்டு உங்கள் கொள்கையுடன் பொருந்தினால் செல்லுபடியாகும்; ஒவ்வொரு சாதனத்திற்கும் புதியதை உருவாக்குவது விளக்க எளிதானது.

படி 2: அடையாளத்தை கோரிக்கையில் வையுங்கள், மின்னஞ்சலில் அல்ல

கோரிக்கை உருவாகும் முன் VPN உண்மையில் எதை அங்கீகரிக்கிறது என்பதை முடிவு செய்யுங்கள், ஏனெனில் அந்தப் பதில் CSR-க்குள் சேரும். OpenVPN பாரம்பரியமாக கிளையன்ட் அடையாளத்தை சான்றிதழின் பொதுப் பெயருடன் இணைக்கிறது, strongSwan போன்ற கருவிகள் அடையாளச் சரத்தை பொருள் அல்லது பொருளின் மாற்றுப் பெயருடன் பொருத்துகின்றன. என் பெயர் alice என்று சொல்லும் மின்னஞ்சல் சான்று அல்ல, மேலும் பொருள் அதையே சொல்லும் கோரிக்கை சற்று மட்டுமே சிறந்தது.

உங்கள் சரிபார்ப்பான் ஒன்றைச் சரிபார்க்கும்போது பொருளின் மாற்றுப் பெயரைச் சேர்க்கவும், ஏனெனில் நவீன பொருத்தம் பழைய CN-ஐ அடிக்கடி புறக்கணிக்கிறது:

openssl req -new -key client.key -out client.csr \
  -subj "/CN=alice-vpn/O=Example" \
  -addext "subjectAltName=DNS:alice-vpn"

CN-ஐ குறுகியதாக, நிலையாக வைத்து, மடிக்கணினி மாதிரிக்குப் பதிலாக கணக்குடன் இணைக்கவும். பயனரின் சாதனத்தின் வரிசை எண்ணைக் கொண்ட பெயர் முதல் வன்பொருள் மாற்றத்திற்காகக் காத்திருக்கும் ஆதரவுச் சிக்கல்.

படி 3: கையொப்பமிடும் முன் கோரிக்கையைச் சரிபார்க்கவும்

வழங்குபவர் இரண்டு வெவ்வேறு விஷயங்களைச் சரிபார்க்கிறார், அவற்றைக் கலப்பதே உன்னதத் தவறு. முதலில், கோரிக்கை உள்நிலையில் ஒத்திசைவாக உள்ளது: கையொப்பம் அது சுமக்கும் பொது விசைக்கு எதிராகச் சரிபார்க்கப்படுகிறது. இரண்டாவது, கோரிக்கையாளர் கோரிக்கை கேட்பதற்கு உரிமை உடையவர், அதற்கு எந்த குறியாக்கச் சரிபார்ப்பும் பதிலளிக்க முடியாது.

இயந்திரப் பகுதி ஒரு கட்டளை, அது பொருளுடன் சரிபார்ப்பு முடிவை அச்சிட வேண்டும்:

openssl req -in client.csr -noout -verify -subject
openssl req -in client.csr -noout -pubkey | openssl pkey -pubin -noout -text

இது என்ன நிரூபிக்கிறது என்பதைக் கவனியுங்கள். சரிபார்ப்பைக் கடக்கும் கோரிக்கை, சமர்ப்பிக்கும் நேரத்தில் அனுப்பியவரிடம் பொருந்தும் தனிப்பட்ட விசை இருந்தது என்பதை மட்டுமே காட்டுகிறது; அனுப்பியவர் பொருளில் பெயரிடப்பட்ட நபர் என்பதை நிரூபிக்கவில்லை, கோரப்பட்ட குழு அல்லது பாதை அணுகலை அனுமதிக்கவும் இல்லை. பதிவு மறுஆய்வு தனி வாயில், யாரும் அங்கீகரிக்காத குழுவைக் கேட்கும் கோரிக்கை அமைதியாகத் திருத்தப்படுவதற்குப் பதிலாக நிராகரிக்கப்பட வேண்டும்.

படி 4: அனுமதியளித்து, பின்னர் வெளிப்படையான நீட்டிப்புகளுடன் கையொப்பமிடுங்கள்

கோரிக்கையை அச்சொட்டாக ஏற்றுக்கொள்வதற்குப் பதிலாக CA கொள்கையைத் தீர்மானிக்கும் இடம் கையொப்பம். செல்லுபடி காலம், விசை பயன்பாடு மற்றும் பங்கு நீட்டிப்பு ஒரு நீட்டிப்புக் கோப்பில் இருக்க வேண்டும், ஆறு மாதங்களுக்குப் பின் நினைவில் இருக்காத இயல்புநிலைகளில் அல்ல. VPN அங்கீகாரத்திற்கான கிளையன்ட் சான்றிதழுக்கு அதன் நோக்கமாக கிளையன்ட் அங்கீகாரம் தேவை.

cat > client.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = digitalSignature
extendedKeyUsage = clientAuth
EOF
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -days 365 -extfile client.ext -out client.crt

ஏற்கனவே ஒன்று பயன்பாட்டில் இருந்தால் இருக்கும் வரிசைக் கோப்புடன் -CAserial பயன்படுத்தி, CA விசையை இணையமற்ற நிலையில் அல்லது உங்கள் கொள்கை பெயரிடும் பாதுகாக்கப்பட்ட சேமிப்பகத்தில் வையுங்கள். சான்றிதழ்களின் வரிசை எண்கள் ஒவ்வொரு வழங்குபவருக்கும் தனித்துவமாக இருக்க வேண்டும்; வரிசைக் கோப்பை புதிதாக மீண்டும் உருவாக்குவது ரத்தைத் தெளிவற்றதாக்கும் மோதல்களுக்கு வாய்ப்பளிக்கிறது.

என்ன வழங்கப்பட்டது என்பதைப் பதிவு செய்யுங்கள்: வரிசை எண், பொருள், கோரப்பட்ட அடையாளம், அங்கீகரித்த நபர் மற்றும் காலாவதி. அந்தப் பதிவே பின்னர் ரத்து முடிவு சார்ந்திருப்பது, மேலும் பதிவின் தடயம் ஒரு அஞ்சல் பெட்டியில் மட்டும் வாழ்ந்தால் அதை சான்றிதழிலிருந்து மட்டும் மீண்டும் கட்ட முடியாது.

படி 5: அதைப் பொருந்தும் விசைக்கு அருகில் நிறுவி ஜோடியை நிரூபியுங்கள்

கிளையன்ட் பெறுவது சான்றிதழும் வழங்குபவரின் சங்கிலியுமே, ஒருபோதும் விசை அல்ல. இணைவதற்கு முன், சான்றிதழ் வட்டில் ஏற்கனவே உள்ள விசையுடன் உண்மையில் ஜோடியாகிறதா என்பதை உறுதிப்படுத்துங்கள், ஏனெனில் பொருந்தாத ஜோடி மிகவும் பின்னர் குழப்பமான கைக்குலுக்கல் தோல்வியை உருவாக்குகிறது:

openssl x509 -in client.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256
openssl pkey -in client.key -pubout -outform DER | openssl sha256

இரண்டு டைஜெஸ்ட்களும் பொருந்த வேண்டும். பின்னர் இணைந்து சேவையகம் பதிவு செய்யும் அடையாளம் நீங்கள் அனுமதித்ததே என்பதை உறுதிப்படுத்துங்கள், சுரங்கம் மேலெழுந்தது மட்டுமல்ல. விசை தொலைந்தால் அல்லது சாதனம் மாற்றப்பட்டால், பதில் ரத்து மற்றும் புதிய சாதனத்திலிருந்து புதிய கோரிக்கை; நிர்வாகியை வேறெங்கிருந்தோ விசையைத் திருப்பி அனுப்பச் சொல்வது அசலை மீட்டெடுக்காது, கோரிக்கையைப் பாதுகாப்பாக்கிய மாதிரியை அமைதியாக உடைக்கிறது.