HTTPS ਪ੍ਰੌਕਸੀ ਨੂੰ ਵੀ ਆਪਣੀ ਸਰਟੀਫਿਕੇਟ ਚੇਨ ਭੇਜਣੀ ਪੈਂਦੀ ਹੈ

ਜੇ ਕਲਾਇੰਟ ਵੈੱਬਸਾਈਟ 'ਤੇ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ HTTPS ਪ੍ਰੌਕਸੀ ਨੂੰ ਰੱਦ ਕਰਦੇ ਹਨ, ਤਾਂ ਪ੍ਰੌਕਸੀ ਲਿਸਨਰ ਵੱਲੋਂ ਭੇਜੀ ਜਾਂਦੀ ਚੇਨ ਦੀ ਜਾਂਚ ਕਰੋ। ਸਿਰਫ਼ ਇੱਕ ਵੈਧ ਲੀਫ਼ ਸਰਟੀਫਿਕੇਟ ਕਲਾਇੰਟ ਨੂੰ ਲੋੜੀਂਦੇ ਇੰਟਰਮੀਡੀਏਟ ਸਰਟੀਫਿਕੇਟ ਨਹੀਂ ਦੇ ਸਕਦਾ।

1. ਜਾਂਚੇ ਜਾ ਰਹੇ ਐਂਡਪੌਇੰਟ ਦੀ ਪਛਾਣ ਕਰੋ। ਕੌਂਫਿਗਰ ਕੀਤੇ ਪ੍ਰੌਕਸੀ URL ਵਿੱਚ ਹੋਸਟਨਾਮ ਅਤੇ ਉਸ ਕਨੈਕਸ਼ਨ ਦੀ ਗਲਤੀ ਪੜ੍ਹੋ। ਲਿਸਨਰ ਦੇ ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਉਹ ਨਾਮ ਕਵਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਵੈੱਬਸਾਈਟ ਦਾ ਸਰਟੀਫਿਕੇਟ ਜਾਂ ਕਿਸੇ ਹੋਰ IP ਉਪਨਾਮ ਦਾ ਸਰਟੀਫਿਕੇਟ ਇਸ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈ ਸਕਦਾ।
2. ਲਿਸਨਰ ਦੀ ਚੇਨ ਕੌਂਫਿਗਰੇਸ਼ਨ ਜਾਂਚੋ। Squid ਦੁਆਰਾ ਸਮਰਥਿਤ OpenSSL ਕੌਂਫਿਗਰੇਸ਼ਨ ਸਰਟੀਫਿਕੇਟ ਫਾਈਲ ਵਿੱਚ ਇੰਟਰਮੀਡੀਏਟ ਸ਼ਾਮਲ ਕਰ ਸਕਦੀ ਹੈ। ਸਥਾਪਿਤ Squid ਸੰਸਕਰਣ ਅਤੇ TLS backend ਲਈ ਲਿਸਨਰ ਸੰਦਰਭ ਵਿੱਚ ਪ੍ਰਬੰਧ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ; ਪੈਕੇਜ ਦਾ ਵਿਵਹਾਰ ਇਕਸਾਰ ਨਹੀਂ ਹੈ। Squid 6.13 ਦਾ TLS ਲਿਸਨਰ ਉਦਾਹਰਨ ਲਿਸਨਰ ਦੇ ਭਰੋਸੇ ਨੂੰ ਮੰਜ਼ਿਲ ਦੇ TLS ਤੋਂ ਵੱਖ ਰੱਖਦਾ ਹੈ।
3. ਕਲਾਇੰਟ ਦੇ ਭਰੋਸੇ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਜਾਂਚੋ। ਇੰਟਰਮੀਡੀਏਟ ਭੇਜਣਾ ਚੇਨ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਪਰ ਕਲਾਇੰਟ ਨੂੰ ਅਜੇ ਵੀ ਇੱਛਤ ਰੂਟ ਟਰੱਸਟ ਐਂਕਰ ਦੀ ਲੋੜ ਹੈ। ਪੂਰੀ ਸਰਵਰ ਚੇਨ ਨੂੰ ਬਿਨਾਂ ਭੇਦਭਾਵ ਦੇ ਰੂਟ ਸਟੋਰ ਵਿੱਚ ਆਯਾਤ ਕਰਨਾ ਸਰਵਰ ਜੋ ਭੇਜਦਾ ਹੈ ਉਸ ਨੂੰ ਠੀਕ ਕਰਨ ਤੋਂ ਵੱਖਰੀ ਤਬਦੀਲੀ ਹੈ।

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