ਰੂਪਾਂਤਰਣ ਤੋਂ ਪਹਿਲਾਂ: SSH ਕੁੰਜੀ ਬਨਾਮ OpenVPN ਸਰਟੀਫਿਕੇਟ
authorized_keys ਦੀ ਇੱਕ ਲਾਈਨ, OpenSSH ਸਰਟੀਫਿਕੇਟ ਅਤੇ X.509 ਸਰਟੀਫਿਕੇਟ ਵੱਖਰੀਆਂ ਵਸਤੂਆਂ ਹਨ। ਕੁਝ ਵੀ ਰੂਪਾਂਤਰਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚੋ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਕਿਹੜੀ ਹੈ।
ਸਰਟੀਫਿਕੇਟ ਗਲਤੀ ਨਾਲ ਆਯਾਤ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਸਪਸ਼ਟ ਕਦਮ ਰੂਪਾਂਤਰਣ ਵਰਗਾ ਲੱਗਦਾ ਹੈ। ਇਹ ਪ੍ਰਵਿਰਤੀ ਲੋਕਾਂ ਨੂੰ ਅਜਿਹੇ ਰਾਹ ਲੈ ਜਾਂਦੀ ਹੈ ਜਿੱਥੇ ਫਾਈਲ ਦਾ ਐਕਸਟੈਂਸ਼ਨ ਬਦਲਦਾ ਹੈ ਪਰ ਅਸਵੀਕਾਰ ਬਿਲਕੁਲ ਉਹੀ ਰਹਿੰਦਾ ਹੈ। authorized_keys ਵਿੱਚ ssh-ed25519 ਲਾਈਨ ਅਤੇ OpenVPN ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਵੱਖਰੀਆਂ ਪਛਾਣ-ਵਸਤੂਆਂ ਹਨ, ਜਿਨ੍ਹਾਂ ਦੇ ਜਾਰੀਕਰਤਾ ਵੱਖਰੇ, ਐਨਕੋਡਿੰਗ ਵੱਖਰੀ ਅਤੇ ਰੱਦ ਕਰਨ ਦੇ ਰਾਹ ਵੱਖਰੇ ਹਨ। ਇਹ ਜਾਂਚਾਂ ਕ੍ਰਮ ਵਿੱਚ ਕੀਤੀਆਂ ਤਾਂ ਇੱਕ ਮਿੰਟ ਵਿੱਚ ਪਤਾ ਲੱਗ ਜਾਵੇਗਾ ਕਿ ਰੂਪਾਂਤਰਣ ਨਾਲ ਕੋਈ ਮਦਦ ਹੋ ਸਕਦੀ ਹੈ ਜਾਂ ਨਹੀਂ।
ਅਸਲ ਵਿੱਚ ਕਿਹੜੀ ਵਸਤੂ ਤੁਹਾਡੇ ਕੋਲ ਹੈ?
ਲੋਕ ਪੰਜ ਚੀਜ਼ਾਂ ਨੂੰ ਕੁੰਜੀ ਕਹਿੰਦੇ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਉਹ ਹੈ ਜੋ TLS ਪ੍ਰੋਫਾਈਲ ਚਾਹੁੰਦਾ ਹੈ। SSH ਜਨਤਕ ਕੁੰਜੀ ਕਿਸਮ-ਉਪਸਰਗ ਅਤੇ base64 ਪੇਲੋਡ ਵਾਲੀ ਇੱਕ ਲਾਈਨ ਦਾ ਪਾਠ ਹੈ। OpenSSH ਸਰਟੀਫਿਕੇਟ ਉਹ ਕੁੰਜੀ ਅਤੇ ਨਾਲ ਦਸਤਖ਼ਤ, principals ਅਤੇ ਵਿਕਲਪ ਹੈ, ਜਿਸਨੂੰ ssh-keygen ਆਪਣੇ ਛੋਟੇ CA ਵਜੋਂ ਕੰਮ ਕਰਕੇ ਬਣਾਉਂਦਾ ਹੈ। X.509 ਸਰਟੀਫਿਕੇਟ ਬਿਲਕੁਲ ਵੱਖਰੀ ਬਣਾਵਟ ਹੈ, ਜੋ ਵਿਸ਼ਾ, ਵੈਧਤਾ ਦੀ ਮਿਆਦ, ਐਕਸਟੈਂਸ਼ਨ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਅਥਾਰਟੀ ਦਾ ਦਸਤਖ਼ਤ ਰੱਖਦੀ ਹੈ। ਨਿੱਜੀ ਕੁੰਜੀ ਗੁਪਤ ਅੱਧਾ ਹਿੱਸਾ ਹੈ, ਅਤੇ ਜਾਰੀ ਕੀਤਾ ਬੰਡਲ ਆਮ ਤੌਰ ’ਤੇ ਇੱਕ ਹੀ ਫਾਈਲ ਵਿੱਚ ਸਰਟੀਫਿਕੇਟ, ਉਸਦੀ ਲੜੀ ਅਤੇ ਨਿੱਜੀ ਕੁੰਜੀ ਹੁੰਦਾ ਹੈ।
ਪਹਿਲੇ ਟੈਸਟ ਵਿੱਚ ਇੱਕ ਹੀ ਕਮਾਂਡ ਲੱਗਦੀ ਹੈ। openssl ਨੂੰ ਫਾਈਲ ਵੱਲ ਸੇਧਿਤ ਕਰੋ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਦੀ ਬਣਾਵਟ ਪਾਰਸ ਕਰਨ ਲਈ ਕਹੋ:
openssl x509 -in client.crt -noout -subject -issuer
ਜੇ ਉਹ unable-to-load ਜਾਂ PEM ਗਲਤੀ ਨਾਲ ਫੇਲ੍ਹ ਹੋਵੇ, ਤਾਂ ਤੁਸੀਂ ਭਾਵੇਂ ਕੋਈ ਵੀ ਨਾਮ ਦਿੱਤਾ ਹੋਵੇ, ਉਹ ਫਾਈਲ X.509 ਸਰਟੀਫਿਕੇਟ ਨਹੀਂ ਹੈ। ਨਾਮ ਬਦਲਣ ਨਾਲ ਅੰਦਰ ਦਾ ASN.1 ਦੁਬਾਰਾ ਨਹੀਂ ਲਿਖਿਆ ਜਾਂਦਾ, ਅਤੇ ਜਨਤਕ ਕੁੰਜੀ ਦੀ ਲਾਈਨ ਨੂੰ PEM ਹੈਡਰ ਪਾਠ ਵਿੱਚ ਲਪੇਟਣ ਨਾਲ ਵੀ ਨਹੀਂ।
ਕੀ ਪ੍ਰੋਫਾਈਲ ਸਰਟੀਫਿਕੇਟ ਮੰਗਦਾ ਹੀ ਹੈ?
ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਕਈ ਪ੍ਰਮਾਣਿਕਤਾ ਢੰਗਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹਨ, ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਕੰਮ ਕਰਦੇ TLS ਪ੍ਰੋਫਾਈਲ ਕਦੇ ਇੱਕ ਵੀ ਨਹੀਂ ਮੰਗਦੇ। ਸਰਵਰ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਪਲੱਗਇਨ, ਵਰਤੋਂਕਾਰ ਨਾਮ ਅਤੇ ਪਾਸਵਰਡ, ਜਾਂ ਟੋਕਨ ਬੈਕਐਂਡ ਰਾਹੀਂ ਪ੍ਰਮਾਣਿਤ ਕਰ ਸਕਦਾ ਹੈ, ਫਿਰ ਵੀ ਕਲਾਇੰਟ ਤੋਂ ਸਰਵਰ ਦੀ ਪਛਾਣ ਜਾਂਚਣ ਦੀ ਮੰਗ ਰੱਖਦਾ ਹੈ। ਜੇ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਕਲਾਇੰਟ-ਸਰਟੀਫਿਕੇਟ ਨਿਰਦੇਸ਼ ਨਹੀਂ, ਤਾਂ ਕਦੇ ਕੋਈ ਸਰਟੀਫਿਕੇਟ ਨਹੀਂ ਮੰਗਿਆ ਜਾਵੇਗਾ, ਅਤੇ ਕੋਈ ਰੂਪਾਂਤਰਣ ਗੇਟਵੇ ਨੂੰ ਇੱਕ ਮੰਗਣ ਲਈ ਮਜਬੂਰ ਨਹੀਂ ਕਰੇਗਾ।
ਪੁਰਾਣੀਆਂ ਸਥਿਰ-ਕੁੰਜੀ ਸੰਰਚਨਾਵਾਂ ਤੀਜਾ ਮਾਮਲਾ ਹਨ। ਉਹ TLS ਹੈਂਡਸ਼ੇਕ ਤੋਂ ਪਹਿਲਾਂ ਦੀਆਂ ਹਨ ਅਤੇ ਪਹਿਲਾਂ ਸਾਂਝੀ ਕੀਤੀ ਗੁਪਤ ਫਾਈਲ ਦੀ ਉਮੀਦ ਕਰਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਉਸ ਖੇਤਰ ਵਿੱਚ ਜਨਤਕ ਕੁੰਜੀ ਚਿਪਕਾਉਣਾ ਵੀ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਪਛਾਣ ਗਲਤ ਹੈ ਇਹ ਫੈਸਲਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੜ੍ਹੋ ਕਿ ਪ੍ਰੋਫਾਈਲ ਅਸਲ ਵਿੱਚ ਕੀ ਮੰਗਦਾ ਹੈ।
ਮੁੜ-ਐਨਕੋਡਿੰਗ ਕੀ ਕਰ ਸਕਦੀ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ
ਨਿੱਜੀ ਕੁੰਜੀਆਂ ਦੇ ਸੱਚਮੁੱਚ ਵੈਧ ਵਿਕਲਪਿਕ ਕੰਟੇਨਰ ਹੁੰਦੇ ਹਨ। ਉਹੀ RSA ਜਾਂ EC ਕੁੰਜੀ ਰਵਾਇਤੀ PEM ਵਜੋਂ, PKCS#8 ਵਜੋਂ, ਜਾਂ PKCS#12 ਬੰਡਲ ਦੇ ਅੰਦਰ ਲਿਖੀ ਜਾ ਸਕਦੀ ਹੈ, ਅਤੇ ਸਾਧਨ ਖੁਸ਼ੀ ਨਾਲ ਉਨ੍ਹਾਂ ਵਿਚਕਾਰ ਰੂਪਾਂਤਰਣ ਕਰਦੇ ਹਨ। ਜਨਤਕ ਕੁੰਜੀਆਂ ਦੀ ਵੀ ਇਹੋ ਕਹਾਣੀ ਹੈ: ssh-keygen SSH ਕੁੰਜੀ ਦਾ RFC 4716 ਰੂਪ ਕੱਢ ਸਕਦਾ ਹੈ, ਅਤੇ OpenSSH ਆਪਣਾ ਸਰਟੀਫਿਕੇਟ ਫਾਰਮੈਟ ਵੀ ਸਮਝਦਾ ਹੈ। ਇਹ ਸਭ ਪ੍ਰਸਤੁਤੀ ਹੈ, ਅਤੇ ਪ੍ਰਸਤੁਤੀ ਭਰੋਸਾ ਨਹੀਂ।
ਰੂਪਾਂਤਰਣ ਜੋ ਨਹੀਂ ਕਰ ਸਕਦਾ ਉਹ ਹੈ ਤੁਹਾਡੀ ਕੁੰਜੀ ਕਦੇ ਨਾ ਦੇਖੀ ਸਰਟੀਫਿਕੇਟ ਅਥਾਰਟੀ ਦਾ ਦਸਤਖ਼ਤ ਬਣਾਉਣਾ। ਸਰਟੀਫਿਕੇਟ ਜਾਰੀਕਰਤਾ ਦਾ ਇਹ ਦਾਅਵਾ ਹੈ ਕਿ ਕੋਈ ਖਾਸ ਜਨਤਕ ਕੁੰਜੀ ਕਿਸੇ ਖਾਸ ਉਦੇਸ਼ ਲਈ ਕਿਸੇ ਖਾਸ ਵਿਸ਼ੇ ਦੀ ਹੈ। ਮੁੜ-ਐਨਕੋਡਿੰਗ ਕੁੰਜੀ ਦੇ ਬਾਈਟ ਸੰਭਾਲਦੀ ਹੈ ਅਤੇ ਦਾਅਵੇ ਨੂੰ ਗੈਰਹਾਜ਼ਰ ਛੱਡਦੀ ਹੈ, ਇਸ ਲਈ ਗੇਟਵੇ ਕੋਲ ਆਪਣੇ ਭਰੋਸਾ-ਸਟੋਰ ਨਾਲ ਜਾਂਚਣ ਲਈ ਕੁਝ ਨਹੀਂ ਬਚਦਾ।
ਇਹੀ ਉਹ ਪੜਾਅ ਹੈ ਜਿੱਥੇ ਬਹੁਤੇ ਯਤਨ ਚੁੱਪਚਾਪ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ: ਫਾਈਲ ਹੁਣ .crt ’ਤੇ ਖ਼ਤਮ ਹੁੰਦੀ ਹੈ, ਕਲਾਇੰਟ ਉਸਨੂੰ ਬਿਨਾਂ ਸ਼ਿਕਾਇਤ ਪੜ੍ਹਦਾ ਹੈ, ਅਤੇ ਹੈਂਡਸ਼ੇਕ ਫਿਰ ਵੀ ਟੁੱਟ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਸਾਹਮਣਾ ਧਿਰ ਭਰੋਸੇਯੋਗ ਜਾਰੀਕਰਤਾ ਤੱਕ ਲੜੀ ਨਹੀਂ ਬਣਾ ਸਕਦੀ।
ਸਰਟੀਫਿਕੇਟ ਅਥਾਰਟੀ ਤਸਵੀਰ ਵਿੱਚ ਕਿੱਥੇ ਆਉਂਦੀ ਹੈ
ਅਸਲ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਤੁਹਾਡੇ ਨਿਯੰਤਰਣ ਵਾਲੀ ਕੁੰਜੀ-ਜੋੜੀ ਅਤੇ ਉਸ ਸਰਟੀਫਿਕੇਟ ਦਸਤਖ਼ਤ ਬੇਨਤੀ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਜੋ ਆਪਰੇਟਰ ਦੀ ਉਮੀਦ ਵਾਲਾ ਵਿਸ਼ਾ ਰੱਖਦੀ ਹੈ। ਆਪਰੇਟਰ ਹੱਕ ਜਾਂਚਦਾ ਹੈ, CA ਕੁੰਜੀ ਨਾਲ ਬੇਨਤੀ ’ਤੇ ਦਸਤਖ਼ਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਜਾਰੀ ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਕਿਸੇ ਵੀ ਵਿਚਕਾਰਲੀ ਲੜੀ ਸਮੇਤ ਵਾਪਸ ਦਿੰਦਾ ਹੈ ਜੋ ਕਲਾਇੰਟ ਨੂੰ ਪੇਸ਼ ਕਰਨੀ ਪੈਂਦੀ ਹੈ। ਫਿਰ ਕਲਾਇੰਟ ਨੂੰ ਉਹ CA ਸਰਟੀਫਿਕੇਟ ਚਾਹੀਦਾ ਹੈ ਜਿਸਨੇ ਉਸ ’ਤੇ ਦਸਤਖ਼ਤ ਕੀਤਾ, ਕਿਉਂਕਿ ਉਹੀ ਉਸਨੂੰ ਪੁਸ਼ਟੀ ਕਰਨ ਦਿੰਦਾ ਹੈ ਕਿ ਜਿਸ ਸਰਵਰ ਨਾਲ ਉਹ ਗੱਲ ਕਰ ਰਿਹਾ ਹੈ ਉਹ ਉਸੇ ਤੈਨਾਤੀ ਦਾ ਹੈ।
ਉਹ ਆਖ਼ਰੀ ਫਾਈਲ ਭੁੱਲਣੀ ਸੌਖੀ ਅਤੇ ਬਦਲਣੀ ਅਸੰਭਵ ਹੈ। CA ਦੀ ਦਸਤਖ਼ਤ ਕੁੰਜੀ ਆਪ ਕਦੇ ਕਲਾਇੰਟ ਸੰਰਚਨਾ ਵਿੱਚ ਨਹੀਂ ਹੁੰਦੀ, ਅਤੇ ਕੋਈ ਵੀ ਸਥਾਨਕ ਰੂਪਾਂਤਰਣ ਉਹ ਲੜੀ ਨਹੀਂ ਬਣਾਉਂਦਾ ਜੋ ਤੁਹਾਨੂੰ ਮਿਲਣੀ ਸੀ।
SSH ਕੁੰਜੀ ਮੁੜ ਵਰਤਣ ਦੀ ਕੀਮਤ
ਮੰਨ ਲਵੋ ਕਿਸੇ ਰੂਪਾਂਤਰਣ ਨੇ ਸੱਚਮੁੱਚ ਕੁਝ ਸਵੀਕਾਰਯੋਗ ਬਣਾਇਆ। SSH ਪਹੁੰਚ ਅਤੇ VPN ਪ੍ਰਮਾਣਿਕਤਾ ਲਈ ਇੱਕੋ ਕੁੰਜੀ-ਜੋੜੀ ਮੁੜ ਵਰਤਣਾ ਫਿਰ ਵੀ ਦੋ ਸੁਤੰਤਰ ਸੁਰੱਖਿਆ ਫੈਸਲੇ ਜੋੜਦਾ ਹੈ। authorized_keys ਵਿੱਚੋਂ ਇੱਕ ਲਾਈਨ ਹਟਾਉਣ ਨਾਲ SSH ਲੌਗਇਨ ਰੁਕ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਉਸੇ ਜਨਤਕ ਕੁੰਜੀ ਲਈ VPN CA ਵੱਲੋਂ ਪਹਿਲਾਂ ਹੀ ਜਾਰੀ ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਕੁਝ ਨਹੀਂ ਹੁੰਦਾ। VPN ਪਾਸਾ ਆਪਣੇ ਹੀ ਤੰਤਰ ਰਾਹੀਂ ਰੱਦ ਹੁੰਦਾ ਹੈ, ਯਾਨੀ ਸਰਟੀਫਿਕੇਟ ਰੱਦੀ ਸੂਚੀ ਜਾਂ ਆਪਰੇਟਰ ਦਾ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਰਿਕਾਰਡ।
ਇਸ ਲਈ ਚੈੱਕਲਿਸਟ ਕਿਸੇ ਚਾਲ ਨਾਲ ਨਹੀਂ, ਸਗੋਂ ਰੁਕਣ ਦੀ ਸ਼ਰਤ ਨਾਲ ਖ਼ਤਮ ਹੁੰਦੀ ਹੈ। ਜੇ openssl ਫਾਈਲ ਨੂੰ ਸਰਟੀਫਿਕੇਟ ਵਜੋਂ ਪਾਰਸ ਨਾ ਕਰੇ, ਤਾਂ ਰੂਪਾਂਤਰਣ ਰੋਕੋ ਅਤੇ ਦੱਸੋ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਕੀ ਹੈ: SSH ਕੁੰਜੀ, SSH ਸਰਟੀਫਿਕੇਟ, X.509 ਸਰਟੀਫਿਕੇਟ, ਨਿੱਜੀ ਕੁੰਜੀ ਜਾਂ ਬੰਡਲ। ਜੇ ਪ੍ਰੋਫਾਈਲ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਨਹੀਂ ਮੰਗਦਾ, ਤਾਂ ਰੁਕੋ ਅਤੇ ਪੁੱਛੋ ਕਿ ਸਰਵਰ ਕਿਹੜੇ ਪ੍ਰਮਾਣਿਕਤਾ ਢੰਗ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ। ਦੋਵੇਂ ਜਵਾਬ X.509 ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ’ਤੇ ਹੀ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਅਗਲਾ ਕਦਮ ਬਣਦਾ ਹੈ, ਅਤੇ ਪਹਿਲੇ ਵਾਕ ਵਿੱਚ ਸਹੀ ਨਾਂ ਹੋਵੇ ਤਾਂ ਉਹ ਗੱਲਬਾਤ ਕਾਫ਼ੀ ਤੇਜ਼ ਹੁੰਦੀ ਹੈ।