VPN ਪ੍ਰਮਾਣ ਪੱਤਰ ਅਥਾਰਟੀ ਬਦਲਣ ਵੇਲੇ ਕੀ ਹੁੰਦਾ ਹੈ

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

ਇੱਕ ਬਦਲੀ, ਦੋ ਵੱਖਰੀਆਂ ਤਬਦੀਲੀਆਂ

ਪ੍ਰਮਾਣ ਪੱਤਰ ਅਥਾਰਟੀ ਇੱਕ ਨਾਮ, ਇੱਕ ਜਨਤਕ ਚਾਬੀ ਅਤੇ ਦਸਤਖ਼ਤ ਕਰਨ ਵਾਲੀ ਨਿੱਜੀ ਚਾਬੀ ਹੁੰਦੀ ਹੈ। ਪ੍ਰਮਾਣਕ ਕਦੇ ਵੀ ਅਮੂਰਤ ਰੂਪ ਵਿੱਚ ‘CA’ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦੇ। ਉਹ ਭਰੋਸਾ ਭੰਡਾਰ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਪਏ ਇੱਕ ਖ਼ਾਸ ਪ੍ਰਮਾਣ ਪੱਤਰ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹਨ, ਅਤੇ ਜਾਰੀਕਰਤਾ ਨੂੰ ਸਿਰਫ਼ ਤਦ ਸਵੀਕਾਰ ਕਰਦੇ ਹਨ ਜਦੋਂ ਦਸਤਖ਼ਤਾਂ ਦੀ ਲੜੀ ਉਸ ਸੰਭਾਲੀ ਨਕਲ ਤੱਕ ਪਹੁੰਚੇ। ਇਸ ਲਈ CA ਬਦਲਣ ਨਾਲ ਦੋ ਚੀਜ਼ਾਂ ਬਦਲਦੀਆਂ ਹਨ ਜੋ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਅਸਫਲ ਹੁੰਦੀਆਂ ਹਨ: ਕਿਹੜੇ ਐਂਕਰ ਸਵੀਕਾਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਉਨ੍ਹਾਂ ਅਧੀਨ ਕਿਹੜੀਆਂ ਸਾਥੀ ਪਛਾਣਾਂ ਜਾਰੀ ਹੋਈਆਂ।

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

ਪ੍ਰਮਾਣਕ ਕੀ ਜਾਂਚਦਾ ਹੈ, ਕ੍ਰਮ ਵਿੱਚ

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

ਉਹ ਸਫ਼ਰ ਔਫਲਾਈਨ ਦੁਹਰਾਉਣ ਲਈ, -CAfile ਨੂੰ ਉਸੇ ਬੰਡਲ ਵੱਲ ਸੰਕੇਤ ਕਰੋ ਜੋ ਤੁਸੀਂ ਤੈਨਾਤ ਕਰੋਗੇ, ਸਿਸਟਮ ਭੰਡਾਰ ਵੱਲ ਨਹੀਂ। ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਤਬਦੀਲੀ ਨਹੀਂ, ਹੋਸਟ ਪਰਖ ਰਹੇ ਹੋ:

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

ਉਹ ਹੁਕਮ ਸਿਰਫ਼ ਗੇਟਵੇ ਦੇ HTTPS ਪ੍ਰਬੰਧਨ ਸਫ਼ੇ ਵਰਗੇ ਸਾਦੇ TLS ਸਰੋਤੇ ਦੇ ਖਿਲਾਫ਼ ਕੰਮ ਕਰਦਾ ਹੈ; OpenVPN ਦਾ ਨਿਯੰਤਰਣ ਚੈਨਲ TLS ਤੋਂ ਪਹਿਲਾਂ ਆਉਂਦਾ ਹੈ, ਇਸ ਲਈ s_client ਸੁਰੰਗ ਦਾ ਹੈਂਡਸ਼ੇਕ ਨਹੀਂ ਵੇਖ ਸਕਦਾ।

ਉਨ੍ਹਾਂ ਗ਼ਲਤੀਆਂ ਪਿੱਛੇ ਦੇ ਮਾਰਗ-ਨਿਰਮਾਣ ਨਿਯਮ RFC 5280 ਭਾਗ 6 ਵਿੱਚ ਹਨ। ਉਹ ਉਹ ਅਸਫਲਤਾਵਾਂ ਸਮਝਾਉਂਦੇ ਹਨ ਜੋ ਹੋਰ ਤਰ੍ਹਾਂ ਮਨਮਾਨੀ ਲੱਗਦੀਆਂ ਹਨ: ਕਿਸੇ ਨੂੰ ਯਾਦ ਨਾ ਰਿਹਾ ਮਿਆਦ ਪੁੱਗਿਆ ਵਿਚਕਾਰਲਾ, ਜਿਸ ਦੀ ਚਾਬੀ ਵਰਤੋਂ ਦਸਤਖ਼ਤ 'ਤੇ ਰੋਕ ਲਾਉਂਦੀ ਹੈ ਅਜਿਹਾ ਪ੍ਰਮਾਣ ਪੱਤਰ, ਜਾਂ ਤੁਹਾਡੇ ਵੱਲੋਂ ਪਰਖੇ ਜਾ ਰਹੇ ਹੋਸਟ ਨੂੰ ਬਾਹਰ ਰੱਖਣ ਵਾਲੀ ਨਾਮ ਸੀਮਾ।

