eMudhra ଇଣ୍ଟରମିଡିଏଟ୍ CA କମ୍ପ୍ରୋମାଇଜ୍: ଆପଣଙ୍କ ଏନଭାଇରନମେଣ୍ଟରେ ପ୍ରଭାବିତ ସାର୍ଟିଫିକେଟ୍‌ଗୁଡ଼ିକୁ କିପରି ଖୋଜିବେ

eMudhra ଇଣ୍ଟରମିଡିଏଟ୍ CA କମ୍ପ୍ରୋମାଇଜ୍: ଆପଣଙ୍କ ଏନଭାଇରନମେଣ୍ଟରେ ପ୍ରଭାବିତ ସାର୍ଟିଫିକେଟ୍‌ଗୁଡ଼ିକୁ କିପରି ଖୋଜିବେ

ଆଠଟି ବାତିଲ (revoked) ହୋଇଥିବା ଇଣ୍ଟରମିଡିଏଟ୍, ଦୁର୍ବଳ P-384 କି’ଗୁଡ଼ିକ ଏବଂ ସର୍ଭର, Go ଆପ୍ସ ଓ ଟ୍ରଷ୍ଟ ଷ୍ଟୋର୍ ପାଇଁ ଏକ ବ୍ୟବହାରିକ ଚେକଲିଷ୍ଟ

ଆପଣଙ୍କ ବ୍ରାଉଜରରେ ଥିବା ପ୍ରତ୍ୟେକ ପ୍ୟାଡଲକ୍ (ତାଲା ଚିହ୍ନ) ଏକ ବିଶ୍ୱାସର ଶୃଙ୍ଖଳା (chain of trust) ଉପରେ ନିର୍ଭର କରେ, ଏବଂ ସେହି ଚେନ୍ କେବଳ ସେତିକି ଶକ୍ତିଶାଳୀ ଯେତିକି ଏଥିରେ ଥିବା ସବୁଠାରୁ ଦୁର୍ବଳ ପ୍ରାଇଭେଟ୍ କି’। ଏହି ମାସରେ, ସେଭଳି ଏକ ଚେନ୍‌ର ଆଠଟି ଲିଙ୍କ୍ ଅନୁମାନଯୋଗ୍ୟ (guessable) ବୋଲି ଜଣାପଡ଼ିଛି।

ଆଜି ଅକ୍ଟୋବର ୨୬, ୨୦୨୬। ଅକ୍ଟୋବର ୧୭ ରେ, ଜଣେ ଗବେଷକ ରିପୋର୍ଟ କରିଥିଲେ ଯେ ଏକ ସାର୍ଟିଫିକେଟ୍ ଅଥରିଟି (CA) eMudhra ର ଆଠଟି ଇଣ୍ଟରମିଡିଏଟ୍ ସାର୍ଟିଫିକେଟ୍ ପଛରେ ଥିବା ପ୍ରାଇଭେଟ୍ କି’ଗୁଡ଼ିକୁ ରିକଭର୍ କରାଯାଇପାରିବ। ପ୍ରମୁଖ ବ୍ରାଉଜର୍ ଏବଂ ଅପରେଟିଂ ସିଷ୍ଟମ୍ ଭେଣ୍ଡରମାନଙ୍କ ଦ୍ୱାରା ଏହି ସାର୍ଟିଫିକେଟ୍‌ଗୁଡ଼ିକୁ ବାତିଲ (revoked) ଏବଂ ବ୍ଲକ୍ କରାଯାଇଛି। ଏହି ସମସ୍ୟାଟି CVE-2026-111943 ଏବଂ CVE-2026-111944 ଭାବରେ ଟ୍ରାକ୍ କରାଯାଉଛି। ଏହି ସପ୍ତାହରେ ସୁରକ୍ଷା ଟିମ୍ ପାଇଁ ଜରୁରୀ କାର୍ଯ୍ୟ କହିବାକୁ ସହଜ କିନ୍ତୁ କରିବା ପାଇଁ ପରିଶ୍ରମସାପେକ୍ଷ: ଆପଣଙ୍କ ଏନଭାଇରନମେଣ୍ଟରେ ଏହି ସାର୍ଟିଫିକେଟ୍‌ଗୁଡ଼ିକ ମଧ୍ୟରୁ କୌଣସିଟି କେଉଁଠାରେ ଦେଖାଯାଉଛି କି ନାହିଁ ଏବଂ ଆପଣଙ୍କର କୌଣସି ସଫ୍ଟୱେର୍ ଏବେ ବି ସେଗୁଡ଼ିକୁ ବିଶ୍ୱାସ କରୁଛି କି ନାହିଁ ତାହା ଖୋଜି ବାହାର କରିବା।

ସାର୍ଟିଫିକେଟ୍ ଚେନ୍ ସମ୍ପର୍କରେ ଏକ ସଂକ୍ଷିପ୍ତ ସୂଚନା

ଯେତେବେଳେ ଆପଣ HTTPS ମାଧ୍ୟମରେ କୌଣସି ୱେବସାଇଟ୍ ପରିଦର୍ଶନ କରନ୍ତି, ସର୍ଭର ଏହାର ନିଜ ନାମ ପାଇଁ ଏକ ଲିଫ୍ ସାର୍ଟିଫିକେଟ୍ (leaf certificate) ଦେଖାଇଥାଏ। ସେହି ସାର୍ଟିଫିକେଟ୍ ଏକ ଇଣ୍ଟରମିଡିଏଟ୍ CAଦ୍ୱାରା ସ୍ୱାକ୍ଷରିତ ହୋଇଥାଏ, ଏବଂ ସେହି ଇଣ୍ଟରମିଡିଏଟ୍ ଏକ ରୁଟ୍ CAଦ୍ୱାରା ସ୍ୱାକ୍ଷରିତ ହୋଇଥାଏ। ଆପଣଙ୍କ ବ୍ରାଉଜର୍ କିମ୍ବା ଅପରେଟିଂ ସିଷ୍ଟମ୍ ବିଶ୍ୱାସ କରୁଥିବା ରୁଟ୍‌ଗୁଡ଼ିକର ଏକ ତାଲିକା ପ୍ରଦାନ କରିଥାଏ, ଯାହାକୁ କୁହାଯାଏ ଏକ ଟ୍ରଷ୍ଟ ଷ୍ଟୋର୍ (trust store).

