టోకెన్ కోసం OpenConnect కి ఏ PKCS#11 URI కావాలి?

సరైన కీ ఇప్పటికే ఉన్న స్మార్ట్ కార్డుకు కూడా దానిపై ఏ వస్తువును ఉపయోగించాలో చెప్పాలి. ఆ స్థితిలో OpenConnect కాపీ చేసిన .key ఫైల్ను కోరదు; సర్టిఫికెట్ను పేర్కొనే PKCS#11 URI ను కోరుతుంది, స్వయంచాలక అన్వేషణ పని పూర్తి చేయలేనప్పుడు పక్కన ఉన్న ప్రైవేట్ కీని కూడా పేర్కొనాలి. ఇబ్బంది ఏమిటంటే వ్యాకరణపరంగా చెల్లుబాటు అయ్యే URI ఏమీ నిరూపించదు. కార్డు తెరవడానికి సిద్ధంగా ఉన్న వస్తువును మాత్రమే కాదు, గేట్వే ఇప్పటికే నమ్ముతున్న నమోదును పేర్కొనాలి.

ఎగుమతి చేసిన కీకి బదులుగా క్లయింట్ ఏమి కోరుతుంది

-c ఎంపిక సాధారణంగా ఫైల్ మార్గాన్ని తీసుకుంటుంది, కానీ విలువ PKCS#11 URI గా పార్స్ అయినప్పుడు, OpenConnect దానిని డిస్క్లోని ఫైల్కు కాకుండా టోకెన్ లోపలి వస్తువుకు సూచనగా పరిగణిస్తుంది. -k ఎంపిక ప్రైవేట్ కీ విషయంలో అదే విధంగా ప్రవర్తిస్తుంది. ఏదీ ఎగుమతి కాదు, కీ కార్డు అందించే రక్షణను ఎప్పటికీ వదలదు. క్లయింట్ మీ నుండి కోరేది టోకెన్ మాడ్యూల్, సర్టిఫికెట్ నిల్వ మరియు గేట్వే నమోదు అంగీకరించే పేరు.

చాలా ప్రయత్నాలు నిలిచిపోయేది ఈ చివరి పరిమితి వద్దే. URI పూర్తిగా బాగా రూపొందించబడినా గేట్వే తిరస్కరించే సర్టిఫికెట్ను ఎంచుకోవచ్చు, ఎందుకంటే చెల్లుబాటు మరియు సంబంధితత్వం వేర్వేరు ప్రశ్నలు. చేయదగిన తనిఖీ నమోదు రికార్డుతో పోలిక, యాదృచ్ఛికంగా తెరుచుకునే మొదటి వస్తువు కోసం వెతకడం కాదు.

రెండు URI, రెండు వేర్వేరు పనులు

సర్టిఫికెట్ యొక్క URI మీరు ఏ గుర్తింపును క్లెయిమ్ చేస్తున్నారో సమాధానమిస్తుంది. పబ్లిక్ కీ మరియు విషయ పంక్తి VPN నిర్వాహకుడు జారీ చేసిన ఖాతా లేదా పరికర ప్రొఫైల్కు సరిపోయే సర్టిఫికెట్ వస్తువును అది సూచిస్తుంది. అదే సర్టిఫికెట్ సాధారణంగా పక్కన నిల్వ చేసిన ప్రైవేట్ కీ వస్తువుతో వస్తుంది, TLS హ్యాండ్షేక్కు నిజంగా అవసరమైనది ఆ జంట.

కీ యొక్క URI, OpenConnect ఊహించలేనప్పుడు సరిపోయే ప్రైవేట్ పదార్థం ఎక్కడ ఉందో సమాధానమిస్తుంది. -c మాత్రమే సెట్ చేస్తే, క్లయింట్ సర్టిఫికెట్ లక్షణాల నుండి కీ-అన్వేషణను నిర్మిస్తుంది; -k ఇవ్వడం ఊహకు బదులుగా స్పష్టమైన వస్తువు సూచనను పెడుతుంది. టోకెన్ యొక్క PIN మూడవ, సంబంధం లేని ఇన్పుట్: అది చర్య కోసం కార్డును తెరుస్తుంది, ఎప్పటికీ వస్తువును గుర్తించదు.

openconnect --protocol=anyconnect \
  -c 'pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=1a2b3c4d;id=%01' \
  vpn.example.net

ఆ ఉద్ధృత స్ట్రింగ్లో ఉన్నదంతా డేటా. అర్ధచంద్ర చుక్కలు URI లక్షణాలను వేరు చేస్తాయి మరియు శాతం-ఎస్కేప్లు పార్సింగ్ను విచ్ఛిన్నం చేసే అక్షరాలను ఎన్కోడ్ చేస్తాయి, కాబట్టి మొత్తం ఆర్గ్యుమెంట్ షెల్ నుండి చెక్కుచెదరకుండా బయటపడాలి.

మీ నమోదుకు సరిపోయే URIని కనుగొనడం

