OCSP ਬਨਾਮ CRL: ਹਰ ਰੱਦ ਕਰਨ ਵਾਲੀ ਜਾਂਚ ਅਸਲ ਵਿੱਚ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ

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

ਕਦਮ 1: ਹਰ ਜਾਂਚ ਕੀ ਦਿੰਦੀ ਹੈ ਅਤੇ ਕਿੰਨਾ ਚਿਰ ਵਰਤੋਂਯੋਗ ਰਹਿੰਦੀ ਹੈ

CRL ਇੱਕ ਦਸਤਖਤ ਕੀਤੀ ਵਸਤੂ ਵਜੋਂ ਪ੍ਰਕਾਸ਼ਿਤ ਹੁੰਦੀ ਹੈ ਜੋ ਜਾਰੀਕਰਤਾ ਵੱਲੋਂ ਰੱਦ ਕੀਤੇ ਹਰ ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਕਵਰ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਪ੍ਰਮਾਣਕਰਤਾ ਇਸਨੂੰ ਇੱਕ ਵਾਰ ਲੈਂਦਾ ਹੈ ਅਤੇ ਸੂਚੀ ਦਾ nextUpdate ਲੰਘਣ ਤੱਕ ਦੁਬਾਰਾ ਵਰਤਦਾ ਹੈ। OCSP ਜਵਾਬ ਹੋਰ ਸੰਕਰਾ ਹੈ: ਇਹ ਠੀਕ ਇੱਕ ਸਰਟੀਫਿਕੇਟ ਲਈ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਅਤੇ thisUpdate, producedAt ਅਤੇ ਆਮ ਤੌਰ ਉੱਤੇ nextUpdate ਵੀ ਲੈ ਕੇ ਚੱਲਦਾ ਹੈ। ਇਹੀ ਫ਼ਰਕ ਬਾਕੀ ਸਭ ਨੂੰ ਨਿਰਧਾਰਿਤ ਕਰਦਾ ਹੈ। ਕੈਸ਼ ਕੀਤੀ CRL ਚੁੱਪਚਾਪ ਪੁਰਾਣੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਕਿਉਂਕਿ ਫਾਈਲ ਅਜੇ ਵੀ ਪਾਰਸ ਹੁੰਦੀ ਹੈ ਅਤੇ ਇਸ ਦਾ ਦਸਤਖਤ ਅਜੇ ਵੀ ਪ੍ਰਮਾਣਿਤ ਹੁੰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਮਿਆਦ ਪੁੱਗਿਆ OCSP ਜਵਾਬ ਉਸੇ ਪਲ ਸਪਸ਼ਟ ਤੌਰ ਉੱਤੇ ਬੇਕਾਰ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸ ਦੇ ਸਮਾਂ-ਛਾਪ ਪੜ੍ਹਦੇ ਹੋ।

ਇਸ ਲਈ ਕੈਸ਼ਿੰਗ ਪਹਿਲੀ ਚੀਜ਼ ਹੈ ਜੋ ਤੈਅ ਕਰਨੀ ਹੈ: ਕਿਹੜਾ ਹਿੱਸਾ ਕਾਪੀ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਉਹ ਕਾਪੀ ਕਿਹੜੀ ਉੱਪਰੀ ਹੱਦ ਦੀ ਪਾਲਣਾ ਕਰਦੀ ਹੈ। ਗੇਟਵੇ ਉੱਤੇ ਹੱਦ nextUpdate ਘਟਾਓ ਸੁਰੱਖਿਆ ਮਾਰਜਨ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਕਦੇ ਵੀ ਉਹ ਨਹੀਂ ਜੋ ਕੋਈ HTTP ਕੈਸ਼ ਹੈਡਰ ਸੰਜੋਗ ਨਾਲ ਸੁਝਾਉਂਦਾ ਹੈ। openssl crl -in issuer.crl -noout -lastupdate -nextupdate ਦੋਵੇਂ ਤਾਰੀਖਾਂ ਛਾਪਦਾ ਹੈ, ਅਤੇ ਜਿਸ ਸੂਚੀ ਦਾ nextUpdate ਪਹਿਲਾਂ ਹੀ ਬੀਤੇ ਵਿੱਚ ਹੈ, ਉਸਨੂੰ ਸਿਰਫ਼ ਪੁਰਾਣੀ ਨਹੀਂ ਸਗੋਂ ਗੁੰਮ ਮੰਨਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਕਦਮ 2: ਸਰਟੀਫਿਕੇਟ ਕਲਾਇੰਟ ਨੂੰ ਕਿੱਥੇ ਭੇਜਦਾ ਹੈ

