క్రాస్-సైన్ చేసిన CA: కీ సరిపోతుంది, AKI బైండింగ్ సరిపోదు
ఒక లీఫ్ కీ గుర్తింపుదారు, జారీచేసినవారు మరియు క్రమ సంఖ్య ద్వారా తన జారీచేసినవారిని పిన్ చేసుకోగలదు. క్రాస్-సైన్ చేసిన గొలుసును పరస్పరం మార్చుకోగలిగినదిగా పరిగణించే ముందు ఆ బైండింగ్ను తనిఖీ చేయండి.
రెండు CA ధృవపత్రాలు ఒకే పబ్లిక్ కీ మరియు ఒకే subject కలిగి ఉండి అయినప్పటికీ పరస్పరం మార్చుకోగలిగినవి కాకపోవచ్చు. ఒకటి స్వయం-సంతకం చేసినది, మరొకటి పాత మూలం ద్వారా క్రాస్-సంతకం చేయబడినది, మరియు వాటి జారీచేసినవారి పేర్లు, క్రమ సంఖ్యలు మరియు సంతకాలు భిన్నంగా ఉంటాయి. లీఫ్ తన Authority Key Identifier ద్వారా ప్రత్యేకంగా వాటిలో ఒకదానికి బంధించుకోగలదు. ఆ బంధం క్లయింట్ తప్పు గొలుసును ఎంచుకుని handshake స్పష్టమైన కారణం లేకుండా విఫలమయ్యే వరకు అదృశ్యంగా ఉంటుంది.
ఈ ఐదు తనిఖీలను క్రమంగా చేయండి: ప్రతి ఒక్కటి వేరే వైఫల్యాన్ని మినహాయిస్తుంది.
తనిఖీ 1: టెంప్లేట్ను తాకే ముందు రెండు గొలుసులను గీయండి
మార్గాలను రాయండి. పాత జనాభా పాత మూలం A ను నమ్ముతుంది, అది CA B ను జారీ చేసింది, అది సర్వర్ లీఫ్ను జారీ చేసింది. కొత్త జనాభా స్వయం-సంతకం చేసిన CA B ను నేరుగా నమ్ముతుంది. రెండు B ధృవపత్రాలు ఒకే కీ మరియు subject కలిగి ఉన్నాయి, అందుకే subject లైన్ చదివే వ్యక్తి ఒక CA చూసే చోట క్లయింట్ రెండు చూస్తాడు.
క్రాస్-సంతకం చేసిన ప్రతి కూడా నిజమైన CA ధృవపత్రం అయి ఉండాలి, సంతకం చేయడానికి అనుమతించే basic constraints మరియు key usage తో.
తనిఖీ 2: కీ మాత్రమే కాదు, AKI ఫీల్డ్లను పోల్చండి
లీఫ్ జారీచేసినవారి పేరు B యొక్క subject తో సరిపోలాలి, ఆ భాగం సాధారణంగా నిలుస్తుంది. రెండు ప్రతులు వేరుపడే ప్రదేశం Authority Key Identifier, ఎందుకంటే అది కీ గుర్తింపుదారు, జారీచేసినవారి ధృవపత్రం మరియు క్రమ సంఖ్యను మోయగలదు. కీ ఒకటే కాబట్టి కీ గుర్తింపుదారు రెండు ప్రతులతో సరిపోతుంది. జారీచేసినవారు మరియు క్రమ సంఖ్య ఫీల్డ్లు సరిగ్గా ఒకదానితో మాత్రమే సరిపోతాయి, అందుకే స్వయం-సంతకం ప్రతికి వ్యతిరేకంగా నిర్మించిన గొలుసు క్రాస్-సంతకం ప్రతికి వ్యతిరేకంగా విఫలమవవచ్చు.
ఊహించకుండా లీఫ్ను పరిశీలించండి: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.
తర్వాత రెండు అభ్యర్థులను openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier" తో పోల్చండి, అదే ఆదేశాన్ని స్వయం-సంతకం ప్రతికి వ్యతిరేకంగా అమలు చేయండి.
లీఫ్ జారీచేసినవారు మరియు క్రమ సంఖ్యను మోస్తే, ఆ విలువలు వివరించే ధృవపత్రం మాత్రమే గొలుసును పూర్తి చేస్తుంది, క్లయింట్ ఏ ప్రతిని లోడ్ చేసినా.
తనిఖీ 3: జారీ విధానాన్ని మార్చండి, సంతకం చేసిన బైట్లను ఎప్పుడూ కాదు
పొడిగింపులు సంతకం లోపల నివసిస్తాయి. ఉన్న లీఫ్పై ఒకదాన్ని జోడించడం, తీసివేయడం లేదా సవరించడం మరమ్మత్తు కాదు, అది వేరే ధృవపత్రం, మరియు మళ్లీ జారీ చేయాలి. మార్పు జారీ విధానానికి చెందుతుంది: authorityKeyIdentifier = keyid,issuer:always కొత్త లీఫ్లు ధృవపత్రానికి నిర్దిష్టమైన బంధాన్ని మోయడానికి చేస్తుంది, అయితే keyid ఒంటరిగా ఉద్దేశపూర్వక క్రాస్-సైనింగ్ పరివర్తనానికి సరిపోయే సడలిన రూపాన్ని నిలుపుతుంది. తదుపరి బ్యాచ్ సంతకం చేయబడక ముందు మీ PKI ఏది కావాలో నిర్ణయించుకోండి.
భాగస్వామ్య టెంప్లేట్ను సవరించడం మీ ముందున్న సర్వర్ మాత్రమే కాదు, ప్రతి భవిష్యత్ ధృవపత్రాన్ని కూడా మారుస్తుంది.
తనిఖీ 4: ప్రతి విశ్వాస జనాభాను విడివిడిగా ధృవీకరించండి
పాత మార్గాన్ని మరియు కొత్త మార్గాన్ని విడి రన్లుగా పరీక్షించండి. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem క్రాస్-సంతకం మార్గాన్ని సాధన చేస్తుంది, కొత్త మూలం మరియు untrusted ఫైల్ లేని అదే ఆదేశం స్వయం-సంతకం మార్గాన్ని సాధన చేస్తుంది. రెండు మూలాలను ఒకే బండిల్లో కలపడం ఏ గొలుసు ఎంచుకోబడిందో దాచుతుంది. తర్వాత నిజమైన క్లయింట్లతో పునరావృతం చేయండి, ఎందుకంటే VPN బ్యాకెండ్ గొలుసుకు ప్రాధాన్యం ఇవ్వవచ్చు లేదా ధృవపత్రాన్ని పిన్ చేయవచ్చు openssl చేయని విధాలుగా.
మధ్యస్థ ధృవపత్రాన్ని క్లయింట్ నిజంగా చదివే సేవా కాన్ఫిగరేషన్ ద్వారా అందించండి, వికీ పేజీ ద్వారా కాదు.
తనిఖీ 5: పాత మార్గాన్ని రిటైర్మెంట్ గడియారంపై ఉంచండి
క్రాస్-సైనింగ్ రూపకల్పన ప్రకారం పాత విశ్వాస మార్గాన్ని సజీవంగా ఉంచుతుంది, అది ఒకేసారి లక్ష్యం మరియు ప్రమాదం. అది రాజీ పడిన పాత మూలానికి పరిహారం ఇవ్వదు, ఆ మూలాన్ని ఏ క్లయింట్ నుండి తీసివేయదు. పాత మార్గం ఎప్పుడు విశ్వాసం ఇవ్వడం ఆపుతుందో రాయండి, ఆ రోజు నిజంగా వస్తుందని నిర్ధారించండి.
లీఫ్లు కదిలే ముందు ప్రతి క్లయింట్ కొత్త మూలాన్ని తీసుకోగలిగితే, సాధారణ ద్వి-విశ్వాస రోల్అవుట్ క్రాస్-సైనింగ్ కంటే సులభం, మరియు రిటైర్ చేయడానికి ఒక వస్తువు తక్కువ మిగులుతుంది.