eMudhra ഇന്റർമീഡിയറ്റ് CA കോംപ്രമൈസ്: നിങ്ങളുടെ എൻവയോൺമെന്റിൽ ബാധിക്കപ്പെട്ട സർട്ടിഫിക്കറ്റുകൾ എങ്ങനെ കണ്ടെത്താം

eMudhra ഇന്റർമീഡിയറ്റ് CA കോംപ്രമൈസ്: നിങ്ങളുടെ എൻവയോൺമെന്റിൽ ബാധിക്കപ്പെട്ട സർട്ടിഫിക്കറ്റുകൾ എങ്ങനെ കണ്ടെത്താം

റദ്ദാക്കിയ എട്ട് ഇന്റർമീഡിയറ്റുകൾ, ദുർബലമായ P-384 കീകൾ, സെർവറുകൾ, Go ആപ്പുകൾ, ട്രസ്റ്റ് സ്റ്റോറുകൾ എന്നിവയ്ക്കായുള്ള പ്രായോഗിക ചെക്ക്‌ലിസ്റ്റ്

നിങ്ങളുടെ ബ്രൗസറിലെ ഓരോ പാഡ്‌ലോക്കും ഒരു ട്രസ്റ്റ് ചെയിനിനെ (chain of trust) ആശ്രയിച്ചാണ് നിലനിൽക്കുന്നത്; അതിലെ ഏറ്റവും ദുർബലമായ പ്രൈവറ്റ് കീയുടെ അത്ര മാത്രമേ ആ ചെയിനിന് കരുത്തുണ്ടാകൂ. ഈ മാസം, അത്തരമൊരു ചെയിനിലെ എട്ട് കണ്ണികൾ ഊഹിച്ചെടുക്കാവുന്നതാണെന്ന് വ്യക്തമായി.

ഇന്ന് 2026 ഒക്ടോബർ 26 ആണ്. ഒക്ടോബർ 17-ന്, സർട്ടിഫിക്കറ്റ് അതോറിറ്റിയായ (CA) eMudhra-യുടെ എട്ട് ഇന്റർമീഡിയറ്റ് സർട്ടിഫിക്കറ്റുകൾക്ക് പിന്നിലെ പ്രൈവറ്റ് കീകൾ വീണ്ടെടുക്കാൻ കഴിയുമെന്ന് ഒരു ഗവേഷകൻ റിപ്പോർട്ട് ചെയ്തു. പ്രമുഖ ബ്രൗസർ, ഓപ്പറേറ്റിംഗ് സിസ്റ്റം വെണ്ടർമാർ ഈ സർട്ടിഫിക്കറ്റുകൾ റദ്ദാക്കുകയും ബ്ലോക്ക് ചെയ്യുകയും ചെയ്തിട്ടുണ്ട്. ഈ പ്രശ്നം CVE-2026-111943, CVE-2026-111944 എന്നിങ്ങനെ ട്രാക്ക് ചെയ്യപ്പെടുന്നു. ഈ ആഴ്ച സെക്യൂരിറ്റി ടീമുകൾക്ക് ചെയ്യാനുള്ള അടിയന്തര ജോലി പറയാൻ എളുപ്പമുള്ളതും ചെയ്യാൻ ശ്രമകരവുമാണ്: ഈ സർട്ടിഫിക്കറ്റുകളിൽ ഏതെങ്കിലും നിങ്ങളുടെ എൻവയോൺമെന്റിൽ എവിടെയെങ്കിലും ഉണ്ടോയെന്നും, നിങ്ങളുടെ ഏതെങ്കിലും സോഫ്റ്റ്‌വെയർ ഇപ്പോഴും അവയെ വിശ്വസിക്കുന്നുണ്ടോയെന്നും കണ്ടെത്തുക.

സർട്ടിഫിക്കറ്റ് ചെയിനുകളെക്കുറിച്ച് ഒരു ലഘുവിവരണം

HTTPS വഴി നിങ്ങൾ ഒരു വെബ്‌സൈറ്റ് സന്ദർശിക്കുമ്പോൾ, സെർവർ സ്വന്തം പേരിനായി നൽകുന്നത് ഒരു ലീഫ് സർട്ടിഫിക്കറ്റ് ആണ്. ആ സർട്ടിഫിക്കറ്റ് ഒപ്പിട്ടിരിക്കുന്നത് ഒരു ഇന്റർമീഡിയറ്റ് CAആണ്, ഈ ഇന്റർമീഡിയറ്റ് ഒപ്പിട്ടിരിക്കുന്നത് ഒരു റൂട്ട് CAആണ്. നിങ്ങളുടെ ബ്രൗസറോ ഓപ്പറേറ്റിംഗ് സിസ്റ്റമോ അത് വിശ്വസിക്കുന്ന റൂട്ടുകളുടെ ഒരു ലിസ്റ്റ് നൽകുന്നുണ്ട്, ഇതിനെ വിളിക്കുന്ന പേരാണ് ട്രസ്റ്റ് സ്റ്റോർ.

