SoftEther ServerCertSet: vpncmd ਨਾਲ ਨਵੀਨੀਕ੍ਰਿਤ ਚੇਨ ਦਰਾਮਦ ਕਰੋ

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

ਨਵੀਨੀਕ੍ਰਿਤ ਫਾਈਲ ਸਰਵਰ ਦੀ ਪਛਾਣ ਨਹੀਂ ਬਦਲਦੀ

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

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

ਸਰੋਤੇ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਚੁਣੌਤੀ ਚੁਣੋ

ਸਰਟੀਫਿਕੇਟ ਵਿੱਚ ਉਹ ਹੋਸਟ ਨਾਮ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਦੀ ਗਾਹਕ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਅੰਦਰੂਨੀ ਲੇਬਲ ਜਾਂ ਪਤੇ ਦੀ ਬਜਾਏ ਜਨਤਕ DNS ਨਾਮ ਵਰਤੋ। HTTP-01 ਲਈ ਚੁਣੌਤੀ ਦਾ ਜਵਾਬ ਥੋੜ੍ਹੀ ਦੇਰ ਲਈ ਪੋਰਟ 80 ਉੱਤੇ ਦੇਣਾ ਪੈਂਦਾ ਹੈ, ਇਹ ਅਸਥਾਈ ਸਰੋਤਾ ਹੈ ਅਤੇ SoftEther ਦਾ ਆਪਣਾ ਪੋਰਟ ਹਿਲਾਉਣ ਦਾ ਕਾਰਨ ਕਦੇ ਨਹੀਂ। DNS-01 ਰਿਕਾਰਡ ਰਾਹੀਂ ਨਿਯੰਤਰਣ ਸਿੱਧ ਕਰਦਾ ਹੈ ਅਤੇ ਆਉਂਦੇ HTTP ਦੀ ਬਿਲਕੁਲ ਲੋੜ ਨਹੀਂ।

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

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

ਚੇਨ ਨੂੰ ਸਰਵਰ ਪੱਧਰ ਉੱਤੇ ਦਰਾਮਦ ਕਰੋ

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

ServerCertSet /LOADCERT:/etc/letsencrypt/live/vpn.example.com/fullchain.pem /LOADKEY:/etc/letsencrypt/live/vpn.example.com/privkey.pem

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

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

ਤੈਨਾਤੀ ਨੂੰ ਹੁੱਕ ਕਰੋ, ਨਵੀਨੀਕਰਨ ਨੂੰ ਨਹੀਂ

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

certbot renew --deploy-hook /usr/local/sbin/softether-deploy.sh

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

ਪੇਸ਼ ਕੀਤੀ ਚੇਨ ਦੀ ਫਾਈਲ ਨਾਲ ਤੁਲਨਾ ਕਰੋ

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

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | grep -c 'BEGIN CERTIFICATE'
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -fingerprint -sha256

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