ରୁଟ୍ କି’ଗୁଡ଼ିକୁ ଅଫଲାଇନ୍ ରଖାଯାଏ ଏବଂ କଡ଼ା ସୁରକ୍ଷାରେ ରଖାଯାଏ। ଇଣ୍ଟରମିଡିଏଟ୍‌ଗୁଡ଼ିକ ଦୈନନ୍ଦିନ ସାଇନିଂ କାର୍ଯ୍ୟ କରନ୍ତି। ମୁଖ୍ୟ କଥା ହେଉଛି ଯେ ଯାହା ପାଖରେ ଇଣ୍ଟରମିଡିଏଟ୍‌ର ପ୍ରାଇଭେଟ୍ କି’ ଥାଏ, ସେ ଯେକୌଣସି ନାମ ପାଇଁ ସାର୍ଟିଫିକେଟ୍ ସାଇନ୍ କରିପାରିବ, ଏବଂ ଯେଉଁ କ୍ଲାଏଣ୍ଟମାନେ ସେହି ଚେନ୍‌କୁ ବିଶ୍ୱାସ କରନ୍ତି ସେମାନେ ସାଧାରଣତଃ ଏହାକୁ ଗ୍ରହଣ କରିବେ। ସେଥିପାଇଁ ଏକ ଲିକ୍ ହୋଇଥିବା ଇଣ୍ଟରମିଡିଏଟ୍ କି’ ଅତ୍ୟନ୍ତ ଗୁରୁତର, ଯଦିଓ ଏପର୍ଯ୍ୟନ୍ତ କୌଣସି ଖରାପ ସାର୍ଟିଫିକେଟ୍ ଦେଖାଯାଇ ନାହିଁ।

ରିପୋର୍ଟ ଅନୁଯାୟୀ କ’ଣ ଘଟିଥିଲା

ସାର୍ବଜନୀନ ଖୁଲାସା ଏବଂ ଭେଣ୍ଡରଙ୍କ ରିପୋର୍ଟ ଅନୁସାରେ, ଘଟଣାଟି ଏହିପରି ଥିଲା:

  • ଏପ୍ରିଲ୍ ୩୦, ୨୦୨୫ ରେ ଏକ କି’ ଜେନେରେସନ୍ ସମାରୋହରେ, eMudhra ୨୪ଟି ସବଅର୍ଡିନେଟ୍ CA ପାଇଁ କି’ଗୁଡ଼ିକ ତିଆରି କରିଥିଲା।
  • ଏକ wrap/unwrap ଷ୍ଟେପ୍‌ରେ ଥିବା ତ୍ରୁଟି ହେତୁ ଦୁର୍ବଳ P-384 କି’ଗୁଡ଼ିକର ଏକ ଦ୍ୱିତୀୟ ସେଟ୍ ସୃଷ୍ଟି ହୋଇଥିଲା। P-384 ହେଉଛି ଏକ ଇଲିପ୍ଟିକ୍ କର୍ଭ (elliptic curve) ଯାହା ଏକ ବହୁତ ବଡ଼ କି’ ସ୍ପେସ୍ (key space) ପ୍ରଦାନ କରିବା ଉଚିତ।
  • ସେହି ଦୁର୍ବଳ କି’ଗୁଡ଼ିକୁ ଭୁଲବଶତଃ ଆଠଟି ଇଣ୍ଟରମିଡିଏଟ୍ ସାର୍ଟିଫିକେଟ୍ ପାଇଁ ବ୍ୟବହାର କରାଯାଇଥିଲା। ସେଗୁଡ଼ିକର ପ୍ରଭାବଶାଳୀ ରାଣ୍ଡମନେସ୍ (ଏଣ୍ଟ୍ରୋପି) ପ୍ରାୟ ୩ ରୁ ୮ ବିଟ୍ ଥିବା ରିପୋର୍ଟ କରାଯାଇଥିଲା, ଯାହାର ଅର୍ଥ ହେଉଛି ସର୍ବାଧିକ ମାତ୍ର କିଛି ଶହ ସମ୍ଭାବ୍ୟ କି’। କମ୍ପ୍ୟୁଟର ପାଇଁ ସେଗୁଡ଼ିକୁ ପୁନରୁଦ୍ଧାର କରିବା ଅତ୍ୟନ୍ତ ସହଜ।
  • ଏହି ଆଠଟି ମଧ୍ୟରୁ ଛଅଟି ହେଉଛି TLS ଇଣ୍ଟରମିଡିଏଟ୍ ଏବଂ ଦୁଇଟି କୋଡ୍-ସାଇନିଂ ଇଣ୍ଟରମିଡିଏଟ୍।

ଏହାର ପ୍ରତିକ୍ରିୟା, ପୁନଶ୍ଚ ରିପୋର୍ଟ ଅନୁଯାୟୀ:

  • Chrome, Mozilla ଏବଂ Apple ଛଅଟି TLS ଇଣ୍ଟରମିଡିଏଟ୍‌କୁ ବ୍ଲକ୍ କରିଦେଇଛନ୍ତି। Microsoft ଦୁଇଟି କୋଡ୍-ସାଇନିଂ ଇଣ୍ଟରମିଡିଏଟ୍‌କୁ ବ୍ଲକ୍ କରିଛି।
  • Google Chrome Root Store ରୁ emSign ECC Root CA - G3 କୁ ହଟାଇ ଦେଇଛି, ଏବଂ Mozilla ଇଣ୍ଟରମିଡିଏଟ୍‌ଗୁଡ଼ିକୁ ସ୍ୱାକ୍ଷର କରିଥିବା ରୁଟ୍ ଉପରୁ ବିଶ୍ୱାସ ପ୍ରତ୍ୟାହାର କରିଛି।
  • eMudhra ଏହି ଆଠଟି ସାର୍ଟିଫିକେଟ୍‌କୁ ବାତିଲ କରିଦେଇଛି ଏବଂ ଏହାର G3 ରୁଟ୍ ଅଧୀନରେ ଇସ୍ୟୁ କରିବା ବନ୍ଦ କରିଦେଇଛି। ଏହା ଦର୍ଶାଇଛି ଯେ ଏହାର ରୁଟ୍ ପ୍ରାଇଭେଟ୍ କି’ ଏବଂ ଅନ୍ୟାନ୍ୟ ଇଣ୍ଟରମିଡିଏଟ୍ ପ୍ରଭାବିତ ହୋଇନାହାନ୍ତି, ଏହି ସମସ୍ୟା କେବଳ ଏହାର ବିଶ୍ୱସ୍ତରୀୟ ୱେବସାଇଟ୍-ସୁରକ୍ଷା ବ୍ୟବସାୟ ମଧ୍ୟରେ ସୀମିତ ଏବଂ ଏହାର ଭାରତୀୟ DSC ଓ eSign ସେବାଗୁଡ଼ିକ ଉପରେ କୌଣସି ପ୍ରଭାବ ପଡ଼ିନାହିଁ, ଏବଂ ପ୍ରଭାବିତ ଇଣ୍ଟରମିଡିଏଟ୍‌ଗୁଡ଼ିକ ମଧ୍ୟରୁ କେବଳ ଗୋଟିଏ ପ୍ରଡକ୍ସନରେ ବ୍ୟବହୃତ ହୋଇଥିଲା, ଯେଉଁଥିରୁ କୌଣସିଟି ୱେବସାଇଟ୍ କିମ୍ବା ଶେଷ ଉପଭୋକ୍ତାମାନଙ୍କୁ ସାର୍ଟିଫିକେଟ୍ ଇସ୍ୟୁ କରିନଥିଲା।

