ਬੈਚ ਫਾਈਲ “ਸਿਸਟਮ ਨਿਰਧਾਰਤ ਰਜਿਸਟਰੀ ਕੁੰਜੀ ਜਾਂ ਮੁੱਲ ਨਹੀਂ ਲੱਭ ਸਕਿਆ” ਸੁਨੇਹੇ ਨਾਲ ਰੁਕ ਜਾਂਦੀ ਹੈ ਅਤੇ ਹਰ ਕੋਈ ਮੰਨ ਲੈਂਦਾ ਹੈ ਕਿ ਸਰਟੀਫਿਕੇਟ ਅਥਾਰਟੀ ਟੁੱਟ ਗਈ ਹੈ। ਅਜਿਹਾ ਨਹੀਂ ਹੈ, ਜਾਂ ਘੱਟੋ-ਘੱਟ ਹਾਲੇ ਨਹੀਂ: ਸਕ੍ਰਿਪਟ ਸੌਫਟਵੇਅਰ ਲੱਭਦਿਆਂ ਅਸਫਲ ਹੋਈ, Easy-RSA ਨੂੰ ਕੁੰਜੀ ਨਾਲ ਕੁਝ ਕਰਨ ਲਈ ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ। ਇਹ ਕ੍ਰਮ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਮੁਰੰਮਤ ਖੋਜ ਦੀ ਸਮੱਸਿਆ ਹੈ ਅਤੇ PKI ਸਿਰਫ਼ ਦਰਸ਼ਕ ਹੈ। ਅਸਫਲ ਲਾਈਨ ਪੜ੍ਹਨਾ ਹੀ ਪੂਰਾ ਨਿਦਾਨ ਹੈ, ਅਤੇ ਇਹ ਕਿਸੇ ਵੀ ਬਦਲਵੇਂ ਰਸਤੇ ਨਾਲੋਂ ਘੱਟ ਸਮਾਂ ਲੈਂਦਾ ਹੈ।

ਗਲਤੀ CA ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਹੁੰਦੀ ਹੈ

ਪੁਰਾਣੀਆਂ Easy-RSA 2 ਬੈਚ ਫਾਈਲਾਂ ਰਜਿਸਟਰੀ ਨੂੰ ਪੁੱਛ ਕੇ OpenSSL ਜਾਂ OpenVPN ਇੰਸਟਾਲੇਸ਼ਨ ਲੱਭਦੀਆਂ ਹਨ, ਫਿਰ ਜੋ ਮਿਲਦਾ ਹੈ ਉਸਦੇ ਆਧਾਰ 'ਤੇ ਵੇਰੀਏਬਲ ਸੈੱਟ ਕਰਦੀਆਂ ਹਨ। ਜਦੋਂ ਪ੍ਰਸ਼ਨ ਕੁਝ ਵਾਪਸ ਨਹੀਂ ਕਰਦਾ, ਕੋਈ ਵੀ ਸਰਟੀਫਿਕੇਟ ਕਾਰਵਾਈ ਚੱਲਣ ਤੋਂ ਪਹਿਲਾਂ ਸਕ੍ਰਿਪਟ ਰੁਕ ਜਾਂਦੀ ਹੈ।

ਇਸ ਲਈ ਰਜਿਸਟਰੀ ਕੁੰਜੀ ਬਾਰੇ ਸੁਨੇਹਾ ਸਕ੍ਰਿਪਟ ਦੇ ਵਾਤਾਵਰਨ ਦਾ ਸਬੂਤ ਹੈ, CA ਡਾਇਰੈਕਟਰੀ ਦਾ ਨਹੀਂ।

ਦੋ ਰਜਿਸਟਰੀ ਵਿਊ, ਇੱਕ ਬੈਚ ਫਾਈਲ

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

reg query "HKLM\SOFTWARE\OpenVPN" /reg:32
reg query "HKLM\SOFTWARE\OpenVPN" /reg:64

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

