eMudhra இடைநிலை CA சமரசம்: உங்கள் சூழலில் பாதிக்கப்பட்ட சான்றிதழ்களைக் கண்டறிவது எப்படி

eMudhra இடைநிலை CA சமரசம்: உங்கள் சூழலில் பாதிக்கப்பட்ட சான்றிதழ்களைக் கண்டறிவது எப்படி

ரத்து செய்யப்பட்ட எட்டு இடைநிலைகள், பலவீனமான P-384 விசைகள், மற்றும் சேவையகங்கள், Go செயலிகள் மற்றும் நம்பக சேமிப்பகங்களுக்கான நடைமுறை சரிபார்ப்புப் பட்டியல்

உங்கள் உலாவியில் தோன்றும் ஒவ்வொரு பூட்டும் ஒரு நம்பிக்கைச் சங்கிலியை (chain of trust) அடிப்படையாகக் கொண்டது, மேலும் அந்தச் சங்கிலியானது அதில் உள்ள மிகவும் பலவீனமான தனிப்பட்ட விசையின் வலிமையைக் கொண்டே தீர்மானிக்கப்படுகிறது. இந்த மாதத்தில், அத்தகைய ஒரு சங்கிலியில் இருந்த எட்டு இணைப்புகளை எளிதில் யூகித்துவிட முடியும் என்பது தெரியவந்தது.

இன்று அக்டோபர் 26, 2026. அக்டோபர் 17 அன்று, ஒரு சான்றிதழ் ஆணையமான (CA) eMudhra-வின் எட்டு இடைநிலைச் சான்றிதழ்களுக்குப் பின்னால் உள்ள தனிப்பட்ட விசைகளை மீட்டெடுக்க முடியும் என்று ஒரு ஆராய்ச்சியாளர் தெரிவித்தார். இந்தச் சான்றிதழ்கள் ரத்து செய்யப்பட்டு, முன்னணி உலாவி மற்றும் இயக்க முறைமை விற்பனையாளர்களால் தடுக்கப்பட்டுள்ளன. இந்தப் பிரச்சனை CVE-2026-111943 மற்றும் CVE-2026-111944 என கண்காணிக்கப்படுகிறது. இந்த வாரத்தில் பாதுகாப்பு குழுக்களுக்கான அவசரப் பணி சொல்வதற்கு எளிதானது, ஆனால் செய்வதற்குச் சற்று கடினமானது: இந்தச் சான்றிதழ்கள் ஏதேனும் உங்கள் சூழலில் எங்கேனும் உள்ளனவா என்பதையும், உங்கள் மென்பொருள்கள் ஏதேனும் இன்னும் அவற்றை நம்புகின்றனவா என்பதையும் கண்டறிவதாகும்.

சான்றிதழ் சங்கிலிகள் குறித்த ஒரு விரைவான மீள்பார்வை

நீங்கள் HTTPS வழியாக ஒரு வலைத்தளத்தைப் பார்வையிடும்போது, சேவையகம் அதன் சொந்தப் பெயருக்கான ஒரு இலைச் சான்றிதழை (leaf certificate) காட்டுகிறது. அந்தச் சான்றிதழ் ஒரு இடைநிலை CA (intermediate CA)ஆல் கையொப்பமிடப்பட்டுள்ளது, மேலும் அந்த இடைநிலைச் சான்றிதழ் ஒரு ரூட் CA (root CA)ஆல் கையொப்பமிடப்பட்டுள்ளது. உங்கள் உலாவி அல்லது இயக்க முறைமை தான் நம்பும் ரூட்களின் பட்டியலை வழங்குகிறது, இது நம்பக சேமிப்பகம் (trust store).