ଭେଣ୍ଡରଙ୍କ ବିବୃତ୍ତିକୁ ସେମାନଙ୍କର ନିଜସ୍ୱ ବୟାନ ଭାବରେ ଗ୍ରହଣ କରନ୍ତୁ। ଆପଣଙ୍କ କାମ ଏହି ଘଟଣାର ବିଚାର କରିବା ନୁହେଁ ବରଂ ଆପଣଙ୍କ ନିଜସ୍ୱ ଏକ୍ସପୋଜର୍ (ସୁରକ୍ଷା ବିପଦ) ନିଶ୍ଚିତ କରିବା।

ପ୍ରଥମେ କାହାକୁ ଯାଞ୍ଚ କରିବା ଉଚିତ

ଆପଣ ଏହାକୁ ତାଲିକାର ଶୀର୍ଷରେ ରଖିବା ଉଚିତ ଯଦି ଆପଣ:

  • ଇଣ୍ଟରନେଟ୍-ଫେସିଂ ୱେବସାଇଟ୍, API, VPN କିମ୍ବା ଅନ୍ୟାନ୍ୟ TLS ସେବା ଚଳାଉଛନ୍ତି।
  • eMudhra କିମ୍ବା emSign ହାୟାରାର୍କି ମାଧ୍ୟମରେ ସାର୍ବଜନୀନ ଭାବରେ ବିଶ୍ୱସନୀୟ ସାର୍ଟିଫିକେଟ୍ କିଣୁଛନ୍ତି।
  • ସାର୍ବଜନୀନ କୋଡ୍-ସାଇନିଂ ସାର୍ଟିଫିକେଟ୍ ଉପରେ ନିର୍ଭର କରୁଥିବା ସାଇନ୍ ହୋଇଥିବା ସଫ୍ଟୱେର୍ ପ୍ରଦାନ କରୁଛନ୍ତି।
  • Go ରେ ଲେଖାଯାଇଥିବା ଆପ୍ଲିକେସନ୍ ନିର୍ମାଣ କିମ୍ବା ପରିଚାଳନା କରୁଛନ୍ତି।
  • ପୁରୁଣା ସିଷ୍ଟମ୍ (legacy systems), ଅନ୍‌ମ୍ୟାନେଜ୍‌ଡ୍ ଏଣ୍ଡପଏଣ୍ଟ, ଆପ୍ଲାଏନ୍ସ କିମ୍ବା କଷ୍ଟମ୍ ଟ୍ରଷ୍ଟ ଷ୍ଟୋର୍‌ଗୁଡ଼ିକର ଯତ୍ନ ନେଉଛନ୍ତି ଯେଉଁଗୁଡ଼ିକ ସ୍ୱୟଂଚାଳିତ ଭାବରେ ଅବିଶ୍ୱାସ (distrust) ଅପଡେଟ୍ ପାଆନ୍ତି ନାହିଁ।

ଆଠଟି ପ୍ରଭାବିତ ଇଣ୍ଟରମିଡିଏଟ୍

ଏକ ସାର୍ଟିଫିକେଟ୍ ମେଳାଇବା ପାଇଁ SHA-256 ଫିଙ୍ଗରପ୍ରିଣ୍ଟ ଏବଂ ସିରିଏଲ୍ ନମ୍ବର ହେଉଛି ସବୁଠାରୁ ବିଶ୍ୱସନୀୟ ଉପାୟ। ନାମ ନକଲ କରାଯାଇପାରେ; କିନ୍ତୁ ଫିଙ୍ଗରପ୍ରିଣ୍ଟ ନୁହେଁ।

ସାର୍ଟିଫିକେଟ୍ ପ୍ରକାର ସିରିଏଲ୍ ନମ୍ବର SHA-256 ଫିଙ୍ଗରପ୍ରିଣ୍ଟ
EM EV TLS CA - G3B (eMudhra BV) TLS c7c41efe92d825f05eae841a4a82c1 E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838
EM OV TLS CA - G3B (eMudhra BV) TLS 6cada367fb1c100088120ea202d568 98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B
EM DV TLS CA - G3B (eMudhra BV) TLS a4aee678f23362b4c0e460b772f214 42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493
EM EV TLS CA - G3C (eMudhra Inc) TLS 8009928a64107601af05fa2f19f109 432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3
EM OV TLS CA - G3C (eMudhra Inc) TLS 296926c227a3a1526392b19482a504 CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F
EM DV TLS CA - G3C (eMudhra Inc) TLS 588b2e3c2bb8cda13e1a1209254321 0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19
EM OV CS CA - G3B (eMudhra BV) କୋଡ୍ ସାଇନିଂ 7818933f8f85b4619a2b35fba83d0a 9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4
EM OV CS CA - G3C (eMudhra Inc) କୋଡ୍ ସାଇନିଂ 544b7f922c31ae220a4a922916f6e6 4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1

ସେଗୁଡ଼ିକୁ କିପରି ଖୋଜିବେ: ଏକ ପର୍ଯ୍ୟାୟକ୍ରମିକ ଯାଞ୍ଚ

ଏହି ଏକ୍ସପୋଜର୍‌ର ଦୁଇଟି ପାର୍ଶ୍ୱ ରହିଛି। ଗୋଟିଏ ହେଉଛି ଆପଣଙ୍କ ସର୍ଭରଗୁଡ଼ିକ କ’ଣ ଉପସ୍ଥାପନ କରନ୍ତି। ଅନ୍ୟଟି ହେଉଛି ଆପଣଙ୍କ ସଫ୍ଟୱେର୍ ଏବେ ବି କାହାକୁ ବିଶ୍ୱାସ କରେ। ନିମ୍ନଲିଖିତ ପଦକ୍ଷେପଗୁଡ଼ିକ ଉଭୟକୁ ଅନ୍ତର୍ଭୁକ୍ତ କରେ, ପ୍ରଥମେ ସାଧାରଣ ଓପନ୍-ସୋର୍ସ ଟୁଲ୍ସ ସହିତ ଏବଂ ତା’ପରେ ବ୍ୟବସାୟିକ ସ୍କାନର୍ ଥିବା ଟିମ୍‌ଗୁଡ଼ିକ ପାଇଁ କମର୍ସିଆଲ୍ ସ୍କାନର୍ ସହିତ।

