ਸਵੈ-ਦਸਤਖ਼ਤ ਕੀਤਾ VPN ਸਰਟੀਫਿਕੇਟ: ਇਸਦਾ ਕੀ ਮਤਲਬ ਹੈ ਅਤੇ ਇਹ ਕਿਸ 'ਤੇ ਭਰੋਸਾ ਕਰਦਾ ਹੈ

ਇੱਥੇ ਸਭ ਤੋਂ ਵੱਧ ਨੁਕਸਾਨ ਦੋ ਵਿਸ਼ਵਾਸ ਕਰਦੇ ਹਨ: ਕਿ ਸਵੈ-ਦਸਤਖ਼ਤ ਕੀਤਾ VPN ਸਰਟੀਫਿਕੇਟ ਮਤਲਬ ਟਨਲ ਐਨਕ੍ਰਿਪਟ ਨਹੀਂ ਹੈ, ਅਤੇ ਕਿ VPN ਕਲਾਇਟ ਨੇ ਜੋ ਵੀ ਮੰਗਿਆ ਉਸ ਨੂੰ ਸਥਾਪਿਤ ਕਰਨਾ ਸਿਰਫ਼ VPN ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ। ਦੋਵੇਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਅਸਲ ਤੈਨਾਤੀ ਦੇ ਸੰਪਰਕ ਵਿੱਚ ਨਹੀਂ ਟਿਕਦਾ। ਸਵੈ-ਦਸਤਖ਼ਤ ਕੀਤਾ ਸਰਟੀਫਿਕੇਟ ਦਸਤਖ਼ਤ ਦੇ ਸਬੰਧ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਸੁਰੱਖਿਆ ਦਾ ਫ਼ੈਸਲਾ ਨਹੀਂ, ਅਤੇ ਤੁਸੀਂ ਜੋ ਭਰੋਸਾ ਜੋੜਦੇ ਹੋ ਉਸ ਦੀ ਪਹੁੰਚ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਇਹ ਕਿਹੜੇ ਸਟੋਰ ਵਿੱਚ ਪੈਂਦਾ ਹੈ। ਮੈਂ ਦੇਖਿਆ ਹੈ ਕਿ ਹੈਲਪਡੈਸਕ ਇੱਕ ਚੇਤਾਵਨੀ ਸ਼ਾਂਤ ਕਰਨ ਲਈ Windows ਮਸ਼ੀਨ ਵਿੱਚ ਪ੍ਰਦਾਤਾ ਦੀ ਰੂਟ ਆਯਾਤ ਕਰਦਾ ਹੈ, ਫਿਰ ਪੂਰੀ ਦੁਪਹਿਰ ਇਹ ਸਮਝਾਉਣ ਵਿੱਚ ਲਾਉਂਦਾ ਹੈ ਕਿ ਬ੍ਰਾਊਜ਼ਰ ਨੇ ਅਸੰਬੰਧਿਤ ਪੋਰਟਲ ਬਾਰੇ ਸ਼ਿਕਾਇਤ ਕਰਨਾ ਕਿਉਂ ਬੰਦ ਕੀਤਾ। ਇਸ ਸਵਾਲ ਦੇ ਦੋਵੇਂ ਅੱਧ ਇਕੱਠੇ ਹਨ, ਇਸ ਲਈ ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਮੰਨੋ।

ਸਰਟੀਫਿਕੇਟ ਭਰੋਸੇ ਦਾ ਸਟੋਰ ਨਹੀਂ ਹੈ

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

ਸਵੀਕ੍ਰਿਤੀ ਕਿਤੇ ਹੋਰੋਂ ਆਉਂਦੀ ਹੈ: ਇੱਕ CA ਫਾਈਲ ਜਿਸ ਵੱਲ ਤੁਸੀਂ ਕਲਾਇਟ ਨੂੰ ਨਿਰਦੇਸ਼ਿਤ ਕਰਦੇ ਹੋ, ਇੱਕ ਫਿੰਗਰਪ੍ਰਿੰਟ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਹੱਥ ਨਾਲ ਤੁਲਨਾ ਕਰਦੇ ਹੋ, ਜਾਂ ਇੱਕ ਰੂਟ ਜੋ ਪਹਿਲਾਂ ਹੀ ਉਸ ਸਟੋਰ ਵਿੱਚ ਬੈਠਾ ਹੈ ਜਿਸ ਨੂੰ ਕਲਾਇਟ ਪੜ੍ਹਦਾ ਹੈ। ਤੈਨਾਤੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਿਹਤਮੰਦ ਹੋ ਸਕਦੀ ਹੈ ਜਦੋਂ ਕਿ ਇਸਦਾ ਸਰਟੀਫਿਕੇਟ ਹਰ ਜਨਤਕ ਟੈਸਟ ਵਿੱਚ ਫੇਲ ਹੋਵੇਗਾ। openssl verify ਸਿਸਟਮ ਬੰਡਲ ਦੇ ਵਿਰੁੱਧ ਅਣਜਾਣ ਜਾਰੀਕਰਤਾ ਦੀ ਰਿਪੋਰਟ ਕਰੇਗਾ, ਅਤੇ ਉਹ ਰਿਪੋਰਟ ਖਰਾਬੀ ਨਹੀਂ, ਸਹੀ ਹੈ।

