లీఫ్ సర్టిఫికెట్ చెల్లుబాటు, చైన్ గడువు ముగిసింది: లోతును చదవండి

మీరు సర్వర్ సర్టిఫికెట్ను తనిఖీ చేస్తారు, గడియారంలో ఇంకా నెలలు మిగిలి ఉన్నాయని చూస్తారు, అయినా క్లయింట్ గడువు ముగిసిందనే సందేశంతో కనెక్షన్ను తిరస్కరిస్తుంది. మీరు చదివే తేదీ లీఫ్ది, మరియు ఫిర్యాదు మార్గంలో లోతైన ఏదో గురించి కావచ్చు. ధృవీకరణ చైన్ గుండా వెళుతుంది, మరియు ఈ ప్రయాణం ఎంచుకునే ఏ సర్టిఫికెట్ అయినా దాని స్వంత చెల్లుబాటు విండోలో విఫలం కావచ్చు. ఏదైనా పునరుద్ధరించే ముందు ఏది విఫలమైందో చదవండి.

లోతు విఫలమైన సర్టిఫికెట్ను పేర్కొంటుంది

OpenSSL నిర్ధారణలో, లోతు 0 లక్ష్య సర్టిఫికెట్ మరియు లోతు 1 దానికి సంతకం చేసిన జారీచేసినవారు, పెద్ద సంఖ్యలు విశ్వాస యాంకర్ వైపు కొనసాగుతాయి. లోతు 1లో నివేదించిన గడువు ముగింపు లీఫ్పై ఉన్న ప్రస్తుత notAfter తో విరుద్ధం కాదు, కాబట్టి కనిపించే సర్టిఫికెట్ను మళ్లీ తనిఖీ చేయడం లోపాన్ని ఎప్పటికీ వివరించదు.

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

ఒకటి కంటే ఎక్కువ సర్టిఫికెట్ పాత్రలు ఉన్న ఉత్పత్తులపై కూడా శ్రద్ధ వహించండి. OpenVPN Access Serverలో, వెబ్ ఇంటర్ఫేస్లను రక్షించే సర్టిఫికెట్లు VPN కనెక్షన్ల కోసం ఉపయోగించే వాటి నుండి వేరుగా ఉంటాయి, కాబట్టి అడ్మిన్ పేజీని తెరిచే బ్రౌజర్ టన్నెల్ మార్గం గురించి ఏమీ నిరూపించదు.

విశ్వాస ఇన్పుట్లు చైన్ అభ్యర్థులతో సమానం కావు

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

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

డిఫాల్ట్ మార్గాన్ని మరియు నిల్వను -no-CApath -no-CAstore తో నిలిపివేయడం పరీక్షను నిజాయితీగా ఉంచుతుంది: ఫలితం మీరు పేర్కొన్న ఫైల్లపై ఆధారపడి ఉంటుంది, వర్క్స్టేషన్ యాదృచ్ఛికంగా నమ్మే దానిపై కాదు. OpenSSL ధృవీకరణ సూచన ఈ ఎంపికలను మరియు అవి ఉత్పత్తి చేసే నిర్ధారణను పత్రీకరిస్తుంది.

ధృవీకరణ విజయవంతమైనప్పుడు -show_chain నిర్మించిన చైన్ను ముద్రిస్తుంది, ఇది మార్గం మీరు ఉద్దేశించినదేనని నిర్ధారించడానికి ఉపయోగపడుతుంది. అది విఫలమైనప్పుడు, నివేదించిన లోతు మరియు subjectను ఉంచుకోండి; ఆ రెండు ఫీల్డ్లు తదుపరి పాఠకుడికి ఏ సర్టిఫికెట్ను పరిశీలించాలో చెబుతాయి.

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

తనిఖీ ఏమి నిరూపిస్తుంది మరియు ఏమి విడిచిపెడుతుంది

ఇది మీరు అందించిన విశ్వాస ఫైల్కు వ్యతిరేకంగా మార్గం మరియు ప్రయోజన తనిఖీ. HTTPS పేరు తనిఖీకి తగిన ఎంపిక ద్వారా ఆశించిన హోస్ట్నామ్ను జోడించండి; VPN కనెక్షన్ కోసం క్లయింట్ యొక్క కాన్ఫిగర్ చేసిన గుర్తింపు తనిఖీలను ఉంచి, ఆ క్లయింట్ నిజంగా చదివే విశ్వాస పదార్థాన్ని ఉపయోగించండి.

సర్వర్ పంపేది అభ్యర్థుల సమూహం, మీ క్లయింట్ చివరికి నిర్మించే మార్గం కాదు. స్థానిక విశ్వాసం మరియు లైబ్రరీ నిర్మాణ నియమాలు రెండూ ఫలితాన్ని రూపొందిస్తాయి, అందుకే అదే ప్రతిస్పందన ఒక యంత్రంలో ధృవీకరించబడి మరొకదానిలో విఫలం కావచ్చు. ఒకేలాంటి మూల్యాంకనాన్ని ఊహించే ముందు విఫలమవుతున్న క్లయింట్ యొక్క నిర్వహిత విశ్వాస నిల్వను మరియు TLS అమలును పనిచేస్తున్న క్లయింట్తో పోల్చండి. అక్కడి భేదం „ఈ ల్యాప్టాప్లో మాత్రమే విఫలమవుతుంది“ అనే అనేక నివేదికలను వివరిస్తుంది.

ప్రతి సర్టిఫికెట్ విండోను ఒక్కొక్కటిగా కాకుండా సమూహంగా చూడటానికి, వాటిని ఇలా ముద్రించండి:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

ఆ రెండవ ఆదేశం ప్రతి ఫైల్ను చేతితో డీకోడ్ చేయకుండా subjectలు మరియు జారీచేసినవారిని జాబితా చేస్తుంది, అలా లీఫ్ ఇంకా బాగానే కనిపిస్తున్నప్పుడు తేదీ దాటిన మధ్యవర్తి సర్టిఫికెట్ను మీరు గుర్తిస్తారు.

ధృవీకరణను బలహీనపరచకుండా మార్గాన్ని సరిచేయండి

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

మూలం నిర్వహణ ఒక గమనికకు అర్హం, ఎందుకంటే సారాంశాలు దాన్ని తరచుగా అతిగా చెబుతాయి. RFC 5280 యాంకర్ను భవిష్యత్ మార్గానికి వెలుపల ఉన్న ఇన్పుట్గా పరిగణిస్తుంది, అయితే OpenSSL తన మూల CA సర్టిఫికెట్ను కలిగి ఉన్న చెల్లుబాటు తనిఖీలను పత్రీకరిస్తుంది. రెండు ప్రకటనలు వాటి స్వంత వ్యవస్థలకు నిజం; ఒక లైబ్రరీ యొక్క మూల-గడువు ప్రవర్తనను ప్రతి క్లయింట్కు సాధారణీకరించడం విశ్వాసంతో కూడిన తప్పు సమాధానాలను ఇస్తుంది.

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