strongSwan: ਕੁੰਜੀ ਕਿਸਮ, ਲੋਡਰ ਅਤੇ ਗਲਤ backend

ਫਾਈਲ ਐਕਸਟੈਂਸ਼ਨ ਕੁੰਜੀ ਐਲਗੋਰਿਦਮ ਦੀ ਪਛਾਣ ਨਹੀਂ ਕਰਦੇ, ਅਤੇ .pem ਲਿਫ਼ਾਫ਼ੇ ਵਿੱਚ RSA ਜਾਂ ECDSA ਸਮੱਗਰੀ ਹੋ ਸਕਦੀ ਹੈ। PEM ਦੱਸਦਾ ਹੈ ਕਿ ਬਾਈਟ ਕਿਵੇਂ ਲਪੇਟੇ ਜਾਂਦੇ ਹਨ, ਜਦੋਂ ਕਿ RSA ਅਤੇ ECDSA ਵੱਖਰੇ ਐਲਗੋਰਿਦਮਾਂ ਦੇ ਨਾਮ ਹਨ, ਅਤੇ PKCS12 ਫਾਈਲ ਤੀਜੀ ਚੀਜ਼ ਹੈ। strongSwan ਪਲੱਗਇਨ ਅਤੇ ਕਨਫਿਗਰੇਸ਼ਨ backend ਰਾਹੀਂ ਪ੍ਰਮਾਣ ਪੱਤਰ ਲੋਡ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਸਰਟੀਫਿਕੇਟ ਸੂਚੀ ਵਿੱਚ ਦਿਖ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਨਿੱਜੀ ਕੁੰਜੀ ਕਦੇ ਵੀ ਵਰਤੋਂ ਯੋਗ ਨਹੀਂ ਬਣਦੀ। ਕਿਸੇ ਵੀ ਭੇਦ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਪਰਤਾਂ ਵੱਖ ਕਰੋ।

ਐਨਕੋਡਿੰਗ, ਐਲਗੋਰਿਦਮ ਅਤੇ ਪੈਕੇਜਿੰਗ ਤਿੰਨ ਪਰਤਾਂ ਹਨ

ਕੁੰਜੀ ਫਾਈਲ ਵਿੱਚ ਐਨਕੋਡਿੰਗ, ਐਲਗੋਰਿਦਮ ਅਤੇ ਅਕਸਰ ਇੱਕ ਕੰਟੇਨਰ ਹੁੰਦਾ ਹੈ। PEM ਜਾਣਿਆ-ਪਛਾਣਿਆ base64 ਲਿਫ਼ਾਫ਼ਾ ਹੈ; DER ਇਸ ਦਾ ਬਾਈਨਰੀ ਬਰਾਬਰ ਹੈ; PKCS12 ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਇਸ ਦੀ ਕੁੰਜੀ ਅਤੇ ਚੇਨ ਨਾਲ ਜੋੜਦਾ ਹੈ। ਸਰਟੀਫਿਕੇਟ-ਚੇਨ ਫਾਈਲ ਇੱਕ ਹੋਰ ਕੰਟੇਨਰ ਹੈ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਵਿੱਚ ਕੋਈ ਨਿੱਜੀ ਕੁੰਜੀ ਨਹੀਂ ਹੁੰਦੀ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਲੇਬਲ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਅੰਦਰ ਦੀ ਸਮੱਗਰੀ RSA ਹੈ ਜਾਂ ECDSA।

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

ਲੋਡਰ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਜਨਤਕ ਕੁੰਜੀਆਂ ਦੀ ਤੁਲਨਾ ਕਰੋ

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

openssl x509 -in server.crt -pubkey -noout |
    openssl pkey -pubin -outform DER |
    openssl dgst -sha256

openssl pkey -in server-key.pem -pubout -outform DER |
    openssl dgst -sha256

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

ਪੁਰਾਣਾ ipsec.secrets ਜਾਂ swanctl ਪ੍ਰਮਾਣ

strongSwan ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਦੋ ਪ੍ਰਮਾਣ ਰਸਤੇ ਹਨ। ਪੁਰਾਣਾ starter ਸਟੈਕ ਕਿਸਮ-ਖਾਸ ਐਂਟਰੀਆਂ ਇੱਥੋਂ ਪੜ੍ਹਦਾ ਹੈ: ipsec.secrets, ਅਤੇ ਹਰ ਐਂਟਰੀ ਨੂੰ ਸਮੱਗਰੀ ਲਈ ਸਹੀ ਕਿਸਮ ਦੱਸਣੀ ਚਾਹੀਦੀ ਹੈ। swanctl ਅਤੇ vici ਸਟੈਕ ਆਪਣੀ ਪ੍ਰਮਾਣ ਡਾਇਰੈਕਟਰੀ ਤੋਂ ਆਪਣੀ ਕਨਫਿਗਰੇਸ਼ਨ ਰਾਹੀਂ ਕੁੰਜੀਆਂ ਲੋਡ ਕਰਦਾ ਹੈ। ਚੱਲ ਰਹੇ backend ਵੱਲੋਂ ਨਾ ਪੜ੍ਹੀ ਜਾਣ ਵਾਲੀ ਫਾਈਲ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਨ ਨਾਲ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ।

: ECDSA "/etc/ipsec.d/private/server-key.pem"

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

ਲੋਡ ਇਵੈਂਟ ਅਤੇ ਪ੍ਰਮਾਣੀਕਰਨ ਨਤੀਜਾ ਪੜ੍ਹੋ

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

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