ਜੇ ਦੋਵਾਂ ਵਿਊ ਵਿੱਚੋਂ ਕਿਸੇ ਵਿੱਚ ਵੀ ਐਂਟਰੀ ਨਹੀਂ ਹੈ, ਤਾਂ ਇੰਸਟਾਲਰ ਨੇ ਇਹ ਕਦੇ ਨਹੀਂ ਬਣਾਈ, ਅਤੇ ਹੱਥੋਂ ਮੁੱਲ ਬਣਾਉਣ ਨਾਲ ਟੂਲ ਕੰਮ ਨਹੀਂ ਕਰਨਗੇ।

ਬਿਨਾਂ ਸ਼ਰਤ /reg:64 ਨਾ ਜੋੜੋ

ਲੁਭਾਉਣ ਵਾਲਾ ਸੁਧਾਰ ਇਹ ਹੈ ਕਿ ਹਰ ਪ੍ਰਸ਼ਨ ਵਿੱਚ 64-ਬਿੱਟ ਚੋਣਕਾਰ ਜੋੜੋ ਅਤੇ ਅੱਗੇ ਵਧੋ। ਕੁਝ ਇੰਸਟਾਲੇਸ਼ਨਾਂ ਵਿੱਚ ਇਹ ਸਹੀ ਹੈ, ਅਤੇ ਹੋਰਾਂ ਵਿੱਚ ਇਹ ਸਕ੍ਰਿਪਟ ਨੂੰ ਉਸ ਵਿਊ ਵੱਲ ਭੇਜਦਾ ਹੈ ਜਿੱਥੇ ਸੱਚਮੁੱਚ ਕੁਝ ਨਹੀਂ ਹੈ।

ਉਮੀਦ ਕੀਤਾ ਮੁੱਲ ਕਿਹੜੇ ਵਿਊ ਵਿੱਚ ਹੈ ਇਹ ਵੇਖਣ ਤੋਂ ਬਾਅਦ ਹੀ ਖੋਜ ਬਦਲੋ।

ਖੋਜ PKI ਦੀ ਮੁਰੰਮਤ ਨਹੀਂ ਹੈ

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

ਕਿਸੇ ਵੀ ਪ੍ਰਯੋਗ ਤੋਂ ਪਹਿਲਾਂ CA ਡਾਇਰੈਕਟਰੀ ਦਾ ਬੈਕਅੱਪ ਲਓ, ਉਸ ਪ੍ਰਯੋਗ ਦਾ ਵੀ ਜਿਸਦੇ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਬਾਰੇ ਤੁਸੀਂ ਯਕੀਨੀ ਹੋ।

Easy-RSA 3 'ਤੇ ਜਾਣਾ ਇੱਕ ਮਾਈਗ੍ਰੇਸ਼ਨ ਹੈ

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

ਵਰਜਨ ਬਦਲਣਾ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਹੈ; ਰਜਿਸਟਰੀ ਗਲਤੀ ਇੱਕ ਦੁਪਹਿਰ ਹੈ।

ਉਹ ਤੁਲਨਾ ਜੋ ਸੱਚਮੁੱਚ ਇਸਨੂੰ ਹੱਲ ਕਰਦੀ ਹੈ

ਚਾਰ ਗੱਲਾਂ ਲਿਖੋ ਅਤੇ ਸਿੱਧੀ ਤੁਲਨਾ ਕਰੋ:

  • ਕਿਹੜੀ ਸਕ੍ਰਿਪਟ ਚੱਲੀ, ਅਤੇ ਕਿਹੜੀ ਲਾਈਨ ਅਸਫਲ ਹੋਈ।
  • ਉਸ ਲਾਈਨ ਨੇ ਕਿਹੜਾ ਰਜਿਸਟਰੀ ਵਿਊ ਪੁੱਛਿਆ।
  • ਸਕ੍ਰਿਪਟ ਨੇ ਕਿਹੜੇ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਪਾਥ ਦੀ ਉਮੀਦ ਕੀਤੀ।
  • ਮਸ਼ੀਨ 'ਤੇ ਸੱਚਮੁੱਚ ਕਿਹੜੀ ਇੰਸਟਾਲੇਸ਼ਨ ਹੈ।

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

ਸੰਬੰਧਿਤ ਲੇਖ