strongSwan send_cert: IKE సర్టిఫికెట్ ఎప్పుడు పంపబడుతుంది

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

send_cert నిజంగా ఏమి నియంత్రిస్తుంది

సర్టిఫికెట్ ద్వారా ప్రామాణీకరణకు peer యొక్క చివరి-ఎంటిటీ సర్టిఫికెట్ IKE మార్పిడి లేదా ముందస్తు తయారీ ద్వారా మరో వైపుకు చేరాలి. swanctl లో కనెక్షన్ సెట్టింగ్ send_cert ఈ చివరి బిందువు తన సర్టిఫికెట్ పేలోడ్ను చేర్చుతుందో లేదో నిర్ణయిస్తుంది: ఎప్పుడూ కాదు, ఎల్లప్పుడూ లేదా ifasked. డిఫాల్ట్ ifasked దాన్ని peer నుండి వచ్చిన సర్టిఫికెట్ అభ్యర్థనకు సమాధానంగా పంపుతుంది. సర్టిఫికెట్ అడగడం వేరే సెట్టింగ్, ఎందుకంటే మరో వైపు నుండి దాని సర్టిఫికెట్ అడగడం తనది అందించడంతో సమానం కాదు.

పాత ipsec.conf మోహరింపులు leftsendcert మరియు rightsendcert ఉపయోగించాయి, ఆ పేర్లు స్థానిక మరియు దూర పాత్రలకు సరిపోతాయి, నేరుగా swanctl కు కాదు.

కనెక్షన్ మార్చే ముందు ఒక ప్రయత్నాన్ని చదవండి

ఒక నియంత్రిత ప్రయత్నం నుండి నిర్ధారణ చేయండి, సర్టిఫికెట్లు చేరి ఉన్నాయనే సాధారణ అభిప్రాయం నుండి కాదు. విధానం మరియు క్రియాశీల అనుబంధం రెండింటినీ పరిశీలించవచ్చు.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan --since "10 min ago" | grep -iE "cert|CERT"

కనెక్షన్ జాబితా కాన్ఫిగర్ చేసిన send_cert విలువను చూపుతుంది, SA జాబితా ఏ కనెక్షన్లు నిజంగా లేచాయో చూపుతుంది. లాగ్ చర్చా వివరాలను జోడిస్తుంది: సర్టిఫికెట్ అభ్యర్థన అందిందో లేదో మరియు సర్టిఫికెట్ పేలోడ్ బయటకు వెళ్ళిందో లేదో. సాధారణ ప్రామాణీకరణ వైఫల్యం డెలివరీ సమస్యను సూచించదు, కాబట్టి ఏదైనా నిర్ణయించే ముందు నిర్దిష్ట మార్పిడిని వెతకండి. ప్రయత్నం యొక్క సమయ ముద్రను నమోదు చేయండి, లాగ్ విండో మొత్తం హ్యాండ్షేక్ను కవర్ చేసేలా.

గ్రహీత నమ్మకం వేరే నిర్ణయం

డెలివరీ మరియు నమ్మకం వేర్వేరు లక్షణాలు, ఒకటి సరిచేయడం మరొకటి సరిచేయదు. గ్రహీత వద్ద ఉద్దేశించిన నమ్మక యాంకర్ ఉండాలి, ఉపయోగించదగిన గొలుసు పొందాలి మరియు ఆశించిన peer గుర్తింపుతో సరిపోలాలి. తన మధ్యవర్తి సర్టిఫికెట్ లేకుండా వచ్చే చివరి-ఎంటిటీ సర్టిఫికెట్ కఠిన గొలుసు తనిఖీలో ఇప్పటికీ విఫలమవుతుంది. దీనికి విరుద్ధంగా, CA ఇన్స్టాల్ చేయడం peer ను తన సర్టిఫికెట్ పంపమని అసలు బలవంతం చేయదు.

openssl x509 -in peer-chain.pem -noout -subject -issuer -dates

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

సాక్ష్యంతో మాత్రమే పంపేవారిని మార్చండి

సర్టిఫికెట్ ఎప్పుడూ పంపబడలేదని మరియు గ్రహీత నిజంగా దాన్ని అడిగాడని లాగ్ చూపినప్పుడు, send_cert ను always గా సెట్ చేయడం ఆ కనెక్షన్కు సమర్థనీయమైన మార్పు. దాన్ని swanctl కాన్ఫిగరేషన్లో వర్తించండి, కనెక్షన్లను మళ్లీ లోడ్ చేయండి మరియు ఉన్న SA ను తిరిగి ఉపయోగించకుండా కొత్త సెషన్ ఏర్పాటు చేయండి. సర్టిఫికెట్ పేలోడ్ ఇప్పుడు కనిపిస్తుందని మరియు గ్రహీత దాన్ని ఉద్దేశించిన యాంకర్కు వ్యతిరేకంగా అంగీకరిస్తాడని నిర్ధారించండి. ఏమీ మారకపోతే, లోపం నమ్మకం వైపే ఉంది మరియు పంపేవారి సెట్టింగ్ కారణం కాదు.

గమనించిన మార్పిడి, యాంకర్ మరియు దాని ఫలిత ధృవీకరణను మార్పు రికార్డులో రాయండి. ఈ పదాలలో వివరించలేని సర్టిఫికెట్ సరిదిద్దడం యాదృచ్ఛికం.