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 ಅವನ್ನು legacy ಪೂರೈಕೆದಾರ ಲೋಡ್ ಆಗದಿದ್ದರೆ ನಿರಾಕರಿಸುತ್ತದೆ. ಸಾಧನದಿಂದ 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 ಸೇರಿಸಿ; ಆ ಒಂದು ಫ್ಲ್ಯಾಗ್ ಹೆಚ್ಚಿನ unable-to-load ದೋಷಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ.
ಕೀಲಿಯನ್ನು ಪ್ರಮಾಣಪತ್ರಕ್ಕೆ ಹೊಂದಿಸುವುದು ಯಾಂತ್ರಿಕ ಕೆಲಸ, ಮತ್ತು ಯಾವುದೇ ಆಮದಿಗೆ ಮೊದಲು ಮಾಡುವುದು ಯೋಗ್ಯ:
openssl x509 -in cert.pem -noout -pubkey | openssl sha256openssl pkey -in key.pem -pubout | openssl sha256
ಒಂದೇ ರೀತಿಯ ಡೈಜೆಸ್ಟ್ಗಳು ಜೋಡಿ ಒಟ್ಟಿಗಿದೆ ಎಂದು ಅರ್ಥ. ವಿಭಿನ್ನ ಡೈಜೆಸ್ಟ್ಗಳು ನಿಮ್ಮ ಬಳಿ ತಪ್ಪು ಕೀಲಿ ಇದೆ ಎಂದು ಅರ್ಥ, ಮತ್ತು ಯಾವುದೇ ಸ್ವರೂಪ ಪರಿವರ್ತನೆ ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ.
ಸ್ವರೂಪ ಎಂದಿಗೂ ಬದಲಿಸದ್ದು
ವಿಶ್ವಾಸದ ನಿರ್ಧಾರಗಳು ಕಂಟೇನರ್ನ ಮೇಲೆ ನಡೆಯುತ್ತವೆ. ಕ್ಲೈಂಟ್ ತನ್ನ ಸಂಗ್ರಹದಲ್ಲಿನ ಮೂಲದವರೆಗೆ ಸರಪಳಿಯನ್ನು ನಡೆದು, ಮಾನ್ಯತೆಯ ವಿಂಡೋ ಪರಿಶೀಲಿಸಿ, ಕ್ಲೈಂಟ್ ದೃಢೀಕರಣಕ್ಕಾಗಿ ವಿಸ್ತೃತ ಕೀಲಿ ಬಳಕೆ ಪರಿಶೀಲಿಸಿ, ಮತ್ತು ಸರ್ವರ್ ಬದಿಯಲ್ಲಿ ಡಯಲ್ ಮಾಡಿದ ಹೆಸರು ಪ್ರಮಾಣಪತ್ರದಲ್ಲಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಈ ಹಂತಗಳಲ್ಲಿ ಯಾವುದೂ ಫೈಲ್ ವಿಸ್ತರಣೆ ಓದುವುದಿಲ್ಲ.
ಆದ್ದರಿಂದ ದೋಷ ಮಾಯವಾಗುವವರೆಗೆ ಫೈಲ್ ಮರುಹೆಸರಿಸುವುದು ಸಮಯ ವ್ಯರ್ಥ ಮಾಡುವ ಅಷ್ಟು ವಿಶ್ವಾಸಾರ್ಹ ಮಾರ್ಗ. ಆಮದು ಯಶಸ್ವಿಯಾಗುತ್ತದೆ, ಗುರುತು ಇನ್ನೂ ತಪ್ಪಾಗಿರುತ್ತದೆ, ಮತ್ತು ವೈಫಲ್ಯ ಹ್ಯಾಂಡ್ಶೇಕ್ ಸಮಯದಲ್ಲಿ ಮತ್ತೆ ಕಾಣಿಸುತ್ತದೆ, ಅಲ್ಲಿ ಸಂದೇಶ ಕಡಿಮೆ ಸಹಾಯಕ. ಎರಡು ವರ್ಷಗಳ ಹಿಂದೆ ರಫ್ತಾದ ಬಂಡಲ್ ಸ್ವಚ್ಛವಾಗಿ ಆಮದಾಗಿ ಹಾಗಿದ್ದರೂ ತಿರಸ್ಕೃತವಾಗುವುದಕ್ಕೂ ಇದೇ ಕಾರಣ: ಅವಧಿ ಮುಗಿಯುವ ದಿನಾಂಕ ಫೈಲ್ ಹೆಸರಿನಲ್ಲಲ್ಲ, ಪ್ರಮಾಣಪತ್ರದ ಒಳಗೆ ಪ್ರಯಾಣಿಸಿತು.
ಮತ್ತೆ ಕೆಲಸ ತಪ್ಪಿಸುವ ಕ್ರಮ
ಕ್ಲೈಂಟ್ನ ದಾಖಲೆಗಳಲ್ಲಿ ಯಾವ ಎನ್ಕೋಡಿಂಗ್ ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ಗುರುತಿಗೆ ಯಾವ ಕಂಟೇನರ್ ನಿರೀಕ್ಷಿಸುತ್ತದೆ ಎಂದು ಕೇಳಿ, ನಂತರ ನಿಮಗೆ ಏನು ನೀಡಲಾಗಿದೆ ಎಂದು ನೋಡಿ. ಕ್ಲೈಂಟ್ಗೆ ಒಂದೇ ಆಮದಿಸಬಹುದಾದ ಗುರುತು ಬೇಕು ಮತ್ತು ನಿಮ್ಮ ಬಳಿ ಪ್ರತ್ಯೇಕ PEM ಫೈಲ್ಗಳಿದ್ದರೆ, ನೀವು ನಿಯಂತ್ರಿಸುವ ಪಾಸ್ವರ್ಡ್ನೊಂದಿಗೆ ಒಮ್ಮೆ ಬಂಡಲ್ ನಿರ್ಮಿಸಿ ಮೂಲಗಳನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ. PEM ಬೇಕಿದ್ದರೆ, ಕೀಲಿ ಮತ್ತು ಸರಪಳಿ ತೆಗೆದು, ನಂತರ ಮಧ್ಯವರ್ತಿ ಫೈಲ್ಗಳನ್ನು ನಿಮ್ಮ ತಂಡ ಈಗಾಗಲೇ ಬಳಸುವ ರುಜುವಾತು ನಿರ್ವಹಣಾ ಪ್ರಕ್ರಿಯೆಯ ಮೂಲಕ ತೆಗೆದುಹಾಕಿ.
ಆಮದಿನ ನಂತರ ಸಂವಾದವನ್ನಲ್ಲ, ಗುರುತನ್ನು ಪರಿಶೀಲಿಸಿ: ವಿಷಯ, ನೀಡುವವರು, ಅವಧಿ ಮತ್ತು ಕ್ಲೈಂಟ್ ಪ್ರಸ್ತುತಪಡಿಸುವ ಹೆಸರು. ಪಟ್ಟಿಯಲ್ಲಿನ ಸ್ನೇಹಪೂರ್ಣ ಹೆಸರು ಲೇಬಲ್, ಪರಿಶೀಲಿಸಿದ ಗುರುತಲ್ಲ. ನಂತರ ಟನೆಲ್ ವಿಫಲವಾದರೆ, ನೀವು ಪ್ಯಾಕಿಂಗ್ ಬದಲು ದೃಢೀಕರಣ ಅಥವಾ ಮಾರ್ಗದರ್ಶನ ಡೀಬಗ್ ಮಾಡುತ್ತಿದ್ದೀರಿ, ಅದು ಬಹಳ ಚಿಕ್ಕ ಸಂಭಾಷಣೆ.