ਪੁਰਾਣੀ ਸੁਰੰਗ ਕਿਉਂ ਚੱਲਦੀ ਰਹਿੰਦੀ ਹੈ

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

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

ਸਥਿਰ-ਚਾਬੀ ਪਰਤ ਨੂੰ ਇਸ ਤੋਂ ਵੱਖ ਰੱਖੋ। tls-auth ਨਿਯੰਤਰਣ ਚੈਨਲ ਵਿੱਚ HMAC ਜੋੜਦਾ ਹੈ, tls-crypt ਉਸ ਨੂੰ ਸ਼ਫ਼ਰ ਕਰਦਾ ਅਤੇ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਦੋਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਪ੍ਰਮਾਣ ਪੱਤਰ ਸਮੱਗਰੀ ਨਹੀਂ ਢੋਂਦਾ, ਇਸ ਲਈ ਕਿਸੇ ਵੀ ਇੱਕ ਦਾ ਘੁਮਾਅ ਆਪਣੀ ਅਸਫਲਤਾ-ਢੰਗ ਵਾਲੀ ਵੱਖਰੀ ਤਬਦੀਲੀ ਹੈ। ਦੋਹਾਂ ਨੂੰ ਮਿਲਾਉਣ ਵਾਲੇ ਤੈਨਾਤੀ ਅਜਿਹੇ ਕਲਾਇੰਟ 'ਤੇ ਪੁੱਜਦੇ ਹਨ ਜਿਸ ਦੀ ਸਥਿਰ ਚਾਬੀ ਠੀਕ ਹੈ, ਪ੍ਰਮਾਣ ਪੱਤਰ ਪੁਰਾਣਾ ਹੈ ਅਤੇ ਗ਼ਲਤੀ ਸੰਦੇਸ਼ ਦੋਹਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਦਾ ਜ਼ਿਕਰ ਨਹੀਂ ਕਰਦਾ।

ਵਿਸ਼ਾ ਨਾਮ ਮੁੜ-ਵਰਤੋਂ ਦਾ ਜਾਲ

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

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

ਨੈੱਟਵਰਕ ਨਾ ਡਿਗਾਉਣ ਵਾਲਾ ਘੁਮਾਅ

ਯੋਜਿਤ ਬਦਲੀ ਲਈ ਇੱਕੋ ਕਦਮ ਵਿੱਚ ਬਦਲਣ ਦੀ ਥਾਂ ਸੀਮਤ ਸਮੇਂ ਲਈ ਦੋਵੇਂ ਐਂਕਰ ਸਵੀਕਾਰ ਕਰੋ। ਨਵੀਂ CA ਅਤੇ ਉਸ ਦੇ ਵਿਚਕਾਰਲੇ ਜਾਰੀ ਕਰੋ, ਨਵਾਂ ਐਂਕਰ ਪੁਰਾਣੇ ਦੇ ਨਾਲ ਹਰ ਪ੍ਰਮਾਣਕ ਦੇ ਬੰਡਲ ਵਿੱਚ ਰੱਖੋ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ ਉਸ ਤੋਂ ਸਾਥੀ ਪ੍ਰਮਾਣ ਪੱਤਰ ਜਾਰੀ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੋ। ਪੁਰਾਣੀ ਪਛਾਣ ਵਾਲੇ ਸਾਥੀ ਪੁਰਾਣੇ ਐਂਕਰ ਦੇ ਖਿਲਾਫ਼ ਪ੍ਰਮਾਣਿਤ ਹੁੰਦੇ ਹਨ; ਨਵੇਂ ਨਵੇਂ ਦੇ ਖਿਲਾਫ਼ ਕੰਮ ਕਰਦੇ ਹਨ।

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

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

ਨਤੀਜਾ ਪ੍ਰਮਾਣਿਤ ਕਰੋ, ਫਾਈਲ ਸੂਚੀ ਨਹੀਂ

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

ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਨਵੀਂ ਪਛਾਣ ਨਾਲ ਨਵਾਂ ਕਨੈਕਸ਼ਨ ਸਫਲ ਹੁੰਦਾ ਹੈ, ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਨਿਵਾਰਤ CA ਵੱਲੋਂ ਜਾਰੀ ਪਛਾਣ ਨਕਾਰੀ ਜਾਂਦੀ ਹੈ। ਲੋਕ ਜਿਸ ਨੂੰ ਛੱਡ ਦਿੰਦੇ ਹਨ ਉਹੀ ਦੂਜੀ ਪਰਖ ਹੈ, ਅਤੇ ਇਹੋ ਇੱਕੋ-ਇੱਕ ਹੈ ਜੋ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਪੁਰਾਣੀ ਅਥਾਰਟੀ ਹੁਣ ਪਹੁੰਚ ਨਹੀਂ ਦਿੰਦੀ। ਜਿੱਥੇ ਤੈਨਾਤੀ CRL ਜਾਂ OCSP 'ਤੇ ਨਿਰਭਰ ਹੈ, ਉੱਥੇ ਪਰਖੋ ਕਿ ਨਵੇਂ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਵਿੱਚ ਵੰਡ ਬਿੰਦੂ ਹੱਲ ਹੁੰਦੇ ਹਨ ਅਤੇ ਪੁੱਛਣ ਵਾਲੇ ਸਾਥੀ ਜਵਾਬਦੇਹ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ।

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