ਸਰਟੀਫਿਕੇਟ ਚਰਚਾਵਾਂ ਵਿੱਚ ਦੋ ਦਾਅਵੇ ਘੁੰਮਦੇ ਹਨ। ਪਹਿਲਾ ਕਿ .p12 ਮਜ਼ਬੂਤ ਵਿਕਲਪ ਹੈ ਅਤੇ .pem ਢਿੱਲਾ; ਦੂਜਾ ਕਿ ਟੈਕਸਟ ਫਾਈਲ ਭੇਜਣੀ ਸੁਰੱਖਿਅਤ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਇਸਨੂੰ ਪੜ੍ਹ ਸਕਦੇ ਹੋ। ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਇੱਕ ਮਿੰਟ ਦੀ ਜਾਂਚ ਵੀ ਨਹੀਂ ਝੱਲਦਾ।

PKCS12, PEM ਅਤੇ DER ਦੱਸਦੇ ਹਨ ਕਿ ਸਰਟੀਫਿਕੇਟ ਵਸਤੂਆਂ ਕਿਵੇਂ ਪੈਕ ਅਤੇ ਐਨਕੋਡ ਹੁੰਦੀਆਂ ਹਨ। ਉਹ ਤੈਅ ਨਹੀਂ ਕਰਦੇ ਕਿ ਸਾਹਮਣੇ ਵਾਲਾ ਕੌਣ ਹੈ, ਜਾਰੀਕਰਤਾ ਭਰੋਸੇਯੋਗ ਹੈ ਜਾਂ ਨਹੀਂ, ਜਾਂ ਫਾਈਲ ਨੂੰ ਪਾਸਵਰਡ ਚਾਹੀਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।

ਕਲਾਇੰਟ ਕੀ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਇਹ ਅਨੁਕੂਲਤਾ ਦਾ ਸਵਾਲ ਹੈ। ਫਾਈਲ ਵਿੱਚ ਕੀ ਹੈ ਇਹ ਪਛਾਣ ਦਾ ਸਵਾਲ ਹੈ। ਇਹਨਾਂ ਦੋਵਾਂ ਨੂੰ ਵੱਖ ਰੱਖੋ ਅਤੇ ਬਹੁਤੀਆਂ ਆਯਾਤ ਗਲਤੀਆਂ ਰਹੱਸਮਈ ਹੋਣਾ ਬੰਦ ਕਰ ਦੇਣਗੀਆਂ।

ਤਿੰਨ ਕੰਟੇਨਰ, ਇੱਕ ਵਸਤੂ ਮਾਡਲ

ਅਸਲ ਵਿੱਚ ਤੁਹਾਡੇ ਕੋਲ ਜੋ ਹੈ ਉਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਸਰਟੀਫਿਕੇਟ ਜਨਤਕ ਕੁੰਜੀ ਬਾਰੇ ਦਸਤਖਤ ਕੀਤਾ ਬਿਆਨ ਹੈ। ਨਿੱਜੀ ਕੁੰਜੀ ਵੱਖਰੀ ਸਮੱਗਰੀ ਹੈ ਜੋ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਉਸ ਕੁੰਜੀ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦੇ ਹੋ। ਚੇਨ ਉਹਨਾਂ ਜਾਰੀਕਰਤਾਵਾਂ ਦਾ ਸਮੂਹ ਹੈ ਜੋ ਤੁਹਾਡੇ ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਉਸ ਰੂਟ ਨਾਲ ਜੋੜਦੇ ਹਨ ਜਿਸ 'ਤੇ ਕਲਾਇੰਟ ਭਰੋਸਾ ਕਰਦਾ ਹੈ। ਤਿੰਨੇ ਪੈਕਿੰਗ ਤੋਂ ਸੁਤੰਤਰ ਹਨ।