ரூட் விசைகள் ஆஃப்லைனில் வைக்கப்பட்டு மிகவும் உன்னிப்பாகப் பாதுகாக்கப்படுகின்றன. இடைநிலைச் சான்றிதழ்களே அன்றாட கையொப்பமிடும் பணிகளைச் செய்கின்றன. இதில் உள்ள ஆபத்து என்னவென்றால், ஒரு இடைநிலைச் சான்றிதழின் தனிப்பட்ட விசையைக் கொண்டிருக்கும் எவரும் எந்தப் பெயருக்கும் ஒரு சான்றிதழில் கையொப்பமிட முடியும், மேலும் அந்தச் சங்கிலியை நம்பும் கிளையண்டுகள் பொதுவாக அதை ஏற்றுக்கொள்ளும். இதனால்தான் இதுவரை எந்தவொரு தவறான சான்றிதழும் கண்டறியப்படவில்லை என்றாலும், கசிந்த இடைநிலை விசை மிகவும் ஆபத்தானதாகக் கருதப்படுகிறது.

அறிக்கைகளின்படி என்ன நடந்தது

பொது வெளிப்பாடு மற்றும் விற்பனையாளர் அறிக்கைகளின்படி, விவகாரம் பின்வருமாறு:

  • ஏப்ரல் 30, 2025 அன்று நடைபெற்ற விசை உருவாக்கும் நிகழ்வின் (key generation ceremony) போது, eMudhra நிறுவனம் 24 துணை CA-களுக்கான விசைகளை உருவாக்கியது.
  • wrap/unwrap படியில் ஏற்பட்ட ஒரு குறைபாடு காரணமாக பலவீனமான P-384 விசைகளின் இரண்டாவது தொகுப்பு உருவானது. P-384 என்பது மிகப்பெரிய விசை வெளியை (key space) வழங்க வேண்டிய ஒரு எலிப்டிக் வளைவு (elliptic curve) ஆகும்.
  • அந்தப் பலவீனமான விசைகள் தவறுதலாக எட்டு இடைநிலைச் சான்றிதழ்களுக்குப் பயன்படுத்தப்பட்டன. அவற்றின் பயனுள்ள சீரற்ற தன்மை (entropy) தோராயமாக 3 முதல் 8 பிட்கள் மட்டுமே இருந்ததாகப் புகாரளிக்கப்பட்டது, அதாவது அதிகபட்சமாக சில நூறு சாத்தியமான விசைகள் மட்டுமே இருக்க முடியும். ஒரு கணினிக்கு அவற்றை மீட்டெடுப்பது மிகவும் அற்பமான செயலாகும்.
  • எட்டில் ஆறு TLS இடைநிலைகள் மற்றும் இரண்டு குறியீடு கையொப்பமிடும் (code-signing) இடைநிலைகள் ஆகும்.

எடுக்கப்பட்ட நடவடிக்கைகள், அறிக்கைகளின்படி:

  • Chrome, Mozilla மற்றும் Apple ஆகியவை ஆறு TLS இடைநிலைகளைத் தடுத்தன. Microsoft இரண்டு குறியீடு கையொப்பமிடும் இடைநிலைகளைத் தடுத்தது.
  • Google நிறுவனம் Chrome Root Store-லிருந்து emSign ECC Root CA - G3-ஐ நீக்கியது, மேலும் Mozilla இந்த இடைநிலைகளில் கையொப்பமிட்ட ரூட் மீதான நம்பிக்கையை விலக்கியது.
  • eMudhra இந்த எட்டு சான்றிதழ்களையும் ரத்து செய்ததுடன், தனது G3 ரூட்டின் கீழ் சான்றிதழ்களை வழங்குவதையும் நிறுத்தியது. தனது ரூட் தனிப்பட்ட விசைகளும் பிற இடைநிலைகளும் பாதிக்கப்படவில்லை என்றும், இந்தப் பிரச்சனை தனது உலகளாவிய வலைத்தள பாதுகாப்பு வணிகத்திற்கு மட்டுமே உட்பட்டது என்றும், தனது இந்திய DSC மற்றும் eSign சேவைகளைப் பாதிக்கவில்லை என்றும், மேலும் பாதிக்கப்பட்ட இடைநிலைகளில் ஒன்று மட்டுமே உற்பத்தியில் (production) பயன்படுத்தப்பட்டது என்றும், வலைத்தளங்களுக்கோ அல்லது இறுதிப் பயனர்களுக்கோ எந்தச் சான்றிதழும் வழங்கப்படவில்லை என்றும் நிறுவனம் கூறுகிறது.