ଷ୍ଟେପ୍ ୧: TLS ବ୍ୟବହାର କରୁଥିବା ପ୍ରତ୍ୟେକ ଜିନିଷର ଏକ ତାଲିକା ପ୍ରସ୍ତୁତ କରନ୍ତୁ

ଆପଣ ଯାହା ତାଲିକାଭୁକ୍ତ କରିନାହାନ୍ତି ତାହା ଯାଞ୍ଚ କରିପାରିବେ ନାହିଁ। ଆପଣଙ୍କର ପବ୍ଲିକ୍ ଡୋମେନ୍, ଆଭ୍ୟନ୍ତରୀଣ ସର୍ଭିସ୍ ନାମ, ଲୋଡ୍ ବାଲାନ୍ସର୍, VPN ଗେଟୱେ ଏବଂ ଆପଣଙ୍କ ନାମ ବ୍ୟବହାର କରୁଥିବା ଯେକୌଣସି ତୃତୀୟ-ପକ୍ଷ ହୋଷ୍ଟେଡ୍ ସାଇଟ୍‌ଗୁଡ଼ିକୁ ଏକତ୍ର କରନ୍ତୁ। ସ୍କାନର୍ ପହଞ୍ଚିପାରୁନଥିବା ସର୍ଭରଗୁଡ଼ିକୁ ଅନ୍ତର୍ଭୁକ୍ତ କରନ୍ତୁ, ଯେପରିକି ରିମୋଟ୍ କର୍ମଚାରୀଙ୍କ ଲ୍ୟାପଟପ୍ ଏବଂ ବିଚ୍ଛିନ୍ନ ନେଟୱାର୍କ। ସେଗୁଡ଼ିକୁ ଦେଖିବା ପାଇଁ ହୋଷ୍ଟ ଉପରେ ଏକ ଏଜେଣ୍ଟ ପ୍ରାୟତଃ ଏକମାତ୍ର ଉପାୟ।

ଷ୍ଟେପ୍ ୨: ପ୍ରତ୍ୟେକ ସର୍ଭର ଉପସ୍ଥାପନ କରୁଥିବା ଚେନ୍ ଯାଞ୍ଚ କରନ୍ତୁ

ଯେକୌଣସି ଗୋଟିଏ ହୋଷ୍ଟ ପାଇଁ, OpenSSL ଚେନ୍‌ରେ ଥିବା ପ୍ରତ୍ୟେକ ସାର୍ଟିଫିକେଟ୍‌କୁ ଏହାର ସବ୍‌ଜେକ୍ଟ, ଇସ୍ୟୁଅର୍, ସିରିଏଲ୍ ଏବଂ ଫିଙ୍ଗରପ୍ରିଣ୍ଟ ସହିତ ପ୍ରିଣ୍ଟ କରିପାରିବ। ଏଠାରେ app.example.com କୁ ଆପଣଙ୍କ ନିଜସ୍ୱ ହୋଷ୍ଟ ସହିତ ବଦଳାନ୍ତୁ:

HOST=app.example.com
echo | openssl s_client -connect "$HOST:443" -servername "$HOST" -showcerts 2>/dev/null \
  | awk '/-----BEGIN CERTIFICATE-----/{n++; f=1} f{print > ("chain-" n ".pem")} /-----END CERTIFICATE-----/{f=0}'

for f in chain-*.pem; do
  openssl x509 -in "$f" -noout -subject -issuer -serial -fingerprint -sha256
  echo
done

OpenSSL ସିରିଏଲ୍‌ଗୁଡ଼ିକୁ ବଡ଼ ଅକ୍ଷରରେ (upper case) ଏବଂ ଫିଙ୍ଗରପ୍ରିଣ୍ଟଗୁଡ଼ିକୁ କୋଲନ୍ (:) ସହିତ ପ୍ରିଣ୍ଟ କରେ, ତେଣୁ କେସ୍ କିମ୍ବା କୋଲନ୍ ପ୍ରତି ଧ୍ୟାନ ନଦେଇ ତୁଳନା କରନ୍ତୁ। ଆଠଟିର ତାଲିକା ସହିତ ଏକ ଦ୍ରୁତ ମେଳ:

for f in chain-*.pem; do
  openssl x509 -in "$f" -noout -fingerprint -sha256 | cut -d= -f2 | tr -d ':'
done | grep -i -E 'E7568FE6|98B89662|42C4ACCD|432EC25F|CB6E1516|0164D7CE|9E39DE28|4B2460A4' \
  && echo "MATCH: affected intermediate found" || echo "No affected intermediate in this chain"

ପ୍ରିଫିକ୍ସଗୁଡ଼ିକ କେବଳ ଏକ ଦ୍ରୁତ ଫିଲ୍ଟର୍। ଯଦି କିଛି ମେଳ ଖାଏ, ତେବେ ପଦକ୍ଷେପ ନେବା ପୂର୍ବରୁ ସାରଣୀ ସହିତ ସମ୍ପୂର୍ଣ୍ଣ ଫିଙ୍ଗରପ୍ରିଣ୍ଟକୁ ତୁଳନା କରନ୍ତୁ। ଏକ ମୌଳିକ ଯାଞ୍ଚ ପାଇଁ ଆପଣଙ୍କ ହୋଷ୍ଟ ତାଲିକା ଉପରେ ଏହାକୁ ଲୁପ୍ (loop) କରନ୍ତୁ।

ଷ୍ଟେପ୍ ୩: ଯଦି ଆପଣ ଏକ ଭଲନରେବିଲିଟି ସ୍କାନର୍ ଚଳାଉଛନ୍ତି ତେବେ ବ୍ୟାପକ ସ୍ତରରେ ସର୍ଚ୍ଚ କରନ୍ତୁ

ଯଦି ଆପଣଙ୍କ ପ୍ରତିଷ୍ଠାନ ପୂର୍ବରୁ Certificate View ସହିତ Qualys VMDR ବ୍ୟବହାର କରୁଛି, ତେବେ Qualys ପ୍ରସ୍ତୁତ କ୍ୱେରୀ ପ୍ରକାଶ କରିଛି। Certificate View ରେ, ଇସ୍ୟୁଅର୍ ନାମ ଉପରେ ଏକ ସର୍ଚ୍ଚ ସମସ୍ତ ଆଠଟିକୁ ଅନ୍ତର୍ଭୁକ୍ତ କରେ:

