ਪੁਰਾਣੀ P12 ਫਾਈਲ OpenSSL 3 ’ਤੇ ਫੇਲ੍ਹ: ਗਲਤ ਪਾਸਫ੍ਰੇਜ਼ ਜਾਂ ਪੁਰਾਣਾ ਸਾਈਫਰ?
ਗਲਤ ਟਾਈਪ ਕੀਤੇ ਪਾਸਫ੍ਰੇਜ਼ ਨੂੰ OpenSSL 3 ਦੁਆਰਾ ਖੋਲ੍ਹਣ ਤੋਂ ਇਨਕਾਰ ਕਰਨ ਵਾਲੇ ਪੁਰਾਣੇ RC2 ਬੰਡਲ ਤੋਂ ਵੱਖ ਕਰੋ, ਫਿਰ ਕੁੰਜੀ ਸੁਰੱਖਿਆ ਹਟਾਏ ਬਿਨਾਂ ਫਾਈਲ ਨੂੰ ਦੁਬਾਰਾ ਸੀਲ ਕਰੋ।
ਆਯਾਤ ਡਾਇਲਾਗ ਤੁਹਾਡਾ ਪਾਸਵਰਡ ਲੈਂਦਾ ਹੈ, ਥੋੜ੍ਹਾ ਘੁੰਮਦਾ ਹੈ ਅਤੇ ਫਿਰ ਕਹਿੰਦਾ ਹੈ ਕਿ ਇਹ ਬੰਡਲ ਪੜ੍ਹ ਨਹੀਂ ਸਕਦਾ। ਤੁਸੀਂ ਪਾਸਫ੍ਰੇਜ਼ ਗਲਤ ਟਾਈਪ ਕੀਤਾ ਜਾਂ ਫਾਈਲ ਕਲਾਇੰਟ ਵੱਲੋਂ ਹੁਣ ਨਾ ਦਿੱਤੇ ਜਾਣ ਵਾਲੇ ਸਾਈਫਰ ਨਾਲ ਸੀਲ ਕੀਤੀ ਗਈ, ਇਸ ਬਾਰੇ ਉਸ ਸੁਨੇਹੇ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਕਿਹਾ ਜਾਂਦਾ। ਇਹ ਵੱਖਰੀਆਂ ਅਸਫਲਤਾਵਾਂ ਅਤੇ ਵੱਖਰੇ ਹੱਲ ਹਨ, ਗਲਤ ਚੋਣ ਕਲਾਇੰਟ ਡਾਊਨਗ੍ਰੇਡ ਵੱਲ ਲੈ ਜਾਂਦੀ ਹੈ ਜੋ ਫ਼ੈਸਲਾ ਸਿਰਫ਼ ਟਾਲਦੀ ਹੈ। ਕਲਾਇੰਟ ਕਿਹੜੇ ਪੜਾਅ ’ਤੇ ਰੁਕਦਾ ਹੈ, ਇਹ ਦੇਖਣਾ ਉਨ੍ਹਾਂ ਨੂੰ ਲਗਭਗ ਇੱਕ ਮਿੰਟ ਵਿੱਚ ਵੱਖ ਕਰਦਾ ਹੈ।
ਡਾਇਲਾਗ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਸੂਚੀ ਵਿਚਕਾਰ ਕੀ ਹੁੰਦਾ ਹੈ
.p12 ਫਾਈਲ ਇੱਕ ਕੰਟੇਨਰ ਹੈ, ਸਰਟੀਫਿਕੇਟ ਨਹੀਂ। ਅੰਦਰ ਇੱਕ ਜਾਂ ਵੱਧ ਸਰਟੀਫਿਕੇਟ ਥੈਲੇ ਅਤੇ ਤੁਹਾਡੇ ਪਾਸਵਰਡ ਤੋਂ ਲਈ ਕੁੰਜੀ ਨਾਲ ਐਨਕ੍ਰਿਪਟ ਕੀਤਾ ਨਿੱਜੀ ਕੁੰਜੀ ਥੈਲਾ, ਨਾਲ ਹੀ ਪੂਰੀ ਫਾਈਲ ’ਤੇ MAC ਕਹਿੰਦੇ ਅਖੰਡਤਾ ਜਾਂਚ ਹੁੰਦੀ ਹੈ। ਇਸਨੂੰ ਖੋਲ੍ਹਣ ਦਾ ਮਤਲਬ ਹੈ ਉਸ MAC ਦੀ ਜਾਂਚ ਕਰਨਾ, ਕੁੰਜੀ ਥੈਲਾ ਡੀਕ੍ਰਿਪਟ ਕਰਨਾ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਬਾਹਰ ਆਉਣ ਵਾਲੀ ਕੁੰਜੀ ਨਾਲ ਮਿਲਾਉਣਾ।
ਪਾਸਵਰਡ ਦੀ ਸਮੱਸਿਆ MAC ਪੜਾਅ ’ਤੇ ਆਉਂਦੀ ਹੈ। ਸਾਈਫਰ ਦੀ ਸਮੱਸਿਆ ਬਾਅਦ ਵਿੱਚ ਆਉਂਦੀ ਹੈ, ਜਦੋਂ ਕੁੰਜੀ ਥੈਲਾ ਖੋਲ੍ਹਣਾ ਪੈਂਦਾ ਹੈ ਅਤੇ ਖੋਲ੍ਹਣ ਵਾਲੇ ਬਿਲਡ ਵਿੱਚ ਫਾਈਲ ਵਿੱਚ ਦੱਸੇ ਐਲਗੋਰਿਦਮ ਦਾ ਅਮਲ ਨਹੀਂ ਹੁੰਦਾ।
ਦੂਜੀ ਸਥਿਤੀ ਅੱਜ ਦੇ ਸਿਸਟਮਾਂ ’ਤੇ ਆਮ ਹੈ ਕਿਉਂਕਿ OpenSSL 3 ਨੇ ਪੁਰਾਣੇ ਐਲਗੋਰਿਦਮਾਂ ਦਾ ਸਮੂਹ ਚੋਣਵੇਂ legacy provider ਵਿੱਚ ਤਬਦੀਲ ਕੀਤਾ। OpenSSL 1.x ਵੱਲੋਂ ਨਿਰਯਾਤ ਕੀਤੇ ਬੰਡਲ ਆਮ ਤੌਰ ’ਤੇ ਸਰਟੀਫਿਕੇਟ 40-ਬਿੱਟ RC2 ਨਾਲ ਅਤੇ ਨਿੱਜੀ ਕੁੰਜੀ ਤਿੰਨ-ਕੁੰਜੀ Triple DES ਨਾਲ ਸੀਲ ਕਰਦੇ ਸਨ। ਡਿਫ਼ਾਲਟ OpenSSL 3 ਬਿਲਡ ਤੁਹਾਡੇ ਸਹੀ ਪਾਸਵਰਡ ਨਾਲ MAC ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਥੈਲੇ ’ਤੇ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਪਾਸਵਰਡ ਕਦੇ ਗਲਤ ਨਹੀਂ ਸੀ ਅਤੇ ਦੁਬਾਰਾ ਟਾਈਪ ਕਰਨ ਨਾਲ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ।
ਕੁੰਜੀ ਬਾਹਰ ਲਿਖੇ ਬਿਨਾਂ ਕੰਟੇਨਰ ਪੜ੍ਹੋ
ਆਪਣੀ ਮਸ਼ੀਨ ਦੇ OpenSSL ਬਿਲਡ ਨੂੰ ਫਾਈਲ ਪਾਰਸ ਕਰਕੇ ਦੱਸਣ ਲਈ ਕਹੋ ਕਿ ਇਹ ਕਿੱਥੇ ਹਾਰ ਮੰਨਦਾ ਹੈ। ਆਉਟਪੁੱਟ ਫਾਈਲ ਤੋਂ ਬਿਨਾਂ ਜਾਂਚ ਕੁੰਜੀ ਨੂੰ ਡਿਸਕ ’ਤੇ ਐਨਕ੍ਰਿਪਟਿਡ ਛੱਡਦੀ ਹੈ, ਸਾਂਝੇ ਹੋਸਟ ’ਤੇ ਇਹ ਕਦਮ ਸੁਰੱਖਿਅਤ ਹੋਣ ਦਾ ਇਹੀ ਇੱਕੋ ਕਾਰਨ ਹੈ।
openssl pkcs12 -in vpn-identity.p12 -info -nooutਸਹੀ ਪਾਸਵਰਡ ਵਾਲੇ ਪੁਰਾਣੇ ਬੰਡਲ ’ਤੇ ਇਹ ਥੈਲੇ ਦੇ ਗੁਣ ਛਾਪਦਾ ਹੈ ਅਤੇ ਫਿਰ digital envelope routines::unsupported ਨਾਲ ਰੁਕ ਜਾਂਦਾ ਹੈ। ਗਲਤ ਪਾਸਵਰਡ ਨਾਲ ਕੋਈ ਵੀ ਥੈਲਾ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ Mac verify error: invalid password? ਮਿਲਦਾ ਹੈ। ਦੋਵੇਂ ਸੁਨੇਹੇ ਉਲਟ ਦਿਸ਼ਾਵਾਂ ਦਿਖਾਉਂਦੇ ਹਨ, ਅਤੇ ਕਲਾਇੰਟ ਨੇ ਜੋ ਜਾਣਕਾਰੀ ਲੁਕਾਈ ਸੀ ਉਹ ਠੀਕ ਇਹੀ ਹੈ।
ਜੇ ਅਸਫਲਤਾ ਅਸਮਰਥਿਤ ਐਲਗੋਰਿਦਮ ਵਾਲੀ ਹੈ ਤਾਂ ਉਹੀ ਹੁਕਮ -legacy ਜੋੜ ਕੇ ਬਾਕੀ ਕੁਝ ਨਾ ਬਦਲਦੇ ਹੋਏ ਦੁਬਾਰਾ ਚਲਾਓ। ਉਹ ਝੰਡਾ legacy provider ਨੂੰ ਸਿਰਫ਼ ਉਸੇ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਲਈ ਲੋਡ ਕਰਦਾ ਹੈ। ਇਹ VPN ਕਲਾਇੰਟ ਨੂੰ ਪੁਰਾਣੇ ਬੰਡਲ ਪਾਰਸ ਕਰਨ ਲਈ ਮਜਬੂਰ ਨਹੀਂ ਕਰਦਾ, ਸਿਸਟਮ-ਵਿਆਪੀ ਕ੍ਰਿਪਟੋ ਨੀਤੀ ਨੂੰ ਨਹੀਂ ਛੂਹੰਦਾ ਅਤੇ ਇਹ ਮੁਰੰਮਤ ਨਹੀਂ, ਮਾਪ ਹੈ, ਕਿਉਂਕਿ ਫਾਈਲ ਅਜੇ ਵੀ ਬਦਲਣੀ ਪੈਂਦੀ ਹੈ।
ਕਿਹੜੀ ਗਲਤੀ ਕਿਹੜਾ ਪੜਾਅ
ਛੋਟਾ ਸਾਰਣੀ ਤਿੰਨ ਨਤੀਜਿਆਂ ਨੂੰ ਵੱਖ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਡਾਇਲਾਗ ਕਿੱਥੇ ਦਿਖਿਆ ਇਸ ਤੋਂ ਵੱਧ ਸ਼ਬਦਾਵਲੀ ਮਹੱਤਵਪੂਰਨ ਹੈ।
| Text you see | Stage | What it tells you |
|---|---|---|
Mac verify error: invalid password? | Integrity check | Passphrase or cached credential, not the cipher |
digital envelope routines::unsupported | Bag decrypt | Algorithm missing from the default provider |
not enough data / header too long | Container format | Wrong encoding, edited file, or truncated download |
not enough data ਜਾਂ header too long ਵਰਗਾ ਪਾਠ ਪਹਿਲੇ ਦੋ ਸਮੂਹਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦਾ। ਇਹ ਫਾਰਮੈਟ ਦੀ ਸਮੱਸਿਆ ਹੈ: .pem ਵਜੋਂ ਨਾਮ ਬਦਲੀ DER ਫਾਈਲ, ਲਾਈਨਾਂ ਦੇ ਸਿਰੇ ਦੁਬਾਰਾ ਲਿਖਣ ਵਾਲੇ ਸੰਪਾਦਕ ਨਾਲ ਵਿਗੜੀ ਕਾਪੀ, ਜਾਂ ਅਧੂਰਾ ਡਾਊਨਲੋਡ। ਸਾਈਫਰਾਂ ਵੱਲ ਦੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਜਾਰੀਕਰਤਾ ਵੱਲੋਂ ਭੇਜੇ ਚੈੱਕਸਮ ਨਾਲ ਤੁਲਨਾ ਕਰੋ।
Mac verify error ਨੂੰ ਸਿਰਫ਼ ਪਾਸਵਰਡ ਬਾਰੇ ਸਬੂਤ ਮੰਨੋ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡੇ ਟਾਈਪ ਕੀਤੇ ਤੋਂ ਗਿਣਿਆ MAC ਸੰਗ੍ਰਹਿਤ ਮੁੱਲ ਨਾਲ ਨਹੀਂ ਮਿਲਦਾ, ਅਜਿਹਾ ਟਾਈਪਿੰਗ ਗਲਤੀ, ਪਿਛਲੇ ਆਯਾਤ ਤੋਂ ਕੈਸ਼ ਹੋਏ ਪਾਸਵਰਡ ਜਾਂ ਕਿਸੇ ਹੋਰ ਪਾਸਫ੍ਰੇਜ਼ ਹੇਠ ਦੁਬਾਰਾ ਨਿਰਯਾਤ ਕੀਤੀ ਫਾਈਲ ਨਾਲ ਹੁੰਦਾ ਹੈ। ਅੰਦਰਲੇ ਐਲਗੋਰਿਦਮ ਪੁਰਾਣੇ ਹਨ ਜਾਂ ਨਹੀਂ, ਇਸ ਬਾਰੇ ਇਹ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ।
ਕਲਾਇੰਟ ਲਈ ਸੱਚਮੁੱਚ ਖੋਲ੍ਹਣਯੋਗ ਬੰਡਲ ਬਣਾਓ
legacy ਪਾਰਸਰ ਫਾਈਲ ਨੂੰ ਸਿਹਤਮੰਦ ਦੱਸਣ ਤੋਂ ਬਾਅਦ ਟਿਕਾਊ ਹੱਲ ਉਹ ਬਦਲ ਹੈ ਜਿਸਦੇ ਐਲਗੋਰਿਦਮ ਨਿਸ਼ਾਨਾ ਕਲਾਇੰਟ ਸਮਰਥਿਤ ਕਰਦਾ ਹੈ: ਕੁੰਜੀ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਥੈਲਿਆਂ ਲਈ AES-256-CBC, ਵਿਉਤਪਤੀ ਲਈ SHA-256 ਵਾਲਾ PBKDF2 ਅਤੇ MAC ਲਈ SHA-256। ਤੁਹਾਡਾ PKI ਪ੍ਰਬੰਧਕ ਇਸਨੂੰ ਉਸੇ ਕੁੰਜੀ ਸਮੱਗਰੀ ਤੋਂ ਨਿਰਯਾਤ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਅੰਦਰਲਾ ਸਰਟੀਫਿਕੇਟ ਉਹੀ ਰਹਿੰਦਾ ਹੈ ਜਿਸ ’ਤੇ ਤੁਹਾਡੇ ਸਰਵਰ ਪਹਿਲਾਂ ਹੀ ਭਰੋਸਾ ਕਰਦੇ ਹਨ।
ਜੇ ਸਥਾਨਕ ਤੌਰ ’ਤੇ ਬਦਲਣਾ ਪਵੇ ਤਾਂ ਥੈਲਿਆਂ ਨੂੰ ਪਹਿਲਾਂ ਸੁੱਟਣ ਦੀ ਥਾਂ ਦੁਬਾਰਾ ਸੀਲ ਕਰਨ ਲਈ pkcs12 ਸਾਧਨ ਨੂੰ ਕਹੋ। ਦੋਵੇਂ ਪਾਸਫ੍ਰੇਜ਼ ਫਾਈਲ ਤੋਂ ਪੜ੍ਹ ਕੇ ਆਪਣੇ ਸ਼ੈੱਲ ਇਤਿਹਾਸ ਤੋਂ ਬਾਹਰ ਰੱਖੋ।
openssl pkcs12 -in vpn-identity.p12 -out vpn-identity-aes.p12 \
-keypbe AES-256-CBC -certpbe AES-256-CBC -macalg sha256 \
-passin file:old.pass -passout file:new.passਸਫਲ ਬਦਲਾਅ ਮਿਆਦ ਖ਼ਤਮ ਹੋਣ, ਕੁੰਜੀ ਵਰਤੋਂ, ਨਿੱਜੀ ਕੁੰਜੀ ਦੇ ਮੇਲ ਜਾਂ ਸਰਵਰ ਦੇ ਜਾਰੀਕਰਤਾ ਲੜੀ ’ਤੇ ਭਰੋਸੇ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ। ਦੁਬਾਰਾ ਪੈਕ ਕਰਨਾ ਆਵਾਜਾਈ ਵਿੱਚ ਬਦਲਾਅ ਹੈ, ਨਵੀਨੀਕਰਨ ਨਹੀਂ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਨੂੰ ਆਪਣੀ ਜਾਂਚ ਦੀ ਲੋੜ ਹੈ।
ਕਲਾਇੰਟ ਨੇ ਫਾਈਲ ਸਵੀਕਾਰ ਕੀਤੀ ਇਸ ਕਾਰਨ ਬਿਨਾਂ ਸੁਰੱਖਿਆ ਵਾਲੀ ਵਿਚਕਾਰਲੀ ਕੁੰਜੀ ਲਿਖਣ ਵਾਲੀ ਜਾਂ ਖਾਲੀ ਆਉਟਪੁੱਟ ਪਾਸਵਰਡ ਰੱਖਣ ਵਾਲੀ ਕੋਈ ਵੀ ਵਿਧੀ ਛੱਡੋ। ਸੁਰੱਖਿਆ ਹਟਾਈ ਪੜ੍ਹਨਯੋਗ ਬੰਡਲ ਤੁਹਾਡੇ ਸ਼ੁਰੂ ਕੀਤੇ ਆਯਾਤ ਫੇਲ੍ਹ ਤੋਂ ਵੀ ਮਾੜਾ ਨਤੀਜਾ ਹੈ।
ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕਲਾਇੰਟ ਨੇ ਤੁਹਾਡੀ ਬਣਾਈ ਫਾਈਲ ਆਯਾਤ ਕੀਤੀ
ਟਰਮੀਨਲ ਵਿੱਚ ਸਾਫ਼ ਪਾਰਸਿੰਗ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਕੰਟੇਨਰ ਵੈਧ ਹੈ। ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ ਕਲਾਇੰਟ ਨੇ ਇਸਨੂੰ ਚੁਣਿਆ, ਕਿਉਂਕਿ ਬਚਿਆ ਪਰੋਫਾਈਲ ਪੁਰਾਣੀ ਫਾਈਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਰਹਿ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੁਝ ਕਲਾਇੰਟ ਆਯਾਤ ਕੀਤੀ ਪਛਾਣ ਨੂੰ ਤੁਹਾਡੇ ਨਾ ਚੁਣੇ ਨਾਮ ਹੇਠ ਕੈਸ਼ ਕਰਦੇ ਹਨ।
ਤੁਸੀਂ ਜੋ ਪਛਾਣ ਆਯਾਤ ਕਰਨ ਜਾ ਰਹੇ ਹੋ ਉਸਨੂੰ ਛਾਪੋ ਅਤੇ ਕਲਾਇੰਟ ਆਪਣੇ ਸਰਟੀਫਿਕੇਟ ਦ੍ਰਿਸ਼ ਵਿੱਚ ਜੋ ਦਿਖਾਉਂਦਾ ਹੈ ਉਸ ਨਾਲ ਤੁਲਨਾ ਕਰੋ।
openssl pkcs12 -in vpn-identity-aes.p12 -clcerts -nokeys -passin file:new.pass \
| openssl x509 -noout -subject -dates -fingerprint -sha256ਪਹਿਲਾਂ ਪੁਰਾਣੀ ਪਰੋਫਾਈਲ ਐਂਟਰੀ ਹਟਾਓ, ਫਿਰ ਆਯਾਤ ਕਰੋ। ਜੇ ਕਲਾਇੰਟ ਲੋਡ ਕੀਤੇ ਵਿਸ਼ੇ ਜਾਂ ਫਿੰਗਰਪ੍ਰਿੰਟ ਦਾ ਲਾਗ ਰੱਖਦਾ ਹੈ ਤਾਂ ਉਸਨੂੰ ਉੱਪਰਲੀ ਲਾਈਨ ਨਾਲ ਮਿਲਾਓ; ਜੇ ਇਹ ਸਿਰਫ਼ ਦੋਸਤਾਨਾ ਨਾਮ ਦਿਖਾਉਂਦਾ ਹੈ ਤਾਂ ਇਸਦੀ ਥਾਂ ਮਿਆਦ ਖ਼ਤਮ ਹੋਣ ਦੀ ਤਾਰੀਖ਼ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਉਸਨੂੰ ਉਸੇ ਜਾਰੀਕਰਤਾ ਦੇ ਹੋਰ ਸਰਟੀਫਿਕੇਟ ਨਾਲ ਉਲਝਾਉਣਾ ਔਖਾ ਹੈ।
PKCS12 ਸੰਦਰਭ ਇੱਥੇ ਵਰਤੇ provider, ਪਾਸਫ੍ਰੇਜ਼ ਅਤੇ ਆਉਟਪੁੱਟ ਵਿਕਲਪ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ। legacy provider ਨੂੰ ਕਲਾਇੰਟ ਵਾਤਾਵਰਣ ਤੋਂ ਬਾਹਰ ਰੱਖਣਾ ਹੀ ਮੁੱਖ ਗੱਲ ਹੈ: ਇਸ ਨਾਲ ਮਾਪੋ, ਇਸ ਤੋਂ ਬਿਨਾਂ ਭੇਜੋ ਅਤੇ ਨਿੱਜੀ ਕੁੰਜੀ ਨੂੰ ਡਿਸਕ ’ਤੇ ਸੁਰੱਖਿਅਤ ਰੱਖੋ।