Access Server లో వెబ్ సర్టిఫికెట్ లోపం: ఖాళీ CA బండిల్
ఖాళీ ca_bundle విలువ లేదా దెబ్బతిన్న PEM అడ్మిన్ ఇంటర్ఫేస్ను ఆపుతుంది. పునఃప్రారంభానికి ముందు సర్టిఫికెట్, కీ, చైన్ను ఒక సెట్గా ధృవీకరించండి, VPN PKI ని తాకవద్దు.
DNS సరిగ్గా పరిష్కరించబడుతుండగా లోడ్ కాని వెబ్ లాగిన్ పేజీ సాధారణంగా DNS సమస్య కాదు. సేవా లాగ్ ఖాళీ సర్టిఫికెట్ బండిల్ మార్గం లేదా వెబ్ సర్టిఫికెట్ మరియు ప్రైవేట్ కీకి PEM పార్సింగ్ వైఫల్యాన్ని పేర్కొంటే, HTTPS శ్రోతకు ఉపయోగకరమైన పదార్థం లేదు, పేరు పరిష్కారం సహాయపడదు. మరమ్మత్తు మూడు కాన్ఫిగరేషన్ కీలలో ఉంది, ఒక VPN క్లయింట్ సర్టిఫికెట్ కూడా మళ్లీ జారీ చేయాల్సిన అవసరం లేదు.
మూడు కీలు నిజంగా ఏమి సూచిస్తాయి
అనుకూల వెబ్ సర్టిఫికెట్ సెట్ cs.cert, cs.priv_key మరియు cs.ca_bundle ద్వారా వివరించబడుతుంది. ప్రతి ఒక్కటి ఫైల్ మార్గాన్ని నిల్వ చేస్తుంది, వెబ్ సేవ మూడింటినీ కలిపి ఉపయోగిస్తుంది. తప్పు కీ ఉన్న సర్టిఫికెట్ లేదా నిజానికి ఆకు సర్టిఫికెట్ అయిన చైన్ ఫైల్ ఖాళీ విలువలా విఫలమవుతుంది.
ఈ కీలు Admin మరియు Client వెబ్ ఇంటర్ఫేస్కు చెందినవి. అవి VPN క్లయింట్లకు సర్టిఫికెట్ జారీ చేసే PKI నుండి వేరుగా ఉంటాయి, కాబట్టి మార్పిడికి ప్రొఫైల్స్, సర్వర్ కీ లేదా సర్టిఫికెట్ అథారిటీని తాకాల్సిన అవసరం లేదు. మొత్తం PKI ని తిరిగి నిర్మించడం ఇక్కడ అత్యంత ఖరీదైన తప్పు.
ఒక భేదం సమయాన్ని ఆదా చేస్తుంది: స్పష్టంగా ఖాళీ అనుకూల విలువ ఎలాంటి ఓవర్రైడ్ లేని స్థితితో సమానం కాదు. మొదటిది పార్సర్కు ఖాళీ మార్గాన్ని ఇస్తుంది, లాగ్ లైన్ అదే చెబుతుంది. రెండోది Access Server ను దాని సొంత పదార్థంపైనే ఉంచుతుంది.
ఉన్న ఫైల్ ఇంకా ఎందుకు పార్స్ కాదు
పార్సర్ ఫైల్ పేరును కాదు, ఫైల్ లోపలి లేబుల్ బ్లాకులను చదువుతుంది. ప్రైవేట్ కీ ఉన్న .crt, ఒకే బ్లాక్గా రాసిన చైన్ లేదా చివరి లైన్ కత్తిరించిన ఫైల్ తిరస్కరించబడతాయి. RFC 7468 ఆ లేబుళ్లను నిర్వచించడం, తదుపరి వస్తువు రకాన్ని చెప్పే ఏకైక మార్గం అవే కాబట్టి.
వస్తువులను పరిశీలించండి, పొడిగింపులను కాదు. Linux లో openssl x509 -noout -subject -issuer -in server.pem మరియు openssl pkey -noout -check -in key.pem రెండు ముఖ్యమైన ప్రశ్నలకు సమాధానం ఇస్తాయి, రెండింటి మాడ్యులస్ లేదా పబ్లిక్ కీ పోల్చడం అవి జత అని నిరూపిస్తుంది. ప్రైవేట్ కీ అవుట్పుట్ను టికెట్లు మరియు చాట్ లాగ్ల నుండి దూరంగా ఉంచండి.
ఖాళీ మార్గం దెబ్బతిన్న ఫైల్తో సమానంగా అనుమానించదగినది, ఎందుకంటే రెండూ అస్పష్టమైన తదుపరి లోపాలను ఇస్తాయి. లాగ్ బండిల్ మార్గం ఖాళీ అని చెబితే, ఫైల్ను డీబగ్ చేసే ముందు నిల్వ చేసిన విలువను చదవండి.
ఉద్దేశపూర్వకంగా ఫాల్బ్యాక్కు తిరిగి వెళ్లండి
Access Server CLI లో మూడు మార్గాలను ఆర్గ్యుమెంట్లుగా తీసుకుని, సెట్ ఉపయోగకరమా అని నివేదించే తనిఖీ ఉంది. కింది మార్గాలు ఉదాహరణలు; వాటిని హోస్ట్పై రక్షిత స్థానాలతో భర్తీ చేయండి.
sacli --ca_bundle=/secure/webcerts/chain.pem \
--cert=/secure/webcerts/server.pem \
--priv_key=/secure/webcerts/key.pem TestWebCertsనడుస్తున్న సేవను తాకే ముందు ఫలితాన్ని చదవండి, ఆ తర్వాత విలువలను దిగుమతి చేసి ఇన్స్టాల్ చేసిన సంస్కరణకు పత్రీకరించిన కార్యకలాపంతో వర్తింపజేయండి. అధికారిక CLI ట్యుటోరియల్ ధృవీకరణ, దిగుమతి మరియు అనువర్తన దశను కవర్ చేస్తుంది, దాని సంస్కరణ ఏ సారాంశం కంటే ముఖ్యం.
వినియోగదారులు నిజంగా టైప్ చేసే పేరును ధృవీకరించండి
అనుకూల పదార్థం దెబ్బతిని, చెల్లుబాటు అయ్యే అంతర్నిర్మిత ఫాల్బ్యాక్ ఇంకా ఉంటే, పత్రీకరించిన పునరుద్ధరణ మూడు ఓవర్రైడ్లను తీసివేసి Access Server ఆ ఫాల్బ్యాక్ను ఉపయోగించనివ్వడం. మొదట కన్సోల్ ప్రాప్యత మరియు ప్రస్తుత కాన్ఫిగరేషన్ కాపీని సిద్ధం చేయండి.
sacli ConfigDel --key "cs.cert"
sacli ConfigDel --key "cs.priv_key"
sacli ConfigDel --key "cs.ca_bundle"
# then the supported apply/restart step for this versionమొత్తం కాన్ఫిగరేషన్ డేటాబేస్ను తొలగించడం సర్టిఫికెట్ మరమ్మత్తు కాదు. ఆ మూడు కీలను లక్ష్యంగా చేసుకోండి, వర్తింపజేయండి మరియు వెబ్ ఇంటర్ఫేస్ స్పందిస్తుందని నిర్ధారించండి. web-ssl డైరెక్టరీలోని స్వయం-సంతకం చేసిన ఫైల్లు ఫాల్బ్యాక్ వనరు, పని ప్రదేశం కాదు.
ఫాల్బ్యాక్ అమలులోకి వచ్చిన తర్వాత బ్రౌజర్ వేరే సర్టిఫికెట్ చూపుతుందని ఆశించండి. అదే సరైన ఫలితం; మీ విశ్వసనీయ పరిపాలనా ప్రక్రియ ద్వారా ధృవీకరించండి.
విజయవంతమైన సైన్-ఇన్ తర్వాతే పునరుద్ధరణ పూర్తవుతుంది
TCP శ్రోత కనిపించినప్పుడు పునరుద్ధరణ ముగియదు. DNS పేరు, సర్టిఫికెట్ గుర్తింపు మరియు ఆ పేరు కోసం చైన్ను ధృవీకరించి, తర్వాత Admin మరియు Client ఇంటర్ఫేస్లను లోడ్ చేసి సైన్-ఇన్ పూర్తి చేయండి. పోర్ట్ తనిఖీ వాటిలో ఏదీ నిరూపించదు.
Access Server 3.1 మరియు తరువాతివి ప్రతి SNI హోస్ట్ పేరుకు వేర్వేరు వెబ్ సర్టిఫికెట్లను అందించగలవు. అలా కాన్ఫిగర్ చేస్తే, డిఫాల్ట్ కీలు మరియు పేరు-నిర్దిష్ట నమోదులు వేర్వేరు సెట్లు, IP చిరునామాతో పరీక్షించడం వినియోగదారులు పొందే దానికి భిన్నమైన సర్టిఫికెట్ను సులభంగా చూపుతుంది. విఫలమైన పేరు సెట్ను సరిచేసి ధృవీకరించి, సంఘటనను మూసివేసే ముందు సైన్-ఇన్ పరీక్షను పునరావృతం చేయండి.