OpenVPN ਦਾ ca ਵਿਕਲਪ ਐਪ-ਸੀਮਿਤ ਭਰੋਸੇ ਦਾ ਸਭ ਤੋਂ ਸਪਸ਼ਟ ਕੇਸ ਹੈ। ਉਹ ਫਾਈਲ ਉਹ ਐਂਕਰ ਦੱਸਦੀ ਹੈ ਜੋ ਕਲਾਇਟ ਸਵੀਕਾਰ ਕਰੇਗਾ, ਅਤੇ ਇਸ ਵਿੱਚ ਇੱਕ ਪ੍ਰਾਈਵੇਟ CA ਜਾਂ ਛੋਟੀ ਤੈਨਾਤੀ ਵਿੱਚ ਸਰਵਰ ਦਾ ਆਪਣਾ ਸਵੈ-ਦਸਤਖ਼ਤ ਕੀਤਾ ਸਰਟੀਫਿਕੇਟ ਹੋ ਸਕਦਾ ਹੈ। ਸੰਸਕਰਣ 2.6 CA ਫਾਈਲ ਵੰਡਣ ਦੀ ਬਜਾਏ SHA-256 ਫਿੰਗਰਪ੍ਰਿੰਟ ਪਿੰਨ ਕਰਨ ਲਈ --peer-fingerprint ਵੀ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ। WireGuard ਹੋਰ ਵੀ ਦੂਰ ਹੈ: ਇਸ ਵਿੱਚ ਸਰਟੀਫਿਕੇਟ ਬਿਲਕੁਲ ਨਹੀਂ ਹਨ, ਸਿਰਫ਼ ਹਰ ਸਾਥੀ ਲਈ ਇੱਕ ਸਥਿਰ ਜਨਤਕ ਕੁੰਜੀ, ਇਸ ਲਈ ਸਵੈ-ਦਸਤਖ਼ਤ ਦਾ ਸਵਾਲ ਇਸ 'ਤੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦਾ।

ਤੁਸੀਂ ਭਰੋਸਾ ਕਿੱਥੇ ਸਥਾਪਿਤ ਕਰਦੇ ਹੋ ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਇਸ ਨੂੰ ਕੌਣ ਵਿਰਾਸਤ ਵਿੱਚ ਪਾਏਗਾ

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

Debian ਜਾਂ Ubuntu 'ਤੇ, /usr/local/share/ca-certificates/ ਵਿੱਚ ਫਾਈਲ ਪਾਉਣਾ ਅਤੇ update-ca-certificates ਚਲਾਉਣਾ ਸਿਸਟਮ-ਵਿਆਪੀ ਬੰਡਲ ਬਦਲਦਾ ਹੈ। Windows 'ਤੇ, certutil -addstore -f Root ਮਸ਼ੀਨ ਸਟੋਰ ਵਿੱਚ ਲਿਖਦਾ ਹੈ ਅਤੇ ਉੱਨਤ ਪ੍ਰੋਂਪਟ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਜਦੋਂ ਕਿ -user ਜੋੜਨਾ ਇਸ ਦੀ ਬਜਾਏ ਮੌਜੂਦਾ ਉਪਭੋਗਤਾ ਦੇ ਸਟੋਰ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦਾ ਹੈ; ਦੋਵੇਂ ਬਦਲਵੇਂ ਨਹੀਂ ਹਨ। Firefox ਆਪਣਾ NSS ਡੇਟਾਬੇਸ ਰੱਖਦਾ ਹੈ, ਇਸ ਲਈ OS-ਪੱਧਰ ਦਾ ਆਯਾਤ ਉੱਥੇ ਕਦੇ ਨਹੀਂ ਦਿਸ ਸਕਦਾ।

ਘੇਰਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇੱਕ ਅਧਿਕਾਰ ਕੀ ਕਰ ਸਕਦਾ ਹੈ। ਜਾਰੀਕਰਤਾ CA ਉਨ੍ਹਾਂ ਨਾਵਾਂ ਲਈ ਦਸਤਖ਼ਤ ਕਰ ਸਕਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨਾਲ ਉਸਦਾ ਕੋਈ ਸਬੰਧ ਨਹੀਂ, ਇਸ ਲਈ ਉਸ ਸਟੋਰ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਵਾਲਾ ਹਰ ਕੋਈ ਉਹ ਦਸਤਖ਼ਤ ਸਵੀਕਾਰ ਕਰੇਗਾ। ਇੱਕ ਪਿੰਨ ਕੀਤਾ ਪੱਤਾ ਅਜਿਹਾ ਨਹੀਂ ਕਰ ਸਕਦਾ; ਇਹ ਠੀਕ ਇੱਕ ਸਾਥੀ ਦੀ ਪਛਾਣ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ। ਜੇ ਮਕਸਦ ਇੱਕ VPN ਨੂੰ ਜੋੜਨਾ ਹੈ, ਤਾਂ ਐਪ-ਸੀਮਿਤ CA ਜਾਂ ਪਿੰਨ ਕੀਤਾ ਪੱਤਾ ਉੱਥੇ ਪਹੁੰਚਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਮਸ਼ੀਨ-ਵਿਆਪੀ ਰੂਟ ਲੱਛਣ ਦੀ ਲੋੜ ਨਾਲੋਂ ਕਿਤੇ ਵੱਡੀ ਰਿਆਇਤ ਹੈ।

ਤੁਸੀਂ ਅਜੇ ਵੀ ਜਨਤਕ CA ਤੋਂ ਬਿਨਾਂ ਐਨਕ੍ਰਿਪਟ ਕਰ ਰਹੇ ਹੋ

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

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

ਜਾਰੀਕਰਤਾ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਨਾਮ ਦੀ ਜਾਂਚ ਨੂੰ ਨਹੀਂ ਛੱਡਦਾ

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

OpenVPN ਵਿਭਾਜਨ ਨੂੰ ਦਿਸਦਾ ਬਣਾਉਂਦਾ ਹੈ। verify-x509-name ਅਨੁਮਾਨਿਤ ਵਿਸ਼ੇ ਨੂੰ name, name-prefix ਜਾਂ subject ਮਿਲਾਨ ਰਾਹੀਂ ਪਿੰਨ ਕਰਦਾ ਹੈ। remote-cert-tls server ਲੋੜ ਕਰਦਾ ਹੈ ਕਿ ਸਾਥੀ ਦਾ ਸਰਟੀਫਿਕੇਟ ਸਰਵਰ ਸਰਟੀਫਿਕੇਟ ਵਜੋਂ ਵਰਤੋਂਯੋਗ ਹੋਵੇ, ਜੋ ਸਿਰਫ਼-ਕਲਾਇਟ ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਰੱਦ ਕਰਦਾ ਹੈ ਭਾਵੇਂ ਜਾਰੀਕਰਤਾ 'ਤੇ ਭਰੋਸਾ ਹੋਵੇ। ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਸੈਟਿੰਗ CA ਫਾਈਲ ਭੇਜਣ ਨਾਲ ਬਦਲੀ ਨਹੀਂ ਜਾਂਦੀ।

ਕੁਝ ਵੀ ਤੈਅ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਰਟੀਫਿਕੇਟ ਦੀ ਜਾਂਚ ਕਰੋ:

• openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿਸਨੇ, ਕਿਹੜੇ ਨਾਵਾਂ ਲਈ ਅਤੇ ਕਦੋਂ ਤੱਕ ਜਾਰੀ ਕੀਤਾ।
• openssl verify -CAfile ca.crt server.crt ਜਾਂਚਦਾ ਹੈ ਕਿ ਭੇਜਣ ਵਾਲੀ ਚੇਨ ਪੱਤੇ ਨੂੰ ਸੱਚਮੁੱਚ ਵੈਧ ਕਰਦੀ ਹੈ ਜਾਂ ਨਹੀਂ।
• openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error ਵੈੱਬ ਪੋਰਟਲ ਵਰਗੇ TLS ਅੰਤ ਬਿੰਦੂਆਂ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ; 1194 'ਤੇ OpenVPN ਪ੍ਰੋਟੋਕੋਲ ਸਾਦਾ TLS ਪ੍ਰਵਾਹ ਨਹੀਂ, ਇਸ ਲਈ ਉਹ ਟੈਸਟ ਉੱਥੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦਾ।

