మరో ల్యాప్‌టాప్ కోసం మరో ధృవపత్రం కావాలి, కానీ శోధన ఫలితాల్లోని మొదటి పాఠం PKI డైరెక్టరీని తొలగించే ఆదేశంతో మొదలవుతుంది. ఆ ఆదేశం మొదటి సెటప్‌ది, నమోదుది కాదు, దాన్ని అమలు చేయడం వల్ల CA, జారీ చరిత్ర మరియు పాత జారీచేసేవారిని నమ్మిన ప్రతి క్లయింట్ ప్రొఫైల్ పోతాయి. నిర్ణయం సన్నగా ఉంది: జారీచేసేవారి వద్ద ఇంకా ఉపయోగించగల స్థితి ఉందా, కొత్త పరికరం మీ నమోదు విధానానికి సరిపోతుందా? మూడు షరతులు నిర్ణయిస్తాయి, ఒకటి మాత్రమే పునర్నిర్మాణాన్ని సమర్థిస్తుంది.

పునర్నిర్మాణం నిజంగా ఏమి నాశనం చేస్తుంది

PKI ను తిరిగి ప్రారంభించడం డైరెక్టరీని ఖాళీ నిర్మాణంతో భర్తీ చేస్తుంది: కొత్త CA కీ మరియు ధృవపత్రం, ఖాళీ జారీ డేటాబేస్ మరియు కొత్త క్రమ సంఖ్య కౌంటర్. క్లయింట్లు తమంతట తాము అనుసరించరు; వాటి ప్రొఫైల్‌లు పాత CA ను పిన్ చేస్తాయి, కాబట్టి ప్రతి పరికరం తిరిగి నమోదు కావాలి, చేరుకోలేనివి చేతితో.

అత్యంత నిశ్శబ్ద నష్టం లెక్కింపు. రద్దు చేయడం ఏ క్రమ సంఖ్యలను ఎవరికి జారీ చేశారో తెలియడంపై ఆధారపడి ఉంటుంది. సూచికను తొలగించినా సంతకం చేయవచ్చు, కానీ మిగిలిన ధృవపత్రాల్లో ఏది రద్దు చేయాలనుకున్నారో ఖచ్చితంగా చెప్పలేరు. జారీచేసేవారి స్థితి లేని ధృవపత్రాలతో ఉన్న CA డైరెక్టరీ వ్యవస్థలోని తప్పు సగాన్ని పునరుద్ధరించే బ్యాకప్.

CA యొక్క ప్రైవేట్ కీని నడుస్తున్న సర్వర్ పక్కన కాపీ చేయడం తిరస్కరించాల్సిన మరో షార్ట్‌కట్: ఇది ఆఫ్‌లైన్‌లో ఉండాల్సిన సంతకం అధికారాన్ని నమ్మలేని ట్రాఫిక్ ఉన్న హోస్ట్‌లో మరో ఫైల్‌గా మారుస్తుంది.

మొదటి షరతు: జారీచేసేవారి స్థితి ఇంకా చేరుకోగలదా

నిర్ణయం ముందు సర్వర్ నిజంగా నమ్మే డైరెక్టరీని కనుగొనండి. సర్వర్ CA గా చూపే ధృవపత్రాన్ని PKI డైరెక్టరీలోని దానితో వేలిముద్ర ద్వారా పోల్చండి, ఫైల్ పేరుతో కాదు:

openssl x509 -in ca.crt -noout -fingerprint -sha256
openssl x509 -in /etc/openvpn/ca.crt -noout -fingerprint -sha256

ముద్రలు సరిపోతే నమోదు అదనపు, ఏమీ పునర్నిర్మించకండి. భిన్నమైతే సర్వర్ నమ్మని CA తో సంతకం చేస్తారు: ధృవపత్రం శుభ్రంగా ఇన్‌స్టాల్ అవుతుంది కానీ హ్యాండ్‌షేక్‌లో విఫలమవుతుంది, ఆ లోపం గంటల తరబడి క్లయింట్ బగ్‌గా తప్పుగా నిర్ధారణ చేయబడుతుంది.

తర్వాత జారీ స్థితిని వెతకండి: సూచిక ఫైల్, క్రమ కౌంటర్ మరియు CRL సంఖ్య ఫైల్. సూచిక లేకపోయినా కీ ఉంటే జారీ చేయవచ్చు, కానీ రద్దులను నమోదు చేసే సమస్య వారసత్వంగా వస్తుంది. దాన్ని మార్పు రికార్డులో రాయండి, ఎందుకంటే తదుపరి రద్దు అభ్యర్థన దాన్ని బయటపెడుతుంది.

రెండో షరతు: కొత్త ప్రైవేట్ కీ ఎవరి వద్ద ఉంది

