VPN ਦੀ ਨਿੱਜੀ ਕੁੰਜੀ ਕਿੱਥੇ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ: ਫਾਇਲ, CNG ਜਾਂ TPM?

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

ਕਾਪੀ ਅਤੇ ਵਰਤੋਂ ਵਿਚਕਾਰ ਚੁਣੋ

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

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

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

ਭੰਡਾਰ ਨੂੰ ਟਨਲ ਡੈਮਨ ਨਾਲ ਮਿਲਾਓ

ਡੈਮਨ ਇਸਨੂੰ ਸੁਰੱਖਿਆ ਨੀਤੀ ਤੋਂ ਵੱਧ ਸੀਮਿਤ ਕਰਦਾ ਹੈ। WireGuard ਫਾਇਲ ਜਾਂ wg set ਇਨਪੁਟ ਤੋਂ base64 ਨਿੱਜੀ ਕੁੰਜੀ ਲੈਂਦਾ ਹੈ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਭੰਡਾਰ ਤੱਕ ਕੋਈ ਰਾਹ ਨਹੀਂ ਰੱਖਦਾ, ਇਸ ਲਈ TPM ਸਮਰਥਿਤ ਇੰਟਰਫੇਸ ਕੁੰਜੀ ਵਿਚਾਰ ਵਿੱਚ ਨਹੀਂ। OpenSSL 3 ਵਿਰੁੱਧ ਬਣਿਆ OpenVPN ਕੁੰਜੀ ਨੂੰ ਪ੍ਰਦਾਤਾ URI ਰਾਹੀਂ ਲੋਡ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ strongSwan PKCS#11 ਸਮਰਥਨ ਦੇ ਨਾਲ TPM ਪਲੱਗਇਨ ਦਿੰਦਾ ਹੈ, ਪਰ ਦੋਵੇਂ ਇਸ ਉੱਤੇ ਨਿਰਭਰ ਹਨ ਕਿ ਤੁਹਾਡਾ ਪੈਕੇਜ ਕਿਵੇਂ ਕੰਪਾਇਲ ਹੋਇਆ।

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

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

ਕੁੰਜੀ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਸੂਚੀ ਬਣਾਓ

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

openssl x509 -in vpn.crt -noout -subject -ext subjectAltName
openssl pkey -in vpn.key -check -noout
openssl x509 -in vpn.crt -noout -pubkey | openssl sha256
openssl pkey -in vpn.key -pubout | openssl sha256

ਆਖਰੀ ਦੋ ਸਾਰ ਸਮਾਨ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਜੇ ਨਹੀਂ, ਡੈਮਨ ਸੈਟਅੱਪ ਪੂਰਾ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਹਰ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ ਸਰਟੀਫਿਕੇਟ ਜਾਂ ਦਸਤਖ਼ਤ ਗਲਤੀ ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ ਜੋ ਅਸਲ ਕਾਰਨ ਦੇ ਨੇੜੇ ਕਿਤੇ ਇਸ਼ਾਰਾ ਨਹੀਂ ਕਰਦੀ। WireGuard ਦਾ ਬਰਾਬਰ ਛੋਟਾ ਹੈ, ਕਿਉਂਕਿ ਜਨਤਕ ਕੁੰਜੀ ਸਿੱਧੀ ਨਿੱਜੀ ਤੋਂ ਲਈ ਜਾਂਦੀ ਹੈ: wg pubkey < /etc/wireguard/wg0.key ਨੂੰ ਉਹ ਸਾਥੀ ਕੁੰਜੀ ਛਾਪਣੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਤੁਹਾਡਾ ਸਰਵਰ ਪਹਿਲਾਂ ਹੀ ਸੰਭਾਲਦਾ ਹੈ।

ਇਜਾਜ਼ਤਾਂ ਉਸੇ ਸੂਚੀ ਦਾ ਹਿੱਸਾ ਹਨ। stat -c '%a %U:%G' /etc/wireguard/wg0.key ਨੂੰ 600 root:root ਵਾਪਸ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਜੋ ਕੁਝ ਗਰੁੱਪ ਜਾਂ ਦੁਨੀਆ ਲਈ ਪੜ੍ਹਿਆ ਜਾ ਸਕੇ ਉਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕੁੰਜੀ ਪਹਿਲਾਂ ਹੀ ਉਹਨਾਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਲਈ ਉਪਲਬਧ ਸੀ ਜਿਨ੍ਹਾਂ ਦੀ ਤੁਸੀਂ ਕਦੇ ਕਲਪਨਾ ਨਹੀਂ ਕੀਤੀ।

ਭੰਡਾਰ ਅਤੇ ਵਰਤੋਂ ਦਾ ਰਾਹ ਜਾਂਚੋ

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

certutil -store -user My
certutil -csp "Microsoft Platform Crypto Provider" -key -user
certutil -verifykeys -user My
ipsec listcerts