certificate:(issuer.name:[`EM EV TLS CA – G3B`, `EM OV TLS CA – G3B`, `EM DV TLS CA – G3B`, `EM EV TLS CA – G3C`, `EM OV TLS CA – G3C`, `EM DV TLS CA – G3C`, `EM OV CS CA – G3B`, `EM OV CS CA – G3C`])

ଏକ ବ୍ୟାପକ ଯାଞ୍ଚ ପ୍ରଭାବିତ ଇଣ୍ଟରମିଡିଏଟ୍‌ଗୁଡ଼ିକରେ ଉଲ୍ଲେଖ ଥିବା ଦୁଇଟି eMudhra ସଂସ୍ଥା ଅଧୀନରେ ଜାରି କରାଯାଇଥିବା ପ୍ରତ୍ୟେକ ସାର୍ଟିଫିକେଟ୍‌କୁ ତାଲିକାଭୁକ୍ତ କରେ:

certificate:(issuer.organization:`eMudhra BV` or issuer.organization:`eMudhra Inc`)

Qualys ପ୍ରଭାବିତ Go ସଂସ୍କରଣଗୁଡ଼ିକ ପାଇଁ QID 5019897 ଏବଂ QID 48395 କୁ ମଧ୍ୟ ତାଲିକାଭୁକ୍ତ କରେ, ଯାହା ଏକ ତଥ୍ୟ-ସଂଗ୍ରହ ଯାଞ୍ଚ ଯାହା ଆଠଟି ଇଣ୍ଟରମିଡିଏଟ୍ ଧାରଣ କରିଥିବା ଚେନ୍‌ଗୁଡ଼ିକୁ ଗଣନା କରେ। ଏଗୁଡ଼ିକ ଉପରେ ନିର୍ଭର କରିବା ପୂର୍ବରୁ ନିଶ୍ଚିତ କରନ୍ତୁ ଯେ ଆପଣଙ୍କ ଏଜେଣ୍ଟମାନଙ୍କ ପାଖରେ ନୂତନ ସିଗ୍ନେଚର୍ ରହିଛି। କ୍ୱେରୀ ଟୋକନ୍‌ଗୁଡ଼ିକ କେସ୍-ସେନ୍ସିଟିଭ୍ (case-sensitive), ତେଣୁ ଯଦି କ୍ୱେରୀରେ ତ୍ରୁଟି ଦେଖାଯାଏ ତେବେ ପ୍ରଡକ୍ଟ ସହାୟତା ଯାଞ୍ଚ କରନ୍ତୁ। ଅନ୍ୟ ସ୍କାନର୍‌ଗୁଡ଼ିକର ନିଜସ୍ୱ ସମକକ୍ଷ ରହିବ; ଟେବୁଲ୍‌ରେ ଥିବା ଫିଙ୍ଗରପ୍ରିଣ୍ଟଗୁଡ଼ିକ ଯେକୌଣସି ଟୁଲ୍ ସହିତ କାମ କରେ।

ଷ୍ଟେପ୍ ୪: ଖରାପ ଚେନ୍‌ଗୁଡ଼ିକୁ ଏବେ ବି ବିଶ୍ୱାସ କରୁଥିବା Go ପ୍ରୋଗ୍ରାମଗୁଡ଼ିକୁ ଖୋଜନ୍ତୁ

ଏହି ଅଂଶଟି ପ୍ରାୟତଃ ଲୋକଙ୍କ ନଜରରୁ ବାଦ୍ ପଡ଼ିଯାଏ। ଆପଣଙ୍କ ସର୍ଭରଗୁଡ଼ିକ ସୁରକ୍ଷିତ ହୋଇପାରେ, କିନ୍ତୁ ଆପଣଙ୍କ ନିଜସ୍ୱ ଆପ୍ଲିକେସନ୍ ଏବେ ବି ଏକ ନକଲି (forged) ସାର୍ଟିଫିକେଟ୍ ଗ୍ରହଣ କରିପାରେ। ଆଡଭାଇଜରୀ ଅନୁସାରେ, Go 1.27.3 ଏବଂ 1.26.10 ସେହି ଆଠଟି କି’ ମଧ୍ୟରୁ ଯେକୌଣସି ଗୋଟିଏ ଧାରଣ କରିଥିବା ଚେନ୍‌କୁ ବ୍ଲକ୍ କରେ (CVE-2026-111943)। Go ପ୍ରୋଗ୍ରାମଗୁଡ଼ିକ ସେମାନଙ୍କର ନିଜସ୍ୱ ସାର୍ଟିଫିକେଟ୍ ଯାଞ୍ଚ କୋଡ୍ ବହନ କରନ୍ତି, ତେଣୁ ପୁରୁଣା Go ସହିତ ନିର୍ମିତ ଏକ ପ୍ରୋଗ୍ରାମ୍ ପୁନଃ ନିର୍ମାଣ (rebuild) ନହେବା ପର୍ଯ୍ୟନ୍ତ ପୁରୁଣା ବ୍ୟବହାର ଜାରି ରଖେ।

ବିଲ୍ଡ ମେସିନ୍‌ଗୁଡ଼ିକରେ ଟୁଲ୍‌ଚେନ୍ (toolchain) ଯାଞ୍ଚ କରନ୍ତୁ:

go version

ଆପଣ ପୂର୍ବରୁ ଚଳାଉଥିବା ଏକ ବାଇନାରୀକୁ କେଉଁ Go ସଂସ୍କରଣ ନିର୍ମାଣ କରିଛି ତାହା ଯାଞ୍ଚ କରନ୍ତୁ:

go version /usr/local/bin/your-service

ପୁରୁଣା ରିଲିଜ୍ ସହିତ ନିର୍ମିତ ଯେକୌଣସି ଜିନିଷକୁ ଏକ ସଂଶୋଧିତ Go ସଂସ୍କରଣ ସହିତ ପୁନଃ ନିର୍ମାଣ (rebuilt) ଏବଂ ପୁନଃ ନିୟୋଜିତ (redeployed) କରାଯିବା ଉଚିତ। ଆପଣଙ୍କ ଅପରେଟିଂ ସିଷ୍ଟମ୍ ଭେଣ୍ଡରଙ୍କ ଅପଡେଟ୍ ମଧ୍ୟ ପ୍ରୟୋଗ କରନ୍ତୁ, କାରଣ ଅନେକ ଡିଷ୍ଟ୍ରିବ୍ୟୁସନ୍ ସେମାନଙ୍କର ନିଜସ୍ୱ ପ୍ୟାଚ୍ ହୋଇଥିବା Go ପ୍ୟାକେଜ୍ ପ୍ରଦାନ କରନ୍ତି।

