ਨਵੀਨੀਕ੍ਰਿਤ VPN ਸਰਟੀਫਿਕੇਟ: ਕੁਝ ਕਲਾਇੰਟ ਅਜੇ ਵੀ ਇਸ ਨੂੰ ਅਸਵੀਕਾਰ ਕਰਦੇ ਹਨ

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

ਇੱਕ ਨਵੀਨੀਕਰਨ, ਦੋ ਵਿਵਹਾਰ

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

ਇਹ ਵੀ ਜਾਂਚੋ ਕਿ ਅਸਫਲ ਕਲਾਇੰਟ ਨੇ ਕਿਹੜਾ ਪ੍ਰੋਫਾਈਲ ਚੁਣਿਆ। ਆਪਣੇ ਹੀ ਸਟੋਰ ਵਿੱਚ ਰਹਿਣ ਵਾਲੀ ਆਯਾਤ ਕੀਤੀ ਕਾਪੀ, ਪ੍ਰਬੰਧਕ ਵੱਲੋਂ ਮੂਲ ਫਾਈਲ ਕਿਤੇ ਹੋਰ ਸੋਧਣ 'ਤੇ ਨਹੀਂ ਬਦਲਦੀ।

ਨਵੀਨੀਕਰਨ ਵਸਤੂ ਬਦਲਦਾ ਹੈ, ਸਿਰਫ਼ ਤਾਰੀਖ਼ ਨਹੀਂ

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

openssl x509 -in server.pem -noout -subject -issuer -dates -fingerprint -sha256
openssl x509 -in server.pem -noout -pubkey | openssl sha256

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

ਪੜ੍ਹੋ ਕਿ ਕਲਾਇੰਟ ਕੀ ਪਿੰਨ ਕਰ ਰਿਹਾ ਹੈ

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

grep -n 'peer-fingerprint' /etc/openvpn/client/*.conf
openssl s_client -connect gw.lab.example.net:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -fingerprint -sha256

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

ਹਰ ਬੈਕਐਂਡ ਵੱਲੋਂ ਪੇਸ਼ ਕੀਤੇ ਸਰਟੀਫਿਕੇਟ ਦੀ ਤੁਲਨਾ ਕਰੋ

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

for h in 10.30.0.11 10.30.0.12; do echo "$h"; openssl s_client -connect $h:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -subject -dates -fingerprint -sha256; done

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

ਪ੍ਰਬੰਧਿਤ ਰਾਹੀਂ ਭਰੋਸਾ ਬਦਲੋ

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

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