ఇది వినియోగదారులు గ్రహించే నిర్ణయం, కాబట్టి స్పష్టంగా తీసుకోండి. క్లయింట్ సృష్టించి అభ్యర్థనగా పంపిన కీ ప్రైవేట్ సగాన్ని మొదటి ఆదేశం నుంచే పరికరంలో ఉంచుతుంది, నిర్వాహకుడు దాన్ని ఎప్పుడూ తాకడు. సర్వర్ సృష్టించిన కీ సాధనాలు లేని పరికరాలకు సులభం, కానీ నిర్వాహకుడిని ప్రతి కీ రక్షకుడిగా చేసి సర్వర్ భంగం ప్రభావాన్ని విస్తరిస్తుంది.

ఉన్న CA పై Easy-RSA 3 తో అభ్యర్థనను దిగుమతి చేసి సంతకం చేయడం రెండు ఆదేశాలు:

./easyrsa import-req /tmp/alice.req alice
./easyrsa sign-req client alice

ధృవపత్ర రకాన్ని ఉద్దేశపూర్వకంగా ఎంచుకోండి. క్లయింట్‌కు బదులు సర్వర్ ధృవపత్రంగా సంతకం చేసిన అభ్యర్థన మంచిగా కనిపించే కానీ ప్రత్యర్థి తిరస్కరించే ఫైల్ ఇస్తుంది, లోప సందేశం కారణం చెప్పదు. openssl ca తో సంతకం చేస్తే అదే ఎంపిక మీరు ఇచ్చే పొడిగింపుల్లో ఉంటుంది, డిఫాల్ట్ విభాగంలో కాదు.

మూడో షరతు: సర్వర్‌కు ధృవపత్రం కంటే ఎక్కువ కావాలా

ధృవపత్ర ధృవీకరణ ఉన్న సాధారణ OpenVPN సర్వర్‌కు ధృవపత్రమే నమోదు: సాధారణ పేరు క్లయింట్ గుర్తింపు అవుతుంది, ఏ డైరెక్టరీ, నెట్టబడిన మార్గం లేదా స్థిర చిరునామా ఆ పేరుపై ఆధారపడి ఉంటుంది. ధృవపత్రం జోడించి కాన్ఫిగ్ మరచిపోతే సొరంగం కనెక్ట్ అవుతుంది కానీ అవసరమైన మార్గాలు కనిపించవు.

వేదికలు దీన్ని మారుస్తాయి. OpenVPN Access Server తన సొంత వినియోగదారు డేటాబేస్ కలిగి ఉంటుంది, కాబట్టి సంతకం చేసిన ధృవపత్రం ఖాతా కాదు; ఖాతా ఉండాలి, అనుమతించబడాలి. ఇతర గేట్‌వేలు గుర్తింపు శ్రేణిని సమూహానికి జోడిస్తాయి. ఒక పరికర నమోదు సాధారణంగా రెండు వ్యవస్థలను తాకుతుంది, ధృవపత్రం మొదటిది మాత్రమే.

అదనపు విధానం మరియు ఎప్పుడు పునర్నిర్మాణం సరైనది

హాని లేకుండా ఒక పరికరాన్ని జోడించే క్రమం: వేలిముద్రతో జారీచేసేవారిని నిర్ధారించండి, PKI డైరెక్టరీ తాజా బ్యాకప్ తీసుకోండి, క్లయింట్ పాత్ర కోసం అభ్యర్థనను దిగుమతి చేసి సంతకం చేయండి, ఆమోదిత మార్గంలో ధృవపత్రాన్ని దాని గొలుసుతో అందించండి, వినియోగదారు కనెక్ట్ కాకముందు ధృవీకరించండి:

openssl verify -CAfile ca.crt alice.crt
openssl x509 -in alice.crt -noout -subject -issuer -dates -purpose

ఉద్దేశ్య పంక్తిలో SSL client కనిపించాలి. జారీ తర్వాత CA బ్యాకప్‌ను నవీకరించి ముగించండి, ఎందుకంటే కొత్త క్రమ సంఖ్య నమోదుకాకముందు తీసుకున్న బ్యాకప్ ఇప్పుడు జోడించిన పరికరం లేని స్థితిని తిరిగి ఇస్తుంది.

పునర్నిర్మాణం మూడు సందర్భాల్లో సరైనది: CA కీ భంగపడింది, జారీ స్థితి తిరిగి పొందలేని విధంగా పోయింది, లేదా కీ అల్గోరిథం లేదా ధృవపత్ర విధానాన్ని ఉద్దేశపూర్వకంగా మారుస్తున్నారు. మూడూ ప్రతి క్లయింట్ తిరిగి నమోదు ప్రణాళిక అవసరమయ్యే ప్రాజెక్టులు, ఒక పరికర అభ్యర్థనలోని దశలు కావు. ఏదీ వర్తించకపోతే అదనంగా నమోదు చేయండి.

సంబంధిత వ్యాసాలు