Access Server ਵਿੱਚ ਵੈੱਬ ਸਰਟੀਫਿਕੇਟ ਗਲਤੀ: ਖਾਲੀ CA ਬੰਡਲ

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

ਤਿੰਨ ਕੁੰਜੀਆਂ ਅਸਲ ਵਿੱਚ ਕੀ ਦਰਸਾਉਂਦੀਆਂ ਹਨ

ਕਸਟਮ ਵੈੱਬ ਸਰਟੀਫਿਕੇਟ ਸੈੱਟ ਨੂੰ cs.cert, cs.priv_key ਅਤੇ cs.ca_bundle ਦੁਆਰਾ ਦਰਸਾਇਆ ਜਾਂਦਾ ਹੈ। ਹਰ ਇੱਕ ਫਾਈਲ ਦਾ ਰਾਹ ਸਟੋਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਵੈੱਬ ਸੇਵਾ ਤਿੰਨੇ ਇਕੱਠੇ ਵਰਤਦੀ ਹੈ। ਗਲਤ ਕੁੰਜੀ ਵਾਲਾ ਸਰਟੀਫਿਕੇਟ, ਜਾਂ ਅਸਲ ਵਿੱਚ ਪੱਤਾ ਸਰਟੀਫਿਕੇਟ ਹੋਣ ਵਾਲੀ ਚੇਨ ਫਾਈਲ, ਖਾਲੀ ਮੁੱਲ ਵਾਂਗ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ।

ਇਹ ਕੁੰਜੀਆਂ Admin ਅਤੇ Client ਵੈੱਬ ਇੰਟਰਫ਼ੇਸ ਦੀਆਂ ਹਨ। ਇਹ ਉਸ PKI ਤੋਂ ਵੱਖਰੀਆਂ ਹਨ ਜੋ VPN ਕਲਾਇੰਟਾਂ ਨੂੰ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਬਦਲਣ ਲਈ ਪ੍ਰੋਫਾਈਲ, ਸਰਵਰ ਕੁੰਜੀ ਜਾਂ ਸਰਟੀਫਿਕੇਟ ਅਥਾਰਟੀ ਨੂੰ ਛੂਹਣ ਦੀ ਲੋੜ ਨਹੀਂ। ਪੂਰੀ PKI ਦੁਬਾਰਾ ਬਣਾਉਣਾ ਇੱਥੇ ਸਭ ਤੋਂ ਮਹਿੰਗੀ ਗਲਤੀ ਹੈ।

ਇੱਕ ਅੰਤਰ ਸਮਾਂ ਬਚਾਉਂਦਾ ਹੈ: ਸਪੱਸ਼ਟ ਤੌਰ ਤੇ ਖਾਲੀ ਕਸਟਮ ਮੁੱਲ ਕੋਈ ਓਵਰਰਾਈਡ ਨਾ ਹੋਣ ਦੀ ਸਥਿਤੀ ਵਰਗਾ ਨਹੀਂ ਹੈ। ਪਹਿਲਾ ਪਾਰਸਰ ਨੂੰ ਖਾਲੀ ਰਾਹ ਦਿੰਦਾ ਹੈ, ਲੌਗ ਲਾਈਨ ਇਹੀ ਕਹਿੰਦੀ ਹੈ। ਦੂਜਾ Access Server ਨੂੰ ਇਸ ਦੀ ਆਪਣੀ ਸਮੱਗਰੀ ਤੇ ਛੱਡ ਦਿੰਦਾ ਹੈ।

ਮੌਜੂਦ ਫਾਈਲ ਵੀ ਕਿਉਂ ਪਾਰਸ ਨਹੀਂ ਹੁੰਦੀ

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

ਵਸਤੂਆਂ ਦੀ ਜਾਂਚ ਕਰੋ, ਐਕਸਟੈਂਸ਼ਨਾਂ ਦੀ ਨਹੀਂ। Linux ਤੇ openssl x509 -noout -subject -issuer -in server.pem ਅਤੇ openssl pkey -noout -check -in key.pem ਦੋ ਮਹੱਤਵਪੂਰਨ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਦੋਹਾਂ ਦਾ ਮਾਡਿਊਲਸ ਜਾਂ ਜਨਤਕ ਕੁੰਜੀ ਤੁਲਨਾ ਕਰਨਾ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਉਹ ਜੋੜੀ ਹਨ। ਨਿੱਜੀ ਕੁੰਜੀ ਦਾ ਆਉਟਪੁੱਟ ਟਿਕਟਾਂ ਅਤੇ ਚੈਟ ਲੌਗਾਂ ਤੋਂ ਦੂਰ ਰੱਖੋ।

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

ਜਾਣਬੁੱਝ ਕੇ ਬੈਕਅੱਪ ਵੱਲ ਵਾਪਸ ਜਾਓ