Windows ਉੱਤੇ ਪਹਿਲੀ ਕਮਾਂਡ ਨਿੱਜੀ ਭੰਡਾਰ ਸੂਚੀਬੱਧ ਕਰਦੀ ਹੈ ਅਤੇ ਹਰ ਐਂਟਰੀ ਦੇ ਨਾਲ ਕੁੰਜੀ ਪ੍ਰਦਾਤਾ ਛਾਪਦੀ ਹੈ, ਅਤੇ ਉੱਥੇ ਹੀ ਇੱਕ ਸਰਟੀਫਿਕੇਟ ਦਿਸਦਾ ਹੈ ਜੋ ਹਾਰਡਵੇਅਰ-ਸਮਰਥਿਤ ਲੱਗਦਾ ਹੈ ਪਰ ਸੌਫਟਵੇਅਰ ਪ੍ਰਦਾਤਾ ਵਿੱਚ ਬੈਠਾ ਹੈ। ਦੂਜੀ ਪਲੇਟਫਾਰਮ ਕ੍ਰਿਪਟੋ ਪ੍ਰਦਾਤਾ ਕੋਲ ਦੀਆਂ ਕੁੰਜੀਆਂ ਸੂਚੀਬੱਧ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਉੱਥੇ ਗੈਰਹਾਜ਼ਰ VPN ਪਛਾਣ ਜਦੋਂਕਿ ਉਸਦਾ ਸਰਟੀਫਿਕੇਟ ਮੌਜੂਦ ਹੋਵੇ, ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਨਿੱਜੀ ਅੱਧ ਕਿਤੇ ਹੋਰ ਰਹਿੰਦਾ ਹੈ। Linux ਗੇਟਵੇ ਉੱਤੇ ipsec listcerts ਦੱਸਦਾ ਹੈ ਕਿ strongSwan ਨੇ ਕੀ ਲੋਡ ਕੀਤਾ, TPM ਪਲੱਗਇਨ ਤੋਂ ਆਈਆਂ ਕੁੰਜੀਆਂ ਸਮੇਤ। ਐਂਟਰੀਆਂ ਦੀ ਗਿਣਤੀ ਉੱਤੇ ਭਰੋਸੇ ਦੀ ਥਾਂ ਫਿੰਗਰਪ੍ਰਿੰਟ ਜਾਂ ਜਨਤਕ ਕੁੰਜੀ ਹੈਸ਼ਾਂ ਦੀ ਸੂਚੀ ਨਾਲ ਤੁਲਨਾ ਕਰੋ।

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

ਨਵੀਨੀਕਰਨ ਅਤੇ ਵਾਪਸੀ ਲਿਖੋ

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

ਸਮਾਪਤੀ ਨੂੰ ਰੁਕਾਵਟ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚੋ: openssl x509 -in vpn.crt -noout -checkend 2592000 ਗੈਰ-ਸਿਫ਼ਰ ਕੋਡ ਨਾਲ ਖਤਮ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਸਰਟੀਫਿਕੇਟ ਤੀਹ ਦਿਨਾਂ ਵਿੱਚ ਸਮਾਪਤ ਹੋਵੇ, ਇਸ ਲਈ ਇਹ ਸਿੱਧਾ ਨਿਗਰਾਨੀ ਜਾਂਚ ਵਿੱਚ ਆ ਜਾਂਦਾ ਹੈ। ਉਸ ਲਾਈਨ ਦਾ ਹਫ਼ਤਾਵਾਰੀ ਚੱਲਣਾ ਉਹ ਨਵੀਨੀਕਰਨ ਫੜਦਾ ਹੈ ਜਿਸਨੂੰ ਕਿਸੇ ਨੇ ਯੋਜਨਾਬੱਧ ਨਹੀਂ ਕੀਤਾ ਸੀ।

ਹਟਾਉਣਾ ਸਰਵਰ ਉੱਤੇ ਹੁੰਦਾ ਹੈ: ਸਾਥੀ ਮਿਟਾਓ ਜਾਂ ਕ੍ਰਮ ਨੰਬਰ ਰੱਦ ਕਰੋ, ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਟਨਲ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਕੈਸ਼ ਕੀਤੇ ਸੈਸ਼ਨ ਵਾਲਾ ਕਲਾਇੰਟ ਅੱਧਾ ਪੂਰਾ ਰੱਦ ਕਰਨਾ ਕੁਝ ਸਮਾਂ ਲੁਕਾ ਸਕਦਾ ਹੈ। ਰੱਦ ਕਰਨਾ ਸਿਰਫ਼ CA ਡੇਟਾਬੇਸ ਤੱਕ ਨਹੀਂ, ਕੇਂਦਰੀਕਰਨ ਦੇ CRL ਜਾਂ OCSP ਰਾਹ ਤੱਕ ਵੀ ਪਹੁੰਚਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਰਟੀਫਿਕੇਟ ਜਨਤਕ ਦਸਤਾਵੇਜ਼ ਹੈ, ਅਤੇ RFC 5280 ਪਰੋਫਾਈਲ ਦੱਸਦਾ ਹੈ ਕਿ ਇਸਦੀ ਤਸਦੀਕ ਕਿਵੇਂ ਹੁੰਦੀ ਹੈ; ਉਸ ਤਸਦੀਕ ਦਾ ਕੋਈ ਹਿੱਸਾ ਘੁੰਮਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਕਾਪੀ ਕੀਤੀ ਨਿੱਜੀ ਕੁੰਜੀ ਦੀ ਰੱਖਿਆ ਨਹੀਂ ਕਰਦਾ।

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