விற்பனையாளரின் அறிக்கைகளை அவர்களின் சொந்தக் கூற்றாகவே கருதுங்கள். இந்தச் சம்பவத்தை மதிப்பிடுவது உங்கள் பணியல்ல, மாறாக உங்கள் சூழல் இதில் பாதிக்கப்பட்டுள்ளதா என்பதை உறுதிப்படுத்துவதே உங்கள் பணியாகும்.

யார் முதலில் சரிபார்க்க வேண்டும்

நீங்கள் பின்வருவனவற்றைச் செய்கிறீர்கள் என்றால், இதற்கு முன்னுரிமை அளிக்க வேண்டும்:

  • இணையத்தை நோக்கிய வலைத்தளங்கள், API-கள், VPN-கள் அல்லது பிற TLS சேவைகளை இயக்குபவர்கள்.
  • eMudhra அல்லது emSign வரிசைமுறைகள் மூலம் பொதுவில் நம்பகமான சான்றிதழ்களை வாங்குபவர்கள்.
  • பொது குறியீடு கையொப்பமிடும் சான்றிதழ்களைச் சார்ந்திருக்கும் கையொப்பமிடப்பட்ட மென்பொருள்களை வெளியிடுபவர்கள்.
  • Go மொழியில் எழுதப்பட்ட பயன்பாடுகளை உருவாக்குகிறீர்கள் அல்லது இயக்குகிறீர்கள் என்றால்.
  • நம்பகமின்மை புதுப்பிப்புகளைத் தானாகப் பெறாத மரபு அமைப்புகள் (legacy systems), நிர்வகிக்கப்படாத முனைப்புள்ளிகள் (unmanaged endpoints), சாதனங்கள் அல்லது தனிப்பயன் நம்பக சேமிப்பகங்களைப் பராமரிப்பவர்கள்.

பாதிக்கப்பட்ட எட்டு இடைநிலைகள்

ஒரு சான்றிதழைப் பொருத்திப் பார்க்க SHA-256 கைரேகை (fingerprint) மற்றும் வரிசை எண் (serial number) ஆகியவை மிகவும் நம்பகமான வழிகளாகும். பெயர்களைப் பிரதி எடுக்க முடியும்; கைரேகைகளை அவ்வாறு செய்ய முடியாது.

சான்றிதழ் வகை வரிசை எண் 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-ஐப் பயன்படுத்தும் அனைத்தின் பட்டியலையும் தயார் செய்யுங்கள்

பட்டியலிடாத எதையும் உங்களால் சரிபார்க்க முடியாது. உங்கள் பொது டொமைன்கள், உள் சேவைப் பெயர்கள், சுமை சமநிலைகள் (load balancers), VPN நுழைவாயில்கள் மற்றும் உங்கள் பெயரைப் பயன்படுத்தும் மூன்றாம் தரப்பு தளங்கள் அனைத்தையும் ஒன்றாகத் திரட்டுங்கள். தொலைதூர ஊழியர்களின் மடிக்கணினிகள் மற்றும் தனிமைப்படுத்தப்பட்ட நெட்வொர்க்குகள் போன்ற ஸ்கேனர்களால் சென்றடைய முடியாத சேவையகங்களையும் இதில் சேர்க்கவும். ஹோஸ்டில் உள்ள ஒரு ஏஜென்ட் மட்டுமே பெரும்பாலும் அவற்றைக் கண்டறிவதற்கான ஒரே வழியாகும்.

படி 2: ஒவ்வொரு சேவையகமும் வழங்கும் சங்கிலியைச் சரிபார்க்கவும்

எந்தவொரு தனி ஹோஸ்டுக்கும், OpenSSL சங்கிலியில் உள்ள ஒவ்வொரு சான்றிதழையும் அதன் Subject, Issuer, Serial மற்றும் கைரேகையுடன் அச்சிட முடியும். இதில் 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) அச்சிடுகிறது; எனவே எழுத்து வடிவம் அல்லது முக்கால்புள்ளிகளைக் கருத்தில் கொள்ளாமல் ஒப்பிட்டுப் பாருங்கள். எட்டு சான்றிதழ்களின் பட்டியலுடன் ஒரு விரைவான ஒப்பீடு:

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"