GnuTLS తో p11tool వస్తుంది, ఇది ప్రస్తుత వినియోగదారు p11-kit ద్వారా నిజంగా ఏమి చేరుకోగలరో జాబితా చేస్తుంది. p11tool --list-tokens తో ప్రారంభించి, ఆపై మీకు ముఖ్యమైన టోకెన్పై సర్టిఫికెట్ వస్తువులను జాబితా చేయండి. వస్తువులు PIN తర్వాత మాత్రమే కనిపిస్తే --login జోడించి, మొదట కనిపించేది ఎంచుకోవడం బదులు విషయాన్ని మరియు జారీచేసినవారిని నమోదు రికార్డుతో పోల్చండి.

టోకెన్ అసలు కనిపించకపోతే, సమస్య OpenConnect కింద ఉంది: p11-kit లో ఆ మిడిల్వేర్ కోసం నమోదైన మాడ్యూల్ లేదు, లేదా మాడ్యూల్ మరో ఖాతా కోసం నమోదైంది. సిస్టమ్-వ్యాప్త నమోదు /etc/pkcs11/modules కింద ఉంటుంది, మరియు వినియోగదారు-వారీ డైరెక్టరీ సిస్టమ్ కాపీని తాకకుండా అదే ఉంచుకోగలదు. మాడ్యూల్ ఫైల్లోని ప్రదాత మార్గం రీడర్ సాఫ్ట్వేర్ నిజంగా ఇన్స్టాల్ చేసిన లైబ్రరీని సూచిస్తుందో లేదో తనిఖీ చేయండి.

జాబితా నుండి URIని కాపీ చేసేటప్పుడు దాని చుట్టూ ఉన్న కోట్ గుర్తులను ఉంచండి. కోట్లు లేని అర్ధచంద్ర చుక్కలు ఆర్గ్యుమెంట్ను మొదటి లక్షణం వద్ద కత్తిరిస్తాయి, క్లయింట్ తర్వాత కనుగొనలేని వస్తువు గురించి నివేదిస్తుంది.

స్వయంచాలక కీ-అన్వేషణ లొంగిపోయినప్పుడు

OpenConnect సర్టిఫికెట్ URI నుండి కీ-అన్వేషణను పొందగలదు, కానీ అది చేసే ఖచ్చితమైన సరిపోలిక వెర్షన్పై ఆధారపడి ఉంటుంది, వస్తువు రకం మరియు లేబుల్ నిర్వహణ కాలక్రమేణా మారింది. పని చేసే వరకు URIని చిన్నగా చేయండి అనే సలహా పాత పరిహార మార్గాన్ని వివరిస్తుంది, అవసరాన్ని కాదు. పొందిన అన్వేషణ విఫలమైతే, సర్టిఫికెట్ URIని మరింత అస్పష్టంగా మార్చడం బదులు -k తో కీని స్పష్టంగా పేర్కొనండి.

క్లయింట్ను నిందించే ముందు కీ ఉందని మరియు p11tool --list-keys తో కనిపిస్తుందని నిర్ధారించండి. తర్వాత వస్తువు సంతకం లేదా డీక్రిప్షన్ కోసం ఉపయోగపడేలా గుర్తించబడిందో లేదో తనిఖీ చేయండి, ఎందుకంటే తప్పు లక్షణాలతో సృష్టించిన కీ URI ఎంత సరైనదైనా హ్యాండ్షేక్ పూర్తి చేయలేదు. OpenVPN ప్రొఫైల్ నుండి సీరియలైజ్ చేసిన pkcs11-id విలువను OpenConnect ఎంపికలోకి మార్చకండి; ఒకే కార్డుతో మాట్లాడుతున్నప్పటికీ రెండు క్లయింట్లు వేర్వేరు గుర్తింపు ఫార్మాట్లను ఉపయోగిస్తాయి.

URI పరిష్కరించబడి PIN ఆమోదించబడినా ప్రమాణీకరణ ఇప్పటికీ విఫలమైతే, URIని ట్యూన్ చేయడం ఆపండి. గేట్వే యొక్క సొంత లోపాన్ని చదవండి, ఎందుకంటే తదుపరి వైఫల్యం టోకెన్ పైన ఉంది.

URI సమస్యల్లా మాత్రమే కనిపించే వైఫల్యాలు

వేరే ప్రోటోకాల్ మాట్లాడే గేట్వే మీ URI సరైనదైనా తప్పైనా అదే విధంగా విఫలమవుతుంది. OpenConnect పాత vpnc క్లయింట్ను ఒక కారణంతో భర్తీ చేసింది, కార్డు మద్దతు సరిపోని గేట్వే ప్రోటోకాల్ను సరిపోయేలా చేయదు. వస్తువు లక్షణాలపై మరో గంట ఖర్చు చేయకముందు సర్వర్ ఆశించే ప్రోటోకాల్ మరియు ప్రమాణీకరణ ఏర్పాటును నిర్ధారించండి.

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

వస్తువు నుండి బయటకు పని చేయండి: p11tool టోకెన్ను చూస్తుందా, సర్టిఫికెట్ మరియు కీని చూస్తుందా, OpenConnect URIని అంగీకరిస్తుందా, ఆ తర్వాత మాత్రమే గేట్వే గుర్తింపును అంగీకరిస్తుందా అని అడగండి. ప్రతి దశకు దాని సొంత లోప సందేశం ఉంది, ప్రతి ఒక్కటి తదుపరి దానికంటే పరీక్షించడం చౌక.