ਰੱਦ ਕੀਤਾ VPN ਸਰਟੀਫਿਕੇਟ ਅਜੇ ਵੀ ਜੁੜਦਾ ਹੈ? CRL ਲਾਗੂਆਉਣਾ ਜਾਂਚੋ
ਰੱਦ ਕੀਤੇ ਸਰਟੀਫਿਕੇਟ ਅਜੇ ਵੀ ਜੁੜਦੇ ਹਨ ਜਦੋਂ CRL ਕਦੇ ਵੈਰੀਫਾਇਰ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦਾ। ਇਸ ਕ੍ਰਮ ਵਿੱਚ ਜਾਰੀਕਰਤਾ, ਲੋਡ ਕੀਤਾ ਕ੍ਰਮ ਨੰਬਰ, ਮੁੜ ਲੋਡ ਵਿਵਹਾਰ ਅਤੇ ਸਰਗਰਮ ਸੈਸ਼ਨ ਜਾਂਚੋ।
ਤੁਸੀਂ ਸਰਟੀਫਿਕੇਟ ਰੱਦ ਕੀਤਾ, ਨਵੀਂ ਸੂਚੀ ਬਣਾਈ, ਅਤੇ ਪੁਰਾਣੀ ਪ੍ਰੋਫਾਈਲ ਅਜੇ ਵੀ ਟਨਲ ਖੜ੍ਹਾ ਕਰਦੀ ਹੈ। ਰੱਦ ਕਰਨਾ ਆਪਣੇ ਆਪ ਵਿੱਚ ਟੁੱਟਿਆ ਨਹੀਂ: CRL ਇੱਕ ਦਸਤਖ਼ਤ ਕੀਤਾ ਐਲਾਨ ਹੈ ਕਿ ਕ੍ਰਮ ਨੰਬਰ ਹੁਣ ਵੈਧ ਨਹੀਂ, ਅਤੇ ਇਹ ਪਹੁੰਚ ਤਦ ਹੀ ਬਦਲਦਾ ਹੈ ਜਦੋਂ TLS ਖ਼ਤਮ ਕਰਨ ਵਾਲਾ ਹਿੱਸਾ ਇਸਨੂੰ ਸਹੀ ਜਾਰੀਕਰਤਾ ਲਈ ਲੋਡ ਕਰਦਾ ਹੈ, ਮਨਜ਼ੂਰੀ ਦਾ ਫ਼ੈਸਲਾ ਲੈਣ ਤੋਂ ਪਹਿਲਾਂ। ਅਜਿਹੇ ਬਹੁਤੇ ਮਾਮਲੇ ਉੱਥੇ ਹੀ ਹਨ, ਅਤੇ ਇਸੇ ਲਈ ਰੱਦ ਕਰਨਾ ਅਤੇ ਇਨਕਾਰ ਕਰਨਾ ਦੋ ਵੱਖਰੇ ਤੱਥ ਹਨ।
ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਪੰਜ ਜਾਂਚਾਂ ਕ੍ਰਮ ਵਿੱਚ ਕਰੋ ਅਤੇ ਪਹਿਲੀ ਅਸਫਲ ਹੋਣ 'ਤੇ ਰੁਕੋ, ਕਿਉਂਕਿ ਹਰ ਅਗਲੀ ਜਾਂਚ ਪਿਛਲੀ ਨੂੰ ਸਹੀ ਮੰਨਦੀ ਹੈ।
ਜਾਂਚੋ ਕਿ ਕਿਹੜਾ ਹਿੱਸਾ ਮਨਜ਼ੂਰੀ ਦਾ ਫ਼ੈਸਲਾ ਲੈਂਦਾ ਹੈ
ਉਸ ਪ੍ਰਕਿਰਿਆ ਦਾ ਨਾਮ ਦੱਸੋ ਜੋ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਦੀ ਤਸਦੀਕ ਕਰਦੀ ਹੈ, ਕਿਉਂਕਿ ਸਿਰਫ਼ ਉਹੀ ਪ੍ਰਕਿਰਿਆ ਸੂਚੀ ਲਾਗੂ ਕਰ ਸਕਦੀ ਹੈ। OpenVPN ਸਰਵਰ 'ਤੇ ਇਹ ਡੈਮਨ ਆਪ ਹੈ, crl-verify ਨਾਲ ਸੰਰਚਿਤ। ocserv ਵਿੱਚ ਇਹ ocserv.conf ਅੰਦਰ crl ਲਾਈਨ ਹੈ। strongSwan ਵਿੱਚ ਇਨਪੁਟ ਲੋਡ ਕੀਤੀਆਂ CRL ਹਨ strictcrlpolicy ਸਮੇਤ। VPN ਦੇ ਸਾਹਮਣੇ TLS ਖ਼ਤਮ ਕਰਨ ਵਾਲਾ ਪ੍ਰਾਕਸੀ ਜਾਂ ਜੰਤਰ ਵੀ ਅਸਲ ਵੈਰੀਫਾਇਰ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਜੇ ਅਜਿਹਾ ਹੈ ਤਾਂ ਉਸਦੇ ਪਿੱਛੇ ਦਾ ਡੈਮਨ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਕਦੇ ਨਹੀਂ ਵੇਖਦਾ।
WireGuard ਵੱਖਰੀ ਸ਼੍ਰੇਣੀ ਵਿੱਚ ਆਉਂਦਾ ਹੈ। ਇਸ ਕੋਲ ਨ ਸਰਟੀਫਿਕੇਟ ਹਨ ਨ ਰੱਦ ਕਰਨ ਦੀ ਸੂਚੀ; ਪੀਅਰ ਨੂੰ ਸੰਰਚਨਾ ਵਿੱਚ ਉਸਦੀ ਜਨਤਕ ਕੁੰਜੀ ਰਾਹੀਂ ਸਵੀਕਾਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਪਹੁੰਚ ਖ਼ਤਮ ਕਰਨ ਦਾ ਅਰਥ ਉਹ ਕੁੰਜੀ ਹਟਾਉਣਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ WireGuard ਵਾਲੀ ਤੈਨਾਤੀ ਵਿੱਚ CRL ਲੱਭ ਰਹੇ ਹੋ, ਤਾਂ ਉਹ ਵਿਧੀ ਉੱਥੇ ਨਹੀਂ ਹੈ।
ਕਲਾਇੰਟ ਪਾਸੇ ਦੇ ਜਾਲ ਤੋਂ ਵੀ ਸਾਵਧਾਨ ਰਹੋ। ਜੋ ਕਲਾਇੰਟ ਸਰਵਰ ਦਾ ਸਰਟੀਫਿਕੇਟ ਪਸੰਦ ਨਾ ਆਉਣ 'ਤੇ ਜੁੜਨ ਤੋਂ ਇਨਕਾਰ ਕਰਦਾ ਹੈ, ਉਹ ਸਰਵਰ ਦੀ ਲੜੀ ਲਾਗੂ ਕਰ ਰਿਹਾ ਹੈ, ਆਪਣੇ ਪ੍ਰਮਾਣ ਰੱਦ ਨਹੀਂ ਕਰ ਰਿਹਾ। ਵਰਤੋਂਕਾਰ ਸਰਟੀਫਿਕੇਟ ਸਿਰਫ਼ ਉੱਥੇ ਹੀ ਰੱਦ ਹੁੰਦਾ ਹੈ ਜਿੱਥੇ ਉਹ ਸਰਟੀਫਿਕੇਟ ਤਸਦੀਕ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਉਹ ਲਗਭਗ ਹਮੇਸ਼ਾ ਸਰਵਰ ਪਾਸਾ ਹੁੰਦਾ ਹੈ।
ਜਾਂਚੋ ਕਿ ਸੂਚੀ ਕਿਸ ਜਾਰੀਕਰਤਾ ਲਈ ਦਸਤਖ਼ਤ ਕੀਤੀ ਗਈ ਹੈ
CRL ਇੱਕ ਜਾਰੀਕਰਤਾ CA ਤੱਕ ਸੀਮਤ ਹੈ। ਜੜ੍ਹ ਅਤੇ ਮੱਧਵਰਤੀ CA ਨਾਲ ਪੱਤਿਆਂ ਦੇ ਸਰਟੀਫਿਕੇਟ ਮੱਧਵਰਤੀ ਤੋਂ ਆਉਂਦੇ ਹਨ, ਇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਸੂਚੀ ਮੱਧਵਰਤੀ ਦੀ CRL ਹੈ; ਜੜ੍ਹ ਦੀ ਸੂਚੀ ਉਨ੍ਹਾਂ ਪੱਤਿਆਂ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ। ਗ਼ਲਤ ਫਾਈਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ ਵੈਰੀਫਾਇਰ ਇਸਨੂੰ ਖੁਸ਼ੀ ਨਾਲ ਪਾਰਸ ਕਰਦਾ ਹੈ, ਕੋਈ ਮਿਲਦੀ ਐਂਟਰੀ ਨਹੀਂ ਲੱਭਦਾ ਅਤੇ ਸਭ ਕੁਝ ਸਵੀਕਾਰ ਕਰ ਲੈਂਦਾ ਹੈ।
ਡੈਮਨ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਜੋੜੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਸਰਟੀਫਿਕੇਟ 'ਤੇ ਜਾਰੀਕਰਤਾ ਸੂਚੀ ਦੇ subject ਨਾਲ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ:
openssl x509 -in client.crt -noout -issuer -serial
openssl crl -in intermediate.crl -noout -issuer -lastupdate -nextupdateਜਦੋਂ ਦੋਵੇਂ ਇੱਕੋ CA ਤੋਂ ਆਉਂਦੇ ਹਨ, ਸਰਟੀਫਿਕੇਟ ਲਈ ਛਾਪਿਆ ਕ੍ਰਮ ਨੰਬਰ ਉਹੀ ਮੁੱਲ ਹੈ ਜੋ ਸੂਚੀ ਵਿੱਚ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਉਹ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਗ਼ਲਤ CRL ਜਾਂ ਉਸਦੀ ਗ਼ਲਤ ਨਕਲ ਹੈ।
ਵੈਧਤਾ ਉਸੇ ਜਾਂਚ ਦੀ ਹੈ। ਅਤੀਤ ਵਿੱਚ nextUpdate ਸੂਚੀ ਨੂੰ ਪੁਰਾਣੀ ਬਣਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਬੰਦ ਰੂਪ ਵਿੱਚ ਅਸਫਲ ਹੋਣ ਵਾਲਾ ਵੈਰੀਫਾਇਰ ਤਦ ਸਿਰਫ਼ ਰੱਦ ਕੀਤੇ ਦੀ ਬਜਾਏ ਹਰ ਕਲਾਇੰਟ ਨੂੰ ਇਨਕਾਰ ਕਰੇਗਾ।
ਜਾਂਚੋ ਕਿ ਕ੍ਰਮ ਨੰਬਰ ਉਸ ਨਕਲ ਵਿੱਚ ਹੈ ਜੋ ਡੈਮਨ ਨੇ ਲੋਡ ਕੀਤੀ
ਰੱਦ ਕਰਨਾ CA ਡੇਟਾਬੇਸ ਵਿੱਚ ਐਂਟਰੀ ਲਿਖਦਾ ਹੈ, ਅਤੇ ਮੁੜ ਉਤਪਾਦਨ ਨਵੀਂ ਫਾਈਲ ਲਿਖਦਾ ਹੈ। ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਕਾਰਵਾਈ ਸ਼ੁਰੂ ਹੁੰਦਿਆਂ ਪੁਰਾਣੀ ਨਕਲ ਲੋਡ ਕੀਤੇ ਚੱਲ ਰਹੇ ਡੈਮਨ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦੀ। ਸੂਚੀ ਡੰਪ ਕਰੋ ਅਤੇ ਕ੍ਰਮ ਨੰਬਰ ਲੱਭੋ:
openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crlਫਿਰ ਜਾਂਚੋ ਕਿ ਤੁਹਾਡਾ ਲਾਗੂਕਰਨ ਫਾਈਲ ਕਿਵੇਂ ਲੈਂਦਾ ਹੈ। OpenVPN crl-verify ਨੂੰ ਦਿੱਤਾ ਮਾਰਗ ਸ਼ੁਰੂ ਹੁੰਦਿਆਂ ਇੱਕ ਵਾਰ ਪੜ੍ਹਦਾ ਹੈ, ਇਸ ਲਈ ਨਵੀਂ ਸੂਚੀ ਲਈ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨਾ ਜਾਂ ਮੁੜ ਸ਼ੁਰੂ ਸੰਕੇਤ ਲਾਜ਼ਮੀ ਹੈ; ਉਹੀ ਵਿਕਲਪ ਕਿਸੇ ਡਾਇਰੈਕਟਰੀ ਵੱਲ ਹੋਵੇ ਤਾਂ ਹਰ ਕਨੈਕਸ਼ਨ 'ਤੇ ਮੁੜ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਸੇ ਲਈ ਡਾਇਰੈਕਟਰੀ ਮੋਡ ਹੈ। strongSwan ਨੂੰ ਆਪਣੇ ਪ੍ਰਮਾਣ ਮੁੜ ਲੋਡ ਕਰਨੇ ਪੈਂਦੇ ਹਨ, ਉਦਾਹਰਨ ਲਈ swanctl --load-creds ਨਾਲ। ਫਾਈਲ ਦਾ ਡਿਸਕ 'ਤੇ ਸਹੀ ਹੋਣਾ ਅਤੇ ਵੈਰੀਫਾਇਰ ਦਾ ਉਸਨੂੰ ਵਰਤਣਾ ਦੋ ਵੱਖਰੇ ਤੱਥ ਹਨ।
ਗੁੰਮ ਜਾਂ ਮਿਆਦ ਪੁੱਗੀ ਸੂਚੀ ਦੀ ਨੀਤੀ ਜਾਂਚੋ
ਇਹ ਉਹ ਫ਼ੈਸਲਾ ਹੈ ਜੋ ਬਹੁਤ ਸਾਰੀਆਂ ਤੈਨਾਤੀਆਂ ਕਦੇ ਸਪੱਸ਼ਟ ਰੂਪ ਵਿੱਚ ਨਹੀਂ ਲੈਂਦੀਆਂ, ਅਤੇ ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਰੱਦ ਕਰਨਾ ਤੁਹਾਡੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ ਜਾਂ ਸਭ ਨੂੰ ਬਾਹਰ ਬੰਦ ਕਰਦਾ ਹੈ। Fail-closed ਦਾ ਅਰਥ ਹੈ ਕਿ ਵਰਤਣਯੋਗ ਰੱਦ ਜਾਣਕਾਰੀ ਤੋਂ ਬਿਨਾਂ ਇਨਕਾਰ ਹੁੰਦਾ ਹੈ; fail-open ਦਾ ਅਰਥ ਹੈ ਕਿ ਵੈਰੀਫਾਇਰ ਉਸ ਤੋਂ ਬਿਨਾਂ ਅੱਗੇ ਵਧਦਾ ਹੈ। strongSwan ਚੋਣ ਨੂੰ strictcrlpolicy ਵਜੋਂ ਦਿਖਾਉਂਦਾ ਹੈ। OpenVPN crl-verify ਨਾਲ ਅਜਿਹੀ ਫਾਈਲ 'ਤੇ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਇਨਕਾਰ ਕਰਦਾ ਹੈ ਜਿਸਨੂੰ ਉਹ ਪੜ੍ਹ ਜਾਂ ਪਾਰਸ ਨਹੀਂ ਸਕਦਾ, ਅਤੇ ਮਿਆਦ ਪੁੱਗੀ ਸੂਚੀ ਚੁੱਪ ਸਵੀਕ੍ਰਿਤੀ ਦੀ ਬਜਾਏ ਮਿਆਦ ਪੁੱਗੀ CRL ਬਾਰੇ TLS ਤਸਦੀਕ ਗ਼ਲਤੀ ਵਜੋਂ ਦਿਖਦੀ ਹੈ।
| State of the revocation data | Fail-closed result | Fail-open result |
|---|---|---|
| List missing or unreadable | Verification fails, so expect an outage | Every client connects, including the revoked one |
List past nextUpdate | Validation errors until a fresh list is deployed | Old status is trusted indefinitely |
| Revoked serial present in the loaded list | Handshake rejected for that certificate | Handshake rejected for that certificate |
ਤੁਸੀਂ ਕੋਈ ਵੀ ਦਿਸ਼ਾ ਚੁਣੋ, ਸਵੈਚਾਲਨ ਚੋਣ ਤੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹੈ: CRL ਨੂੰ nextUpdate ਤੋਂ ਪਹਿਲਾਂ ਮੁੜ ਬਣਾਉਣ ਵਾਲਾ ਕੰਮ, ਅਤੇ ਤੈਨਾਤ ਨਕਲ ਪੁਰਾਣੀ ਹੋਣ 'ਤੇ ਚੇਤਾਵਨੀ, ਦੋਵੇਂ ਨੀਤੀਆਂ ਨੂੰ ਘਟਨਾ ਬਣਨ ਤੋਂ ਰੋਕਦੇ ਹਨ। OCSP ਨਾਲ ਆਨਲਾਈਨ ਜਾਂਚ ਤਾਜ਼ਗੀ ਨੂੰ ਜਵਾਬਦਾਤਾ ਵੱਲ ਲੈ ਜਾਂਦੀ ਹੈ, ਪਰ ਉਹੀ ਨਿਯਮ ਲਾਗੂ ਹੈ, ਕਿਉਂਕਿ ਜਵਾਬ ਜਾਂਚਣ ਲਈ ਸੰਰਚਿਤ ਨਾ ਕੀਤਾ ਵੈਰੀਫਾਇਰ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ।
ਸਰਗਰਮ ਸੈਸ਼ਨ ਜਾਂਚੋ, ਫਿਰ ਕੁੰਜੀ ਦੀਆਂ ਨਕਲਾਂ
ਰੱਦ ਕਰਨ ਦਾ ਮੁਲਾਂਕਣ ਸਰਟੀਫਿਕੇਟ ਤਸਦੀਕ ਦੌਰਾਨ ਹੁੰਦਾ ਹੈ, ਜੋ ਜੁੜਦਿਆਂ ਅਤੇ ਮੁੜ ਗੱਲਬਾਤ ਵੇਲੇ ਹੁੰਦਾ ਹੈ। ਸਥਾਪਿਤ ਸੈਸ਼ਨ ਮੁੜ ਗੱਲਬਾਤ ਹੋਣ ਤੱਕ ਚੱਲਦਾ ਹੈ, ਅਤੇ OpenVPN ਦਾ ਡਿਫ਼ਾਲਟ reneg-sec 3600 ਨਾਲ ਘੰਟੇ ਵਿੱਚ ਇੱਕ ਵਾਰ ਹੈ। ਜੇ ਵਿਅਕਤੀ ਨੂੰ ਹੁਣੇ ਨੈੱਟਵਰਕ ਤੋਂ ਬਾਹਰ ਜਾਣਾ ਹੈ, ਤਾਂ ਸੂਚੀ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਦੇ ਨਾਲ ਸੈਸ਼ਨ ਵੀ ਖ਼ਤਮ ਕਰੋ, ਅਤੇ ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਮੁੜ ਜੁੜਨਾ ਇਨਕਾਰ ਹੁੰਦਾ ਹੈ।
ਪ੍ਰਮਾਣਾਂ ਨੂੰ ਉਨ੍ਹਾਂ ਦੀਆਂ ਨਕਲਾਂ ਤੋਂ ਵੱਖ ਰੱਖੋ। ਇੱਕ ਲੈਪਟਾਪ 'ਤੇ ਪ੍ਰੋਫਾਈਲ ਮਿਟਾਉਣਾ ਉਸੇ ਨਿੱਜੀ ਕੁੰਜੀ ਦੀ ਦੂਜੀ ਨਕਲ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਹੋਣ ਤੋਂ ਨਹੀਂ ਰੋਕਦਾ; ਰੱਦ ਕਰਨਾ ਹੀ ਹਰ ਨਕਲ ਨੂੰ ਬੇਕਾਰ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਉਹ ਵੀ ਤਦ ਜਦੋਂ ਪਿਛਲੀਆਂ ਜਾਂਚਾਂ ਸਹੀ ਹੋਣ। ਬਦਲਵੇਂ ਜੰਤਰ ਨੂੰ ਆਪਣਾ ਸਰਟੀਫਿਕੇਟ ਦਿਓ ਤਾਂ ਜੋ ਇੱਕ ਨੂੰ ਦੂਜੇ ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਰੱਦ ਕੀਤਾ ਜਾ ਸਕੇ।
ਇਸਨੂੰ ਪੂਰਾ ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ: ਤਸਦੀਕ ਕਰਨ ਵਾਲਾ ਹਿੱਸਾ ਪਛਾਣਿਆ ਗਿਆ ਹੈ, ਸੂਚੀ ਦਾ ਜਾਰੀਕਰਤਾ ਪੱਤੇ ਦੇ ਜਾਰੀਕਰਤਾ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ, ਰੱਦ ਕੀਤਾ ਕ੍ਰਮ ਨੰਬਰ ਉਸ ਨਕਲ ਵਿੱਚ ਹੈ ਜੋ ਡੈਮਨ ਨੇ ਅਸਲ ਵਿੱਚ ਲੋਡ ਕੀਤੀ, ਗੁੰਮ ਜਾਂ ਮਿਆਦ ਪੁੱਗੀਆਂ ਸੂਚੀਆਂ ਦੀ ਨੀਤੀ ਜਾਣਬੁੱਝ ਕੇ ਹੈ ਅਤੇ ਨਿਗਰਾਨੀ ਹੇਠ ਹੈ, ਅਤੇ ਸਰਗਰਮ ਸੈਸ਼ਨ ਉਡੀਕਣ ਦੀ ਬਜਾਏ ਖ਼ਤਮ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਨ੍ਹਾਂ ਸਭ ਦੇ ਪਿੱਛੇ ਦੇ ਫਾਰਮੈਟ RFC 5280 ਵਿੱਚ ਦਰਸਾਏ ਗਏ ਹਨ।