. റൂട്ട് കീകൾ ഓഫ്‌ലൈനായി സൂക്ഷിക്കുകയും കർശനമായി സംരക്ഷിക്കുകയും ചെയ്യുന്നു. ഇന്റർമീഡിയറ്റുകളാണ് ദൈനംദിന സൈനിംഗ് ജോലികൾ ചെയ്യുന്നത്. ഒരു ഇന്റർമീഡിയറ്റിന്റെ പ്രൈവറ്റ് കീ കൈവശമുള്ള ആർക്കും ഏത് പേരിനും സർട്ടിഫിക്കറ്റ് ഒപ്പിടാൻ കഴിയും, കൂടാതെ ഈ ചെയിൻ വിശ്വസിക്കുന്ന ക്ലയന്റുകൾ സാധാരണയായി അത് സ്വീകരിക്കുകയും ചെയ്യും എന്നതാണ് ഇതിലെ അപകടസാധ്യത. അതുകൊണ്ടാണ് ഇതുവരെ ഒരു വ്യാജ സർട്ടിഫിക്കറ്റും കണ്ടിട്ടില്ലെങ്കിൽപ്പോലും, ചോർന്ന ഇന്റർമീഡിയറ്റ് കീ ഗുരുതരമായ പ്രശ്നമാകുന്നത്.

റിപ്പോർട്ട് ചെയ്യപ്പെട്ടതനുസരിച്ച്, എന്താണ് സംഭവിച്ചത്

പബ്ലിക് വെളിപ്പെടുത്തലുകളും വെണ്ടർ റിപ്പോർട്ടുകളും അനുസരിച്ച്, സംഭവം ഇപ്രകാരമാണ്:

  • 2025 ഏപ്രിൽ 30-ന് നടന്ന ഒരു കീ ജനറേഷൻ ചടങ്ങിൽ (key generation ceremony), 24 സബോർഡിനേറ്റ് CA-കൾക്കായി eMudhra കീകൾ സൃഷ്ടിച്ചു.
  • ഒരു wrap/unwrap ഘട്ടത്തിലുണ്ടായ തകരാറ് കാരണം ദുർബലമായ രണ്ടാമതൊരു സെറ്റ് P-384 കീകൾ സൃഷ്ടിക്കപ്പെട്ടു. വളരെ വലിയ കീ സ്പേസ് (key space) നൽകേണ്ട ഒരു എലിപ്റ്റിക് കർവ് (elliptic curve) ആണ് P-384.
  • ആ ദുർബലമായ കീകൾ അബദ്ധത്തിൽ എട്ട് ഇന്റർമീഡിയറ്റ് സർട്ടിഫിക്കറ്റുകൾക്കായി ഉപയോഗിച്ചു. അവയുടെ ഫലപ്രദമായ റാൻഡംനെസ്സ് (entropy) ഏകദേശം 3 മുതൽ 8 ബിറ്റുകൾ മാത്രമാണെന്ന് റിപ്പോർട്ട് ചെയ്യപ്പെട്ടു, അതായത് പരമാവധി ഏതാനും നൂറ് സാധ്യമായ കീകൾ മാത്രം. ഒരു കമ്പ്യൂട്ടറിനെ സംബന്ധിച്ച് അവ വീണ്ടെടുക്കുക എന്നത് വളരെ നിസ്സാരമായ കാര്യമാണ്.
  • ഇതിൽ എട്ടെണ്ണത്തിൽ ആറെണ്ണം TLS ഇന്റർമീഡിയറ്റുകളും രണ്ടെണ്ണം കോഡ്-സൈനിംഗ് (code-signing) ഇന്റർമീഡിയറ്റുകളുമാണ്.

