CA ਬੰਡਲ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪਤਾ ਕਰੋ ਕਿ ਕਿਹੜਾ TLS ਹੈਂਡਸ਼ੇਕ ਫੇਲ੍ਹ ਹੋਇਆ। ਪ੍ਰਾਕਸੀ ਅਤੇ ਵੈੱਬਸਾਈਟ ਦੇ ਸਰਟੀਫਿਕੇਟ ਵੱਖਰੇ ਕਨੈਕਸ਼ਨਾਂ ਉੱਤੇ ਜਾਂਚੇ ਜਾ ਸਕਦੇ ਹਨ।

ਪ੍ਰਾਕਸੀ ਅਤੇ ਮੰਜ਼ਿਲTLS ਜਾਂਚਾਂ
HTTPS ਮੰਜ਼ਿਲ ਲਈ HTTP ਪ੍ਰਾਕਸੀCONNECT ਤੋਂ ਬਾਅਦ ਟਨਲ ਰਾਹੀਂ ਮੰਜ਼ਿਲ ਦੇ ਸਰਟੀਫਿਕੇਟ ਦੀ ਤਸਦੀਕ ਕਰੋ।
HTTPS ਮੰਜ਼ਿਲ ਲਈ HTTPS ਪ੍ਰਾਕਸੀਪਹਿਲਾਂ ਪ੍ਰਾਕਸੀ ਤੱਕ TLS ਦੀ ਤਸਦੀਕ ਕਰੋ; ਟਨਲ ਖੁੱਲ੍ਹਣ ਤੋਂ ਬਾਅਦ ਮੰਜ਼ਿਲ ਦੇ ਵੱਖਰੇ TLS ਸੈਸ਼ਨ ਦੀ ਤਸਦੀਕ ਕਰੋ।

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

curl ਦੋਵਾਂ ਕਨੈਕਸ਼ਨਾਂ ਲਈ ਵੱਖਰੇ CA ਵਿਕਲਪ ਦਿੰਦਾ ਹੈ:

curl --proxy https://proxy.example:8443 --proxy-cacert proxy-ca.pem --cacert site-ca.pem https://example.com/

--proxy-cacert ਪ੍ਰਾਕਸੀ ਲਈ ਭਰੋਸੇ ਦਾ ਆਧਾਰ ਦਿੰਦਾ ਹੈ; --cacert ਮੰਜ਼ਿਲ ਲਈ। ਮਿਸਾਲ ਦੇ ਐਂਡਪੁਆਇੰਟ ਅਤੇ ਫਾਈਲਾਂ ਨੂੰ ਆਪਣੇ ਚਾਹੇ ਭਰੋਸੇ ਦੇ ਪ੍ਰਬੰਧ ਦੇ ਮੁੱਲਾਂ ਨਾਲ ਬਦਲੋ। ਸਿਸਟਮ ਦਾ ਭਰੋਸਾ ਪਹਿਲਾਂ ਹੀ ਕਾਫ਼ੀ ਹੋਵੇ ਤਾਂ ਕਸਟਮ ਬੰਡਲ ਦੀ ਲੋੜ ਨਹੀਂ।

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

ਪੋਰਟ ਕਨੈਕਸ਼ਨ ਜਾਂ CONNECT ਦਾ ਰੱਦ ਹੋਣਾ ਪਹਿਲੇ ਪੜਾਅ ਦਾ ਮਾਮਲਾ ਹੈ; ਸਰਟੀਫਿਕੇਟ ਬਦਲਣ ਨਾਲ ਇਹ ਠੀਕ ਨਹੀਂ ਹੋਵੇਗਾ। ਦੂਜੇ ਪਾਸੇ, ਮੰਜ਼ਿਲ ਦੀ TLS ਤਸਦੀਕ ਤੋਂ ਬਾਅਦ ਵੈੱਬਸਾਈਟ ਦੀ HTTP ਗਲਤੀ ਮਿਲੇ ਜਵਾਬ ਦਾ ਮਾਮਲਾ ਹੈ, ਇਕ ਹੋਰ CA ਤਬਦੀਲੀ ਦਾ ਨਹੀਂ।

ਸੰਬੰਧਿਤ ਲੇਖ