ପ୍ରକ୍ସି ବ୍ୟବହାର ବେଳେ ସାର୍ଟିଫିକେଟ୍ ତ୍ରୁଟି
ସାର୍ଟିଫିକେଟ୍ ସେଟିଂ ବଦଳାଇବା ପୂର୍ବରୁ ଯାଞ୍ଚ ପ୍ରକ୍ସିର ନିଜ TLS ସଂଯୋଗରେ ବିଫଳ ହେଲା କି ଗନ୍ତବ୍ୟ ୱେବସାଇଟ୍ରେ, ଚିହ୍ନଟ କରନ୍ତୁ।
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 ପରିବର୍ତ୍ତନର ନୁହେଁ।