ലഭ്യമായ വിവരങ്ങൾ അനുസരിച്ച് ഇതിനോടുള്ള പ്രതികരണം ഇങ്ങനെയായിരുന്നു:

  • Chrome, Mozilla, Apple എന്നിവ ആറ് TLS ഇന്റർമീഡിയറ്റുകളെ ബ്ലോക്ക് ചെയ്തു. Microsoft രണ്ട് കോഡ്-സൈനിംഗ് ഇന്റർമീഡിയറ്റുകളെ ബ്ലോക്ക് ചെയ്തു.
  • Google Chrome Root Store-ൽ നിന്ന് emSign ECC Root CA - G3 നീക്കം ചെയ്യുകയും, Mozilla ഈ ഇന്റർമീഡിയറ്റുകൾ ഒപ്പിട്ട റൂട്ടിന്മേലുള്ള വിശ്വാസ്യത (trust) ഒഴിവാക്കുകയും ചെയ്തു.
  • eMudhra ആ എട്ട് സർട്ടിഫിക്കറ്റുകളും റദ്ദാക്കുകയും തങ്ങളുടെ G3 റൂട്ടിന് കീഴിൽ പുതിയവ നൽകുന്നത് നിർത്തുകയും ചെയ്തു. തങ്ങളുടെ റൂട്ട് പ്രൈവറ്റ് കീകളെയും മറ്റ് ഇന്റർമീഡിയറ്റുകളെയും ഇത് ബാധിച്ചിട്ടില്ലെന്നും, ഈ പ്രശ്നം തങ്ങളുടെ ആഗോള വെബ്‌സൈറ്റ്-സെക്യൂരിറ്റി ബിസിനസ്സിൽ മാത്രമായി പരിമിതപ്പെടുത്തിയിരിക്കുന്നുവെന്നും ഇന്ത്യൻ DSC, eSign സേവനങ്ങളെ ബാധിച്ചിട്ടില്ലെന്നും, ബാധിക്കപ്പെട്ട ഇന്റർമീഡിയറ്റുകളിൽ ഒരെണ്ണം മാത്രമേ പ്രൊഡക്ഷനിൽ ഉപയോഗിച്ചിരുന്നുള്ളൂവെന്നും, അവയൊന്നും വെബ്‌സൈറ്റുകൾക്കോ അന്തിമ ഉപയോക്താക്കൾക്കോ സർട്ടിഫിക്കറ്റുകൾ നൽകിയിട്ടില്ലെന്നും അവർ പ്രസ്താവിക്കുന്നു.

വെണ്ടറുടെ പ്രസ്താവനകളെ അവരുടെ വിശദീകരണമായി മാത്രം കണക്കാക്കുക. സംഭവത്തെ വിലയിരുത്തുകയല്ല, മറിച്ച് നിങ്ങളുടെ സിസ്റ്റങ്ങൾ ഇതിന് വിധേയമായിട്ടുണ്ടോ (exposure) എന്ന് സ്ഥിരീകരിക്കുകയാണ് നിങ്ങളുടെ ജോലി.

ആരൊക്കെയാണ് ആദ്യം പരിശോധിക്കേണ്ടത്

താഴെ പറയുന്ന കാര്യങ്ങൾ നിങ്ങളുമായി ബന്ധപ്പെട്ടതാണെങ്കിൽ ഇതിന് മുൻഗണന നൽകണം:

  • ഇന്റർനെറ്റുമായി നേരിട്ട് ബന്ധപ്പെടുന്ന വെബ്‌സൈറ്റുകൾ, API-കൾ, VPN-കൾ അല്ലെങ്കിൽ മറ്റ് TLS സേവനങ്ങൾ എന്നിവ പ്രവർത്തിപ്പിക്കുന്നുണ്ടെങ്കിൽ.
  • eMudhra അല്ലെങ്കിൽ emSign ഹൈറാർക്കികൾ വഴി പബ്ലിക് ട്രസ്റ്റഡ് സർട്ടിഫിക്കറ്റുകൾ വാങ്ങിയിട്ടുണ്ടെങ്കിൽ.
  • പബ്ലിക് കോഡ്-സൈനിംഗ് സർട്ടിഫിക്കറ്റുകളെ ആശ്രയിക്കുന്ന ഒപ്പിട്ട സോഫ്റ്റ്‌വെയറുകൾ വിതരണം ചെയ്യുന്നുണ്ടെങ്കിൽ.
  • Go ഭാഷയിൽ എഴുതിയ ആപ്ലിക്കേഷനുകൾ നിർമ്മിക്കുകയോ പ്രവർത്തിപ്പിക്കുകയോ ചെയ്യുന്നുണ്ടെങ്കിൽ.
  • ഓട്ടോമാറ്റിക്കായി ഡിസ്‌ട്രസ്റ്റ് (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) Code signing 7818933f8f85b4619a2b35fba83d0a 9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4
EM OV CS CA - G3C (eMudhra Inc) Code signing 544b7f922c31ae220a4a922916f6e6 4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1

അവ എങ്ങനെ കണ്ടെത്താം: ഘട്ടം ഘട്ടമായുള്ള പരിശോധന

