PKCS12, PEM లేదా DER: VPN క్లయింట్కు నిజంగా ఏమి కావాలి
ప్యాకేజింగ్ మీ క్లయింట్ గుర్తింపును దిగుమతి చేస్తుందో లేదో నిర్ణయిస్తుంది, అది విశ్వసనీయమో కాదో కాదు. PKCS12, PEM, DER లను పోల్చి, ఆపై ధృవీకరించండి.
సర్టిఫికెట్ చర్చల్లో రెండు వాదనలు తిరుగుతుంటాయి. మొదటిది .p12 బలమైన ఎంపిక అని, .pem సడలినది అని; రెండవది, ఒక టెక్స్ట్ ఫైల్ను మీరు చదవగలరు కాబట్టి దాన్ని పంపడం సురక్షితం అని. వాటిలో ఏదీ ఒక నిమిషం పరిశీలనను తట్టుకోదు.
PKCS12, PEM, DER లు సర్టిఫికెట్ వస్తువులు ఎలా ప్యాక్ చేయబడి ఎన్కోడ్ చేయబడతాయో వివరిస్తాయి. ఎదుటివారు ఎవరు, జారీచేసినవారు విశ్వసనీయులా, ఫైల్కు పాస్వర్డ్ అవసరమా అనేది అవి నిర్ణయించవు.
క్లయింట్ ఏమి అంగీకరిస్తుంది అనేది అనుకూలత ప్రశ్న. ఫైల్లో ఏమి ఉంది అనేది గుర్తింపు ప్రశ్న. వాటిని వేరుగా ఉంచండి, అప్పుడు చాలా దిగుమతి లోపాలు మిస్టరీగా ఉండవు.
మూడు కంటైనర్లు, ఒకే వస్తు నమూనా
మీ దగ్గర నిజంగా ఉన్నదానితో ప్రారంభించండి. సర్టిఫికెట్ అనేది పబ్లిక్ కీ గురించిన సంతకం చేసిన ప్రకటన. ప్రైవేట్ కీ అనేది ఆ కీని మీరు నియంత్రిస్తున్నారని నిరూపించే ప్రత్యేక పదార్థం. చైన్ అనేది మీ సర్టిఫికెట్ను క్లయింట్ విశ్వసించే రూట్తో కలిపే జారీచేసేవారి సముదాయం. ప్యాకేజింగ్ ఏదైనా ఈ మూడూ ఉంటాయి.
PKCS12 ఫైల్, సాధారణంగా .p12 లేదా .pfx, RFC 7292లో నిర్వచించిన కంటైనర్; ఇది ప్రైవేట్ కీ, ఒకటి లేదా అంతకంటే ఎక్కువ సర్టిఫికెట్లు మరియు చైన్ను ఒకే పాస్వర్డ్ రక్షిత బ్లాబ్లో, గుర్తింపును పేర్కొనే మారుపేరుతో మోసుకెళ్లగలదు. PEM ఫైల్ అనేది RFC 7468లో నిర్వచించిన టెక్స్ట్ ఫ్రేమింగ్: BEGIN మరియు END పంక్తుల మధ్య base64 బాడీ, ఒక ఫైల్ వరుసగా అనేక బ్లాకులను ఉంచగలదు. DER అనేది అదే ASN.1 నిర్మాణాల బైనరీ ఎన్కోడింగ్, PEM బాడీ అంటే base64తో చుట్టబడిన DER మాత్రమే.
ఆ చివరి వాక్యమే గుర్తుంచుకోదగినది. PEM ను DER గా మార్చడం ర్యాపింగ్ను తిరిగి రాస్తుంది, కంటెంట్ను కాదు, తిరిగి మార్చితే అసలు బైట్లే వస్తాయి.
| Container | Can hold | Does not decide |
|---|---|---|
| PKCS12 (.p12, .pfx) | Key, leaf certificate, chain, alias, password | Which root the client trusts |
| PEM (.pem, .crt, .cer) | Any number of base64 blocks | Whether the private key is present |
| DER (.der, .cer) | One binary structure | The object type, whatever the extension says |
ఎన్కోడింగ్ అంటే ఎన్క్రిప్షన్ కాదు
Base64 ఒక రవాణా అక్షరమాల. అది ఏమీ దాచదు, ఎవరైనా షెల్లో PEM బ్లాక్ను డీకోడ్ చేయగలరు. DER ఫైల్ బైనరీ మరియు సమానంగా బహిరంగం. ఆ రెండు లక్షణాలు రక్షణ కావు, పాస్వర్డ్ ఉందని కూడా అవి సూచించవు.
నిజమైన రక్షణ కీ పదార్థంలో ఉంటుంది. PKCS12 బండిల్ తన కంటెంట్ను పాస్వర్డ్ నుండి తీసిన కీతో ఎన్క్రిప్ట్ చేయగలదు. PEM ప్రైవేట్ కీని పాత హెడర్ బ్లాక్తో ఎన్క్రిప్ట్ చేయవచ్చు లేదా PKCS#8 EncryptedPrivateKeyInfo లో ఉంచవచ్చు. సర్టిఫికెట్ ఒంటరిగా ఏ రహస్యాన్ని కలిగి ఉండదు, అందుకే సర్టిఫికెట్ మాత్రమే ఉత్పత్తి చేసిన ఎక్స్పోర్ట్, ఏ ఫార్మాట్లో చుట్టినా క్లయింట్ ప్రామాణీకరించలేకపోతుంది.
ఎక్స్టెన్షన్ ఒక సూచన, ఒప్పందం కాదు. .cer మరియు .crt తో ముగిసే ఫైల్లు రెండు ఎన్కోడింగుల్లోనూ కనిపిస్తాయి, పరికరాలు DER సర్టిఫికెట్లను .pem పేర్లతో ఎగుమతి చేయడం చాలా సాధారణం, కాబట్టి సఫిక్స్ నుండి ఊహించడం మధ్యాహ్నాన్ని వృథా చేస్తుంది. బదులుగా మొదటి బైట్లను చదవండి: PEM ఫైల్ BEGIN పంక్తితో తెరుచుకుంటుంది, DER 0x30 తో మొదలవుతుంది ఎందుకంటే బయటి నిర్మాణం SEQUENCE.
దిగుమతి నిజంగా ఎందుకు విఫలమవుతుంది
క్లయింట్ లోప సందేశాలు అనేక వేర్వేరు సమస్యలను చెల్లని సర్టిఫికెట్ గురించిన ఒకే వాక్యంగా కుదించుతాయి, కాబట్టి వాటిని కారణం ప్రకారం వేరు చేయండి. అత్యంత సాధారణమైనది ఎన్కోడింగ్ అసమతుల్యత: PEM ను పార్స్ చేసే క్లయింట్ DER ఫైల్పై పార్స్ లోపాన్ని ఇస్తుంది, పరిష్కారం కొత్త సర్టిఫికెట్ కాదు, మార్పిడి. రెండవది కీ లేకపోవడం, సర్టిఫికెట్ సరిగ్గా ఉంటుంది కానీ గుర్తింపు నిరూపించలేము. మూడవది చైన్, మధ్యవర్తి లేని బండిల్ దిగుమతి డైలాగ్లో సరిగ్గా కనిపిస్తుంది కానీ హ్యాండ్షేక్ సమయంలో విఫలమవుతుంది.
ఎన్క్రిప్షన్ పారామితులు నాల్గవదాన్ని కలిగిస్తాయి, అది తప్పు పాస్వర్డ్ లాగానే కనిపిస్తుంది. పాత పరికరాలు PKCS12 ఫైళ్లను RC2-40 మరియు 3DES తో ఎగుమతి చేశాయి, లెగసీ ప్రొవైడర్ లోడ్ కాకపోతే OpenSSL 3 వాటిని నిరాకరిస్తుంది. AES-256-CBC మరియు PBKDF2 తో పరికరం నుండి తిరిగి ఎగుమతి చేయడమే శాశ్వత పరిష్కారం. ఒక ఫైల్ కోసం క్లయింట్ మెషీన్లో లెగసీ సైఫర్లను శాశ్వతంగా ఆన్ చేయడం చెడ్డ వ్యాపారం.
ఐదవది అస్పష్టత. రెండు కీలు మరియు రెండు సర్టిఫికెట్లు ఉన్న కంటైనర్, లేదా మూడు CERTIFICATE బ్లాకులు ఉన్న PEM ఫైల్, క్లయింట్ను ఎంచుకోవాలని బలవంతం చేస్తుంది, దాని ఎంపిక తరచుగా మొదటి అంశమే. సొరంగం తప్పు గుర్తింపుతో వచ్చినప్పుడు, అదే సాధారణ కారణం.
మార్చే ముందు పరిశీలించండి
రహస్యాలను ప్రింట్ చేయకుండా నిర్మాణాన్ని చదవండి. openssl pkcs12 -in bundle.p12 -info -noout కీ మరియు సర్టిఫికెట్ అవుట్పుట్ను అణచివేస్తూ ఎన్క్రిప్షన్ అల్గోరిథమ్లను మరియు మారుపేర్లను నివేదిస్తుంది, మరియు openssl-pkcs12 మాన్యువల్ ఫ్లాగ్లను వివరిస్తుంది. -noout తీసివేసి -nodes జోడించడం మీరు నిల్వ చేయాలనుకునే ఫైళ్లను ఉత్పత్తి చేయడానికి, త్వరిత పరిశీలనకు కాదు, ఎందుకంటే అది ప్రైవేట్ కీని స్పష్టంగా రాస్తుంది.
సర్టిఫికెట్ కోసం, openssl x509 -in cert.pem -noout -subject -issuer -dates దిగుమతి డైలాగ్ సమాధానం ఇవ్వని దానికి సమాధానం ఇస్తుంది, మరియు -ext subjectAltName జోడిస్తే సర్టిఫికెట్ నిజంగా ఏ పేర్లకు చెల్లుబాటు అవుతుందో చూపిస్తుంది. ఫైల్ DER అయితే, -inform DER జోడించండి; ఆ ఒక్క ఫ్లాగ్ చాలా లోడ్ కాలేని లోపాలను పరిష్కరిస్తుంది.
కీని సర్టిఫికెట్తో సరిపోల్చడం యాంత్రికం, ఏ దిగుమతికైనా ముందు చేయదగినది:
openssl x509 -in cert.pem -noout -pubkey | openssl sha256openssl pkey -in key.pem -pubout | openssl sha256
ఒకేలాంటి డైజెస్ట్లు ఆ జోడీ ఒకదానికొకటి చెందినదని అర్థం. వేర్వేరు డైజెస్ట్లు మీ దగ్గర తప్పు కీ ఉందని అర్థం, ఎంత ఫార్మాట్ మార్పిడి అయినా దాన్ని మార్చదు.
ఫార్మాట్ ఎప్పుడూ మార్చనివి
విశ్వాస నిర్ణయాలు కంటైనర్ పైనే జరుగుతాయి. క్లయింట్ చైన్ను తన స్టోర్లోని రూట్ వరకు నడిచి, చెల్లుబాటు విండోను తనిఖీ చేస్తుంది, క్లయింట్ ప్రామాణీకరణ కోసం పొడిగించిన కీ వినియోగాన్ని తనిఖీ చేస్తుంది, మరియు సర్వర్ వైపు తాను డయల్ చేసిన పేరు సర్టిఫికెట్లో ఉందో లేదో తనిఖీ చేస్తుంది. ఆ దశల్లో ఏదీ ఫైల్ ఎక్స్టెన్షన్ను చదవదు.
అందుకే లోపం మాయమయ్యే వరకు ఫైల్ను పేరు మార్చడం సమయాన్ని కోల్పోయే నమ్మకమైన మార్గం. దిగుమతి విజయవంతమవుతుంది, గుర్తింపు ఇంకా తప్పే ఉంటుంది, మరియు వైఫల్యం హ్యాండ్షేక్ సమయంలో మళ్లీ కనిపిస్తుంది, అక్కడ సందేశం తక్కువ సహాయకం. రెండు సంవత్సరాల క్రితం ఎగుమతి చేసిన బండిల్ శుభ్రంగా దిగుమతి అయినా ఇంకా తిరస్కరించబడడానికి కూడా ఇదే కారణం: గడువు తేదీ ఫైల్ పేరులో కాదు, సర్టిఫికెట్ లోపల ప్రయాణించింది.
పునఃపనిని నివారించే క్రమం
క్లయింట్ డాక్యుమెంటేషన్ను ఏ ఎన్కోడింగ్లను అంగీకరిస్తుంది మరియు క్లయింట్ గుర్తింపు కోసం ఏ కంటైనర్ ఆశిస్తుంది అని అడగండి, తర్వాత మీకు ఇచ్చినదాన్ని చూడండి. క్లయింట్కు ఒకే దిగుమతి చేయగల గుర్తింపు కావాలి మరియు మీ దగ్గర విడివిడి PEM ఫైళ్లు ఉంటే, మీరు నియంత్రించే పాస్వర్డ్తో బండిల్ను ఒకసారి నిర్మించి మూలాలను ఉంచండి. PEM కావాలంటే, కీ మరియు చైన్ను వేరు చేయండి, తర్వాత మీ బృందం ఇప్పటికే ఉపయోగించే ఏదైనా క్రెడెన్షియల్ నిర్వహణ ప్రక్రియ ద్వారా మధ్యంతర ఫైళ్లను తొలగించండి.
దిగుమతి తర్వాత, డైలాగ్ను కాదు గుర్తింపును ధృవీకరించండి: సబ్జెక్ట్, జారీచేసినవారు, గడువు, మరియు క్లయింట్ చూపించే పేరు. జాబితాలోని స్నేహపూర్వక పేరు ఒక లేబుల్, ధృవీకరించిన గుర్తింపు కాదు. సొరంగం తర్వాత విఫలమైతే, మీరు ప్యాకేజింగ్ కాదు, ప్రామాణీకరణ లేదా రూటింగ్ డీబగ్ చేస్తున్నారు, అది చాలా చిన్న సంభాషణ.