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

ਕਲਾਇੰਟ ਜੋ ਮੰਗਦਾ ਹੈ ਉਹ ਪਛਾਣ ਹੈ

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

ItemWhat it can doWhat it cannot do
CA or server certificateValidate the gateway's chainAuthenticate this client
Client certificate without keyNothing for authenticationProve possession of anything
Identity (cert plus key)Answer the authentication challengeGuarantee the gateway accepts it

ਇਸ ਲਈ .cer ਫ਼ਾਈਲ ਆਯਾਤ ਕਰਨ ਨਾਲ ਕਦੇ ਵੀ ਵਰਤੋਂਯੋਗ ਕਲਾਇੰਟ ਪਛਾਣ ਨਹੀਂ ਬਣਦੀ। ਫ਼ਾਈਲ ਵਿੱਚ ਸਿਰਫ਼ ਜਨਤਕ ਸਮੱਗਰੀ ਹੁੰਦੀ ਹੈ। ਨਾਮ ਬਦਲਣ ਜਾਂ ਭਰੋਸਾ ਦੇਣ ਨਾਲ ਇਹ ਕੁੰਜੀ-ਜੋੜੀ ਨਹੀਂ ਬਣਦੀ।

ਚੁਣਨ ਵਾਲਾ ਖਾਲੀ ਰਹਿਣ ਦੇ ਤਿੰਨ ਕਾਰਨ

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

security find-identity -v -p ssl-client

ਇਹ ਉਹਨਾਂ ਪਛਾਣਾਂ ਦੀ ਸੂਚੀ ਦਿੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਿਸਟਮ ਕਲਾਇੰਟ ਪ੍ਰਮਾਣੀਕਰਨ ਲਈ ਵੈਧ ਮੰਨਦਾ ਹੈ। ਜੇ ਗਿਣਤੀ ਸਿਫ਼ਰ ਹੈ, ਤਾਂ ਸਮੱਸਿਆ VPN ਕਲਾਇੰਟ ਤੋਂ ਪਹਿਲਾਂ ਹੈ ਅਤੇ ਪ੍ਰੋਫ਼ਾਈਲ ਦਾ ਕੋਈ ਸੋਧ ਇਸਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰੇਗਾ। ਜੇ ਪਛਾਣ ਇੱਥੇ ਦਿਸਦੀ ਹੈ ਪਰ ਕਲਾਇੰਟ ਵਿੱਚ ਨਹੀਂ, ਤਾਂ ਫ਼ਰਕ ਕਲਾਇੰਟ ਦੇ ਸਟੋਰ ਜਾਂ ਦਾਇਰੇ ਵਿੱਚ ਹੈ।

ਨਿੱਜੀ ਕੁੰਜੀ ਕਿੱਥੇ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ ਕੌਣ ਇਸਨੂੰ ਵਰਤ ਸਕਦਾ ਹੈ

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

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

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

ਪ੍ਰੋਫ਼ਾਈਲ ਪ੍ਰਮਾਣ ਵੱਲ ਕਿਵੇਂ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ

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

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

ਚੋਣ ਅਤੇ ਸਵੀਕ੍ਰਿਤੀ ਵੱਖਰੇ ਪੜਾਅ ਹਨ

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

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

ਸੰਬੰਧਿਤ ਲੇਖ