ਲੀਫ਼ ਸਰਟੀਫਿਕੇਟ ਆਮ ਤੌਰ ਉੱਤੇ ਦੋ ਸੰਕੇਤ ਰੱਖਦਾ ਹੈ: ਇੱਕ CRL ਵੰਡ ਬਿੰਦੂ ਐਕਸਟੈਂਸ਼ਨ ਅਤੇ OCSP ਲਈ ਇੱਕ ਅਥਾਰਟੀ ਜਾਣਕਾਰੀ ਪਹੁੰਚ ਐਂਟਰੀ। openssl x509 -in client.pem -noout -ext crlDistributionPoints ਪਹਿਲਾ ਛਾਪਦਾ ਹੈ, ਅਤੇ ਦੂਜਾ openssl x509 -in client.pem -noout -text ਦੇ AIA ਭਾਗ ਹੇਠ ਹੈ। ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਐਕਸਟੈਂਸ਼ਨ ਸੰਕੇਤਕ ਹੈ, ਬਾਧਿਆ ਨਹੀਂ। ਜੋ ਕਲਾਇੰਟ ਕਦੇ ਵੀ ਰੱਦ ਕਰਨ ਦੀ ਜਾਂਚ ਲਾਗੂ ਨਹੀਂ ਕਰਦਾ, ਉਹ ਅਜਿਹੇ ਸਰਟੀਫਿਕੇਟ ਨਾਲ ਬਿਲਕੁਲ ਠੀਕ ਜੁੜ ਜਾਵੇਗਾ ਜਿਸ ਦੇ ਐਕਸਟੈਂਸ਼ਨ ਇੱਕ ਸਾਲ ਤੋਂ ਮਰੇ ਪ੍ਰਤਿਕਰਿਆਕਾਰ ਦਾ ਨਾਮ ਦਿੰਦੇ ਹਨ।

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

ਕਦਮ 3: ਰੁਕਾਵਟ ਤੋਂ ਪਹਿਲਾਂ fail-closed ਜਾਂ fail-open ਚੁਣੋ

ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਪ੍ਰਤਿਕਰਿਆਕਾਰ ਜਾਂ ਮਿਆਦ ਪੁੱਗੀ ਸੂਚੀ ਫ਼ੈਸਲਾ ਲੈਣ ਲਈ ਮਜਬੂਰ ਕਰਦੀ ਹੈ: ਕਨੈਕਸ਼ਨ ਰੱਦ ਕਰੋ, ਜਾਂ ਸਵੀਕਾਰ ਕਰੋ ਅਤੇ ਖੱਪਾ ਦਰਜ ਕਰੋ। OpenSSL ਦਾ verify ਸਬਕਮਾਂਡ ਸਖ਼ਤ ਚੋਣ ਨੂੰ ਸਪਸ਼ਟ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ -crl_check ਜੋੜਨ ਨਾਲ ਉਪਲਬਧ ਨਾ ਹੋਣ ਵਾਲੀ CRL unable to get certificate CRL ਅਤੇ ਅਸਫਲ ਪ੍ਰਮਾਣਿਕਤਾ ਬਣ ਜਾਂਦੀ ਹੈ। ਬਹੁਤੀਆਂ ਸਟੈਕਾਂ ਵਿੱਚ ਸਾਫ਼ਟ-ਫੇਲ ਕੋਈ ਝੰਡਾ ਨਹੀਂ ਹੁੰਦਾ, ਉਹ ਜਾਂਚ ਦੀ ਗੈਰਹਾਜ਼ਰੀ ਹੈ, ਅਤੇ ਇਸੇ ਲਈ ਇਹ ਹਾਦਸੇ ਨਾਲ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ।

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

ਕਦਮ 4: ਸਾਬਤ ਕਰੋ ਕਿ ਜਾਂਚ ਉੱਥੇ ਹੀ ਚੱਲਦੀ ਹੈ ਜਿੱਥੇ ਟ੍ਰੈਫਿਕ ਸਵੀਕਾਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ

ਉਹ ਪ੍ਰਕਿਰਿਆ ਲੱਭੋ ਜੋ ਕਨੈਕਸ਼ਨ ਖ਼ਤਮ ਕਰਦੀ ਹੈ ਜਾਂ ਅਧਿਕਾਰ ਦਿੰਦੀ ਹੈ, ਫਿਰ ਉਸ ਤੋਂ ਉਹ ਕਨਫਿਗਰੇਸ਼ਨ ਲਾਈਨ ਪੁੱਛੋ ਜੋ ਰੱਦ ਕਰਨ ਦੀ ਜਾਂਚ ਸਮਰੱਥ ਕਰਦੀ ਹੈ। ਜੋ ਗੇਟਵੇ ਚੇਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਪਰ ਕਦੇ ਵੀ ਰੱਦ ਕਰਨ ਬਾਰੇ ਨਹੀਂ ਪੁੱਛਦਾ, ਉਹ ਤੁਹਾਡੇ ਦਸਤਾਵੇਜ਼ਾਂ ਵਾਲੀ ਨੀਤੀ ਤੋਂ ਵੱਖਰੀ ਨੀਤੀ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਚੇਨ ਦਾ ਕੋਈ ਸਕ੍ਰੀਨਸ਼ਾਟ ਇਸਦਾ ਉਲਟਾ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ। OpenVPN ਇਸ ਵਿਕਲਪ ਨੂੰ crl-verify ਲਿਖਦਾ ਹੈ; strongSwan CRL ਅਤੇ OCSP ਖੋਜਾਂ ਨੂੰ CA ਕਨਫਿਗਰੇਸ਼ਨ ਹੇਠ ਰੱਖਦਾ ਹੈ, ਜਿੱਥੇ crl_uris ਜਾਂ ocsp_uris ਸੈੱਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਵੱਲ ਵੀ ਇਸ਼ਾਰਾ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਮੰਨ ਲਓ ਕਿ ਜਾਂਚ ਗੈਰਹਾਜ਼ਰ ਹੈ।

OCSP ਜਵਾਬ ਤਾਂ ਹੀ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਜਾਰੀ ਕਰਨ ਵਾਲੀ CA ਨੇ ਇਸ ਉੱਤੇ ਦਸਤਖਤ ਕੀਤੇ ਹੋਣ, ਜਾਂ ਜਦੋਂ ਉਸ CA ਵੱਲੋਂ ਸੌਂਪੇ ਗਏ OCSPSigning ਵਿਸਤ੍ਰਿਤ ਕੁੰਜੀ ਵਰਤੋਂ ਵਾਲੇ ਪ੍ਰਤਿਕਰਿਆਕਾਰ ਨੇ ਦਸਤਖਤ ਕੀਤੇ ਹੋਣ, ਇਸ ਲਈ ਅਸੰਬੰਧਿਤ ਸੇਵਾ ਤੋਂ ਆਇਆ ਜਵਾਬ ਕੁਝ ਵੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ। ਜੇ ਤੁਸੀਂ ਖੁਦ ਪ੍ਰਤਿਕਰਿਆਕਾਰ ਚਲਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਸਦੀ ਸਖ਼ਤ ਨਿਰਭਰਤਾ ਵਜੋਂ ਨਿਗਰਾਨੀ ਕਰੋ, ਕਿਉਂਕਿ ਇੱਕ ਮਰੀ ਸੇਵਾ ਇੱਕੋ ਵੇਲੇ ਹਰ fail-closed ਕਲਾਇੰਟ ਲਈ ਰੁਕਾਵਟ ਬਣ ਜਾਂਦੀ ਹੈ।

ਕਦਮ 5: ਜਾਣਬੁੱਝ ਕੇ ਇੱਕ ਸਰਟੀਫਿਕੇਟ ਰੱਦ ਕਰੋ

ਇੱਕ ਟੈਸਟ ਸਰਟੀਫਿਕੇਟ ਲਓ, ਇਸਨੂੰ ਉਸੇ ਚੈਨਲ ਰਾਹੀਂ ਰੱਦ ਕਰੋ ਜੋ ਉਤਪਾਦਨ ਵਰਤਦਾ ਹੈ, ਅਤੇ ਪ੍ਰਤਿਕਰਿਆਕਾਰ ਨੂੰ ਸਿੱਧਾ ਪੁੱਛੋ। openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text ਨੂੰ ਰੱਦ ਕਰਨ ਦੇ ਸਮੇਂ ਸਮੇਤ Cert Status: revoked ਦੀ ਰਿਪੋਰਟ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ good ਜਵਾਬ ਦਾ ਅਰਥ ਹੈ ਕਿ ਤੁਹਾਡਾ ਰੱਦ ਕਰਨਾ ਉਸ ਪ੍ਰਤਿਕਰਿਆਕਾਰ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਿਆ ਜਿਸਨੂੰ ਤੁਹਾਡੇ ਕਲਾਇੰਟ ਪੁੱਛਦੇ ਹਨ। ਫਿਰ ਸੂਚੀ ਮਾਰਗ ਰਾਹੀਂ ਉਹੀ ਫ਼ੈਸਲਾ ਵੇਖਣ ਲਈ openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem ਚਲਾਓ। ਨਿਕਾਸ ਕੋਡ ਦੀ ਥਾਂ ਕਾਰਨ ਸਤਰ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਰੱਦ ਕਰਨ ਦਾ ਇਨਕਾਰ ਅਤੇ ਚੇਨ ਗਲਤੀ ਦੋਵੇਂ ਅਸਫਲਤਾ ਵਿੱਚ ਖ਼ਤਮ ਹੁੰਦੇ ਹਨ।

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