VPN క్లయింట్ కీని ఎలా సృష్టించాలి మరియు సంతకం కోసం CSRని ఎలా సమర్పించాలి
ప్రైవేట్ కీని క్లయింట్ వద్దే ఉంచి అభ్యర్థనను మాత్రమే పంపండి. 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రెండు డైజెస్ట్లు సరిపోలాలి. ఆపై కనెక్ట్ అయి, సర్వర్ నమోదు చేసే గుర్తింపు మీరు అధికారం ఇచ్చినదే అని నిర్ధారించండి, టన్నెల్ పైకి వచ్చింది మాత్రమే కాదు. కీ పోయినా లేదా పరికరం మార్చబడినా, సమాధానం రద్దు మరియు కొత్త పరికరం నుండి కొత్త అభ్యర్థన; నిర్వాహకుడిని వేరే చోటి నుండి కీని తిరిగి పంపమని అడగడం అసలైనదాన్ని తిరిగి తీసుకురాదు మరియు అభ్యర్థనను సురక్షితం చేసిన నమూనాను నిశ్శబ్దంగా విచ్ఛిన్నం చేస్తుంది.