Access Server ਦੇ CLI ਵਿੱਚ ਜਾਂਚ ਹੈ ਜੋ ਤਿੰਨ ਰਾਹਾਂ ਨੂੰ ਆਰਗਿਊਮੈਂਟ ਵਜੋਂ ਲੈਂਦੀ ਹੈ ਅਤੇ ਦੱਸਦੀ ਹੈ ਕਿ ਸੈੱਟ ਵਰਤੋਂ ਯੋਗ ਹੈ ਜਾਂ ਨਹੀਂ। ਹੇਠਾਂ ਦਿੱਤੇ ਰਾਹ ਉਦਾਹਰਨ ਹਨ; ਇਨ੍ਹਾਂ ਨੂੰ ਹੋਸਟ ਤੇ ਸੁਰੱਖਿਅਤ ਸਥਾਨਾਂ ਨਾਲ ਬਦਲੋ।

sacli --ca_bundle=/secure/webcerts/chain.pem \
      --cert=/secure/webcerts/server.pem \
      --priv_key=/secure/webcerts/key.pem TestWebCerts

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

ਉਹ ਨਾਮ ਜਾਂਚੋ ਜੋ ਵਰਤੋਂਕਾਰ ਅਸਲ ਵਿੱਚ ਲਿਖਦੇ ਹਨ

ਜਦੋਂ ਕਸਟਮ ਸਮੱਗਰੀ ਖਰਾਬ ਹੋਵੇ ਅਤੇ ਵੈਧ ਅੰਦਰੂਨੀ ਬੈਕਅੱਪ ਅਜੇ ਮੌਜੂਦ ਹੋਵੇ, ਤਾਂ ਦਸਤਾਵੇਜ਼ੀ ਰਿਕਵਰੀ ਤਿੰਨ ਓਵਰਰਾਈਡ ਹਟਾਉਣਾ ਅਤੇ Access Server ਨੂੰ ਉਹ ਬੈਕਅੱਪ ਵਰਤਣ ਦੇਣਾ ਹੈ। ਪਹਿਲਾਂ ਕੰਸੋਲ ਪਹੁੰਚ ਅਤੇ ਮੌਜੂਦਾ ਸੰਰਚਨਾ ਦੀ ਕਾਪੀ ਤਿਆਰ ਕਰੋ।

sacli ConfigDel --key "cs.cert"
sacli ConfigDel --key "cs.priv_key"
sacli ConfigDel --key "cs.ca_bundle"
# then the supported apply/restart step for this version

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

ਉਮੀਦ ਕਰੋ ਕਿ ਬੈਕਅੱਪ ਲਾਗੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਬ੍ਰਾਊਜ਼ਰ ਵੱਖਰਾ ਸਰਟੀਫਿਕੇਟ ਦਿਖਾਏਗਾ। ਇਹੀ ਸਹੀ ਨਤੀਜਾ ਹੈ; ਇਸ ਨੂੰ ਆਪਣੀ ਭਰੋਸੇਯੋਗ ਪ੍ਰਬੰਧਕੀ ਪ੍ਰਕਿਰਿਆ ਰਾਹੀਂ ਜਾਂਚੋ।

ਰਿਕਵਰੀ ਸਫਲ ਸਾਈਨ-ਇਨ ਤੋਂ ਬਾਅਦ ਹੀ ਪੂਰੀ ਹੁੰਦੀ ਹੈ

TCP ਸਰੋਤਾ ਦਿਖਣ ਤੇ ਰਿਕਵਰੀ ਪੂਰੀ ਨਹੀਂ ਹੁੰਦੀ। DNS ਨਾਮ, ਸਰਟੀਫਿਕੇਟ ਦੀ ਪਛਾਣ ਅਤੇ ਉਸ ਨਾਮ ਦੀ ਚੇਨ ਜਾਂਚੋ, ਫਿਰ Admin ਅਤੇ Client ਦੋਵੇਂ ਇੰਟਰਫ਼ੇਸ ਲੋਡ ਕਰੋ ਅਤੇ ਸਾਈਨ-ਇਨ ਪੂਰਾ ਕਰੋ। ਪੋਰਟ ਜਾਂਚ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ।

Access Server 3.1 ਅਤੇ ਬਾਅਦ ਵਾਲੇ ਹਰ SNI ਹੋਸਟਨਾਮ ਲਈ ਵੱਖਰੇ ਵੈੱਬ ਸਰਟੀਫਿਕੇਟ ਵੀ ਪਰੋਸ ਸਕਦੇ ਹਨ। ਜੇ ਇਹ ਸੰਰਚਿਤ ਹੈ, ਤਾਂ ਡਿਫ਼ਾਲਟ ਕੁੰਜੀਆਂ ਅਤੇ ਨਾਮ-ਵਿਸ਼ੇਸ਼ ਐਂਟਰੀਆਂ ਵੱਖਰੇ ਸੈੱਟ ਹਨ, ਅਤੇ IP ਪਤੇ ਨਾਲ ਜਾਂਚ ਕਰਨ ਤੇ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਮਿਲਣ ਵਾਲੇ ਤੋਂ ਵੱਖਰਾ ਸਰਟੀਫਿਕੇਟ ਆਸਾਨੀ ਨਾਲ ਦਿਸ ਸਕਦਾ ਹੈ। ਫੇਲ੍ਹ ਹੋਏ ਨਾਮ ਦਾ ਸੈੱਟ ਸੁਧਾਰੋ ਅਤੇ ਜਾਂਚੋ, ਅਤੇ ਘਟਨਾ ਬੰਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਾਈਨ-ਇਨ ਜਾਂਚ ਦੁਹਰਾਓ।