முன்னொட்டுகள் (prefixes) ஒரு விரைவான வடிகட்டி மட்டுமே. ஏதேனும் பொருந்தினால், நடவடிக்கை எடுப்பதற்கு முன் அட்டவணையுடன் முழு கைரேகையையும் ஒப்பிடவும். ஒரு அடிப்படை சோதனைக்கு இதை உங்கள் ஹோஸ்ட் பட்டியல் முழுவதும் இயக்கவும்.

படி 3: நீங்கள் ஒரு பாதிப்பு ஸ்கேனரை இயக்கினால் பெரிய அளவில் தேடுங்கள்

உங்கள் நிறுவனம் ஏற்கனவே Certificate View உடன் கூடிய Qualys VMDR-ஐப் பயன்படுத்தினால், Qualys ஆயத்த வினவல்களை (queries) வெளியிட்டுள்ளது. Certificate View-இல், வழங்குநர் பெயர் (issuer name) மீதான ஒரு தேடல் இந்த எட்டையும் உள்ளடக்குகிறது:

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) தன்மை கொண்டவை, எனவே வினவலில் பிழை ஏற்பட்டால் தயாரிப்பு உதவியைப் பார்க்கவும். பிற ஸ்கேனர்கள் அவற்றின் சொந்த மாற்று வழிகளைக் கொண்டிருக்கும்; அட்டவணையில் உள்ள கைரேகைகள் எந்தவொரு கருவியிலும் செயல்படும்.

படி 4: தவறான சங்கிலிகளை இன்னும் நம்பும் Go நிரல்களைக் கண்டறியவும்

இது மக்கள் பொதுவாகக் கவனிக்கத் தவறும் பகுதியாகும். உங்கள் சேவையகங்கள் பாதுகாப்பாக இருக்கலாம், ஆனால் உங்கள் சொந்த பயன்பாடுகள் இன்னும் போலிச் சான்றிதழை ஏற்றுக்கொள்ளக்கூடும். பாதுகாப்பு ஆலோசனைகளின்படி, Go 1.27.3 மற்றும் 1.26.10 ஆகியவை இந்த எட்டு விசைகளில் ஏதேனும் ஒன்றைக் கொண்டுள்ள சங்கிலிகளைத் தடுக்கின்றன (CVE-2026-111943). Go நிரல்கள் அவற்றின் சொந்த சான்றிதழ் சரிபார்ப்புக் குறியீட்டைக் கொண்டுள்ளன, எனவே பழைய Go பதிப்பில் உருவாக்கப்பட்ட ஒரு நிரல் மீண்டும் உருவாக்கப்படும் வரை பழைய நடத்தையையே தொடரும்.

பில்ட் மெஷின்களில் கருவித்தொகுப்பைச் (toolchain) சரிபார்க்கவும்:

go version

நீங்கள் ஏற்கனவே இயக்கும் பைனரியை எந்த Go பதிப்பு உருவாக்கியது என்பதைச் சரிபார்க்கவும்:

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

பழைய பதிப்பில் உருவாக்கப்பட்ட எதையும் சரிசெய்யப்பட்ட Go பதிப்பைக் கொண்டு மீண்டும் உருவாக்கி, மறுபயன்பாட்டிற்கு உட்படுத்த வேண்டும். மேலும் உங்கள் இயக்க முறைமை விற்பனையாளரின் புதுப்பிப்புகளையும் பயன்படுத்தவும், ஏனெனில் பல விநியோகங்கள் (distributions) அவற்றின் சொந்த பேட்ச் செய்யப்பட்ட Go தொகுப்புகளை வழங்குகின்றன.