ਸਮਾਂ ਸਮਾਪਤ ਤਾਰੀਖ, ਤੁਸੀਂ ਜੁੜਦੇ ਨਾਮ ਲਈ subjectAltName ਨਾ ਹੋਣਾ, ਜਾਂ serverAuth ਵਰਤੋਂ ਨਾ ਹੋਣਾ ਵਾਲਾ ਸਰਟੀਫਿਕੇਟ ਐਂਕਰ ਕਿੰਨੀ ਵੀ ਸਾਵਧਾਨੀ ਨਾਲ ਸਥਾਪਿਤ ਕੀਤਾ ਗਿਆ ਹੋਵੇ, ਫੇਲ ਹੁੰਦਾ ਹੈ।

ਇੱਕ ਸਵੀਕਾਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੰਜ ਜਾਂਚਾਂ

ਤੁਸੀਂ ਠੀਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਕਨੈਕਸ਼ਨ ਤੋਂ ਇਲਾਵਾ ਕਿਸੇ ਚੈਨਲ 'ਤੇ ਫਿੰਗਰਪ੍ਰਿੰਟ ਦੀ ਤੁਲਨਾ ਕਰੋ: ਕੰਸੋਲ, ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਇੰਸਟਾਲਰ, ਦਸਤਖ਼ਤ ਕੀਤੀ ਸੰਰਚਨਾ ਫਾਈਲ। ਸਰਵਰ 'ਤੇ openssl x509 -in server.crt -noout -fingerprint -sha256 ਅਤੇ ਕਲਾਇਟ ਲੌਗ ਵਿੱਚ ਉਹੀ ਮੁੱਲ ਇੱਕੋ ਵਸਤੂ ਵੇਖ ਰਹੇ ਹੋ ਇਹ ਜਾਣਨ ਲਈ ਕਾਫ਼ੀ ਹਨ।

ਫਿਰ ਤੁਸੀਂ ਕੀ ਸਥਾਪਿਤ ਕਰ ਰਹੇ ਹੋ ਤੈਅ ਕਰੋ: ਇੱਕ ਪੱਤਾ, ਜਾਂ ਹੋਰ ਬਣਾ ਸਕਣ ਵਾਲਾ ਅਧਿਕਾਰ। ਫਿਰ ਤੈਅ ਕਰੋ ਕਿ ਇਹ ਕਿੱਥੇ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਉਹ ਐਪਲੀਕੇਸ਼ਨ ਦੱਸੋ ਜੋ ਉਸ ਸਟੋਰ ਨੂੰ ਪੜ੍ਹਦੇ ਹਨ। ਹਟਾਉਣ ਦਾ ਰਾਹ ਉਦੋਂ ਲਿਖੋ ਜਦੋਂ ਇਹ ਅਜੇ ਯਾਦ ਹੈ, ਕਿਉਂਕਿ ਭਰੋਸਾ-ਕਰੋ-ਅਤੇ-ਅੱਗੇ-ਵਧੋ ਇਸੇ ਤਰ੍ਹਾਂ ਅਸਥਾਈ ਆਯਾਤ ਸਥਾਈ ਬਣਦਾ ਹੈ।

ਅੰਤ ਵਿੱਚ, ਤਬਦੀਲੀ ਦੀ ਯੋਜਨਾ ਬਣਾਓ। ਪਿੰਨ ਕੀਤਾ ਸਰਟੀਫਿਕੇਟ ਜਾਂ ਫਿੰਗਰਪ੍ਰਿੰਟ ਸਰਟੀਫਿਕੇਟ ਬਦਲਣ ਵੇਲੇ ਉਸੇ ਭਰੋਸੇਯੋਗ ਚੈਨਲ ਰਾਹੀਂ ਅਪਡੇਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਪ੍ਰਾਈਵੇਟ CA ਦਾ ਆਪਣਾ ਜਾਰੀ ਕਰਨ ਅਤੇ ਰੱਦ ਕਰਨ ਦਾ ਜੀਵਨ ਚੱਕਰ ਹੈ। ਜੇ ਪ੍ਰਾਈਵੇਟ ਕੁੰਜੀ ਲੀਕ ਹੋ ਜਾਵੇ, ਤਾਂ ਉਸੇ ਸਰਟੀਫਿਕੇਟ ਦੀ ਕਾਪੀ 'ਤੇ ਦੁਬਾਰਾ ਭਰੋਸਾ ਕਰਨਾ ਕੁਝ ਵੀ ਠੀਕ ਨਹੀਂ ਕਰਦਾ; ਪਛਾਣ ਬਦਲਣੀ ਪਵੇਗੀ।

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