VPN సర్టిఫికేట్ అధారిటీని మార్చినప్పుడు ఏం జరుగుతుంది
VPN CA మార్పు విశ్వాసాన్ని మరియు గుర్తింపును విడివిడిగా మారుస్తుంది. ధృవీకర్తలు ఏమి పరిశీలిస్తారు, పాత సొరంగాలు ఎందుకు నిలిచి ఉంటాయి, రెండు దిశలు పనిచేస్తాయని ఎలా నిరూపించాలి.
VPN సర్టిఫికేట్ అధారిటీని మార్చడం ఫైల్ మార్పిడి కాదు. కొత్త CA తన మొదటి సర్టిఫికేట్పై సంతకం చేసిన క్షణం, ఇంకా పాతదాన్ని మాత్రమే నమ్ముతున్న ప్రతి ధృవీకర్త నిర్ణయం తీసుకోవాలి, కొత్త యాంకర్ ఎప్పటికీ రాని హోస్ట్లు మంచి సహచరులను తిరస్కరిస్తూనే ఉంటాయి. ఇది రెండు దిశల్లోనూ పాడవడం నేను చూశాను: గేట్వే కొత్త CA నేర్చుకుంది కానీ క్లయింట్లు నేర్చుకోలేదు, అందువల్ల కొత్త కనెక్షన్లు విఫలమయ్యాయి, ఇప్పటికే లేచిన సొరంగాలు అలాగే నిలిచి అంతరాయాన్ని రూటింగ్ సమస్యలా కనిపించేలా చేశాయి. ఏం మారుతుందో, లోపాలు కనిపించే క్రమంలోనే క్రింద ఇచ్చాను.
ఒక మార్పిడి, రెండు వేర్వేరు మార్పులు
సర్టిఫికేట్ అధారిటీ అంటే ఒక పేరు, ఒక పబ్లిక్ కీ మరియు సంతకం చేసే ప్రైవేట్ కీ. ధృవీకర్తలు ఎప్పుడూ అమూర్తంగా ‘CA’పై నమ్మకం ఉంచరు. నమ్మక నిల్వలో ఇప్పటికే ఉన్న ఒక నిర్దిష్ట సర్టిఫికేట్ను నమ్ముతారు, సంతకాల గొలుసు ఆ నిల్వ చేసిన ప్రతిని చేరితేనే జారీచేసేవారిని అంగీకరిస్తారు. అందువల్ల CA మార్పు స్వతంత్రంగా విఫలమయ్యే రెండు విషయాలను మారుస్తుంది: ఏ యాంకర్లు అంగీకరించబడతాయి మరియు వాటి కింద ఏ సహచర గుర్తింపులు జారీ అయ్యాయి.
చాలా VPN అమరికలు రెండు దిశల్లోనూ ధృవీకరిస్తాయి. క్లయింట్ గేట్వే సర్టిఫికేట్ను, గేట్వే క్లయింట్ సర్టిఫికేట్ను ధృవీకరిస్తాయి. కేవలం క్లయింట్ బండిల్ను మాత్రమే రిఫ్రెష్ చేసే మార్పు, పాత CA గుర్తింపును ఇంకా చూపుతున్న ప్రతి క్లయింట్ను సర్వర్ తిరస్కరించనిస్తుంది, దీనికి విరుద్ధమూ అంతే సాధారణం. మొదట అమలు స్థానాలను జాబితా చేయండి: క్లయింట్ నమ్మక నిల్వలు, గేట్వే ca ఫైల్, దాని ముందు TLS ముగించే ఏ ప్రాక్సీ అయినా, మరియు బయట నుండి చివరి బిందువును పరిశీలించే ప్రోబ్.
ధృవీకర్త ఏమి పరిశీలిస్తాడు, క్రమంగా
మార్గ ధృవీకరణ సహచరి సర్టిఫికేట్ నుండి మధ్యవర్తుల ద్వారా నమ్మదగిన యాంకర్ను చేరుకునే వరకు ఎక్కుతుంది. ప్రతి అడుగులో సంతకాన్ని ధృవీకరిస్తుంది, ప్రతి సర్టిఫికేట్ తన చెల్లుబాటు విండోలో ఉందో లేదో చూస్తుంది, ప్రాథమిక పరిమితులు మరియు కీ వినియోగం జారీచేసేవారికి సంతకం చేయడానికి అనుమతిస్తాయని నిర్ధారిస్తుంది. ఆ తర్వాతే అప్లికేషన్ ఆకు సర్టిఫికేట్ను చూస్తుంది: విషయం యొక్క ప్రత్యామ్నాయ పేర్లు డయల్ చేసిన పేరును కవర్ చేయాలి, విస్తరించిన కీ వినియోగం సర్వర్ లేదా క్లయింట్ ప్రామాణీకరణను అనుమతించాలి.
ఆ ప్రయాణాన్ని ఆఫ్లైన్లో పునరావృతం చేయడానికి, -CAfile ను మీరు అమర్చబోయే ఖచ్చితమైన బండిల్కు చూపండి, సిస్టమ్ నిల్వకు కాదు. లేకపోతే మీరు మార్పును కాదు, హోస్ట్ను పరీక్షిస్తున్నారు:
openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt
ఆ ఆదేశం గేట్వే యొక్క HTTPS నిర్వహణ పేజీ లాంటి సాధారణ TLS శ్రోతకు వ్యతిరేకంగా మాత్రమే పనిచేస్తుంది; OpenVPN నియంత్రణ ఛానెల్ TLS కంటే ముందు వస్తుంది, కాబట్టి s_client సొరంగం యొక్క చేతులు కలపడాన్ని పరిశీలించలేదు.
ఆ లోపాల వెనుక ఉన్న మార్గ నిర్మాణ నియమాలు RFC 5280 విభాగం 6 లో ఉన్నాయి. అవి ఇతరత్రా ఏకపక్షంగా కనిపించే వైఫల్యాలను వివరిస్తాయి: ఎవరూ గుర్తుంచుకోని గడువు ముగిసిన మధ్యవర్తి, కీ వినియోగం సంతకాన్ని నిషేధించే సర్టిఫికేట్, లేదా మీరు పరీక్షిస్తున్న హోస్ట్ను మినహాయించే పేరు పరిమితి.
పాత సొరంగం ఎందుకు పని చేస్తూనే ఉంటుంది
TLS మరియు OpenVPN రెండూ చేతులు కలపడం ముగిసిన తర్వాత స్థాపించిన సెషన్ను సజీవంగా ఉంచుతాయి. ప్రతి ప్యాకెట్కు సహచరి సర్టిఫికేట్ను తిరిగి ధృవీకరించేది ఏదీ లేదు, కాబట్టి మార్పుకు ముందు కనెక్ట్ అయిన క్లయింట్ తిరిగి చర్చలు, తిరిగి కనెక్షన్ లేదా సొరంగం పడిపోయే వరకు ట్రాఫిక్ పంపుతూనే ఉంటుంది. ఈ ఖాళీ వల్లే CA మార్పు గంట పాటు బాగానే కనిపించి తర్వాత అత్యంత దారుణ క్షణంలో విఫలమవుతుంది: ల్యాప్టాప్ నిద్ర నుండి లేస్తుంది, NAT మ్యాపింగ్ గడువు ముగుస్తుంది, గేట్వే మళ్లీ ప్రారంభమవుతుంది.
సెషన్ పునరుద్ధరణ ఈ భ్రమను మరింత సాగదీస్తుంది. TLS సెషన్ టికెట్ క్లయింట్ను సర్టిఫికేట్లను మళ్లీ పంపకుండా తిరిగి రావడానికి అనుమతిస్తుంది, పునరుద్ధరణ మార్గ ధృవీకరణను దాటవేస్తుంది ఎందుకంటే మొదటి చేతులు కలపడం దాన్ని ఇప్పటికే చేసింది. కాబట్టి నిజాయితీ పరీక్ష కొత్త ప్రక్రియలో పూర్తి చేతులు కలపడం. సొరంగాన్ని తిరిగి కనెక్ట్ చేయడానికి బదులుగా క్లయింట్ను తిరిగి ప్రారంభించండి, పరీక్ష ప్రొఫైల్పై టికెట్లను నిలిపివేయడాన్ని పరిగణించండి, అప్పుడు పునరుద్ధరణ మార్గం విరిగిన గొలుసును దాచలేదు.
స్థిర-కీ పొరను దీని నుండి వేరుగా ఉంచండి. tls-auth నియంత్రణ ఛానెల్కు HMAC జోడిస్తుంది, tls-crypt దాన్ని ఎన్క్రిప్ట్ చేసి ప్రామాణీకరిస్తుంది, రెండూ సర్టిఫికేట్ పదార్థాన్ని మోసుకుపోవు, కాబట్టి ఏదైనా తిప్పడం దాని స్వంత వైఫల్య పద్ధతి ఉన్న వేరు మార్పు. రెండింటినీ కలిపే అమరికలు, స్థిర కీ సరిగ్గా ఉన్న, సర్టిఫికేట్ పాతదైన, లోప సందేశం రెండింటినీ ప్రస్తావించని క్లయింట్తో ముగుస్తాయి.
విషయ పేరును పునర్వినియోగించే ఉచ్చు
దిగువన ఏదీ మారకూడదని పూర్వీకుని విశిష్ట పేరును తిరిగి ఉపయోగించాలని ప్రేరణ కలుగుతుంది. అది ఇంటర్ఫేస్లో జారీచేసేవారి పంక్తిని స్థిరంగా ఉంచి, మీకు అవసరమైన ఏకైక సంకేతాన్ని నాశనం చేస్తుంది. ఒకే విషయాలు, వేర్వేరు కీలు ఉన్న రెండు సర్టిఫికేట్లను పేరుతో వేరు చేయలేము, కాబట్టి రెండు యాంకర్లు ఉన్న బండిల్ ధృవీకర్తకు రెండు అభ్యర్థులను ఇస్తుంది, ఎంచుకోవడానికి నియమం లేదు.
అప్పుడు మార్గ నిర్మాణం తప్పుదాన్ని ఎంచుకోవచ్చు, సరైన యాంకర్ ఉన్నప్పటికీ ‘స్థానిక జారీచేసేవారి సర్టిఫికేట్ పొందలేము’ అని నివేదించవచ్చు, లేదా అభ్యర్థుల క్రమం భిన్నంగా ఉన్నందున అదే బండిల్ ఉన్న మరో హోస్ట్పై విజయం, ఇక్కడ వైఫల్యం కావచ్చు. పేరు తప్పనిసరిగా పునర్వినియోగించాల్సి వస్తే, పరివర్తన కాలంలో రెండు యాంకర్లను వేర్వేరు ఫైళ్లలో ఉంచి స్పష్టంగా లోడ్ చేయండి, ప్రతి సహచరి కొత్త జారీచేసేవారిని చూపించిన తర్వాతే వాటిని విలీనం చేయండి. లేకపోతే ప్రత్యామ్నాయానికి వేరు సాధారణ పేరు ఇవ్వండి — తరం లేదా తేదీ ప్రత్యయం సరిపోతుంది — అప్పుడు లాగ్లు మరియు లోప పాఠాలు విఫలమైన సహచరి ఏ అధికారం కింద జారీ అయిందో చెబుతాయి.
నెట్వర్క్ను పడదోయని భ్రమణం
ప్రణాళికాబద్ధ మార్పిడి కోసం ఒకే అడుగులో మార్చడానికి బదులుగా పరిమిత కాలానికి రెండు యాంకర్లను అంగీకరించండి. కొత్త CA మరియు దాని మధ్యవర్తులను జారీ చేయండి, కొత్త యాంకర్ను పాత దాని పక్కన ప్రతి ధృవీకర్త బండిల్లో పెట్టండి, ఆ తర్వాతే దాని నుండి సహచరి సర్టిఫికేట్లను జారీ చేయడం ప్రారంభించండి. పాత గుర్తింపులు ఉన్న సహచరులు పాత యాంకర్కు వ్యతిరేకంగా ధృవీకరించబడతాయి; కొత్తవి కొత్తదానికి వ్యతిరేకంగా పనిచేస్తాయి.
ఈ క్రమంలో చేస్తే ప్రతి అడుగూ తిరిగి మార్చగలిగేది. మీరు నివారించే వైఫల్యం ఏకకాల మార్పిడి: బండిల్ నవీకరణను మిస్ అయిన క్లయింట్ పాత యాంకర్ను ఇప్పటికే విరమించిన గేట్వేను ఎదుర్కొంటుంది, చేతులు కలపడం మరణిస్తుంది, ఏ లాగ్ కూడా ఏ వైపు పాతదో చెప్పదు.
వ్యతిరేక దిశలో విరమించండి. నిలిచి ఉండాల్సిన ప్రతి గుర్తింపును తిరిగి జారీ చేయండి, ప్రతి ఒక్కటి కొత్త గొలుసును చూపుతుందని నిర్ధారించి, తర్వాత బండిల్ల నుండి పాత యాంకర్ను తీసివేయండి. పాత CA యొక్క ప్రైవేట్ కీని సేవ నుండి తీసివేయండి, ఎందుకంటే ఇంకా సంతకం చేయగల జారీచేసేవారు ఉంటే భ్రమణం పూర్తికాలేదని అర్థం. ఆడిట్ కోసం సర్టిఫికేట్లు మరియు జారీ రికార్డులను ఉంచండి. కోల్పోయిన జారీచేసేవారు అదే విశ్వాసానికి పునరుద్ధరించబడతారు; బహిర్గతం కొత్త గుర్తింపులు కావాలి, పాత యాంకర్కు తిరిగి వెళ్లడం లేదు.
ఫలితాన్ని ధృవీకరించండి, ఫైల్ జాబితాను కాదు
ఆశించిన డైరెక్టరీలోని నమ్మక ఫైల్ పెద్దగా ఏమీ నిరూపించదు. అప్లికేషన్ మరో మార్గం, మరో ఆకృతి లేదా నవీకరణ మార్చే ప్యాకేజీ లోపలి ప్రతిని చదవవచ్చు. ఫైల్ ఉందా అని కాదు, రెండు చివరల ప్రవర్తనను పరిశీలించండి.
కొత్త గుర్తింపుతో కొత్త కనెక్షన్ విజయవంతమవుతుందని నిర్ధారించి, తర్వాత విరమించిన CA జారీ చేసిన గుర్తింపు తిరస్కరించబడుతుందని నిర్ధారించండి. ప్రజలు దాటవేసేది ఆ రెండో పరీక్షే, పాత అధికారం ఇక ప్రవేశం ఇవ్వదని చూపే ఏకైక పరీక్షా అదే. అమరిక CRL లేదా OCSPపై ఆధారపడితే, కొత్త సర్టిఫికేట్లలోని పంపిణీ బిందువులు పరిష్కరించబడతాయో, అడిగే సహచరులు ప్రతిస్పందకుడిని చేరుకుంటారో పరిశీలించండి.
ఎప్పుడూ కనెక్ట్ కాని క్లయింట్తో ముగించండి: దాని ప్రొఫైల్ స్థితిని తొలగించి, కనెక్ట్ చేసి, చర్చించిన గొలుసును చదవండి. నిల్వ చేసిన సెషన్ను పునరుద్ధరించే సహచరి ఏమీ ధృవీకరించకుండానే స్థానభ్రంశం విజయవంతమైందని సంతోషంగా నివేదిస్తుంది.