प्रमाणपत्र प्राधिकरण और विश्वास शृंखलाएँ
जानिए कि रूट CA, मध्यवर्ती CA और अंतिम-इकाई प्रमाणपत्र ऐसी पदानुक्रम बनाते हैं जिस पर ब्राउज़र और ऑपरेटिंग सिस्टम भरोसा करते हैं।
प्रमाणपत्र प्राधिकरण और विश्वास शृंखलाएँ, CoddyKit पर Security+ Academy का एक निःशुल्क पाठ है। यह 4 में से 1वाँ पाठ है। इस अध्ययन पथ के 3 तक कोई भी पाठ पूरा पढ़ना निःशुल्क है — इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ व्यावहारिक अभ्यास भी उपलब्ध कराता है। यह Security+ Academy सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। Security+ Academy पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
Public Key Crypto में Trust की समस्या
असममित एन्क्रिप्शन तभी उपयोगी है जब आप भरोसा कर सकें कि कोई public key वास्तव में उसी व्यक्ति या संस्था की है, जिसकी आप उम्मीद कर रहे हैं। किसी trust mechanism के बिना attacker किसी व्यक्ति की public key के लिए आपके request को intercept करके उसकी जगह अपनी key रख सकता है — यह एक सामान्य man-in-the-middle attack है। Public Key Infrastructure (PKI) इस trust problem को Certificate Authority (CA) प्रस्तुत करके हल करता है — यह एक trusted third party है, जो verified identities से public keys को जोड़ने वाले certificates पर digital signature करती है। यदि आपको CA पर भरोसा है, तो आप उन सभी पर भरोसा कर सकते हैं जिन्हें CA ने certify किया है।
Certificate Authority क्या है
Certificate Authority (CA) वह organization है जो certificate requestor की identity Verify करने के बाद digital certificates जारी करती है। CA प्रत्येक certificate पर अपनी private key से हस्ताक्षर करती है, जिससे CA पर भरोसा करने वाला कोई भी व्यक्ति CA की public key का उपयोग करके certificate की authenticity Verify कर सकता है। इसके दो प्रकार हैं: Public CAs (जैसे DigiCert, GlobalSign, Let's Encrypt), जिनके root certificates operating systems और browsers में पहले से install होते हैं; और Private (Internal) CAs, जिन्हें organizations internal certificate issuance के लिए स्वयं चलाती हैं (VPNs, internal Services, device certificates)।
# View a website's certificate and issuer
openssl s_client -connect google.com:443 -showcerts 2>/dev/null |
openssl x509 -noout -text | grep -A2 'Issuer'
# Issuer: C = US, O = Google Trust Services, CN = WR2
# Subject: CN = *.google.com
# Check CA certificate details
curl -v https://google.com 2>&1 | grep 'issuer'Root CAs: अंतिम Trust Anchor
Root CA PKI hierarchy में सर्वोच्च Authority होती है। Root CA certificates self-signed होते हैं — उन्हें validate करने के लिए उनसे ऊपर कोई Authority नहीं होती। इसके बजाय, root certificates पर इसलिए Trust किया जाता है क्योंकि operating system vendors (Microsoft, Apple, Mozilla) कठोर auditing processes के माध्यम से root CAs की जाँच करते हैं और उनके certificates को trusted certificate stores में पहले से install करते हैं। किसी सामान्य browser के trust store में लगभग 130-150 trusted root CAs होते हैं। यदि किसी root CA से समझौता हो जाए, तो उसके द्वारा कभी भी जारी किया गया प्रत्येक certificate संदिग्ध हो जाता है — इसी कारण root CA private keys को offline, air-gapped hardware security modules (HSMs) में रखा जाता है।
# List trusted root CAs on Linux (varies by distro)
ls /etc/ssl/certs/ | head -20
# Or view specific CA cert
openssl x509 -in /etc/ssl/certs/DigiCert_Global_Root_CA.pem -noout -text
# On Windows, view trust store via MMC
# certmgr.msc > Trusted Root Certification AuthoritiesIntermediate CAs: Delegation Layer
Root CAs end entities को शायद ही कभी सीधे certificates जारी करती हैं। इसके बजाय, वे intermediate CA operators को certificates जारी करके Intermediate CAs (जिन्हें subordinate CAs भी कहा जाता है) बनाती हैं। फिर Intermediate CAs end-entity certificates (जैसे HTTPS Server certificates) जारी करती हैं। यह delegation hierarchy कई उद्देश्यों की पूर्ति करती है: root CA private keys को offline रखकर उनकी सुरक्षा करती है (यदि कोई intermediate CA compromise हो जाए, तो केवल उसकी certificate chain revoke होती है, पूरी root नहीं); अलग-अलग use cases (code signing बनाम TLS) के लिए specialized CAs की सुविधा देती है; और private PKI में organizational hierarchy सक्षम करती है।
Trust Chain (Certificate Chain)
certificate chain (या chain of trust) end-entity certificate से trusted root CA तक certificates का क्रम है। किसी सामान्य HTTPS website के लिए chain इस प्रकार होती है: End-entity cert (जैसे *.google.com) → Intermediate CA cert (जैसे Google Trust Services WR2) → Root CA cert (जैसे Google Trust Services LLC)। जब आपका browser किसी site पर जाता है, तो वह पूरी chain को validate करता है — यह जाँचते हुए कि प्रत्येक certificate का signature उसके ठीक ऊपर वाले level द्वारा बनाया गया है और root trusted store में मौजूद है। इस chain में कोई भी break certificate error का कारण बनता है।
# View the full certificate chain
openssl s_client -connect example.com:443 -showcerts 2>/dev/null
# Shows: 0 = end-entity cert, 1 = intermediate CA, 2 = root CA
# Verify a certificate chain manually
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt server_cert.pem
# server_cert.pem: OKCross-Certification और Bridge CAs
जब दो अलग-अलग PKI hierarchies को आपसी trust स्थापित करना होता है, तो वे cross-certification का उपयोग करती हैं। प्रत्येक CA दूसरे की root को certificate जारी करती है, जिससे दोनों दिशाओं में trust स्थापित होता है। Bridge CA एक central hub CA होती है, जो कई domain CAs के साथ cross-certify करती है और अलग-अलग organizations या government agencies के बीच trust का जाल बनाती है। US Federal Bridge CA कई federal government PKI systems को जोड़ती है। Cross-certification का management जटिल है, लेकिन organizations को merge करते समय या एक ही hierarchy में मिले बिना inter-agency trust स्थापित करते समय यह आवश्यक होता है।
Registration Authorities (RA)
Registration Authority (RA) वह entity है जो CA की ओर से identity verification करती है, लेकिन स्वयं certificates जारी नहीं करती। RA certificate requests प्राप्त करती है, applicant की identity Verify करती है (certificate type के आधार पर document checks, domain validation या in-person verification के माध्यम से) और approved requests को signing के लिए CA को forward करती है। यह delegation CAs को सारी verification स्वयं किए बिना अपनी issuance बढ़ाने देती है। Enterprise PKI में RA वह HR department या IT helpdesk हो सकता है जो employee certificate requests को validate करता है।
Certificate Validation Levels
CAs अलग-अलग validation levels पर certificates देती हैं, जो यह दर्शाते हैं कि requester's identity कितनी thoroughly Verify की गई है। Domain Validation (DV): CA केवल यह Verify करती है कि requester domain को control करता है (automated, इसमें कुछ minutes लगते हैं, Let's Encrypt इसका उपयोग करता है)। Organization Validation (OV): CA organization के legal existence को Verify करती है (1-3 business days)। Extended Validation (EV): सबसे thorough जाँच — legal identity, physical address और operational existence (1-2 weeks; browser address bars में हरे company name को दिखाने के लिए उपयोग किया जाता था)। Basic encryption के लिए DV पर्याप्त है; banking sites जैसे high-value targets के लिए EV उपयुक्त है।
Certificate Pinning
Certificate pinning एक ऐसी technique है जिसमें application को किसी भी trusted root CA के किसी भी certificate के बजाय केवल किसी specific certificate या CA पर Trust करने के लिए hardcode किया जाता है। इससे MITM attacks रुकते हैं, भले ही attacker किसी trusted CA से fraudulent certificate प्राप्त कर ले। Mobile apps और security-sensitive applications यह सुनिश्चित करने के लिए pinning का उपयोग करते हैं कि वे केवल अपने servers के certificates स्वीकार करें। इसका downside यह है कि यदि pinned certificate expire या rotate हो जाए, तो app update होने तक application काम करना बंद कर देती है। HPKP (HTTP Public Key Pinning) browser-based pinning mechanism था, जिसे गलत deployment के risks के कारण deprecated कर दिया गया है।
Internal Private CA Setup
Organizations अपनी internal certificate needs के लिए अपनी private CA चलाती हैं — VPN clients को authenticate करने, internal HTTPS Services के लिए certificates जारी करने, code पर हस्ताक्षर करने और devices को authenticate करने के लिए। Microsoft Active Directory Certificate Services (AD CS) सबसे सामान्य enterprise private CA है। Internal CA certificates उन सभी devices और browsers में distribute किए जाने चाहिए जिन्हें internally issued certificates पर Trust करना है, आमतौर पर Group Policy के माध्यम से। Private CAs ऐसे certificates जारी नहीं कर सकतीं जिन पर public internet Trust करे — उनका उपयोग केवल organization के उन devices तक सीमित है जिनमें private CA root install है।
# Create a simple private CA with OpenSSL
# Generate root CA private key
openssl genrsa -aes256 -out ca.key 4096
# Create self-signed root CA certificate (valid 10 years)
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt \
-subj '/C=US/O=MyCompany/CN=MyCompany Root CA'
# Now use ca.crt and ca.key to sign intermediate and end-entity certsCA Compromise और DigiNotar से मिले Lessons
DigiNotar compromise (2011) Security+ candidates के लिए जानने योग्य सबसे important CA incident है। Dutch CA DigiNotar को attackers ने breach किया और Google, Mozilla तथा government domains के लिए fraudulent certificates जारी किए। इनका उपयोग Iran में citizens पर man-in-the-middle attacks करने के लिए किया गया। परिणामस्वरूप, प्रत्येक major browser और OS vendor ने तुरंत DigiNotar को अपने trusted root stores से हटा दिया और DigiNotar द्वारा कभी जारी किए गए सभी certificates invalid हो गए। DigiNotar कुछ ही weeks में bankrupt हो गया। इस incident ने दिखाया कि CA compromise catastrophic होता है और अब CA systems के लिए CAA DNS records, Certificate Transparency तथा multi-factor authentication क्यों आवश्यक हैं।
त्वरित जाँच
इस पाठ में दिए गए CompTIA Security+ (SY0-701) के सिद्धांतों पर अपनी समझ जाँचें।
पाठ का पुनरावलोकन
इस पाठ में आपने सीखा: Certificate प्राधिकरण सार्वजनिक keys को सत्यापित पहचानों से जोड़ते हैं; विश्वास की श्रृंखला अंतिम इकाई से intermediate CAs होते हुए self-signed root तक जाती है; Root CAs को HSMs में ऑफ़लाइन रखा जाता है और OSes पहले से उन पर विश्वास करते हैं; तथा CA के साथ समझौता (DigiNotar) होने पर लाखों Certificates अमान्य हो सकते हैं। अब हम X.509 Certificate संरचना का अध्ययन करेंगे।
एआई शिक्षक के साथ Security+ Academy सीखें — निःशुल्क
अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।
- पाठ्यक्रम
- 30
- पाठ
- 120
अक्सर पूछे जाने वाले प्रश्न
क्या “प्रमाणपत्र प्राधिकरण और विश्वास शृंखलाएँ” पाठ निःशुल्क है?
हाँ — Security+ Academy अध्ययन पथ के 3 तक कोई भी पाठ, जिसमें “प्रमाणपत्र प्राधिकरण और विश्वास शृंखलाएँ” भी शामिल है, यहाँ वेब पर पूरा पढ़ना निःशुल्क है। इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ इंटरैक्टिव अभ्यास भी उपलब्ध कराता है। Security+ Academy पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
“प्रमाणपत्र प्राधिकरण और विश्वास शृंखलाएँ” में मैं क्या सीखूँगा?
जानिए कि रूट CA, मध्यवर्ती CA और अंतिम-इकाई प्रमाणपत्र ऐसी पदानुक्रम बनाते हैं जिस पर ब्राउज़र और ऑपरेटिंग सिस्टम भरोसा करते हैं। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ Security+ Academy का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।
क्या Security+ Academy शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?
पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर Security+ Academy शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 1वाँ पाठ है।
“प्रमाणपत्र प्राधिकरण और विश्वास शृंखलाएँ” पाठ पूरा करने में कितना समय लगता है?
CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।
क्या मैं इस Security+ Academy पाठ में कोड लिख और चला सकता हूँ?
हाँ। हर Security+ Academy पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।
इस पाठ्यक्रम के सभी पाठ
- प्रमाणपत्र प्राधिकरण और विश्वास शृंखलाएँ
- X.509 प्रमाणपत्र की संरचना
- प्रमाणपत्र का जीवनचक्र और निरस्तीकरण
- PKI के उपयोग: HTTPS, S/MIME और कोड साइनिंग