పాత P12 OpenSSL 3 లో విఫలమవుతుంది: తప్పు పాస్వర్డా లేదా పాత సైఫరా?
OpenSSL 3 తెరవడానికి నిరాకరించే పాత RC2 బండిల్ నుండి తప్పుగా టైప్ చేసిన పాస్ఫ్రేజ్ను వేరు చేసి, కీ రక్షణను తీసివేయకుండా ఫైల్ను మళ్లీ సీల్ చేయండి.
దిగుమతి డైలాగ్ మీ పాస్వర్డ్ను తీసుకొని, కొద్దిసేపు తిరిగి, బండిల్ను చదవలేమని చెబుతుంది. మీరు పాస్ఫ్రేజ్ను తప్పుగా టైప్ చేశారా లేదా క్లయింట్ ఇక ఇవ్వని సైఫర్తో ఫైల్ సీల్ చేయబడిందా అని ఆ సందేశంలో ఏమీ చెప్పదు. ఇవి వేర్వేరు వైఫల్యాలు, వేర్వేరు సరిదిద్దులు, తప్పు ఎంపిక క్లయింట్ తగ్గింపుకు దారితీస్తుంది, అది నిర్ణయాన్ని వాయిదా వేస్తుంది. క్లయింట్ ఏ దశలో ఆగుతుందో గమనించడం వాటిని సుమారు ఒక నిమిషంలో వేరు చేస్తుంది.
డైలాగ్ మరియు సర్టిఫికెట్ జాబితా మధ్య ఏమి జరుగుతుంది
.p12 ఫైల్ ఒక కంటైనర్, సర్టిఫికెట్ కాదు. లోపల ఒకటి లేదా ఎక్కువ సర్టిఫికెట్ సంచులు మరియు మీ పాస్వర్డ్ నుండి పొందిన కీతో ఎన్క్రిప్ట్ చేయబడిన ప్రైవేట్ కీ సంచి, అలాగే మొత్తం ఫైల్పై MAC అనే సమగ్రతా తనిఖీ ఉంటాయి. దాన్ని తెరవడం అంటే ఆ MAC ను ధృవీకరించడం, కీ సంచిని డీక్రిప్ట్ చేయడం మరియు సర్టిఫికెట్ను బయటకు వచ్చే కీతో సరిపోల్చడం.
పాస్వర్డ్ సమస్య MAC దశలో వస్తుంది. సైఫర్ సమస్య తర్వాత వస్తుంది, కీ సంచిని విప్పాల్సి వచ్చినప్పుడు మరియు విప్పే బిల్డ్లో ఫైల్లో పేర్కొన్న అల్గారిథమ్ అమలు లేనప్పుడు.
రెండవ సందర్భం నేటి వ్యవస్థల్లో సాధారణం ఎందుకంటే OpenSSL 3 పాత అల్గారిథమ్ల సమూహాన్ని ఐచ్ఛిక legacy provider లోకి మార్చింది. OpenSSL 1.x ఎగుమతి చేసిన బండిల్లు సాధారణంగా సర్టిఫికెట్లను 40-బిట్ RC2 తో, ప్రైవేట్ కీని మూడు కీల Triple DES తో సీల్ చేసేవి. డిఫాల్ట్ OpenSSL 3 బిల్డ్ ఇప్పటికీ మీ సరైన పాస్వర్డ్తో MAC ను ధృవీకరించి తర్వాత సంచిపై విఫలమవుతుంది, కాబట్టి పాస్వర్డ్ ఎప్పుడూ తప్పు కాదు, మళ్లీ టైప్ చేయడం ఏమీ మార్చదు.
కీని బయటకు రాయకుండా కంటైనర్ చదవండి
మీ యంత్రంలోని OpenSSL బిల్డ్ను ఫైల్ను విశ్లేషించి అది ఎక్కడ వదిలేస్తుందో చదవమని అడగండి. అవుట్పుట్ ఫైల్ లేకుండా తనిఖీ కీని డిస్క్లో ఎన్క్రిప్ట్ చేసినట్లే ఉంచుతుంది, పంచుకున్న హోస్ట్లో ఈ దశ సురక్షితం కావడానికి అదే ఏకైక కారణం.
openssl pkcs12 -in vpn-identity.p12 -info -nooutసరైన పాస్వర్డ్ ఉన్న పాత బండిల్లో ఇది సంచి లక్షణాలను ముద్రించి తర్వాత digital envelope routines::unsupported తో ఆగుతుంది. తప్పు పాస్వర్డ్తో ఏ సంచి చదవకముందే Mac verify error: invalid password? వస్తుంది. రెండు సందేశాలు వ్యతిరేక దిశలను చూపుతాయి, క్లయింట్ దాచిన సమాచారం అదే.
వైఫల్యం మద్దతు లేని అల్గారిథమ్ దైతే, అదే ఆదేశాన్ని -legacy చేర్చి మరేదీ మార్చకుండా మళ్లీ అమలు చేయండి. ఆ ఫ్లాగ్ legacy provider ను ఆ ఒక ప్రక్రియకు మాత్రమే లోడ్ చేస్తుంది. ఇది VPN క్లయింట్ను పాత బండిల్లను విశ్లేషించమని బలవంతం చేయదు, వ్యవస్థ వ్యాప్త క్రిప్టో విధానాన్ని తాకదు, ఫైల్ ఇంకా మార్చాల్సి ఉండటం వల్ల ఇది మరమ్మతు కాదు, కొలత.
ఏ లోపం ఏ దశ
చిన్న పట్టిక మూడు ఫలితాలను వేరుగా ఉంచుతుంది, డైలాగ్ ఎక్కడ కనిపించిందనే దానికంటే పదాలు ముఖ్యం.
| Text you see | Stage | What it tells you |
|---|---|---|
Mac verify error: invalid password? | Integrity check | Passphrase or cached credential, not the cipher |
digital envelope routines::unsupported | Bag decrypt | Algorithm missing from the default provider |
not enough data / header too long | Container format | Wrong encoding, edited file, or truncated download |
not enough data లేదా header too long వంటి వచనం మొదటి రెండు సమూహాలలో దేనిలోనూ రాదు. ఇది ఆకృతి సమస్య: .pem గా పేరు మార్చిన DER ఫైల్, పంక్తి ముగింపులను తిరిగి రాసిన ఎడిటర్ చెడగొట్టిన ప్రతి, లేదా అసంపూర్ణ డౌన్లోడ్. సైఫర్లను చూడటం ప్రారంభించకముందు జారీ చేసినవారు పంపిన చెక్సమ్తో పోల్చండి.
Mac verify error ను పాస్వర్డ్ గురించిన సాక్ష్యంగా మాత్రమే పరిగణించండి. మీరు టైప్ చేసిన దాని నుండి లెక్కించిన MAC నిల్వ చేసిన విలువతో సరిపోలడం లేదని అర్థం, ఇది టైపింగ్ పొరపాటు, మునుపటి దిగుమతి నుండి కాష్ చేసిన పాస్వర్డ్, లేదా మరో పాస్ఫ్రేజ్ కింద మళ్లీ ఎగుమతి చేసిన ఫైల్ వల్ల జరుగుతుంది. లోపలి అల్గారిథమ్లు పాతవా కాదా అనే దానిపై ఏమీ చెప్పదు.
క్లయింట్ నిజంగా తెరవగల బండిల్ నిర్మించండి
legacy పార్సర్ ఫైల్ ఆరోగ్యకరమని నిర్ధారించిన తర్వాత, శాశ్వత పరిష్కారం లక్ష్య క్లయింట్ మద్దతు ఇచ్చే అల్గారిథమ్లతో కూడిన ప్రత్యామ్నాయం: కీ మరియు సర్టిఫికెట్ సంచులకు AES-256-CBC, ఉత్పాదనకు SHA-256 తో PBKDF2, MAC కు SHA-256. మీ PKI నిర్వాహకుడు దాన్ని అదే కీ పదార్థం నుండి ఎగుమతి చేయగలరు, లోపలి సర్టిఫికెట్ మీ సర్వర్లు ఇప్పటికే నమ్ముతున్న సర్టిఫికెట్గానే ఉంటుంది.
స్థానికంగా మార్చాల్సి వస్తే, సంచులను మొదట కుమ్మరించడం బదులు మళ్లీ సీల్ చేయమని pkcs12 సాధనాన్ని అడగండి. రెండు పాస్ఫ్రేజ్లను ఫైల్ నుండి చదివి మీ షెల్ చరిత్ర నుండి దూరంగా ఉంచండి.
openssl pkcs12 -in vpn-identity.p12 -out vpn-identity-aes.p12 \
-keypbe AES-256-CBC -certpbe AES-256-CBC -macalg sha256 \
-passin file:old.pass -passout file:new.passవిజయవంతమైన మార్పిడి గడువు ముగింపు, కీ వినియోగం, ప్రైవేట్ కీ సరిపోలిక లేదా సర్వర్ జారీ చేసే గొలుసును నమ్ముతుందా అనే దానిపై ఏమీ చెప్పదు. తిరిగి ప్యాక్ చేయడం రవాణా మార్పు, పునరుద్ధరణ కాదు, వాటిలో ప్రతిదానికి దాని స్వంత తనిఖీ ఇంకా అవసరం.
క్లయింట్ ఫైల్ను అంగీకరించిందనే కారణంతో రక్షణ లేని మధ్యంతర కీని రాసే లేదా ఖాళీ అవుట్పుట్ పాస్వర్డ్ ఉంచే ఏ విధానాన్నైనా దాటవేయండి. రక్షణ తీసివేసిన చదవగల బండిల్ మీరు ప్రారంభించిన దిగుమతి వైఫల్యం కంటే చెడ్డ ఫలితం.
మీరు నిర్మించిన ఫైల్ను క్లయింట్ దిగుమతి చేసుకుందని నిర్ధారించండి
టెర్మినల్లో శుభ్రమైన విశ్లేషణ కంటైనర్ చెల్లుబాటు అని రుజువు చేస్తుంది. క్లయింట్ దాన్ని ఎంచుకుందని రుజువు చేయదు, ఎందుకంటే మిగిలిన ప్రొఫైల్ పాత ఫైల్ను చూపుతూ ఉండవచ్చు, కొన్ని క్లయింట్లు దిగుమతి చేసిన గుర్తింపును మీరు ఎంచుకోని పేరుతో కాష్ చేస్తాయి.
మీరు దిగుమతి చేయబోయే గుర్తింపును ముద్రించి, క్లయింట్ తన సర్టిఫికెట్ వీక్షణలో చూపే దానితో పోల్చండి.
openssl pkcs12 -in vpn-identity-aes.p12 -clcerts -nokeys -passin file:new.pass \
| openssl x509 -noout -subject -dates -fingerprint -sha256మొదట పాత ప్రొఫైల్ నమోదును తొలగించి, తర్వాత దిగుమతి చేయండి. క్లయింట్ లోడ్ చేసిన విషయాన్ని లేదా వేలిముద్రను లాగ్ చేస్తే, పై పంక్తితో సరిపోల్చండి; అది స్నేహపూర్వక పేరును మాత్రమే చూపితే, దానికి బదులు గడువు తేదీని తనిఖీ చేయండి, ఎందుకంటే దాన్ని అదే జారీ చేసినవారి మరో సర్టిఫికెట్తో గందరగోళపరచడం కష్టం.
PKCS12 సూచన ఇక్కడ ఉపయోగించిన provider, పాస్ఫ్రేజ్ మరియు అవుట్పుట్ ఎంపికలను జాబితా చేస్తుంది. legacy provider ను క్లయింట్ వాతావరణం వెలుపల ఉంచడమే ముఖ్యం: దానితో కొలవండి, అది లేకుండా పంపండి, ప్రైవేట్ కీని డిస్క్లో రక్షితంగా ఉంచండి.