PKCS12 ਫਾਈਲ, ਆਮ ਤੌਰ 'ਤੇ .p12 ਜਾਂ .pfx, RFC 7292 ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕੰਟੇਨਰ ਹੈ ਜੋ ਨਿੱਜੀ ਕੁੰਜੀ, ਇੱਕ ਜਾਂ ਵੱਧ ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਚੇਨ ਨੂੰ ਪਾਸਵਰਡ-ਸੁਰੱਖਿਅਤ ਇੱਕ ਬਲਾਕ ਵਿੱਚ ਰੱਖ ਸਕਦਾ ਹੈ, ਪਛਾਣ ਦਾ ਨਾਮ ਦੇਣ ਵਾਲੇ ਅਲਿਆਸ ਨਾਲ। PEM ਫਾਈਲ RFC 7468 ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਟੈਕਸਟ ਫਰੇਮਿੰਗ ਹੈ: BEGIN ਅਤੇ END ਲਾਈਨਾਂ ਵਿਚਕਾਰ base64 ਬਾਡੀ, ਅਤੇ ਇੱਕ ਫਾਈਲ ਵਿੱਚ ਲਗਾਤਾਰ ਕਈ ਬਲਾਕ ਹੋ ਸਕਦੇ ਹਨ। DER ਉਹਨਾਂ ਹੀ ASN.1 ਢਾਂਚਿਆਂ ਦੀ ਬਾਈਨਰੀ ਐਨਕੋਡਿੰਗ ਹੈ, ਅਤੇ PEM ਬਾਡੀ ਸ਼ਬਦਸ਼ਃ base64 ਵਿੱਚ ਲਪੇਟਿਆ DER ਹੈ।

ਉਹ ਆਖਰੀ ਵਾਕ ਯਾਦ ਰੱਖਣ ਯੋਗ ਹੈ। PEM ਨੂੰ DER ਵਿੱਚ ਬਦਲਣਾ ਫਰੇਮਿੰਗ ਦੁਬਾਰਾ ਲਿਖਦਾ ਹੈ, ਸਮੱਗਰੀ ਨਹੀਂ, ਅਤੇ ਵਾਪਸ ਬਦਲਣ 'ਤੇ ਮੂਲ ਬਾਈਟ ਮਿਲਦੇ ਹਨ।

ContainerCan holdDoes not decide
PKCS12 (.p12, .pfx)Key, leaf certificate, chain, alias, passwordWhich root the client trusts
PEM (.pem, .crt, .cer)Any number of base64 blocksWhether the private key is present
DER (.der, .cer)One binary structureThe 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 ਜੋੜੋ; ਉਹ ਇੱਕੋ ਫਲੈਗ ਬਹੁਤੀਆਂ unable-to-load ਗਲਤੀਆਂ ਹੱਲ ਕਰਦਾ ਹੈ।

ਕੁੰਜੀ ਨੂੰ ਸਰਟੀਫਿਕੇਟ ਨਾਲ ਮਿਲਾਉਣਾ ਯੰਤਰਿਕ ਹੈ, ਅਤੇ ਕਿਸੇ ਵੀ ਆਯਾਤ ਤੋਂ ਪਹਿਲਾਂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ:

openssl x509 -in cert.pem -noout -pubkey | openssl sha256
openssl pkey -in key.pem -pubout | openssl sha256

ਇੱਕੋ ਡਾਇਜੈਸਟ ਦਾ ਮਤਲਬ ਹੈ ਜੋੜੀ ਇਕੱਠੀ ਹੈ। ਵੱਖਰੇ ਡਾਇਜੈਸਟ ਦਾ ਮਤਲਬ ਹੈ ਤੁਹਾਡੇ ਕੋਲ ਗਲਤ ਕੁੰਜੀ ਹੈ, ਅਤੇ ਕੋਈ ਫਾਰਮੈਟ ਬਦਲਾਅ ਇਸਨੂੰ ਨਹੀਂ ਬਦਲੇਗਾ।

ਫਾਰਮੈਟ ਕਦੇ ਨਾ ਬਦਲਣ ਵਾਲੀ ਚੀਜ਼

ਭਰੋਸੇ ਦੇ ਫੈਸਲੇ ਕੰਟੇਨਰ ਦੇ ਉੱਪਰ ਹੁੰਦੇ ਹਨ। ਕਲਾਇੰਟ ਆਪਣੇ ਸਟੋਰ ਦੇ ਰੂਟ ਤੱਕ ਚੇਨ ਚੱਲਦਾ ਹੈ, ਵੈਧਤਾ ਵਿੰਡੋ ਜਾਂਚਦਾ ਹੈ, ਕਲਾਇੰਟ ਪ੍ਰਮਾਣੀਕਰਨ ਲਈ ਵਿਸਤ੍ਰਿਤ ਕੁੰਜੀ ਵਰਤੋਂ ਜਾਂਚਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਪਾਸੇ ਜਾਂਚਦਾ ਹੈ ਕਿ ਡਾਇਲ ਕੀਤਾ ਨਾਮ ਸਰਟੀਫਿਕੇਟ ਵਿੱਚ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਕਦਮ ਫਾਈਲ ਐਕਸਟੈਂਸ਼ਨ ਨਹੀਂ ਪੜ੍ਹਦਾ।

