VPN ਸਰਟੀਫਿਕੇਟ ਅਜੇ ਵੈਧ ਨਹੀਂ: ਤਿੰਨ ਕਾਰਨ, ਜਾਂਚ ਦਾ ਇੱਕ ਕ੍ਰਮ
«ਅਜੇ ਵੈਧ ਨਹੀਂ» ਦਾ ਅਰਥ ਹੈ ਕਿ ਡਿਵਾਈਸ ਦੀ ਘੜੀ ਪਿੱਛੇ ਹੈ, ਵਿੰਡੋ ਸੱਚਮੁੱਚ ਬਾਅਦ ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਜਾਂ ਵਿਚਕਾਰਲਾ ਸਰਟੀਫਿਕੇਟ ਅਜੇ ਖੁੱਲ੍ਹਿਆ ਨਹੀਂ। ਉਹਨਾਂ ਨੂੰ ਇਸੇ ਕ੍ਰਮ ਵਿੱਚ ਜਾਂਚੋ।
ਤੁਸੀਂ ਕਲਾਇੰਟ ਖੋਲ੍ਹਦੇ ਹੋ, ਮਹੀਨਿਆਂ ਤੋਂ ਵਰਤ ਰਹੇ ਪਰੋਫਾਈਲ ਨੂੰ ਚੁਣਦੇ ਹੋ, ਅਤੇ ਇਹ "certificate is not yet valid" ਨਾਲ ਰੁਕ ਜਾਂਦਾ ਹੈ। ਤੁਹਾਡੇ ਸਾਈਨ-ਇਨ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਿਆ, ਅਤੇ ਟਰੱਸਟ ਸਟੋਰ ਸੰਭਵ ਤੌਰ 'ਤੇ ਠੀਕ ਹੈ: ਹੈਂਡਸ਼ੇਕ ਵਿੱਚ ਪੇਸ਼ ਕੀਤਾ ਸਰਟੀਫਿਕੇਟ ਵੈਧਤਾ ਦੀ ਵਿੰਡੋ ਰੱਖਦਾ ਹੈ ਜੋ ਜਾਂਚਕਰਤਾ ਵੱਲੋਂ ਵਰਤੇ ਜਾ ਰਹੇ ਪਲ ਤੋਂ ਬਾਅਦ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ। ਤਿੰਨ ਵੱਖਰੀਆਂ ਸਥਿਤੀਆਂ ਉਹੀ ਸੰਦੇਸ਼ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਲਈ ਵੱਖਰੇ ਕਦਮ ਚਾਹੀਦੇ ਹਨ। ਹੇਠਾਂ ਦਿੱਤਾ ਕ੍ਰਮ ਘੜੀ ਜਾਂ ਸਰਟੀਫਿਕੇਟ ਫਾਈਲ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਕਿਹੜੀ ਹੈ।
ਤਿੰਨ ਕਾਰਨਾਂ ਵਿੱਚੋਂ ਤੁਸੀਂ ਕਿਹੜਾ ਦੇਖ ਰਹੇ ਹੋ
ਪਹਿਲਾ ਕਾਰਨ ਸਥਾਨਕ ਹੈ: ਜਾਂਚ ਕਰਨ ਵਾਲੇ ਡਿਵਾਈਸ ਦੀ ਘੜੀ ਸਰਟੀਫਿਕੇਟ ਦੀ ਸ਼ੁਰੂਆਤੀ ਤਾਰੀਖ ਤੋਂ ਪਹਿਲਾਂ ਦੀ ਹੈ। ਇਹ ਮਰੇ CMOS ਬੈਟਰੀ ਵਾਲੇ ਹਾਰਡਵੇਅਰ 'ਤੇ, ਪੁਰਾਣੇ ਸਨੈਪਸ਼ਾਟ ਤੋਂ ਬਹਾਲ ਕੀਤੀਆਂ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ 'ਤੇ, ਸਮਾਂ ਗੁਆਉਣ ਲਈ ਕਾਫੀ ਦੇਰ ਬੰਦ ਰਹੇ ਯੰਤਰਾਂ 'ਤੇ, ਅਤੇ ਉਹਨਾਂ ਨੈੱਟਵਰਕਾਂ 'ਤੇ ਦਿਖਦਾ ਹੈ ਜਿੱਥੇ ਬਾਹਰ ਜਾਣ ਵਾਲਾ NTP ਬਲਾਕ ਹੈ ਅਤੇ ਕਿਸੇ ਨੇ ਧਿਆਨ ਨਹੀਂ ਦਿੱਤਾ। ਸਰਟੀਫਿਕੇਟ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੈਧ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਇਸ ਤਰ੍ਹਾਂ ਫੇਲ੍ਹ ਹੋ ਸਕਦਾ ਹੈ।
ਦੂਜਾ ਕਾਰਨ ਜਾਰੀਕਰਤਾ ਦਾ ਹੈ, ਕਿਉਂਕਿ ਸਰਟੀਫਿਕੇਟ ਸੱਚਮੁੱਚ ਭਵਿੱਖ ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ: ਜਲਦੀ ਜਾਰੀ ਕੀਤਾ, ਸਪਸ਼ਟ ਸ਼ੁਰੂਆਤੀ ਸਮੇਂ ਨਾਲ ਬਣਾਇਆ, ਜਾਂ ਅਜੇ ਨਾ ਚੱਲੇ ਸਕ੍ਰਿਯਕਰਨ ਕਦਮ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਸਾਈਨ ਕੀਤਾ। ਤੀਜਾ ਕਾਰਨ ਸਭ ਤੋਂ ਵੱਧ ਸਮਾਂ ਬਰਬਾਦ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਪੱਤਾ ਮੌਜੂਦਾ ਹੈ ਜਦਕਿ ਪੇਸ਼ ਕੀਤੀ ਚੇਨ ਦਾ ਦੂਜਾ ਸਰਟੀਫਿਕੇਟ ਨਹੀਂ, ਇਸ ਲਈ ਗਲਤੀ ਉਸ ਸਮੱਗਰੀ ਦਾ ਨਾਮ ਲੈਂਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਕਦੇ ਸਥਾਪਿਤ ਨਹੀਂ ਕੀਤੀ।
ਇੱਕ ਸਵਾਲ ਉਹਨਾਂ ਨੂੰ ਵੱਖਰਾ ਕਰਦਾ ਹੈ। ਕੀ ਫੇਲ੍ਹ ਹੋਣਾ ਡਿਵਾਈਸ ਦੇ ਪਿੱਛੇ ਚੱਲਦਾ ਹੈ ਜਾਂ ਸੇਵਾ ਦੇ? ਇੱਕੋ ਨੈੱਟਵਰਕ 'ਤੇ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰਦੀਆਂ ਦੋ ਮਸ਼ੀਨਾਂ ਘੜੀਆਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀਆਂ ਹਨ। ਜੇ ਹਰ ਕਲਾਇੰਟ ਇੱਕੋ ਤਰ੍ਹਾਂ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ ਤਾਂ ਇਹ ਸਰਟੀਫਿਕੇਟ ਦੀ ਵਿੰਡੋ ਅਤੇ ਉਸ ਪਿੱਛੇ ਦੀ ਚੇਨ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ।
ਵਿੰਡੋ ਉਸੇ ਸਰਟੀਫਿਕੇਟ ਤੋਂ ਪੜ੍ਹੋ ਜੋ ਸੱਚਮੁੱਚ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਸੀ
ਪਿਛਲੀ ਤੈਨਾਤੀ ਤੋਂ ਬਚੀ PEM ਫਾਈਲ ਦੀ ਜਾਂਚ ਨਾ ਕਰੋ; ਸੇਵਾ ਤੋਂ ਉਹ ਚੇਨ ਮੰਗੋ ਜੋ ਉਹ ਹੁਣ ਭੇਜ ਰਹੀ ਹੈ। openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts ਚੇਨ ਦਾ ਹਰ ਸਰਟੀਫਿਕੇਟ ਛਾਪਦਾ ਹੈ। ਲੋੜੀਂਦਾ ਬਲਾਕ ਸੰਭਾਲੋ ਅਤੇ openssl x509 -noout -subject -issuer -dates ਚਲਾਓ; ਆਖਰੀ notBefore ਅਤੇ notAfter ਛਾਪਦਾ ਹੈ, ਅਤੇ ਉਹੀ ਦੋ ਮੁੱਲ ਫੈਸਲਾ ਕਰਦੇ ਹਨ। Windows 'ਤੇ, ਕਨੈਕਸ਼ਨ ਦਾ ਸਰਟੀਫਿਕੇਟ ਡਾਇਲਾਗ ਅਤੇ ਐਕਸਪੋਰਟ ਕੀਤੀ ਫਾਈਲ 'ਤੇ certutil -dump ਉਹੀ ਫੀਲਡ ਦਿਖਾਉਂਦੇ ਹਨ।
ਵਿੰਡੋ ਦੇ ਦੋਵੇਂ ਸਿਰੇ ਪੜ੍ਹੋ, ਸਿਰਫ ਸ਼ੁਰੂਆਤ ਨਹੀਂ। ਦੋ ਘੰਟਿਆਂ ਵਿੱਚ ਖੁੱਲ੍ਹਣ ਵਾਲਾ ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਦੋ ਘੰਟਿਆਂ ਵਿੱਚ ਬੰਦ ਹੋਣ ਵਾਲਾ ਵੱਖਰੇ ਸੰਦੇਸ਼ਾਂ ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ ਅਤੇ ਵੱਖਰੀਆਂ ਟੀਮਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਦੇ ਹਨ। ਗਲਤੀ ਕਿਹੜੇ ਸਰਟੀਫਿਕੇਟ ਦਾ ਨਾਮ ਲੈਂਦੀ ਹੈ — ਪੱਤਾ, ਵਿਚਕਾਰਲਾ ਜਾਂ ਰੂਟ — ਨੋਟ ਕਰੋ, ਕਿਉਂਕਿ ਇਸ ਨਾਲ ਤੈਅ ਹੁੰਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਪਾਸੇ ਕੁਝ ਵੀ ਠੀਕ ਹੋ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।
ਵਿੰਡੋ ਦੀ ਉਡੀਕ ਕੀਤੇ ਬਿਨਾਂ ਵੀ ਪਰਖ ਸਕਦੇ ਹੋ। ਤਸਦੀਕ ਸਪਸ਼ਟ ਸਮਾਂ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem ਉਸ ਟਾਈਮਸਟੈਂਪ 'ਤੇ ਚੇਨ ਦਾ ਮੁਲਾਂਕਣ ਕਰਦਾ ਹੈ। ਫੇਲ੍ਹ ਹੋਣਾ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰਨ ਲਈ ਮੌਜੂਦਾ ਸਮੇਂ ਨਾਲ ਚਲਾਓ, ਫਿਰ ਸਰਟੀਫਿਕੇਟ ਦੇ ਸ਼ੁਰੂਆਤੀ ਸਮੇਂ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਵਿੰਡੋ ਖੁੱਲ੍ਹਣ 'ਤੇ ਉਹੀ ਚੇਨ ਪਾਸ ਹੁੰਦੀ ਹੈ। RFC 5280 ਵੈਧਤਾ ਫੀਲਡ ਅਤੇ ਇਸ ਨਿਯਮ ਦੀ ਪਰਿਭਾਸ਼ਾ ਦਿੰਦਾ ਹੈ ਕਿ ਸਰਟੀਫਿਕੇਟ ਦੀ ਵਰਤੋਂ ਇਸ ਤੋਂ ਬਾਹਰ ਨਹੀਂ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ, ਅਤੇ ਤੁਹਾਡੇ ਕਲਾਇੰਟ ਨੇ ਹੁਣੇ ਉਹੀ ਨਿਯਮ ਲਾਗੂ ਕੀਤਾ ਹੈ।
ਤੁਹਾਡੀ ਘੜੀ, ਜਾਂ ਉਹਨਾਂ ਦੀ
ਡਿਵਾਈਸ ਦੀ ਘੜੀ ਦੀ ਤੁਲਨਾ UTC ਵਿੱਚ ਸਰਟੀਫਿਕੇਟ ਦੀ ਸ਼ੁਰੂਆਤ ਨਾਲ ਕਰੋ, ਉਸ ਸਰੋਤ ਤੋਂ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਭਰੋਸਾ ਕਰਦੇ ਹੋ। date -u ਪਲ ਦਿੰਦਾ ਹੈ, ਅਤੇ systemd ਹੋਸਟ 'ਤੇ timedatectl status ਇਹ ਵੀ ਦੱਸਦਾ ਹੈ ਕਿ ਘੜੀ ਸਿੰਕ ਹੈ ਜਾਂ ਨਹੀਂ। Windows 'ਤੇ, w32tm /query /status ਮੌਜੂਦਾ ਸਰੋਤ ਅਤੇ ਆਖਰੀ ਸਫਲ ਸਿੰਕ ਦਿਖਾਉਂਦਾ ਹੈ। ਟਰੇ ਵਿੱਚ ਦਿਖਾਇਆ ਟਾਈਮਜ਼ੋਨ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਚੋਣ ਹੈ, ਗਲਤ ਘੜੀ ਨਹੀਂ; ਜਾਂਚਕਰਤਾ UTC ਪਲਾਂ ਦੀ ਤੁਲਨਾ ਕਰਦਾ ਹੈ।
| What you see | Most likely reading | Next step |
|---|---|---|
| Clock behind, one device affected | Local time fault | Resync time, keep validation on, retest |
| Clock correct, window opens soon | Certificate staged early | Wait for the window or follow the cutover plan |
| Clock correct, intermediate not yet valid | Chain material mismatch | Operator replaces the intermediate |
| Some peers pass, others do not | Inconsistent nodes | Record each peer's chain before changing anything |
ਜੇ ਘੜੀ ਪਿੱਛੇ ਹੈ, ਤਾਂ ਕੋਈ ਵੀ ਸਰਟੀਫਿਕੇਟ ਸਮੱਗਰੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਦੁਬਾਰਾ ਸਿੰਕ ਕਰੋ ਅਤੇ ਦੁਬਾਰਾ ਪਰਖੋ। ਕੁਝ ਮਿੰਟ ਜਾਂ ਘੰਟੇ ਗਲਤ ਡਿਵਾਈਸ ਆਪਣੇ ਸਾਹਮਣੇ ਆਉਣ ਵਾਲੇ ਹਰ ਹਾਲ ਹੀ ਵਿੱਚ ਜਾਰੀ ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਅਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਸਿਰਫ ਇੱਕ ਸੇਵਾ ਨਹੀਂ, ਇਸ ਲਈ ਇੱਕ-ਸੇਵਾ ਵਾਲੀ ਵਿਆਖਿਆ ਆਮ ਤੌਰ 'ਤੇ ਗਲਤ ਹੁੰਦੀ ਹੈ। ਜੇ ਘੜੀ ਸਹੀ ਅਤੇ ਸਿੰਕ ਹੈ, ਤਾਂ ਡਿਵਾਈਸ ਵੱਲ ਦੇਖਣਾ ਬੰਦ ਕਰੋ: ਵਿੰਡੋ ਜਾਰੀਕਰਤਾ ਦੀ ਹੈ, ਅਤੇ ਇਸ ਨੂੰ ਪਾਸ ਕਰਾਉਣ ਲਈ ਕੋਈ ਸਥਾਨਕ ਸੈਟਿੰਗ ਨਹੀਂ ਬਦਲਣੀ ਚਾਹੀਦੀ।
ਉਹ ਟੇਬਲ ਪੂਰਾ ਫੈਸਲਾ ਹੈ। ਘੜੀ ਨੂੰ ਉਸ ਮੁੱਲ 'ਤੇ ਲਿਜਾਣਾ ਜਿਸਦੀ ਸਰਟੀਫਿਕੇਟ ਉਮੀਦ ਕਰਦਾ ਹੈ ਮੁਰੰਮਤ ਨਹੀਂ ਹੈ, ਅਤੇ ਸਮਾਂ-ਜਾਂਚ ਬੰਦ ਕਰਨਾ ਵੀ ਮੁਰੰਮਤ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਦੋਵੇਂ ਉਸ ਸਥਿਤੀ ਨੂੰ ਲੁਕਾਉਂਦੇ ਹਨ ਜਿਸਨੇ ਗਲਤੀ ਪੈਦਾ ਕੀਤੀ।
ਪੱਤਾ ਠੀਕ ਦਿਖਣ 'ਤੇ ਵੀ ਚੇਨ ਕਿਉਂ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ
ਨਵੀਨੀਕਰਨ ਕੀਤੇ ਪੱਤੇ ਅਤੇ ਬਦਲਵੇਂ ਵਿਚਕਾਰਲੇ ਸਰਟੀਫਿਕੇਟ ਆਮ ਤੌਰ 'ਤੇ ਇਕੱਠੇ ਭੇਜੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਹਮੇਸ਼ਾ ਇੱਕੋ ਪਲ 'ਤੇ ਨਹੀਂ ਪਹੁੰਚਦੇ। ਸੇਵਾ ਉਸ ਵਿਚਕਾਰਲੇ ਨਾਲ ਸਾਈਨ ਕੀਤਾ ਨਵਾਂ ਪੱਤਾ ਭੇਜ ਸਕਦੀ ਹੈ ਜਿਸਦੀ ਆਪਣੀ ਵਿੰਡੋ ਬਾਅਦ ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਜਾਂ ਨਵੇਂ ਪੱਤੇ ਹੇਠ ਪੁਰਾਣਾ ਵਿਚਕਾਰਲਾ ਪਰੋਸਣਾ ਜਾਰੀ ਰੱਖ ਸਕਦੀ ਹੈ। ਦੋਵੇਂ ਹਾਲਤਾਂ ਵਿੱਚ ਪੱਤੇ ਦੀਆਂ ਆਪਣੀਆਂ ਤਾਰੀਖਾਂ ਵਾਜਬ ਦਿਖਣ 'ਤੇ ਵੀ ਚੇਨ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ।
ਲੋਡ-ਸੰਤੁਲਿਤ ਅੰਤ ਬਿੰਦੂ ਇਸਨੂੰ ਟੁੱਟੇ ਤੋਂ ਅਸੰਗਤ ਵਿੱਚ ਬਦਲਦੇ ਹਨ। ਜੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਸਫਲ ਹੋਵੇ, ਜਾਂ ਇੱਕ ਨੈੱਟਵਰਕ ਚੱਲੇ ਅਤੇ ਦੂਜਾ ਨਾ ਚੱਲੇ, ਤਾਂ ਸੈਟਿੰਗਾਂ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਨੋਟ ਕਰੋ ਕਿ ਕਿਹੜੇ ਪੀਅਰ ਨੇ ਜਵਾਬ ਦਿੱਤਾ ਅਤੇ ਕਿਹੜੀ ਚੇਨ ਭੇਜੀ। openssl s_client ਜੁੜਿਆ ਪਤਾ ਛਾਪਦਾ ਹੈ, ਇਸ ਲਈ ਕੁਝ ਕੋਸ਼ਿਸ਼ਾਂ ਦੱਸਦੀਆਂ ਹਨ ਕਿ ਹਰ ਨੋਡ ਉਹੀ ਚੇਨ ਪਰੋਸਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।
ਤਸਦੀਕ ਨੂੰ ਅਟੁੱਟ ਰੱਖਣ ਵਾਲੇ ਮੁਰੰਮਤ ਦੇ ਰਾਹ
ਘੜੀ ਦੀ ਸਮੱਸਿਆ ਡਿਵਾਈਸ 'ਤੇ ਤਸਦੀਕ ਚਾਲੂ ਰੱਖ ਕੇ ਠੀਕ ਹੁੰਦੀ ਹੈ। ਸਰਟੀਫਿਕੇਟ ਦੀ ਸਮੱਸਿਆ ਆਪਰੇਟਰ ਵੱਲੋਂ ਹੁਣ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਵਾਲੀ ਵਿੰਡੋ ਲਈ ਜਾਰੀ ਸਮੱਗਰੀ ਨਾਲ ਠੀਕ ਹੁੰਦੀ ਹੈ। ਕੋਈ ਕਲਾਇੰਟ ਸੈਟਿੰਗ ਅਜੇ-ਅਵੈਧ ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਵੈਧ ਨਹੀਂ ਬਣਾਉਂਦੀ; ਸਮਾਂ-ਜਾਂਚ ਛੱਡਣ ਵਾਲੇ ਫਲੈਗ ਨਿਦਾਨ ਦੀ ਪੁਸ਼ਟੀ ਲਈ ਹਨ, ਉਤਪਾਦਨ ਵਿੱਚ ਭੇਜਣ ਲਈ ਨਹੀਂ।
ਜਦੋਂ ਸਰਟੀਫਿਕੇਟ ਯੋਜਨਾਬੱਧ ਸਕ੍ਰਿਯਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੋਵੇ, ਤਾਂ ਕਟਓਵਰ ਯੋਜਨਾ ਦੀ ਪਾਲਣਾ ਕਰੋ। ਇਸਦੀ ਵਿੰਡੋ ਖੁੱਲ੍ਹਣ 'ਤੇ ਸਥਾਪਿਤ ਕਰੋ, ਜਾਂ ਸਪਲਾਇਰ ਵੱਲੋਂ ਦਸਤਾਵੇਜ਼ਬੱਧ ਓਵਰਲੈਪ ਪ੍ਰਕਿਰਿਆ ਵਰਤੋ, ਜਲਦੀ ਸਥਾਪਿਤ ਕਰਕੇ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਚੇਤਾਵਨੀਆਂ ਵਿੱਚੋਂ ਕਲਿੱਕ ਕਰਨਾ ਸਿਖਾਉਣ ਦੀ ਬਜਾਏ। ਜਿਹੜੀਆਂ ਚੇਤਾਵਨੀਆਂ ਲੋਕ ਅਣਡਿੱਠ ਕਰਨਾ ਸਿੱਖ ਜਾਂਦੇ ਹਨ, ਉਹ ਥੋੜ੍ਹੀ ਦੇਰੀ ਨਾਲੋਂ ਵੱਧ ਮਹਿੰਗੀਆਂ ਪੈਂਦੀਆਂ ਹਨ।
ਅੰਤ ਵਿੱਚ, ਉਸੇ ਤਰ੍ਹਾਂ ਦੁਬਾਰਾ ਪਰਖੋ ਜਿਵੇਂ ਫੇਲ੍ਹ ਹੋਣਾ ਹੋਇਆ ਸੀ: ਨਵਾਂ ਸੈਸ਼ਨ, ਉਹੀ ਕਲਾਇੰਟ, ਤੁਹਾਨੂੰ ਸੱਚਮੁੱਚ ਲੋੜੀਂਦਾ ਸਰੋਤ। TLS ਲਾਇਬ੍ਰੇਰੀਆਂ ਕਨੈਕਸ਼ਨ ਦੀ ਉਮਰ ਭਰ ਤਸਦੀਕ ਕੀਤੀ ਚੇਨ ਕੈਸ਼ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕੀਤਾ ਸੈਸ਼ਨ ਇਸਨੂੰ ਜ਼ਰੂਰੀ ਨਹੀਂ ਦੁਬਾਰਾ ਜਾਂਚਦਾ, ਇਸ ਲਈ ਪੁਰਾਣਾ ਸੈਸ਼ਨ ਮੁਰੰਮਤ ਤੋਂ ਬਾਅਦ ਵੀ ਫੇਲ੍ਹ ਹੁੰਦਾ ਰਹਿ ਸਕਦਾ ਹੈ ਜਾਂ ਰਿਗ੍ਰੇਸ਼ਨ ਤੋਂ ਬਾਅਦ ਵੀ ਕੰਮ ਕਰਦਾ ਰਹਿ ਸਕਦਾ ਹੈ। ਵਿਊਅਰ ਵਿੱਚ ਖੁੱਲ੍ਹਣ ਵਾਲੀ ਫਾਈਲ ਸਿਰਫ ਇਹ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਫਾਈਲ ਪੜ੍ਹੀ ਜਾ ਸਕਦੀ ਹੈ; ਪੂਰਾ ਹੋਇਆ ਹੈਂਡਸ਼ੇਕ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਚੇਨ ਤਸਦੀਕ ਹੁੰਦੀ ਹੈ।
ਟਿਕਟ ਬੰਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਚਾਰ ਗੱਲਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ: ਫੇਲ੍ਹ ਹੋਏ ਡਿਵਾਈਸ ਦਾ UTC ਸਮਾਂ ਅਤੇ ਸਿੰਕ ਸਥਿਤੀ, ਪੇਸ਼ ਕੀਤੀ ਚੇਨ ਦੇ ਹਰ ਸਰਟੀਫਿਕੇਟ ਦਾ notBefore ਅਤੇ notAfter, ਦੂਜੇ ਕਲਾਇੰਟ ਤੋਂ ਉਹੀ ਚੇਨ, ਅਤੇ ਉਹ ਨਾਮ ਜੋ ਗਲਤੀ ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਦਿੰਦੀ ਹੈ। ਜੇ ਘੜੀ ਸਹੀ ਹੈ ਅਤੇ ਵਿੰਡੋ ਨਹੀਂ ਖੁੱਲ੍ਹੀ, ਤਾਂ ਬਾਕੀ ਆਪਰੇਟਰ ਦਾ ਕੰਮ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ ਪਾਸੇ ਤੋਂ ਸਹੀ ਕਦਮ ਤਸਦੀਕ ਕਮਜ਼ੋਰ ਕਰਨ ਦੀ ਬਜਾਏ ਵਿੰਡੋ ਦੀ ਉਡੀਕ ਕਰਨਾ ਹੈ।