VPN ਕਲਾਇੰਟ ਕੁੰਜੀ ਕਿਵੇਂ ਬਣਾਈਏ ਅਤੇ ਦਸਤਖ਼ਤ ਲਈ CSR ਕਿਵੇਂ ਜਮ੍ਹਾਂ ਕਰੀਏ

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

ਕਦਮ 1: ਕੁੰਜੀ ਉੱਥੇ ਹੀ ਬਣਾਓ ਜਿੱਥੇ ਉਹ ਰਹੇਗੀ

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

ਸੌਫਟਵੇਅਰ ਪ੍ਰਵਾਹ ਇਸ ਤਰ੍ਹਾਂ ਦਿਸਦਾ ਹੈ, ਕੁੰਜੀ ਅਤੇ ਬੇਨਤੀ ਇੱਕੋ ਸੈਸ਼ਨ ਵਿੱਚ ਬਣਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ:

umask 077
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out client.key
openssl req -new -key client.key -out client.csr -subj "/CN=alice-vpn/O=Example"

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

ਕਦਮ 2: ਪਛਾਣ ਬੇਨਤੀ ਵਿੱਚ ਰੱਖੋ, ਈਮੇਲ ਵਿੱਚ ਨਹੀਂ

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

ਜਦੋਂ ਤੁਹਾਡਾ ਪੁਸ਼ਟੀਕਰਤਾ ਇੱਕ ਦੀ ਜਾਂਚ ਕਰੇ ਤਾਂ ਵਿਸ਼ੇ ਦਾ ਬਦਲਵਾਂ ਨਾਮ ਜੋੜੋ, ਕਿਉਂਕਿ ਆਧੁਨਿਕ ਮਿਲਾਨ ਅਕਸਰ ਪੁਰਾਣੇ CN ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦਾ ਹੈ:

openssl req -new -key client.key -out client.csr \
  -subj "/CN=alice-vpn/O=Example" \
  -addext "subjectAltName=DNS:alice-vpn"

CN ਨੂੰ ਛੋਟਾ, ਸਥਿਰ ਅਤੇ ਲੈਪਟਾਪ ਮਾਡਲ ਦੀ ਬਜਾਏ ਖਾਤੇ ਨਾਲ ਬੱਝਾ ਰੱਖੋ। ਜਿਸ ਨਾਮ ਵਿੱਚ ਵਰਤੋਂਕਾਰ ਦੇ ਡਿਵਾਈਸ ਦਾ ਸੀਰੀਅਲ ਨੰਬਰ ਹੋਵੇ ਉਹ ਪਹਿਲੀ ਹਾਰਡਵੇਅਰ ਬਦਲੀ ਦੀ ਉਡੀਕ ਕਰਦੀ ਸਹਾਇਤਾ ਸਮੱਸਿਆ ਹੈ।

ਕਦਮ 3: ਦਸਤਖ਼ਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਬੇਨਤੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

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

ਯੰਤਰਿਕ ਹਿੱਸਾ ਇੱਕ ਹੁਕਮ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਵਿਸ਼ੇ ਨਾਲ ਪੁਸ਼ਟੀ ਨਤੀਜਾ ਛਾਪਣਾ ਚਾਹੀਦਾ ਹੈ:

openssl req -in client.csr -noout -verify -subject
openssl req -in client.csr -noout -pubkey | openssl pkey -pubin -noout -text

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

ਕਦਮ 4: ਅਧਿਕਾਰ ਦਿਓ, ਫਿਰ ਸਪਸ਼ਟ ਐਕਸਟੈਂਸ਼ਨਾਂ ਨਾਲ ਦਸਤਖ਼ਤ ਕਰੋ

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

cat > client.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = digitalSignature
extendedKeyUsage = clientAuth
EOF
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -days 365 -extfile client.ext -out client.crt

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

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

ਕਦਮ 5: ਇਸਨੂੰ ਮੇਲ ਖਾਂਦੀ ਕੁੰਜੀ ਦੇ ਕੋਲ ਸਥਾਪਿਤ ਕਰੋ ਅਤੇ ਜੋੜੀ ਸਾਬਤ ਕਰੋ

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

openssl x509 -in client.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256
openssl pkey -in client.key -pubout -outform DER | openssl sha256

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