IKEv2 లో రెండు సంతకాలు ఉన్నాయి: ధృవపత్రం మరియు IKE_AUTH

మీ టికెట్ ధృవపత్రం SHA-256 అని చెబుతుంది, కానీ గేట్వే లాగ్ మరో సంతకం అల్గారిథమ్ను పేర్కొంటుంది, మరియు ఎవరో ఇప్పటికే CA ను తిరిగి జారీ చేయాలనే అభ్యర్థనను సిద్ధం చేసారు. ఆ అభ్యర్థన ఎక్కడికైనా వెళ్లే ముందు రెండు సంతకాలను వేరు చేయండి: ఒకటి పబ్లిక్ కీపై జారీచేసేవారి ముద్ర, మరొకటి IKE_AUTH సమయంలో పీర్ వద్ద సరిపోలే ప్రైవేట్ కీ ఉందని రుజువు. వివిధ భాగాలు వాటిని ఎంచుకుంటాయి, అవి భిన్నంగా ఉండటానికి అనుమతి ఉంది. ప్రతిదాన్ని అది నివసించే చోటి నుండి చదవడానికి రెండు ఆదేశాలు మరియు ఒక పట్టిక అవసరం.

ధృవపత్రం నుండి జారీచేసేవారి సంతకం చదవండి

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

openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"

రెండు లేబుళ్లను వేర్వేరు నమోదులుగా రాయండి. మొదటిది CA ను వివరిస్తుంది, రెండవది సబ్జెక్ట్ కీని, మరియు ఏదీ ఆన్లైన్ సంతకాన్ని ముందుగా చెప్పదు.

IKE మార్పిడి నుండి ఆన్లైన్ సంతకం చదవండి

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

ipsec statusall | grep -i "auth\|proposal"

ఒక వైపు మరొకటి తయారు చేయలేని పథకాన్ని పేర్కొన్నప్పుడు, టికెట్ మాట్లాడిన ఆ అసంగతిని మీరు కనుగొన్నారు. CA ను తిరిగి జారీ చేయడం దానికి తప్పు మరమ్మత్తు, ఎందుకంటే విఫలమైనది ధృవపత్రం కాదు.

RFC 7427 ఏమి మారుస్తుంది, ఏమి మార్చదు

అసలు పద్ధతులు RFC 7296 లో ప్రతి అల్గారిథమ్ కలయిక ప్రకారం సంఖ్యలు పొందాయి. తర్వాతి RFC 7427 సంతకం పొడిగింపు సంతకం-హాష్ మద్దతు సంకేతంతో సాధారణ Digital Signature పద్ధతిని జోడిస్తుంది, కాబట్టి కొత్త హాష్కు దాని సొంత పద్ధతి సంఖ్య అవసరం లేదు. ఇది చర్చల ద్వారా నిర్ణయమవుతుంది, ఊహించబడదు: పీర్ లైబ్రరీ అదే ధృవపత్రాలను పార్స్ చేయగలదని పొడిగింపు పొందదు, మరియు అసలు పద్ధతులను మాత్రమే అమలు చేసే పీర్ గేట్వేను వాటిలో ఒకటి ఉంచుకోవాలని బలవంతం చేస్తుంది. ఇది సాంగత్య ఖర్చుతో కూడిన విధాన మార్పిడి, లోపం కాదు.

మద్దతు ప్రతి దిశకు మరియు ప్రతి కనెక్షన్కు ఉంటుంది, కాబట్టి కుటుంబ స్థాయి దావాను నమ్మడం కంటే మీ ముందున్న బిల్డ్ను పరీక్షించండి. మూడు సంవత్సరాల క్రితం రాసిన సామర్థ్య మాత్రిక మూడేళ్ల నాటి బిల్డ్లను వివరిస్తుంది.

జాబితాలో నాలుగు వరుసలు పెట్టండి

వాదనను ముగించే నమోదులో నాలుగు పంక్తులు ఉన్నాయి, ప్రతిదీ వేరే చోటి నుండి చదవబడింది మరియు ప్రతిదీ వేరే వ్యక్తిచే మార్చబడింది. ఏదైనా నిర్ణయించే ముందు దాన్ని నింపండి, ఎందుకంటే తప్పు వరుసే మరమ్మత్తును ఎంచుకుంటుంది.

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

PKI ను బలహీనపరచకుండా పాత కేసును పరిష్కరించండి

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

తర్వాత రెండు పఠనాలను మళ్లీ పైనుండి నడపండి, ఎందుకంటే ఒక వరుసలో మార్పు మరొకదానిలో చర్చించేదాన్ని జరపవచ్చు. మొత్తం జాబితా రెండు ఆదేశాలు మరియు ఒక పట్టిక, మరియు పీర్ రౌటర్, ల్యాప్టాప్ లేదా పరికరం అయినా పని అదే.