OpenVPN ਪੀਅਰਾਂ ਲਈ ਆਪਣਾ ਮੌਜੂਦਾ ਐਂਟਰਪ੍ਰਾਈਜ਼ CA ਵਰਤੋ

OpenVPN ਵਿੱਚ ਕੁਝ ਵੀ ਸਰਟੀਫਿਕੇਟ ਦੇ Easy-RSA ਤੋਂ ਆਉਣ ਦੀ ਮੰਗ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਜਿਸ ਫਲੀਟ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਸੰਗਠਨਾਤਮਕ PKI ਹੈ ਉਸਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਦੂਜਾ ਨਹੀਂ ਬਣਾਉਣਾ ਚਾਹੀਦਾ। ਅਸਲ ਕੰਮ ਸੰਦ ਚੁਣਨਾ ਨਹੀਂ ਹੈ, ਸਗੋਂ ਇਹ ਤੈਅ ਕਰਨਾ ਹੈ ਕਿ ਜਾਰੀ ਕੀਤੀਆਂ ਪਛਾਣਾਂ ਦਾ ਕੀ ਅਰਥ ਹੈ, ਟਨਲ ਕਿਹੜੇ ਪੀਅਰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਨਵੀਨੀਕਰਨ ਤੇ ਰੱਦ ਕਰਨਾ ਪ੍ਰਮਾਣਕ ਕੋਲ ਕਿਵੇਂ ਪਹੁੰਚਦੇ ਹਨ। ਹੇਠਾਂ ਦਿੱਤੇ ਪੰਜ ਕਦਮ ਕ੍ਰਮ ਵਿੱਚ ਪੂਰੇ ਕਰੋ, ਕਿਉਂਕਿ ਬਾਅਦ ਦਾ ਕਦਮ ਪਹਿਲੇ ਵਿੱਚ ਲਏ ਭੂਮਿਕਾ-ਫੈਸਲੇ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦਾ।

ਇੱਕ ਸਾਂਝੀ ਪਛਾਣ ਦੀ ਥਾਂ ਦੋ ਭੂਮਿਕਾਵਾਂ ਜਾਰੀ ਕਰੋ

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

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

ਹਰ ਪਾਸੇ ਭਰੋਸਾ-ਇਨਪੁੱਟ ਜੋੜੋ

ਕਲਾਇੰਟ ਅਤੇ ਸਰਵਰ ਦੋਵਾਂ ਨੂੰ ਕ੍ਰਮਵਾਰ ਭਰੋਸਾ-ਐਂਕਰ, ਆਪਣੀ ਪਛਾਣ ਅਤੇ ਸਪਸ਼ਟ ਭੂਮਿਕਾ-ਉਮੀਦ ਚਾਹੀਦੀ ਹੈ। ਤਿੰਨੇ ਦਾ ਜ਼ਿਕਰ ਕਰਨ ਵਾਲਾ ਕਲਾਇੰਟ ਟੁਕੜਾ ਇੰਝ ਦਿਸਦਾ ਹੈ।

client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crl

ਸਰਵਰ ਪਾਸਾ remote-cert-tls client ਅਤੇ ਆਪਣੇ ਸਰਟੀਫਿਕੇਟ ਨਾਲ ਇਸਦਾ ਪ੍ਰਤੀਬਿੰਬ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਸਰਵਰ ਵਜੋਂ ਸਵੀਕਾਰ ਹੋਣ ਤੋਂ ਰੋਕਦਾ ਹੈ। ਨਾਮ-ਜਾਂਚ ਭੂਮਿਕਾ-ਜਾਂਚ ਤੋਂ ਵੱਖਰਾ ਫੈਸਲਾ ਹੈ। ਬ੍ਰਾਊਜ਼ਰ-ਸ਼ੈਲੀ ਹੋਸਟਨੇਮ ਮੇਲ ਮੰਨਣ ਦੀ ਥਾਂ ਇਹ ਦੇਖਣ ਲਈ ਤੈਨਾਤ ਕਨਫਿਗਰੇਸ਼ਨ ਪੜ੍ਹੋ ਕਿ ਕਿਹੜਾ ਖੇਤਰ ਤੁਲਨਾ ਵਿੱਚ ਆਉਂਦਾ ਹੈ। ਦੋਵਾਂ ਪਾਸਿਆਂ ਨੂੰ ਇਹ ਵੀ ਸਪਸ਼ਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਉਹ ਕਿਹੜੇ ਜਾਰੀਕਰਤਾ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹਨ, ਕਿਉਂਕਿ ਪੂਰੀ ਫਲੀਟ ਵਿੱਚ ਸਾਂਝਾ ਫਾਈਲ ਪਾਥ ਸਾਂਝੀ ਨੀਤੀ ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਹੈ।

ਭਰੋਸਾ ਵਧਾਏ ਬਿਨਾਂ ਵਿਚਕਾਰਲੇ ਸਰਟੀਫਿਕੇਟ ਪਹੁੰਚਾਓ

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

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

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

ਰੱਦ ਕਰਨਾ ਅਸਲ ਵਿੱਚ ਕਿਵੇਂ ਆਉਂਦਾ ਹੈ ਇਹ ਤੈਅ ਕਰੋ

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

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

ਅਸਲੀ ਕਲਾਇੰਟ ਨਾਲ ਸਵੀਕ੍ਰਿਤੀ ਸਾਬਤ ਕਰੋ

ਜਿਸਨੂੰ ਇਜਾਜ਼ਤ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਅਜਿਹੇ ਕਲਾਇੰਟ ਨੂੰ ਜੋੜੋ ਅਤੇ ਲੌਗ ਵਿੱਚ ਗੱਲਬਾਤ ਕੀਤੇ ਸਰਟੀਫਿਕੇਟ ਦੇ ਵੇਰਵੇ ਪੁਸ਼ਟੀ ਕਰੋ। ਫਿਰ ਉਹ ਕੇਸ ਅਜ਼ਮਾਓ ਜੋ ਅਸਫਲ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ: ਸਰਵਰ ਵਜੋਂ ਪੇਸ਼ ਕੀਤਾ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ, ਭਰੋਸਾ-ਐਂਕਰ ਤੋਂ ਬਾਹਰਲੇ ਜਾਰੀਕਰਤਾ ਦਾ ਸਰਟੀਫਿਕੇਟ, ਅਤੇ ਵਾਧੂ ਹੋਣ 'ਤੇ ਰੱਦ ਕੀਤਾ ਸਰਟੀਫਿਕੇਟ।

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