ଷ୍ଟେପ୍ ୫: ବଦଳାନ୍ତୁ, ଅପଡେଟ୍ କରନ୍ତୁ ଏବଂ ନଜର ରଖନ୍ତୁ

  • ପ୍ରଥମେ ବଦଳାନ୍ତୁ। ଯେଉଁ ଲିଫ୍ ସାର୍ଟିଫିକେଟ୍‌ର ଚେନ୍‌ରେ ଏହି ଆଠଟି ମଧ୍ୟରୁ ଗୋଟିଏ ଅନ୍ତର୍ଭୁକ୍ତ, ତାହାକୁ ଅନ୍ୟ ଏକ ବିଶ୍ୱସ୍ତ CA ଦ୍ୱାରା ପୁନଃ ଜାରି (reissued) କରାଯିବା ଉଚିତ ଏବଂ ସଠିକ୍ ଚେନ୍ ସହିତ ପୁନଃ ନିୟୋଜିତ କରାଯିବା ଉଚିତ।
  • ଅପଡେଟ୍ କରନ୍ତୁ। OS ସୁରକ୍ଷା ଅପଡେଟ୍ ପ୍ରୟୋଗ କରନ୍ତୁ ଏବଂ Go ରନ୍‌ଟାଇମ୍‌କୁ ସଂଶୋଧିତ ରିଲିଜ୍‌କୁ ସ୍ଥାନାନ୍ତରିତ କରନ୍ତୁ।
  • ବାତିଲକରଣ (revocation) ଯାଞ୍ଚ କାର୍ଯ୍ୟ କରୁଛି ବୋଲି ନିଶ୍ଚିତ କରନ୍ତୁ। ବାତିଲକରଣ କେବଳ ସେହି କ୍ଲାଏଣ୍ଟମାନଙ୍କୁ ସାହାଯ୍ୟ କରେ ଯେଉଁମାନେ ପ୍ରକୃତରେ ଏହାକୁ ଯାଞ୍ଚ କରନ୍ତି। କଷ୍ଟମ୍ ଟ୍ରଷ୍ଟ ଷ୍ଟୋର୍, ଆପ୍ଲାଏନ୍ସ ଏବଂ ପୁରୁଣା Java କିମ୍ବା ଏମ୍ବେଡେଡ୍ ସିଷ୍ଟମ୍‌ଗୁଡ଼ିକରୁ ଇଣ୍ଟରମିଡିଏଟ୍‌ଗୁଡ଼ିକୁ ହାତରେ (manually) ହଟାଇବା କିମ୍ବା ସ୍ପଷ୍ଟ ଭାବରେ ଅବିଶ୍ୱାସ (distrusted) କରିବା ଆବଶ୍ୟକ ହୋଇପାରେ।
  • ନଜର ରଖନ୍ତୁ। ଆପଣଙ୍କ ସର୍ଚ୍ଚଗୁଡ଼ିକୁ ଏକ ସିଡ୍ୟୁଲ୍ଡ୍ ଜବ୍ କିମ୍ବା ଡ୍ୟାସବୋର୍ଡ ଭାବରେ ସେଭ୍ କରନ୍ତୁ ଏବଂ ଫଳାଫଳ ସମ୍ପୂର୍ଣ୍ଣ ସୁରକ୍ଷିତ ନରହିବା ପର୍ଯ୍ୟନ୍ତ ପ୍ରତ୍ୟେକ ସ୍କାନ୍ ପରେ ସେଗୁଡ଼ିକୁ ପୁନର୍ବାର ଚଲାନ୍ତୁ।

ନିଷ୍କର୍ଷ

eMudhra ଘଟଣାଟି ଏକ ସ୍ମାରକ ଯେ ଇଣ୍ଟରନେଟ୍‌ରେ ବିଶ୍ୱାସ ଦୁଇଟି ଜିନିଷ ଉପରେ ନିର୍ଭର କରେ: ଆପଣ ଉପସ୍ଥାପନ କରୁଥିବା ସାର୍ଟିଫିକେଟ୍ ଏବଂ ଆପଣ ବିଶ୍ୱାସ କରିବାକୁ ବାଛିଥିବା ଅଥରିଟି। ଏହାର ସମାଧାନ କୌଣସି ଜଟିଳ ନୁହେଁ। ଆପଣଙ୍କର TLS ଏଣ୍ଡପଏଣ୍ଟଗୁଡ଼ିକୁ ତାଲିକାଭୁକ୍ତ କରନ୍ତୁ, ଆଠଟି ଜଣାଶୁଣା ଫିଙ୍ଗରପ୍ରିଣ୍ଟ ସହିତ ସେଗୁଡ଼ିକର ଚେନ୍ ଯାଞ୍ଚ କରନ୍ତୁ, ସଂଶୋଧିତ ଟୁଲ୍‌ଚେନ୍ ସହିତ Go ପ୍ରୋଗ୍ରାମଗୁଡ଼ିକୁ ପୁନଃ ନିର୍ମାଣ କରନ୍ତୁ, ଏବଂ ନିଶ୍ଚିତ କରନ୍ତୁ ଯେ ଆପଣଙ୍କର ପୁରୁଣା ସିଷ୍ଟମ୍‌ଗୁଡ଼ିକ ପ୍ରକୃତରେ ଅବିଶ୍ୱାସ (distrust) ଗ୍ରହଣ କରିଛନ୍ତି। ଏହାକୁ ଏହି ସପ୍ତାହରେ କରନ୍ତୁ, ଏବଂ ତା’ପରେ ଯାଞ୍ଚ ଜାରି ରଖନ୍ତୁ।

ସୁବିଧାଗୁଡ଼ିକ (Merits)

  • ପ୍ରଭାବିତ ସାର୍ଟିଫିକେଟ୍‌ଗୁଡ଼ିକ ସଠିକ୍ ଫିଙ୍ଗରପ୍ରିଣ୍ଟ ସହିତ ଏକ କ୍ଷୁଦ୍ର, ନିର୍ଦ୍ଦିଷ୍ଟ ତାଲିକା, ତେଣୁ ମେଳାଇବା ସଠିକ୍ ହୋଇଥାଏ।
  • ପ୍ରମୁଖ ବ୍ରାଉଜର୍ ଏବଂ ଅପରେଟିଂ ସିଷ୍ଟମ୍‌ଗୁଡ଼ିକ ପୂର୍ବରୁ ସେଗୁଡ଼ିକୁ ବ୍ଲକ୍ କରିସାରିଛନ୍ତି, ଯାହା ଅଧିକାଂଶ ସାଧାରଣ ଉପଭୋକ୍ତାଙ୍କୁ ସ୍ୱୟଂଚାଳିତ ଭାବରେ ସୁରକ୍ଷିତ ରଖେ।
  • OpenSSL ଏବଂ go version ଭଳି ମାଗଣା ଟୁଲ୍ସ ଏକ ମୌଳିକ ଯାଞ୍ଚ ପାଇଁ ଯଥେଷ୍ଟ।
  • ବିଦ୍ୟମାନ ସ୍କାନର୍‌ଗୁଡ଼ିକ ଏହି ସର୍ଚ୍ଚକୁ ଏକ ପୁନରାବୃତ୍ତିଯୋଗ୍ୟ ଡ୍ୟାସବୋର୍ଡରେ ପରିଣତ କରିପାରିବେ।
  • ଏହି ଅଭ୍ୟାସ ଭବିଷ୍ୟତର ଘଟଣାଗୁଡ଼ିକ ପାଇଁ ଆପଣଙ୍କ ସାର୍ଟିଫିକେଟ୍ ଇନଭେଣ୍ଟୋରୀକୁ ଉନ୍ନତ କରିଥାଏ।