ഇതിന്റെ സാധ്യതകൾക്ക് രണ്ട് വശങ്ങളുണ്ട്. ഒന്ന് നിങ്ങളുടെ സെർവറുകൾ നൽകുന്നതാണ്. മറ്റൊന്ന് നിങ്ങളുടെ സോഫ്റ്റ്‌വെയർ ഇപ്പോഴും വിശ്വസിക്കുന്നവയാണ്. താഴെ നൽകിയിരിക്കുന്ന ഘട്ടങ്ങളിൽ ഇവ രണ്ടും ഉൾക്കൊള്ളുന്നു; ആദ്യം സാധാരണ ഓപ്പൺ സോഴ്സ് ടൂളുകൾ ഉപയോഗിച്ചും, തുടർന്ന് ഇതിനകം കൊമേഴ്‌സ്യൽ സ്കാനർ ഉള്ള ടീമുകൾക്കായി അത് ഉപയോഗിച്ചും പരിശോധിക്കാം.

ഘട്ടം 1: TLS ഉപയോഗിക്കുന്ന എല്ലാറ്റിന്റെയും ഒരു ലിസ്റ്റ് തയ്യാറാക്കുക

നിങ്ങൾ ലിസ്റ്റ് ചെയ്യാത്ത കാര്യങ്ങൾ നിങ്ങൾക്ക് പരിശോധിക്കാൻ കഴിയില്ല. നിങ്ങളുടെ പബ്ലിക് ഡൊമെയ്‌നുകൾ, ഇന്റേണൽ സർവീസ് പേരുകൾ, ലോഡ് ബാലൻസറുകൾ, VPN ഗേറ്റ്‌വേകൾ, നിങ്ങളുടെ പേര് ഉപയോഗിക്കുന്ന ഏതെങ്കിലും തേർഡ്-പാർട്ടി ഹോസ്റ്റഡ് സൈറ്റുകൾ എന്നിവ ഒരുമിച്ച് ശേഖരിക്കുക. വിദൂര ജീവനക്കാരുടെ ലാപ്‌ടോപ്പുകൾ, ഒറ്റപ്പെട്ട നെറ്റ്‌വർക്കുകൾ എന്നിവ പോലെ സ്കാനറുകൾക്ക് എത്തിച്ചേരാൻ കഴിയാത്ത സെർവറുകളും ഇതിൽ ഉൾപ്പെടുത്തുക. അവ കണ്ടെത്താൻ പലപ്പോഴും ഹോസ്റ്റിൽ ഇൻസ്റ്റാൾ ചെയ്ത ഏജന്റ് മാത്രമായിരിക്കും ഒരേയൊരു മാർഗ്ഗം.

ഘട്ടം 2: ഓരോ സെർവറും നൽകുന്ന ചെയിൻ പരിശോധിക്കുക