ਇਸ ਲਈ ਗਲਤੀ ਨਾ ਮਿਟਣ ਤੱਕ ਫਾਈਲ ਦਾ ਨਾਮ ਬਦਲਣਾ ਸਮਾਂ ਬਰਬਾਦ ਕਰਨ ਦਾ ਇੰਨਾ ਭਰੋਸੇਯੋਗ ਤਰੀਕਾ ਹੈ। ਆਯਾਤ ਸਫਲ ਹੁੰਦਾ ਹੈ, ਪਛਾਣ ਫਿਰ ਵੀ ਗਲਤ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ ਅਸਫਲਤਾ ਹੈਂਡਸ਼ੇਕ ਦੌਰਾਨ ਘੱਟ ਸਹਾਇਕ ਸੰਦੇਸ਼ ਨਾਲ ਦੁਬਾਰਾ ਆਉਂਦੀ ਹੈ। ਦੋ ਸਾਲ ਪਹਿਲਾਂ ਨਿਰਯਾਤ ਕੀਤਾ ਬੰਡਲ ਸਾਫ਼ ਆਯਾਤ ਹੋ ਕੇ ਵੀ ਰੱਦ ਹੋਣ ਦਾ ਕਾਰਨ ਵੀ ਇਹੀ ਹੈ: ਮਿਆਦ ਪੁੱਗਣ ਦੀ ਤਾਰੀਖ ਫਾਈਲ ਦੇ ਨਾਮ ਵਿੱਚ ਨਹੀਂ, ਸਰਟੀਫਿਕੇਟ ਦੇ ਅੰਦਰ ਸਫ਼ਰ ਕਰਦੀ ਸੀ।

ਦੁਬਾਰਾ ਕੰਮ ਤੋਂ ਬਚਣ ਵਾਲਾ ਕ੍ਰਮ

ਕਲਾਇੰਟ ਦੇ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਪੁੱਛੋ ਕਿ ਕਿਹੜੀ ਐਨਕੋਡਿੰਗ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਪਛਾਣ ਲਈ ਕਿਹੜਾ ਕੰਟੇਨਰ ਚਾਹੀਦਾ ਹੈ, ਫਿਰ ਦੇਖੋ ਤੁਹਾਨੂੰ ਕੀ ਦਿੱਤਾ ਗਿਆ। ਕਲਾਇੰਟ ਇੱਕ ਆਯਾਤਯੋਗ ਪਛਾਣ ਚਾਹੁੰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਵੱਖਰੀਆਂ PEM ਫਾਈਲਾਂ ਹਨ ਤਾਂ ਆਪਣੇ ਨਿਯੰਤਰਣ ਵਾਲੇ ਪਾਸਵਰਡ ਨਾਲ ਇੱਕ ਵਾਰ ਬੰਡਲ ਬਣਾਓ ਅਤੇ ਸਰੋਤ ਰੱਖੋ। PEM ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਕੁੰਜੀ ਅਤੇ ਚੇਨ ਕੱਢੋ, ਅਤੇ ਫਿਰ ਵਿਚਕਾਰਲੀਆਂ ਫਾਈਲਾਂ ਤੁਹਾਡੀ ਟੀਮ ਵੱਲੋਂ ਪਹਿਲਾਂ ਹੀ ਵਰਤੀ ਜਾਂਦੀ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਸੰਭਾਲ ਪ੍ਰਕਿਰਿਆ ਰਾਹੀਂ ਹਟਾਓ।

ਆਯਾਤ ਤੋਂ ਬਾਅਦ ਸੰਵਾਦ ਨਹੀਂ, ਪਛਾਣ ਪ੍ਰਮਾਣਿਤ ਕਰੋ: ਵਿਸ਼ਾ, ਜਾਰੀਕਰਤਾ, ਮਿਆਦ ਅਤੇ ਕਲਾਇੰਟ ਦਾ ਪੇਸ਼ ਕਰਨ ਵਾਲਾ ਨਾਮ। ਸੂਚੀ ਵਿੱਚ ਦੋਸਤਾਨਾ ਨਾਮ ਲੇਬਲ ਹੈ, ਪ੍ਰਮਾਣਿਤ ਪਛਾਣ ਨਹੀਂ। ਫਿਰ ਟਨਲ ਫੇਲ੍ਹ ਹੋਵੇ ਤਾਂ ਤੁਸੀਂ ਪੈਕਿੰਗ ਦੀ ਬਜਾਏ ਪ੍ਰਮਾਣੀਕਰਨ ਜਾਂ ਰੂਟਿੰਗ ਡੀਬੱਗ ਕਰ ਰਹੇ ਹੋ, ਜੋ ਬਹੁਤ ਛੋਟੀ ਗੱਲਬਾਤ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