ଅସୁବିଧାଗୁଡ଼ିକ (Demerits)

  • କଷ୍ଟମ୍ କିମ୍ବା ଫ୍ରୋଜେନ୍ ଟ୍ରଷ୍ଟ ଷ୍ଟୋର୍ ଥିବା ସିଷ୍ଟମ୍‌ଗୁଡ଼ିକ ମାନୁଆଲ୍ କାର୍ଯ୍ୟ ବିନା ଭେଣ୍ଡର ବ୍ଲକଲିଷ୍ଟରୁ ଉପକୃତ ହୁଅନ୍ତି ନାହିଁ।
  • Go ବାଇନାରୀଗୁଡ଼ିକୁ ପୁନଃ ନିର୍ମାଣ (rebuild) କରିବାକୁ ପଡ଼ିବ; କେବଳ ଟୁଲ୍‌ଚେନ୍ ଅପଡେଟ୍ କରିବା ଦ୍ୱାରା ପୂର୍ବରୁ ନିୟୋଜିତ ହୋଇଥିବା ପ୍ରୋଗ୍ରାମଗୁଡ଼ିକ ସଂଶୋଧିତ ହୁଏ ନାହିଁ।
  • ନେଟୱାର୍କ ସ୍କାନ୍ ସେହି ହୋଷ୍ଟଗୁଡ଼ିକୁ ବାଦ୍ ଦେଇଥାଏ ଯେଉଁଠାରେ ସେମାନେ ପହଞ୍ଚିପାରନ୍ତି ନାହିଁ, ତେଣୁ ଏଜେଣ୍ଟ କଭରେଜ୍ କିମ୍ବା ମାନୁଆଲ୍ ଯାଞ୍ଚ ଆବଶ୍ୟକ।
  • ଯେଉଁ କ୍ଲାଏଣ୍ଟମାନେ ଏହାକୁ ଯାଞ୍ଚ କରନ୍ତି ନାହିଁ ସେମାନଙ୍କ ପାଇଁ ବାତିଲକରଣ (revocation) ଅବିଶ୍ୱସନୀୟ।
  • ଆପ୍ଲାଏନ୍ସ ଏବଂ ତୃତୀୟ-ପକ୍ଷ ହୋଷ୍ଟେଡ୍ ସାଇଟ୍‌ଗୁଡ଼ିକରେ ସାର୍ଟିଫିକେଟ୍ ବଦଳାଇବା ପାଇଁ ସମୟ ଏବଂ ଭେଣ୍ଡରଙ୍କ ସହାୟତା ଆବଶ୍ୟକ ହୋଇପାରେ।

ସତର୍କତା (Caution)

ଏହି ଲେଖାଟି କେବଳ ଶିକ୍ଷା ଏବଂ ସାଧାରଣ ମାର୍ଗଦର୍ଶନ ପାଇଁ ଉଦ୍ଦିଷ୍ଟ। ହୋଷ୍ଟ ନାମ ଯେପରିକି app.example.com ଏବଂ ପାଥ୍ ଯେପରିକି /usr/local/bin/your-service ହେଉଛି ପ୍ଲେସହୋଲ୍ଡର, ଯାହାକୁ ଆପଣ ଆପଣଙ୍କ ନିଜସ୍ୱ ତଥ୍ୟ ସହିତ ବଦଳାଇବା ଉଚିତ। ଏହି ଘଟଣାର ବିବରଣୀ ଉପରୋକ୍ତ ତାରିଖ ସୁଦ୍ଧା ଉପଲବ୍ଧ ସାର୍ବଜନୀନ ରିପୋର୍ଟ ଏବଂ ଭେଣ୍ଡରଙ୍କ ବିବୃତ୍ତିରୁ ସଂକ୍ଷେପରେ ନିଆଯାଇଛି ଏବଂ ଏଥିରେ ପରିବର୍ତ୍ତନ ହୋଇପାରେ; ଆପଣଙ୍କ ବ୍ରାଉଜର୍, ଅପରେଟିଂ ସିଷ୍ଟମ୍, Go ଏବଂ ସ୍କାନର୍ ଭେଣ୍ଡରଙ୍କଠାରୁ ନୂତନ ଆଡଭାଇଜରୀଗୁଡ଼ିକ ଯାଞ୍ଚ କରନ୍ତୁ, ଏବଂ କୌଣସି ପଦକ୍ଷେପ ନେବା ପୂର୍ବରୁ ଏକ ପ୍ରାଧିକୃତ ଉତ୍ସରୁ ପ୍ରତ୍ୟେକ ଫିଙ୍ଗରପ୍ରିଣ୍ଟ ଯାଞ୍ଚ କରନ୍ତୁ।