ഏതൊരു സിംഗിൾ ഹോസ്റ്റിനും, സബ്ജക്റ്റ്, ഇഷ്യൂവർ, സീരിയൽ, ഫിംഗർപ്രിന്റ് എന്നിവ സഹിതം ചെയിനിലെ ഓരോ സർട്ടിഫിക്കറ്റും പ്രിന്റ് ചെയ്യാൻ 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) ഫിംഗർപ്രിന്റുകൾ കോളനുകളോടെയുമാണ് (colons) പ്രിന്റ് ചെയ്യുന്നത്, അതിനാൽ അക്ഷരങ്ങളുടെ വലുപ്പച്ചെറുപ്പമോ (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"

ഈ പ്രിഫിക്സുകൾ വേഗത്തിലുള്ള ഒരു ഫിൽട്ടർ മാത്രമാണ്. എന്തെങ്കിലും പൊരുത്തപ്പെടുന്നുണ്ടെങ്കിൽ, നടപടിയെടുക്കുന്നതിന് മുൻപായി ടേബിളുമായി ഒത്തുനോക്കി പൂർണ്ണമായ ഫിംഗർപ്രിന്റ് ഉറപ്പുവരുത്തുക. പ്രാഥമിക പരിശോധനയ്ക്കായി നിങ്ങളുടെ ഹോസ്റ്റ് ലിസ്റ്റിലെല്ലാം ഇത് തുടർച്ചയായി പ്രവർത്തിപ്പിക്കുക.

ഘട്ടം 3: ഒരു വൾനറബിലിറ്റി സ്കാനർ ഉപയോഗിക്കുന്നുണ്ടെങ്കിൽ വലിയ തോതിൽ തിരച്ചിൽ നടത്തുക

നിങ്ങളുടെ ഓർഗനൈസേഷൻ ഇതിനകം 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`)

ബാധിക്കപ്പെട്ട Go പതിപ്പുകൾക്കായി QID 5019897-ഉം, ഈ എട്ട് ഇന്റർമീഡിയറ്റുകൾ ഉൾപ്പെടുന്ന ചെയിനുകൾ കണ്ടെത്തുന്നതിനായുള്ള ഇൻഫർമേഷൻ-ഗാതേർഡ് ചെക്ക് ആയി QID 48395-ഉം Qualys ലിസ്റ്റ് ചെയ്യുന്നുണ്ട്. ഇവയെ ആശ്രയിക്കുന്നതിന് മുൻപായി നിങ്ങളുടെ ഏജന്റുകളിൽ ഏറ്റവും പുതിയ സിഗ്നേച്ചറുകൾ ഉണ്ടെന്ന് ഉറപ്പാക്കുക. ക്വറി ടോക്കണുകൾ കേസ്-സെൻസിറ്റീവ് (case-sensitive) ആണ്, അതിനാൽ ക്വറിയിൽ എന്തെങ്കിലും പിശക് ഉണ്ടായാൽ പ്രൊഡക്റ്റ് ഹെൽപ്പ് പരിശോധിക്കുക. മറ്റ് സ്കാനറുകൾക്ക് അവരുടേതായ സമാന ഫീച്ചറുകൾ ഉണ്ടാകും; ടേബിളിലെ ഫിംഗർപ്രിന്റുകൾ ഏത് ടൂളിലും ഉപയോഗിക്കാൻ സാധിക്കുന്നതാണ്.

ഘട്ടം 4: മോശം ചെയിനുകളെ ഇപ്പോഴും വിശ്വസിക്കുന്ന Go പ്രോഗ്രാമുകൾ കണ്ടെത്തുക

ആളുകൾ ശ്രദ്ധിക്കാതെ പോകുന്ന ഒരു ഭാഗമാണിത്. നിങ്ങളുടെ സെർവറുകൾ സുരക്ഷിതമായിരിക്കാം, എന്നാൽ നിങ്ങളുടെ സ്വന്തം ആപ്ലിക്കേഷനുകൾ ഇപ്പോഴും വ്യാജ സർട്ടിഫിക്കറ്റ് സ്വീകരിച്ചേക്കാം. അഡ്വൈസറികൾ പ്രകാരം, Go 1.27.3, 1.26.10 എന്നിവ ഈ എട്ട് കീകളിൽ ഏതെങ്കിലും അടങ്ങിയിട്ടുള്ള ചെയിനുകളെ ബ്ലോക്ക് ചെയ്യുന്നു (CVE-2026-111943). Go പ്രോഗ്രാമുകളിൽ അവയുടേതായ സർട്ടിഫിക്കറ്റ് വെരിഫിക്കേഷൻ കോഡ് അടങ്ങിയിട്ടുണ്ട്, അതിനാൽ പഴയ Go പതിപ്പ് ഉപയോഗിച്ച് നിർമ്മിച്ച ഒരു പ്രോഗ്രാം വീണ്ടും റീബിൽഡ് ചെയ്യുന്നത് വരെ പഴയ രീതി തന്നെ തുടരും.

ബിൽഡ് മെഷീനുകളിലെ ടൂൾചെയിൻ പരിശോധിക്കുക:

go version

നിങ്ങൾ നിലവിൽ പ്രവർത്തിപ്പിക്കുന്ന ബൈനറി ഏത് Go പതിപ്പിലാണ് നിർമ്മിച്ചതെന്ന് പരിശോധിക്കുക:

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

പഴയ പതിപ്പിൽ നിർമ്മിച്ച ഏതൊരു പ്രോഗ്രാമും പ്രശ്നം പരിഹരിച്ച Go പതിപ്പ് ഉപയോഗിച്ച് റീബിൽഡ് ചെയ്യുകയും വീണ്ടും ഡിപ്ലോയ് ചെയ്യുകയും വേണം. ഒപ്പം നിങ്ങളുടെ ഓപ്പറേറ്റിംഗ് സിസ്റ്റം വെണ്ടറുടെ അപ്‌ഡേറ്റുകളും ഇൻസ്റ്റാൾ ചെയ്യുക, കാരണം പല ഡിസ്ട്രിബ്യൂഷനുകളും അവരുടേതായ പാച്ച് ചെയ്ത Go പാക്കേജുകൾ നൽകാറുണ്ട്.

ഘട്ടം 5: മാറ്റുക, അപ്‌ഡേറ്റ് ചെയ്യുക, നിരീക്ഷണം തുടരുക

  • ആദ്യം മാറ്റിസ്ഥാപിക്കുക. ഈ എട്ടെണ്ണത്തിൽ ഒരെണ്ണമെങ്കിലും ഉൾപ്പെടുന്ന ചെയിനുള്ള ഏതൊരു ലീഫ് സർട്ടിഫിക്കറ്റും മറ്റൊരു വിശ്വസനീയമായ CA വഴി വീണ്ടും ഇഷ്യൂ ചെയ്യുകയും ശരിയായ ചെയിൻ ഉപയോഗിച്ച് വീണ്ടും ഡിപ്ലോയ് ചെയ്യുകയും വേണം.
  • അപ്‌ഡേറ്റ് ചെയ്യുക. OS സെക്യൂരിറ്റി അപ്‌ഡേറ്റുകൾ ഇൻസ്റ്റാൾ ചെയ്യുകയും Go റൺടൈമുകൾ പ്രശ്നം പരിഹരിച്ച പുതിയ പതിപ്പുകളിലേക്ക് മാറ്റുകയും ചെയ്യുക.
  • റിവൊക്കേഷൻ പരിശോധനകൾ കൃത്യമായി പ്രവർത്തിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക. റിവൊക്കേഷൻ (റദ്ദാക്കൽ) പരിശോധിക്കുന്ന ക്ലയന്റുകൾക്ക് മാത്രമേ അത് പ്രയോജനപ്പെടൂ. കസ്റ്റം ട്രസ്റ്റ് സ്റ്റോറുകൾ, അപ്ലയൻസുകൾ, പഴയ Java അല്ലെങ്കിൽ എംബഡഡ് സിസ്റ്റങ്ങൾ എന്നിവയിൽ നിന്ന് ഇന്റർമീഡിയറ്റുകൾ നേരിട്ട് നീക്കം ചെയ്യുകയോ അവയെ വിശ്വസനീയമല്ലെന്ന് സ്വമേധയാ അടയാളപ്പെടുത്തുകയോ (distrust) ചെയ്യേണ്ടി വന്നേക്കാം.
  • നിരീക്ഷണം തുടരുക. നിങ്ങളുടെ തിരച്ചിലുകൾ ഒരു ഷെഡ്യൂൾഡ് ജോബ് അല്ലെങ്കിൽ ഡാഷ്‌ബോർഡ് ആയി സേവ് ചെയ്യുകയും, ഫലങ്ങളിൽ യാതൊരു പ്രശ്നങ്ങളുമില്ലെന്ന് ഉറപ്പാകുന്നത് വരെ ഓരോ സ്കാനിംഗിന് ശേഷവും അവ വീണ്ടും പ്രവർത്തിപ്പിക്കുകയും ചെയ്യുക.

ഉപസംഹാരം

ഇന്റർനെറ്റിലെ വിശ്വാസ്യത രണ്ട് കാര്യങ്ങളെ ആശ്രയിച്ചിരിക്കുന്നുവെന്ന ഓർമ്മപ്പെടുത്തലാണ് eMudhra സംഭവം: നിങ്ങൾ നൽകുന്ന സർട്ടിഫിക്കറ്റുകളും നിങ്ങൾ വിശ്വസിക്കാൻ തിരഞ്ഞെടുക്കുന്ന അതോറിറ്റികളും. ഇതിനുള്ള പരിഹാരം അസാധാരണമൊന്നുമല്ല. നിങ്ങളുടെ TLS എൻഡ്‌പോയിന്റുകൾ ലിസ്റ്റ് ചെയ്യുക, അവയുടെ ചെയിനുകൾ അറിയപ്പെടുന്ന എട്ട് ഫിംഗർപ്രിന്റുകളുമായി ഒത്തുനോക്കുക, പ്രശ്നം പരിഹരിച്ച ടൂൾചെയിൻ ഉപയോഗിച്ച് Go പ്രോഗ്രാമുകൾ റീബിൽഡ് ചെയ്യുക, ഒപ്പം നിങ്ങളുടെ പഴയ സിസ്റ്റങ്ങൾക്ക് ഡിസ്‌ട്രസ്റ്റ് വിവരങ്ങൾ ലഭിച്ചിട്ടുണ്ടെന്ന് ഉറപ്പാക്കുക. ഈ ആഴ്ച തന്നെ ഇത് ചെയ്യുക, തുടർന്ന് പരിശോധനകൾ നിലനിർത്തുക.

മേന്മകൾ

  • ബാധിക്കപ്പെട്ട സർട്ടിഫിക്കറ്റുകൾ കൃത്യമായ ഫിംഗർപ്രിന്റുകളുള്ള ചെറുതും നിർദ്ദിഷ്ടവുമായ ഒരു ലിസ്റ്റാണ്, അതിനാൽ ഒത്തുനോക്കൽ കൃത്യമായിരിക്കും.
  • പ്രമുഖ ബ്രൗസറുകളും ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങളും ഇതിനകം തന്നെ അവയെ ബ്ലോക്ക് ചെയ്തിട്ടുണ്ട്, ഇത് സാധാരണ ഉപയോക്താക്കളിൽ ഭൂരിഭാഗത്തിനും ഓട്ടോമാറ്റിക്കായി സംരക്ഷണം നൽകുന്നു.
  • OpenSSL, go version തുടങ്ങിയ സൗജന്യ ടൂളുകൾ ഒരു അടിസ്ഥാന പരിശോധനയ്ക്ക് മതിയായതാണ്.
  • നിലവിലുള്ള സ്കാനറുകൾക്ക് ഈ തിരച്ചിലിനെ ആവർത്തിച്ച് പരിശോധിക്കാവുന്ന ഒരു ഡാഷ്‌ബോർഡാക്കി മാറ്റാൻ കഴിയും.
  • ഭാവിയിലുണ്ടാകുന്ന ഇത്തരം സംഭവങ്ങൾക്കായി നിങ്ങളുടെ സർട്ടിഫിക്കറ്റ് ഇൻവെന്ററി മെച്ചപ്പെടുത്താൻ ഈ പ്രവർത്തനം സഹായിക്കും.

പോരായ്മകൾ

  • കസ്റ്റം അല്ലെങ്കിൽ ഫ്രോസൺ ട്രസ്റ്റ് സ്റ്റോറുകളുള്ള സിസ്റ്റങ്ങൾക്ക് മാനുവൽ ഇടപെടലില്ലാതെ വെണ്ടർ ബ്ലോക്ക്‌ലിസ്റ്റുകളിൽ നിന്നുള്ള പ്രയോജനം ലഭിക്കില്ല.
  • Go ബൈനറികൾ നിർബന്ധമായും റീബിൽഡ് ചെയ്യണം; ടൂൾചെയിൻ മാത്രം അപ്‌ഡേറ്റ് ചെയ്യുന്നത് വഴി നിലവിൽ ഡിപ്ലോയ് ചെയ്ത പ്രോഗ്രാമുകൾ ശരിയാകില്ല.
  • നെറ്റ്‌വർക്ക് സ്കാനുകൾക്ക് എത്തിച്ചേരാൻ കഴിയാത്ത ഹോസ്റ്റുകൾ കണ്ടെത്താനാകില്ല, അതിനാൽ ഏജന്റ് കവറേജോ മാനുവൽ പരിശോധനയോ ആവശ്യമാണ്.
  • റിവൊക്കേഷൻ പരിശോധിക്കാത്ത ക്ലയന്റുകളിൽ ഇത് വിശ്വസനീയമല്ല.
  • അപ്ലയൻസുകളിലും തേർഡ്-പാർട്ടി ഹോസ്റ്റ് ചെയ്ത സൈറ്റുകളിലും സർട്ടിഫിക്കറ്റുകൾ മാറ്റിസ്ഥാപിക്കുന്നതിന് സമയവും വെണ്ടറുടെ സഹായവും ആവശ്യമായി വന്നേക്കാം.

മുന്നറിയിപ്പ്

ഈ ലേഖനം വിദ്യാഭ്യാസത്തിനും പൊതുവായ മാർഗ്ഗനിർദ്ദേശത്തിനും ഉള്ളതാണ്. ഇതിൽ പറയുന്ന app.example.com പോലുള്ള ഹോസ്റ്റ് നാമങ്ങളും, /usr/local/bin/your-service പോലുള്ള പാത്തുകളും നിങ്ങളുടെ ആവശ്യാനുസരണം മാറ്റേണ്ട പ്ലേസ്‌ഹോൾഡറുകളാണ് (placeholders). സംഭവത്തെക്കുറിച്ചുള്ള വിശദാംശങ്ങൾ മുകളിൽ സൂചിപ്പിച്ച തീയതി വരെയുള്ള പൊതു റിപ്പോർട്ടുകളിൽ നിന്നും വെണ്ടർ പ്രസ്താവനകളിൽ നിന്നും സംഗ്രഹിച്ചതാണ്, അവയിൽ മാറ്റങ്ങൾ വന്നേക്കാം; നിങ്ങളുടെ ബ്രൗസർ, ഓപ്പറേറ്റിംഗ് സിസ്റ്റം, Go, സ്കാനർ വെണ്ടർമാർ എന്നിവരിൽ നിന്നുള്ള ഏറ്റവും പുതിയ അഡ്വൈസറികൾ പരിശോധിക്കുക, ഒപ്പം ഒരു പൊരുത്തപ്പെടുത്തൽ കണ്ടെത്തിയാൽ നടപടിയെടുക്കുന്നതിന് മുൻപ് ആധികാരികമായ ഉറവിടവുമായി ഒത്തുനോക്കി ഓരോ ഫിംഗർപ്രിന്റും ഉറപ്പുവരുത്തുക.

പതിവായി ചോദിക്കുന്ന ചോദ്യങ്ങൾ

  • എന്താണ് eMudhra ഇന്റർമീഡിയറ്റ് CA കോംപ്രമൈസ്? — eMudhra-യുടെ എട്ട് ഇന്റർമീഡിയറ്റ് സർട്ടിഫിക്കറ്റുകൾ ദുർബലമായ P-384 കീകൾ ഉപയോഗിച്ചാണ് നിർമ്മിച്ചത്, ഇവയുടെ പ്രൈവറ്റ് കീകൾ വീണ്ടെടുക്കാൻ കഴിയുമായിരുന്നു; അതിനാൽ 2026 ഒക്ടോബറിൽ പ്രമുഖ വെണ്ടർമാർ അവ റദ്ദാക്കുകയും ബ്ലോക്ക് ചെയ്യുകയും ചെയ്തു.
  • ഏതൊക്കെ CVE-കളാണ് ഈ പ്രശ്നം ട്രാക്ക് ചെയ്യുന്നത്? — ഇത് CVE-2026-111943, CVE-2026-111944 എന്നിങ്ങനെ ട്രാക്ക് ചെയ്യപ്പെടുന്നു; ബാധിക്കപ്പെട്ട ചെയിനുകളെ ബ്ലോക്ക് ചെയ്യുന്ന Go പരിഹാരം CVE-2026-111943-ന് കീഴിലാണ് ലിസ്റ്റ് ചെയ്തിരിക്കുന്നത്.
  • ഇന്ത്യൻ DSC, eSign സർട്ടിഫിക്കറ്റുകളെ ഇത് ബാധിച്ചിട്ടുണ്ടോ? — ഈ പ്രശ്നം തങ്ങളുടെ ആഗോള വെബ്‌സൈറ്റ്-സെക്യൂരിറ്റി ബിസിനസ്സിൽ മാത്രമായി പരിമിതപ്പെടുത്തിയിരിക്കുന്നുവെന്നും ഇന്ത്യൻ DSC, eSign സേവനങ്ങളെ ബാധിച്ചിട്ടില്ലെന്നും eMudhra പ്രസ്താവിക്കുന്നു.
  • എന്റെ വെബ്‌സൈറ്റ് ബാധിക്കപ്പെട്ട ഇന്റർമീഡിയറ്റ് ഉപയോഗിക്കുന്നുണ്ടോ എന്ന് എങ്ങനെ പരിശോധിക്കാം? — ചെയിൻ പരിശോധിക്കാൻ openssl s_client -showcertsഉപയോഗിക്കുക, തുടർന്ന് ഓരോ സർട്ടിഫിക്കറ്റിന്റെയും SHA-256 ഫിംഗർപ്രിന്റ് പ്രിന്റ് ചെയ്ത് മുകളിൽ നൽകിയിട്ടുള്ള എട്ട് ഫിംഗർപ്രിന്റുകളുമായി താരതമ്യം ചെയ്യുക.
  • Go ആപ്ലിക്കേഷനുകൾക്ക് പ്രത്യേക ശ്രദ്ധ നൽകേണ്ടത് എന്തുകൊണ്ട്? — Go പ്രോഗ്രാമുകളിൽ അവയുടേതായ സർട്ടിഫിക്കറ്റ് പരിശോധനകൾ ഉള്ളതിനാൽ, ബാധിക്കപ്പെട്ട ചെയിനുകളെ നിരസിക്കുന്നതിനായി അവ Go 1.27.3 അല്ലെങ്കിൽ 1.26.10 (അല്ലെങ്കിൽ അതിനുശേഷമുള്ള പരിഹരിച്ച പതിപ്പ്) ഉപയോഗിച്ച് റീബിൽഡ് ചെയ്യണം.
  • സുരക്ഷിതമായിരിക്കാൻ റിവൊക്കേഷൻ (റദ്ദാക്കൽ) മാത്രം മതിയോ? — എപ്പോഴും മതിയാകില്ല, കാരണം ചില ക്ലയന്റുകൾ ഒരിക്കലും റിവൊക്കേഷൻ പരിശോധിക്കാറില്ല; കസ്റ്റം ട്രസ്റ്റ് സ്റ്റോറുകളിൽ നിന്നും പഴയ സിസ്റ്റങ്ങളിൽ നിന്നും സർട്ടിഫിക്കറ്റുകൾ നേരിട്ട് നീക്കം ചെയ്യുകയോ മാനുവലായി ഡിസ്‌ട്രസ്റ്റ് ചെയ്യുകയോ ചെയ്യേണ്ടി വന്നേക്കാം.
  • ബാധിക്കപ്പെട്ട ഒരു സർട്ടിഫിക്കറ്റ് കണ്ടെത്തിയാൽ ഞാൻ എന്തുചെയ്യണം? — വിശ്വസനീയമായ മറ്റൊരു 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.