படி 5: மாற்றவும், புதுப்பிக்கவும், தொடர்ந்து கண்காணிக்கவும்

  • முதலில் மாற்றவும். இந்த எட்டில் ஒன்றை தனது சங்கிலியில் கொண்டுள்ள எந்தவொரு இலைச் சான்றிதழும் மற்றொரு நம்பகமான CA மூலம் மீண்டும் வழங்கப்பட்டு, சரியான சங்கிலியுடன் மறுபயன்பாட்டில் வைக்கப்பட வேண்டும்.
  • புதுப்பிக்கவும். OS பாதுகாப்புப் புதுப்பிப்புகளைப் பயன்படுத்தவும் மற்றும் Go இயக்க நேரங்களைச் சரிசெய்யப்பட்ட பதிப்புகளுக்கு மாற்றவும்.
  • ரத்துசெய்தல் சரிபார்ப்புகள் செயல்படுகின்றனவா என்பதை உறுதிப்படுத்தவும். சான்றிதழ் ரத்து என்பது அதை உண்மையில் சரிபார்க்கும் கிளையண்டுகளுக்கு மட்டுமே பயனளிக்கும். தனிப்பயன் நம்பக சேமிப்பகங்கள், சாதனங்கள் மற்றும் பழைய Java அல்லது உட்பொதிக்கப்பட்ட அமைப்புகளுக்கு இடைநிலைகளை கைமுறையாக அகற்றவோ அல்லது வெளிப்படையாக நம்பகமற்றதாகவோ மாற்ற வேண்டியிருக்கலாம்.
  • தொடர்ந்து கண்காணியுங்கள். உங்கள் தேடல்களை ஒரு திட்டமிடப்பட்ட பணியாகவோ (scheduled job) அல்லது டாஷ்போர்டாகவோ சேமித்து, முடிவுகள் சுத்தமாக இருக்கும் வரை ஒவ்வொரு ஸ்கேனிற்குப் பிறகும் அவற்றை மீண்டும் இயக்கவும்.

முடிவுரை

இணையத்தில் நம்பிக்கை என்பது இரண்டு விஷயங்களைச் சார்ந்துள்ளது என்பதை eMudhra சம்பவம் நினைவூட்டுகிறது: நீங்கள் வழங்கும் சான்றிதழ்கள் மற்றும் நீங்கள் நம்பத் தேர்ந்தெடுக்கும் அதிகார அமைப்புகள். இதற்கான தீர்வு ஒன்றும் விசித்திரமானது அல்ல. உங்கள் TLS இறுதிப்புள்ளிகளைப் பட்டியலிடுங்கள், அறியப்பட்ட எட்டு கைரேகைகளுடன் அவற்றின் சங்கிலிகளை ஒப்பிட்டுப் பாருங்கள், சரிசெய்யப்பட்ட கருவித்தொகுப்பைக் கொண்டு Go நிரல்களை மீண்டும் உருவாக்குங்கள், மேலும் உங்கள் பழைய அமைப்புகள் உண்மையில் நம்பகமின்மையைப் பெற்றுள்ளன என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள். இதை இந்த வாரமே செய்யுங்கள், பின்னர் சோதனைகளைத் தொடர்ந்து நடத்துங்கள்.

நன்மைகள்

  • பாதிக்கப்பட்ட சான்றிதழ்கள் துல்லியமான கைரேகைகளுடன் கூடிய குறுகிய, நிலையான பட்டியல் என்பதால், பொருத்தம் துல்லியமாக இருக்கும்.
  • முன்னணி உலாவிகளும் இயக்க முறைமைகளும் ஏற்கனவே அவற்றைத் தடுத்துவிட்டன, இது பெரும்பாலான அன்றாட பயனர்களைத் தானாகவே பாதுகாக்கிறது.
  • OpenSSL மற்றும் go version போன்ற இலவசக் கருவிகளே ஒரு அடிப்படை சரிபார்ப்புக்குப் போதுமானவை.
  • தற்போதுள்ள ஸ்கேனர்கள் இந்தத் தேடலைத் திரும்பத் திரும்பச் செய்யக்கூடிய ஒரு டாஷ்போர்டாக மாற்ற முடியும்.
  • இந்த முயற்சி எதிர்கால சம்பவங்களுக்காக உங்கள் சான்றிதழ் இருப்புப்பட்டியலை (certificate inventory) மேம்படுத்துகிறது.

குறைபாடுகள்

  • தனிப்பயன் அல்லது முடக்கப்பட்ட நம்பக சேமிப்பகங்களைக் கொண்ட அமைப்புகள் கைமுறை வேலை இல்லாமல் விற்பனையாளர் தடுப்புப் பட்டியல்களால் பலனடையாது.
  • 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.