ବାରମ୍ବାର ପଚରାଯାଉଥିବା ପ୍ରଶ୍ନଗୁଡ଼ିକ (FAQ)

  • eMudhra ଇଣ୍ଟରମିଡିଏଟ୍ CA କମ୍ପ୍ରୋମାଇଜ୍ କ’ଣ? — eMudhra ର ଆଠଟି ଇଣ୍ଟରମିଡିଏଟ୍ ସାର୍ଟିଫିକେଟ୍ ଦୁର୍ବଳ P-384 କି’ ସହିତ ତିଆରି ହୋଇଥିଲା ଯାହାର ପ୍ରାଇଭେଟ୍ କି’ଗୁଡ଼ିକୁ ପୁନରୁଦ୍ଧାର (recover) କରାଯାଇପାରୁଥିଲା, ତେଣୁ ଅକ୍ଟୋବର ୨୦୨୬ ରେ ପ୍ରମୁଖ ଭେଣ୍ଡରମାନଙ୍କ ଦ୍ୱାରା ସେଗୁଡ଼ିକୁ ବାତିଲ ଏବଂ ବ୍ଲକ୍ କରାଯାଇଥିଲା।
  • କେଉଁ CVE ଗୁଡ଼ିକ ଏହି ସମସ୍ୟାକୁ ଟ୍ରାକ୍ କରୁଛନ୍ତି? — ଏହା CVE-2026-111943 ଏବଂ CVE-2026-111944 ଭାବରେ ଟ୍ରାକ୍ କରାଯାଇଛି; ପ୍ରଭାବିତ ଚେନ୍‌ଗୁଡ଼ିକୁ ବ୍ଲକ୍ କରୁଥିବା Go ସମାଧାନ CVE-2026-111943 ଅଧୀନରେ ତାଲିକାଭୁକ୍ତ ହୋଇଛି।
  • ଭାରତୀୟ DSC ଏବଂ eSign ସାର୍ଟିଫିକେଟ୍ ପ୍ରଭାବିତ ହୋଇଛି କି? — eMudhra ଦର୍ଶାଇଛି ଯେ ଏହି ସମସ୍ୟା କେବଳ ଏହାର ବିଶ୍ୱସ୍ତରୀୟ ୱେବସାଇଟ୍-ସୁରକ୍ଷା ବ୍ୟବସାୟ ମଧ୍ୟରେ ସୀମିତ ଏବଂ ଏହାର ଭାରତୀୟ DSC ଓ eSign ସେବାକୁ ପ୍ରଭାବିତ କରେ ନାହିଁ।
  • ମୋର ୱେବସାଇଟ୍ ଏକ ପ୍ରଭାବିତ ଇଣ୍ଟରମିଡିଏଟ୍ ବ୍ୟବହାର କରୁଛି କି ନାହିଁ ମୁଁ କିପରି ଯାଞ୍ଚ କରିବି? — ଚେନ୍ ବାହାର କରିବା ପାଇଁ ଚଲାନ୍ତୁ openssl s_client -showcerts, ପ୍ରତ୍ୟେକ ସାର୍ଟିଫିକେଟ୍‌ର SHA-256 ଫିଙ୍ଗରପ୍ରିଣ୍ଟ ପ୍ରିଣ୍ଟ କରନ୍ତୁ ଏବଂ ଉପରେ ତାଲିକାଭୁକ୍ତ ହୋଇଥିବା ଆଠଟି ଫିଙ୍ଗରପ୍ରିଣ୍ଟ ସହିତ ତୁଳନା କରନ୍ତୁ।
  • Go ଆପ୍ଲିକେସନ୍‌ଗୁଡ଼ିକ ଉପରେ କାହିଁକି ବିଶେଷ ଧ୍ୟାନ ଦେବା ଆବଶ୍ୟକ? — Go ପ୍ରୋଗ୍ରାମଗୁଡ଼ିକ ସେମାନଙ୍କର ନିଜସ୍ୱ ସାର୍ଟିଫିକେଟ୍ ଯାଞ୍ଚ ବହନ କରନ୍ତି, ତେଣୁ ପ୍ରଭାବିତ ଚେନ୍‌ଗୁଡ଼ିକୁ ପ୍ରତ୍ୟାଖ୍ୟାନ କରିବା ପାଇଁ ସେଗୁଡ଼ିକୁ Go 1.27.3 କିମ୍ବା 1.26.10 (କିମ୍ବା ପରବର୍ତ୍ତୀ ସଂଶୋଧିତ ରିଲିଜ୍) ସହିତ ପୁନଃ ନିର୍ମାଣ କରାଯିବା ଆବଶ୍ୟକ।
  • ସୁରକ୍ଷିତ ରହିବା ପାଇଁ ବାତିଲକରଣ (revocation) ଯଥେଷ୍ଟ କି? — ସବୁବେଳେ ନୁହେଁ, କାରଣ କେତେକ କ୍ଲାଏଣ୍ଟ କଦାପି ବାତିଲକରଣ ଯାଞ୍ଚ କରନ୍ତି ନାହିଁ; କଷ୍ଟମ୍ ଟ୍ରଷ୍ଟ ଷ୍ଟୋର୍ ଏବଂ ପୁରୁଣା ସିଷ୍ଟମ୍‌ଗୁଡ଼ିକରୁ ସାର୍ଟିଫିକେଟ୍‌ଗୁଡ଼ିକୁ ହାତରେ (manually) ହଟାଇବା କିମ୍ବା ଅବିଶ୍ୱାସ କରିବା ଆବଶ୍ୟକ ହୋଇପାରେ।
  • ଯଦି ମୁଁ ଏକ ପ୍ରଭାବିତ ସାର୍ଟିଫିକେଟ୍ ପାଏଁ ତେବେ ମୋତେ କ’ଣ କରିବା ଉଚିତ? — ଅନ୍ୟ ଏକ ବିଶ୍ୱସ୍ତ CA ରୁ ଲିଫ୍ ସାର୍ଟିଫିକେଟ୍ ପୁନଃ ଜାରି କରନ୍ତୁ, ଏହାକୁ ସଠିକ୍ ଚେନ୍ ସହିତ ନିୟୋଜିତ କରନ୍ତୁ, ଏବଂ ପୁରୁଣା ଚେନ୍ ଚାଲିଯାଇଛି ବୋଲି ନିଶ୍ଚିତ କରିବା ପାଇଁ ପୁନଃ ସ୍କାନ୍ କରନ୍ତୁ।
  • ଏଥିପାଇଁ ମୁଁ ଏକ ଭଲନରେବିଲିଟି ସ୍କାନର୍ ବ୍ୟବହାର କରିପାରିବି କି? — ହଁ; Qualys Certificate View ଭଳି ଟୁଲ୍ସ ଇସ୍ୟୁଅର୍ ଏବଂ ସିରିଏଲ୍ ସର୍ଚ୍ଚ ପ୍ରଦାନ କରେ, ଏବଂ ସାର୍ଟିଫିକେଟ୍ ଫିଙ୍ଗରପ୍ରିଣ୍ଟ ରେକର୍ଡ କରୁଥିବା ଯେକୌଣସି ସ୍କାନର୍ ଏଠାରେ ତାଲିକାଭୁକ୍ତ ଆଠଟି ସହିତ ମେଳ କରିପାରିବ।

ଟ୍ୟାଗ୍ସ

#eMudhra #CertificateAuthority #TLS #PKI #CVE2026111943 #CyberSecurity #GoLang #VulnerabilityManagement #CodeSigning #Qualys

Free field guide

Kubernetes Security Checklist

Harden cluster access, workload identity, pod security, network boundaries, software supply chain, secrets, and operational monitoring.