ਹਰ VPN ਕਲਾਇੰਟ ਉੱਤੇ ca.key ਕਾਪੀ ਕਰਨ ਨਾਲ CA ਕਿਉਂ ਟੁੱਟਦੀ ਹੈ
ਕਲਾਇੰਟ CA ਦਾ ਜਨਤਕ ਸਰਟੀਫਿਕੇਟ ਜਾਂਚਦਾ ਹੈ; ਉਸ ਨੂੰ ਦਸਤਖ਼ਤ ਕਰਨ ਵਾਲੀ ਕੁੰਜੀ ਕਦੇ ਲੋੜੀਂਦੀ ਨਹੀਂ ਹੁੰਦੀ। ca.key ਹਰ ਡਿਵਾਈਸ ਉੱਤੇ ਕਾਪੀ ਕਰਨਾ ਇੱਕ ਵੀ ਨਕਲ ਲੈਣ ਵਾਲੇ ਨੂੰ ਜਾਰੀ ਕਰਨ ਦਾ ਅਧਿਕਾਰ ਦੇ ਦਿੰਦਾ ਹੈ।
ਸੈਟਅਪ ਹਦਾਇਤਾਂ ਵਿੱਚ ਕਿਤੇ, ਕਿਹੜੀਆਂ ਫਾਈਲਾਂ ਉੱਥੇ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ ਇਹ ਤੈਅ ਕਰਨ ਨਾਲੋਂ ਸੌਖਾ ਹੋਣ ਕਾਰਨ ਇੱਕ ਡਾਇਰੈਕਟਰੀ ਹਰ ਲੈਪਟਾਪ ਉੱਤੇ ਪੂਰੀ ਕਾਪੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਉਸ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ca.key ਹੈ, ਅਤੇ ਜਿਵੇਂ ਹੀ ਇਹ ਦੂਜੀ ਡਿਵਾਈਸ ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ, ਸਰਟੀਫਿਕੇਟ ਅਥਾਰਟੀ ਅਥਾਰਟੀ ਨਹੀਂ ਰਹਿੰਦੀ। ਹੁਣ ਕੋਈ ਵੀ ਧਾਰਕ ਅਜਿਹੀਆਂ ਪਛਾਣਾਂ ਜਾਰੀ ਕਰ ਸਕਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਉੱਤੇ ਬਾਕੀ ਨੈੱਟਵਰਕ ਭਰੋਸਾ ਕਰੇਗਾ।
ਇਹ ਉਲਝਣ ਇੱਕ ਵਾਰ ਸੁਲਝਾਉਣ ਯੋਗ ਹੈ, ਕਿਉਂਕਿ ਦੋਵੇਂ ਫਾਈਲਾਂ ਦਿਖਣ ਵਿੱਚ ਸਮਾਨ ਪਰ ਕੰਮ ਵਿੱਚ ਉਲਟ ਹਨ।
ਪੜਤਾਲ ਸਮੱਗਰੀ ਅਤੇ ਦਸਤਖ਼ਤ ਸਮੱਗਰੀ
ਕਲਾਇੰਟ ਨੂੰ CA ਦਾ ਜਨਤਕ ਸਰਟੀਫਿਕੇਟ ਲੋੜੀਂਦਾ ਹੈ ਤਾਂ ਜੋ ਜਾਂਚ ਸਕੇ ਕਿ ਸਾਹਮਣੇ ਵਾਲੇ ਪਾਸੇ ਵੱਲੋਂ ਪੇਸ਼ ਕੀਤਾ ਸਰਟੀਫਿਕੇਟ ਉਸ ਅਥਾਰਟੀ ਨੇ ਦਸਤਖ਼ਤ ਕੀਤਾ ਹੈ। ਇਹ ਪੜਤਾਲ ਦਾ ਕੰਮ ਹੈ ਅਤੇ ਇਸ ਲਈ ਕਿਸੇ ਭੇਦ ਦੀ ਲੋੜ ਨਹੀਂ। ਸਾਹਮਣੇ ਵਾਲੇ ਪਾਸੇ ਦੇ ਸਰਟੀਫਿਕੇਟ ਉੱਤੇ ਦਸਤਖ਼ਤ ਕਰਨਾ ਵੱਖਰਾ ਕੰਮ ਹੈ, ਜੋ CA ਚਲਾਉਣ ਵਾਲਾ ਇੱਕ ਵਾਰ, ਆਪਣੇ ਸੁਰੱਖਿਅਤ ਭੰਡਾਰ ਤੋਂ ਕਦੇ ਬਾਹਰ ਨ ਨਿਕਲਣ ਵਾਲੀ ਨਿੱਜੀ ਕੁੰਜੀ ਨਾਲ ਕਰਦਾ ਹੈ। ਇਹਨਾਂ ਦੋ ਕੰਮਾਂ ਨੂੰ ਵੱਖ ਰੱਖਣਾ ਹੀ ਦੋ ਫਾਈਲਾਂ ਭੇਜਣ ਦਾ ਪੂਰਾ ਮਕਸਦ ਹੈ।
ਇਸ ਲਈ ca.crt ਪਰੋਫਾਈਲ ਵਿੱਚ ਆਉਂਦੀ ਹੈ ਅਤੇ ca.key ਉਸ ਦੇ ਨੇੜੇ ਕਿਤੇ ਨਹੀਂ ਆਉਂਦੀ। ਫਾਈਲ ਦੇ ਨਾਮ ਇੱਕ ਰਵਾਇਤ ਹਨ, ਗਾਰੰਟੀ ਨਹੀਂ, ਇਸ ਲਈ ਕਿਸਮ ਨੂੰ ਨਾਮ ਤੋਂ ਅਨੁਮਾਨ ਲਾਉਣ ਦੀ ਥਾਂ ਜਾਂਚਣਾ ਪੈਂਦਾ ਹੈ।
ਵਿਚਕਾਰਲੀ CA ਜਾਂ ਆਨਲਾਈਨ ਜਾਰੀ ਸੇਵਾ ਵਾਲੀ ਬਣਾਵਟ ਇਸ ਦਾ ਅਪਵਾਦ ਨਹੀਂ। ਵੱਡੇ ਪੈਮਾਨੇ ਉੱਤੇ ਡਿਵਾਈਸ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਕਰਦੇ ਹੋਏ ਦਸਤਖ਼ਤ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਨੂੰ ਅੰਤਿਮ ਬਿੰਦੂਆਂ ਤੋਂ ਦੂਰ ਰੱਖਣ ਦਾ ਇਹੀ ਮਿਆਰੀ ਤਰੀਕਾ ਹੈ।
ਕਲਾਇੰਟ ਨੂੰ ਆਪਣੀ ਕੁੰਜੀ ਨਾਲ ਕੀ ਸਾਬਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ
ਹਰ ਡਿਵਾਈਸ ਨੂੰ ਆਪਣੀ ਕੁੰਜੀ ਜੋੜੀ ਅਤੇ ਆਪਣਾ ਸਰਟੀਫਿਕੇਟ ਮਿਲਦਾ ਹੈ, ਜਿਸ ਉੱਤੇ CA ਇੱਕ ਵਾਰ ਦਸਤਖ਼ਤ ਕਰਦੀ ਹੈ। ਕਲਾਇੰਟ ਉਹ ਸਰਟੀਫਿਕੇਟ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਮਿਲਦੀ ਨਿੱਜੀ ਕੁੰਜੀ ਆਪਣੇ ਕੋਲ ਹੋਣ ਦਾ ਸਬੂਤ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਸਵੀਕਾਰ ਕਰਨਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਲੈਪਟਾਪ ਗੁੰਮ ਹੋਣ ’ਤੇ ਰੱਦ ਹੋਣ ਵਾਲੀ ਪਛਾਣ ਇਹੀ ਹੈ।
ਚੋਰੀ ਤੋਂ ਬਾਅਦ ਇਹ ਫ਼ਰਕ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ। ਹਰ ਡਿਵਾਈਸ ਲਈ ਵੱਖਰੀ ਪਛਾਣ ਹੋਣ ’ਤੇ ਖੁੱਲ੍ਹਿਆ ਇੱਕ ਕਲਾਇੰਟ ਰੱਦ ਕਰਕੇ ਜਾਂ ਸਾਹਮਣੇ ਵਾਲੇ ਪਾਸੇ ਨੂੰ ਹਟਾ ਕੇ ਕੱਢਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਬਾਕੀ ਬੇੜਾ ਕੰਮ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ।
ਲੀਕ ਹੋਈ ਅਥਾਰਟੀ ਕੁੰਜੀ ਨਾਲ ਇਹ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। ਇਸ ਨੇ ਹੁਣ ਤੱਕ ਦਸਤਖ਼ਤ ਕੀਤੇ ਜਾਂ ਕਰ ਸਕਣ ਵਾਲੇ ਹਰ ਸਰਟੀਫਿਕੇਟ ਉੱਤੇ ਸ਼ੱਕ ਪੈ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਪ੍ਰਤੀਕਿਰਿਆ ਇੱਕ ਰੱਦ ਨਹੀਂ ਸਗੋਂ ਭਰੋਸੇ ਦੀ ਬਦਲੀ ਹੈ। ਇਹ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਹੈ, ਟਿਕਟ ਨਹੀਂ।
| File | Role | Belongs on |
|---|---|---|
ca.crt | Public certificate used to verify signatures | Every client profile |
ca.key | Private key that issues certificates | Protected CA storage only |
| client key pair | Proves one device's identity | That device alone |
ਫਾਈਲ ਨੂੰ ਕਿਤੇ ਵੀ ਕਾਪੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੜ੍ਹੋ
ਦੋ ਹੁਕਮ ਕੋਈ ਭੇਦ ਛਾਪੇ ਬਿਨਾਂ ਦੱਸਦੇ ਹਨ ਕਿ ਤੁਹਾਡੇ ਹੱਥ ਵਿੱਚ ਕਿਸ ਕਿਸਮ ਦੀ ਵਸਤੂ ਹੈ। ਪਹਿਲਾ ਸਰਟੀਫਿਕੇਟ ਉੱਤੇ ਵਿਸ਼ਾ ਅਤੇ CA ਝੰਡਾ ਦੱਸਦਾ ਹੈ; ਦੂਜਾ ਕੁੰਜੀ ਦੀ ਵੈਧਤਾ ਜਾਂਚ ਕੇ ਉਸ ਦੀ ਕਿਸਮ ਦੱਸਦਾ ਹੈ। ਤੁਸੀਂ ਵੰਡਣ ਜਾ ਰਹੇ ਬੰਡਲ ਦੀਆਂ ਫਾਈਲਾਂ ਉੱਤੇ ਦੋਵੇਂ ਚਲਾਓ। ਨਿੱਜੀ ਕੁੰਜੀ ਵਜੋਂ ਵੈਧ ਹੋਣ ਵਾਲੀ ਕੋਈ ਵੀ ਚੀਜ਼ ਕਲਾਇੰਟ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ।
openssl x509 -in ca.crt -noout -subject -ext basicConstraints openssl pkey -in ca.key -noout -check
ਜੇ ਕਲਾਇੰਟ ਬੰਡਲ ਵਿੱਚ ਪਈ ਫਾਈਲ ਉੱਤੇ ਦੂਜਾ ਹੁਕਮ ਸਫਲ ਹੋਵੇ, ਤਾਂ ਰੁਕੋ ਅਤੇ ਬੰਡਲ ਨੂੰ ਛੇੜਿਆ ਹੋਇਆ ਮੰਨੋ। ਜੋ ਨਤੀਜਾ ਕਹਿੰਦਾ ਹੈ ਕਿ ਕੁੰਜੀ ਵੈਧ ਹੈ, ਉਹ ਇਹ ਵੀ ਕਹਿੰਦਾ ਹੈ ਕਿ ਉਹ ਮੌਜੂਦ ਹੈ, ਅਤੇ ਮੌਜੂਦਗੀ ਹੀ ਪੂਰੀ ਸਮੱਸਿਆ ਹੈ।
ਉਲਟ ਦਿਸ਼ਾ ਵੱਲ ਵੀ ਧਿਆਨ ਦਿਓ: ਕਲਾਇੰਟ ਪਰੋਫਾਈਲ ਵਿੱਚ ਉਸ ਕਲਾਇੰਟ ਦੀ ਆਪਣੀ ਨਿੱਜੀ ਕੁੰਜੀ ਕਾਨੂੰਨੀ ਤੌਰ ’ਤੇ ਹੁੰਦੀ ਹੈ। ਮਿਲਦੀ ਹਰ ਕੁੰਜੀ ਮਿਟਾਉਣ ਨਾਲ ਕੁਝ ਸੁਧਰੇ ਬਿਨਾਂ ਕਨੈਕਸ਼ਨ ਟੁੱਟਦਾ ਹੈ, ਇਸ ਲਈ ਹਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਵਸਤੂ ਦੀ ਪਛਾਣ ਕਰਨੀ ਪੈਂਦੀ ਹੈ।
ਪਹਿਲਾਂ ਹੀ ਵੰਡੀ ਕੁੰਜੀ ਨੂੰ ਕਾਬੂ ਵਿੱਚ ਰੱਖਣਾ
ਇਹ ਨ ਮੰਨੋ ਕਿ ਸਥਾਨਕ ਨਕਲ ਮਿਟਾਉਣ ਨਾਲ ਖੁਲਾਸਾ ਉਲਟ ਜਾਂਦਾ ਹੈ। ਜਿਸ ਕੋਲ ਵੀ ਫਾਈਲ ਸੀ ਉਹ ਇਸ ਦੀ ਨਕਲ ਕਰ ਸਕਦਾ ਸੀ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਅਨੁਮਾਨ ਇਹੀ ਹੈ ਕਿ ਉਸ ਨੇ ਕੀਤੀ। ਆਪਰੇਟਰ ਦੀ ਘਟਨਾ ਪ੍ਰਕਿਰਿਆ ਦੀ ਪਾਲਣਾ ਕਰੋ ਅਤੇ ਭਰੋਸੇ ਦਾ ਲੰਗਰ ਬਦਲੋ, ਨਵੀਂ CA ਹੇਠ ਡਿਵਾਈਸ ਸਰਟੀਫਿਕੇਟ ਦੁਬਾਰਾ ਜਾਰੀ ਕਰਦਿਆਂ।
ਫਿਰ ਸਮੱਸਿਆ ਪੈਦਾ ਕਰਨ ਵਾਲੀ ਪੈਕੇਜਿੰਗ ਬਦਲੋ। ਫਾਈਲਾਂ ਦੀ ਸਪਸ਼ਟ ਆਗਿਆ ਸੂਚੀ ਨਾਲ ਡਾਇਰੈਕਟਰੀ ਸੂਚੀ ਭੇਜੋ, CA ਕੁੰਜੀ ਅਜਿਹੀ ਮਸ਼ੀਨ ਉੱਤੇ ਰੱਖੋ ਜੋ ਕਦੇ ਕਲਾਇੰਟ ਬੇੜੇ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦੀ, ਅਤੇ ਦਰਜ ਕਰੋ ਕਿ ਕਿਹੜਾ ਸਿਸਟਮ ਇਸ ਨੂੰ ਰੱਖਦਾ ਹੈ।
ਜੇ ਅਥਾਰਟੀ ਨੂੰ ਵਾਰ-ਵਾਰ ਜਾਰੀ ਕਰਨਾ ਪਵੇ, ਤਾਂ ਦਸਤਖ਼ਤ ਕਰਨਾ ਤੰਗ ਦਾਇਰੇ ਅਤੇ ਘੱਟ ਵੈਧਤਾ ਵਾਲੀ ਸੇਵਾ ਜਾਂ ਵਿਚਕਾਰਲੀ ਅਥਾਰਟੀ ਦੇ ਪਿੱਛੇ ਲੈ ਜਾਓ। ਇਸ ਤਰ੍ਹਾਂ ਭਵਿੱਖ ਦੀ ਗਲਤੀ ਪੂਰੀ ਤੈਨਾਤੀ ਦੀ ਭਰੋਸਾ-ਜੜ੍ਹ ਦੀ ਥਾਂ ਜਾਰੀ ਕਰਨ ਦੇ ਇੱਕ ਹਿੱਸੇ ਨੂੰ ਹੀ ਖੋਲ੍ਹਦੀ ਹੈ।