File Transfer Protocol (FTP): Port 20 (Data) and Port 21 (Control) Notes in Hindi : FTP प्रोटोकॉल: पोर्ट 20 (डेटा) और पोर्ट 21 (कंट्रोल कनेक्शन) और 20 महत्वपूर्ण MCQ प्रश्न (Rajasthan IT Exam)

PGDCA, BCA, B-Tech, MCA, M-Tech, B.Sc computer science राजस्थान सूचना सहायक व कंप्यूटर शिक्षक विशेष नोट्स: इस अध्याय में हम Public Key Infrastructure (PKI) and Certificate Authorities (CA) (PKI (पब्लिक की इन्फ्रास्ट्रक्चर) और सर्टिफिकेट अथॉरिटी (CA) की भूमिका) की संपूर्ण थ्योरी, मुख्य तकनीकी बिंदु, तुलनात्मक तालिका और विगत परीक्षाओं के पैटर्न पर आधारित 20 अति-महत्वपूर्ण बहुविकल्पीय प्रश्न (MCQs) विस्तृत हिंदी व अंग्रेजी व्याख्या सहित पढ़ेंगे।

Overview: Public Key Infrastructure (PKI) combines policies, hardware, protocols, and Certificate Authorities (CAs) to create, distribute, verify, and revoke X.509 certificates across hierarchical chains of trust.

अध्याय सार: PKI (Public Key Infrastructure) नियमों, हार्डवेयर, प्रोटोकॉल और सर्टिफिकेट अथॉरिटी (CA) का वह संपूर्ण ढांचा है जो ट्रस्ट चेन के माध्यम से डिजिटल सर्टिफिकेट जारी करने, सत्यापित करने और रद्द करने का प्रबंधन करता है।

Public Key Infrastructure (PKI) and Certificate Authorities (CA): Detailed Notes & Architecture (PKI (पब्लिक की इन्फ्रास्ट्रक्चर) और सर्टिफिकेट अथॉरिटी (CA) की भूमिका)

1. Core PKI Components: CA, RA, VA & Relying Parties (PKI के प्रमुख घटक: CA, RA, VA और रिलाइंग पार्टी)

[EN] PKI establishes scalable trust across four principal roles: (1) Certificate Authority (CA), the trusted issuer that cryptographically signs X.509 certificates and publishes revocation records; (2) Registration Authority (RA), which verifies applicant identities and domain ownership before approving issuance (never signing certificates itself); (3) Validation Authority (VA), hosting OCSP responders and CRLs; and (4) End-Entities (Subscribers) and Relying Parties (browsers/OS clients) verifying chains against pre-installed Root Trust Stores.

[HI] PKI चार प्रमुख भूमिकाओं पर चलता है: (1) CA (Certificate Authority) जो सर्टिफिकेट साइन कर जारी करती है; (2) RA (Registration Authority) जो सर्टिफिकेट साइन करने से पहले आवेदक की पहचान व डोमेन स्वामित्व सत्यापित करती है; (3) VA जो OCSP/CRL द्वारा वैधता जांचती है; तथा (4) क्लाइंट/ब्राउज़र जो रूट ट्रस्ट स्टोर से जांच करते हैं।

2. Hierarchical Trust Chain: Root CA -> Intermediate CA -> Leaf (पदानुक्रमित ट्रस्ट चेन: Root CA -> Intermediate CA -> लीफ सर्टिफिकेट)

[EN] Real PKI uses a multi-tier hierarchy rather than letting Root CAs sign millions of websites directly. The Root CA holds a self-signed certificate pre-trusted inside Windows, macOS, Linux, and browser trust stores, kept strictly air-gapped offline inside tamper-resistant Hardware Security Modules (HSMs). The Root CA signs Intermediate (Issuing) CAs, which run online to issue End-Entity Leaf certificates. If an Intermediate CA is compromised, the Root CA can revoke it without breaking the entire ecosystem.

[HI] वास्तविक PKI में रूट CA सीधे वेबसाइट सर्टिफिकेट साइन नहीं करती—बल्कि रूट CA का सेल्फ-साइन्ड सर्टिफिकेट ब्राउज़र/OS के ट्रस्ट स्टोर में पहले से रहता है और उसकी कुंजी को इंटरनेट से अलग (Air-gapped HSM में) रखा जाता है। रूट CA ऑनलाइन Intermediate CA को साइन करती है, जो आगे वेबसाइटों को लीफ सर्टिफिकेट देती हैं।

3. Automation (ACME) & Revocation: CRL vs OCSP Stapling (स्वचालन (ACME) और निरस्तीकरण: CRL बनाम OCSP स्टेपलिंग)

[EN] Modern web PKI automates issuance via the ACME protocol (RFC 8555, pioneered by Let's Encrypt), proving domain control via HTTP-01 or DNS-01 challenges in seconds. When keys leak, CAs revoke certificates using either CRLs (Certificate Revocation Lists—periodic signed lists that grow megabytes large) or OCSP (Online Certificate Status Protocol—real-time queries leaking user browsing history to the CA and adding latency). OCSP Stapling solves both flaws by letting the web server cache the CA's timestamped OCSP response and staple it right inside the TLS handshake.

[HI] आज ACME प्रोटोकॉल (जैसे Let's Encrypt) द्वारा सर्टिफिकेट सेकंडों में स्वतः जारी होते हैं। रद्द किए गए सर्टिफिकेट की जांच के लिए CRL (बड़ी आवधिक सूची) या OCSP (रीयल-टाइम पूछताछ, जिससे निजता व गति प्रभावित होती है) चलते हैं; OCSP Stapling में वेब सर्वर स्वयं CA का हस्ताक्षरित उत्तर TLS हैंडशेक के साथ चिपका देता है जिससे निजता व गति दोनों बचती हैं।

4. Rogue CA Defenses: Certificate Transparency & DNS CAA (दुर्भावनापूर्ण CA से सुरक्षा: CT लॉग्स और DNS CAA)

[EN] Because ANY publicly trusted Root/Intermediate CA can technically sign a certificate for ANY domain, past compromises (like DigiNotar in 2011 forging Google certs) motivated strong safeguards. Certificate Transparency (CT, RFC 6962) mandates that every trusted public TLS cert be recorded in cryptographically verifiable, append-only public Merkle logs (returning Signed Certificate Timestamps, SCTs) so domain owners immediately spot unauthorized certs. Additionally, DNS CAA records (RFC 8659) restrict which CAs are permitted to issue certs for a domain.

[HI] 2011 की DigiNotar घटना (जिसमें हैक हुई CA ने Google के नकली सर्टिफिकेट बना लिए थे) के बाद Certificate Transparency (CT, RFC 6962) अनिवार्य हुई—अब हर पब्लिक TLS सर्टिफिकेट को सार्वजनिक मर्कल लॉग में दर्ज करना पड़ता है। साथ ही डोमेन मालिक DNS CAA रिकॉर्ड (`0 issue "letsencrypt.org"`) द्वारा तय कर सकते हैं कि कौन सी CA उनका सर्टिफिकेट बना सकती है।

Syntax, Formula & Technical Example (Public Key Infrastructure (PKI) and Certificate Authorities (CA))

# PKI Chain Verification, DNS CAA Record & ACME Issuance Commands
# Trust Chain: Root CA (OS Trust Store) -> Intermediate CA -> Leaf Server (computersir.in)
# 1. Verify full certificate chain locally using OpenSSL:
#    openssl verify -CAfile root_ca.pem -untrusted intermediate_ca.pem server_leaf.pem
# 2. Restrict authorized CAs via DNS CAA record (RFC 8659):
#    computersir.in.  IN  CAA  0 issue "letsencrypt.org"
#    computersir.in.  IN  CAA  0 iodef "mailto:security@computersir.in"
# 3. Check TLS chain + OCSP stapling status on a live domain:
#    openssl s_client -connect computersir.in:443 -status -servername computersir.in

Public Key Infrastructure (PKI) and Certificate Authorities (CA) Quick Reference & Comparison Table

PKI Entity / Protocol	Primary Operational Function	Security & Architectural Exam Note
Root CA	Top self-signed anchor stored in OS/Browser Trust Store	Kept strictly offline inside FIPS 140-3 HSMs; signs Intermediates
Registration Authority (RA)	Authenticates applicant identity & domain control before issuance	Vets CSR requests; never signs certificates directly
OCSP Stapling	Web server attaches CA-signed status inside TLS handshake	Eliminates CA query latency and protects user browsing privacy
Certificate Transparency (CT)	Public append-only Merkle logs issuing SCT receipts	Detects rogue or compromised CA certificate misissuance

Public Key Infrastructure (PKI) and Certificate Authorities (CA) Top 20 Bilingual MCQs with Answers

Q1. In a standard hierarchical PKI, what is the specific role of the Registration Authority (RA) compared to the Certificate Authority (CA)?

(मानक पदानुक्रमित PKI में Certificate Authority (CA) की तुलना में Registration Authority (RA) का विशिष्ट कार्य क्या होता है?)

(A) The RA signs and issues Root CA certificates offline

(B) The RA replaces OCSP servers inside web browsers

(C) The RA verifies the applicant's identity and CSR eligibility, then forwards approved requests to the CA for cryptographic signing

(D) The RA generates every user's Private Key centrally

Correct Answer: (C)

[EN] Separating RA identity vetting from CA signing enforces separation of duties—the RA never possesses the CA's signing private key.

[HI] RA आवेदक की पहचान और दस्तावेज़ों का सत्यापन करती है तथा स्वीकृति के बाद सर्टिफिकेट पर हस्ताक्षर करने हेतु CA को भेजती है; RA स्वयं साइन नहीं करती।

Q2. Why do trustworthy PKI operators keep the Root CA's private key strictly offline (air-gapped) inside Hardware Security Modules (HSMs)?

(विश्वसनीय PKI संचालक Root CA की प्राइवेट की को हमेशा इंटरनेट से कटे हुए (Air-gapped) HSM में ऑफलाइन क्यों रखते हैं?)

(A) Compromising a Root CA destroys trust across all issued certificates and requires emergency OS/browser trust-store updates worldwide

(B) To avoid paying ACME licensing fees

(C) Because Root CA private keys cannot compute signatures over TCP/IP

(D) Because HSMs automatically expire every 24 hours

Correct Answer: (A)

[EN] Root CAs only boot briefly in guarded ceremonies to sign new Intermediate CAs or CRLs; everyday certificate signing stays isolated on Intermediate CAs.

[HI] यदि Root CA की प्राइवेट की चोरी हो जाए, तो दुनिया भर के करोड़ों सिस्टम में विश्वास टूट जाएगा; इसलिए इसे ऑफलाइन रखकर केवल Intermediate CA के माध्यम से काम होता है।

Q3. During a TLS handshake, how does a client verify an entire 3-tier PKI chain (Root -> Intermediate -> Server Leaf)?

(TLS हैंडशेक के दौरान कोई ब्राउज़र 3-स्तरीय PKI चेन (Root -> Intermediate -> Server Leaf) को किस क्रम से सत्यापित करता है?)

(A) By downloading the Root CA private key over port 80

(B) By verifying only the Server Leaf cert against itself

(C) By trusting whichever cert has the largest Serial Number

(D) Using Root's pre-trusted Public Key to verify Intermediate's signature, then Intermediate's Public Key to verify the Server Leaf cert

Correct Answer: (D)

[EN] The browser walks up from the leaf cert (matching Issuer -> Subject) until anchoring on a self-signed Root CA already trusted in its local Root Store.

[HI] ब्राउज़र पहले से भरोसेमंद स्थानीय Root Store की पब्लिक की से Intermediate CA को और फिर उसकी पब्लिक की से वेबसाइट सर्टिफिकेट के सिग्नेचर को सत्यापित करता है।

Q4. What two problems of traditional real-time OCSP queries does OCSP Stapling resolve?

(पारंपरिक रीयल-टाइम OCSP पूछताछ की किन दो समस्याओं को 'OCSP Stapling' हल करता है?)

(A) Eliminating the need for Subject Alternative Names

(B) Replacing RSA-2048 with Caesar ciphers

(C) Privacy leakage (CA seeing every site a user visits) and handshake connection latency/availability risk

(D) Making X.509 certificates valid for 50 years

Correct Answer: (C)

[EN] With OCSP Stapling, the origin web server fetches the signed timestamped OCSP response periodically and staples it into the TLS handshake.

[HI] OCSP स्टेपलिंग में वेब सर्वर स्वयं CA से हस्ताक्षरित OCSP स्थिति लाकर हैंडशेक में जोड़ देता है, जिससे यूज़र की ब्राउज़िंग निजता और कनेक्शन गति दोनों सुरक्षित रहते हैं।

Q5. Why do modern browsers dislike relying solely on traditional Certificate Revocation Lists (CRLs) for web PKI?

(आधुनिक वेब ब्राउज़र केवल पारंपरिक Certificate Revocation Lists (CRLs) पर निर्भर क्यों नहीं रहते?)

(A) CRLs work only with MD5 hashes

(B) CRLs expose every server's Private Key inside plain text

(C) CRLs grow huge (tens of megabytes), download slowly, and update only periodically leaving revocation delay windows

(D) CRLs require manual user typing for each domain

Correct Answer: (C)

[EN] Instead of pulling massive full CRLs per CA, modern browsers combine OCSP Stapling with compact proprietary push lists (e.g., Chrome CRLSets / Firefox OneCRL).

[HI] CRLs आकार में बहुत भारी (मेगाबाइट्स) हो जाती हैं और देर से अपडेट होती हैं; इसलिए अब OCSP स्टेपलिंग और ब्राउज़र की कॉम्पैक्ट पुश लिस्ट उपयोग होती है।

Q6. What does Certificate Transparency (CT, RFC 6962) require CAs to do before browsers trust a newly issued public HTTPS certificate?

(नए पब्लिक HTTPS सर्टिफिकेट पर भरोसा करने से पहले Certificate Transparency (CT, RFC 6962) CA से क्या अनिवार्य करवाती है?)

(A) Publish the server's Private Key inside GitHub

(B) Sign the certificate with three different Root CAs simultaneously

(C) Submit the certificate to public append-only Merkle logs and embed Signed Certificate Timestamps (SCTs)

(D) Wait 30 days before turning on port 443

Correct Answer: (C)

[EN] Public CT logs prevent stealth rogue-cert issuance (like DigiNotar 2011) because domain owners monitor logs and detect unauthorized certificates immediately.

[HI] प्रत्येक नए सर्टिफिकेट को सार्वजनिक मर्कल लॉग में दर्ज कर SCT रसीद जोड़नी होती है, जिससे किसी भी नकली सर्टिफिकेट को तुरंत पकड़ा जा सके।

Q7. How does a domain owner use a DNS CAA (Certification Authority Authorization, RFC 8659) record?

(एक डोमेन मालिक DNS CAA (RFC 8659) रिकॉर्ड का उपयोग किस सुरक्षा नियंत्रण के लिए करता है?)

(A) To act as a backup mail server MX record

(B) To publish the website's AES session key in DNS

(C) To disable HTTPS redirects on subdomains

(D) To declare exactly which Certificate Authorities are allowed to issue TLS certificates for that domain

Correct Answer: (D)

[EN] For example, `0 issue "letsencrypt.org"` instructs compliant CAs (like DigiCert or Sectigo) to refuse issuing certificates for that domain.

[HI] DNS CAA रिकॉर्ड तय करता है कि केवल उन्हीं सूचीबद्ध CA को उस डोमेन के लिए सर्टिफिकेट जारी करने की अनुमति होगी, अन्य सभी को मना किया जाता है।

Q8. Which automated PKI protocol standardized in RFC 8555 allows web servers (via Certbot) to obtain and renew free DV certificates automatically?

(RFC 8555 में मानकीकृत कौन सा स्वचालित PKI प्रोटोकॉल वेब सर्वरों (Certbot द्वारा) को स्वतः मुफ्त सर्टिफिकेट पाने व नवीनीकरण करने की सुविधा देता है?)

(A) BGP-4 Route Reflection

(B) DHCPv6 Relay

(C) SCEP over SNMPv1

(D) ACME (Automated Certificate Management Environment)

Correct Answer: (D)

[EN] Let's Encrypt built ACME to automate CSR submission, HTTP-01/DNS-01 validation, and 90-day renewals without human errors or outages.

[HI] ACME प्रोटोकॉल (Let's Encrypt द्वारा लोकप्रिय) बिना मानवीय हस्तक्षेप के डोमेन सत्यापन व हर 90 दिनों में स्वतः सर्टिफिकेट नवीनीकरण करता है।

Q9. What does 'Key Escrow' (Key Archival) in an enterprise PKI refer to, and when is it appropriate vs dangerous?

(एंटरप्राइज PKI में 'की एस्क्रो' (Key Escrow) किसे कहते हैं, और यह कब उचित बनाम अनुचित होता है?)

(A) Publishing Root CA keys on social media

(B) Securely backing up decryption Private Keys so encrypted corporate files stay recoverable if an employee leaves; NEVER used for signing keys

(C) Sharing browser session cookies across websites

(D) Deleting all CRLs monthly

Correct Answer: (B)

[EN] Archiving encryption keys prevents permanent corporate data loss, whereas escrowing a *signing* private key would destroy legal non-repudiation because the CA could forge signatures.

[HI] एन्क्रिप्शन प्राइवेट की का बैकअप रखना कर्मचारी के जाने पर डेटा बचाने हेतु सही है, परंतु साइनिंग प्राइवेट की का एस्क्रो कभी नहीं होना चाहिए क्योंकि इससे नॉन-रेप्यूडिएशन नष्ट हो जाता है।

Q10. Which PKI validation tier performs ONLY automated verification that the requester controls the domain name (via HTTP file or DNS TXT record)?

(PKI सत्यापन का कौन सा स्तर केवल यह जांचता है कि आवेदक का उस डोमेन नाम पर तकनीकी नियंत्रण है (कंपनी की कानूनी जांच के बिना)?)

(A) Extended Validation (EV) certificate

(B) Organization Validated (OV) certificate

(C) Qualified Hardware Smartcard

(D) Domain Validated (DV) certificate

Correct Answer: (D)

[EN] DV validates domain control automatically in seconds (e.g., Let's Encrypt), whereas OV and EV manually vet legal business registration.

[HI] DV (Domain Validated) सर्टिफिकेट केवल HTTP या DNS चैलेंज द्वारा डोमेन नियंत्रण जांचकर सेकंडों में जारी हो जाता है; OV व EV में संगठन की कानूनी जांच होती है।

Q11. What happens if an attacker compromises an online Intermediate CA and issues a forged certificate for a major bank, and how does the PKI recover?

(यदि कोई हमलावर ऑनलाइन Intermediate CA को हैक कर किसी बैंक का जाली सर्टिफिकेट बना ले, तो PKI इसे कैसे संभालती है?)

(A) Nothing can be done until the year 2038

(B) The offline Root CA immediately revokes the compromised Intermediate CA's certificate and publishes it in CRL/OneCRL

(C) Every user must replace their physical motherboard

(D) The bank changes its IPv4 address only

Correct Answer: (B)

[EN] Isolating online risk inside Intermediate CAs limits blast radius: revoking that single Intermediate CA invalidates all rogue certs beneath it while leaving the Root CA intact.

[HI] ऑफलाइन Root CA तुरंत उस हैक हुई Intermediate CA के सर्टिफिकेट को रद्द कर देती है, जिससे उसके नीचे बने सभी जाली सर्टिफिकेट अमान्य हो जाते हैं।

Q12. In mutual TLS (mTLS) zero-trust microservices architectures, what extra PKI check occurs compared to standard browser HTTPS?

(सामान्य ब्राउज़र HTTPS की तुलना में ज़ीरो-ट्रस्ट माइक्रोसर्विसेस के म्यूचुअल TLS (mTLS) में कौन सी अतिरिक्त PKI जांच होती है?)

(A) Certificates are replaced by plaintext API passwords

(B) Neither side checks certificate expiration dates

(C) Both the server AND the client present X.509 certificates and verify each other's chain against trusted CAs

(D) Only Root CAs can run on port 443

Correct Answer: (C)

[EN] Standard HTTPS authenticates only the server; mTLS requires the client workload/device to prove its own PKI certificate identity too.

[HI] सामान्य HTTPS में केवल सर्वर अपना सर्टिफिकेट दिखाता है, जबकि mTLS में सर्वर और क्लाइंट दोनों एक-दूसरे के X.509 सर्टिफिकेट सत्यापित करते हैं।

Q13. In a Bridge or Cross-Certified PKI topology (used between separate government or corporate PKIs), how is mutual trust established?

(दो अलग-अलग सरकारी या कॉरपोरेट PKI प्रणालियों के बीच आपसी विश्वास स्थापित करने के लिए क्रॉस-सर्टिफिकेशन या ब्रिज CA क्या करता है?)

(A) One corporation deletes its own encryption keys

(B) Independent Root CAs issue cross-certificates trusting each other's CA public keys (or via a neutral Bridge CA) without merging into one global Root

(C) Every employee manually installs 10,000 leaf certs

(D) Both companies switch to unencrypted HTTP

Correct Answer: (B)

[EN] A Bridge CA forms a hub connecting multiple peer PKI hierarchies via bilateral cross-certificates so users in Organization A validate certs issued by Organization B.

[HI] ब्रिज CA या क्रॉस-सर्टिफिकेशन द्वारा दो स्वतंत्र PKI प्रणालियाँ एक-दूसरे के सर्टिफिकेट को बिना एकल रूट में विलय किए प्रमाणित कर पाती हैं।

Q14. What catastrophic 2011 security breach demonstrated why blind trust in every global CA without CT logs was dangerous?

(2011 की किस बड़ी सुरक्षा घटना ने साबित किया कि बिना CT लॉग्स के हर वैश्विक CA पर आंख मूंदकर भरोसा करना खतरनाक है?)

(A) The DigiNotar CA breach (where attackers minted rogue *.google.com certificates used for MitM spying in Iran)

(B) The Heartbleed OpenSSL buffer bug

(C) The SolarWinds Orion build compromise

(D) The Morris Internet Worm

Correct Answer: (A)

[EN] Following DigiNotar's compromise and delayed disclosure, Microsoft, Apple, Google, and Mozilla permanently distrusted DigiNotar and built Certificate Transparency.

[HI] 2011 में डच कंपनी DigiNotar के हैक होने पर हमलावरों ने Google के नकली सर्टिफिकेट बना लिए थे, जिसके बाद उसे ट्रस्ट स्टोर से हटाकर CT लॉग्स बनाए गए।

Q15. What does 'Certificate Pinning' (HPKP / app-level pinning) attempt to do, and why was HTTP HPKP deprecated in browsers?

(सर्टिफिकेट पिनिंग (Certificate Pinning) का उद्देश्य क्या होता है और ब्राउज़रों में HTTP-आधारित HPKP को क्यों बंद कर दिया गया?)

(A) Pinning restricts accepted certs to specific public-key hashes; HPKP was deprecated because misconfigured pins could lock users out of a website permanently

(B) Pinning converts PEM certificates into JPEG images

(C) Pinning stores Private Keys inside CSS stylesheets

(D) Pinning disables OCSP Stapling forever

Correct Answer: (A)

[EN] While mobile native apps still occasionally pin backup keys carefully, web HPKP posed severe self-Denial-of-Service risks ('ransomware pinning') and was replaced by CT.

[HI] पिनिंग केवल निश्चित पब्लिक-की हैश को स्वीकार करती है, परंतु गलत पिन सेट होने पर वेबसाइट हमेशा के लिए ब्लॉक हो जाने के खतरे (DoS) के कारण ब्राउज़रों ने HPKP हटा दिया।

Q16. Which statement about PKI and Certificate Authorities (CAs) is FALSE?

(PKI और सर्टिफिकेट अथॉरिटी (CA) के बारे में निम्नलिखित में से कौन सा कथन असत्य (FALSE) है?)

(A) A trusted CA generates and retains a copy of every public website's Private Key inside the browser's Root Store

(B) Registration Authorities verify identity before a CA signs a certificate

(C) OCSP Stapling delivers signed revocation status directly inside the TLS handshake

(D) An offline Root CA signs online Intermediate CAs to isolate compromise risk

Correct Answer: (A)

[EN] A CA NEVER generates or receives a public website's Private Key (the site generates its key locally and sends only the Public Key inside a CSR); browsers store only public CA root certs.

[HI] CA कभी भी किसी वेबसाइट की प्राइवेट की अपने पास नहीं रखती और न ही ब्राउज़र में वेबसाइटों की प्राइवेट की होती है; ब्राउज़र केवल CA की पब्लिक रूट कुंजियाँ रखता है।

Q17. Within Public Key Infrastructure (PKI) and Certificate Authorities (CA), which pki entity / protocol directly maps to: "Top self-signed anchor stored in OS/Browser Trust Store"?

(Public Key Infrastructure (PKI) and Certificate Authorities (CA) में कौन सा PKI Entity / Protocol सीधे "Top self-signed anchor stored in OS/Browser Trust Store" से संबंधित है?)

(A) OCSP Stapling

(B) Registration Authority (RA)

(C) Certificate Transparency (CT)

(D) Root CA

Correct Answer: (D)

[EN] In Public Key Infrastructure (PKI) and Certificate Authorities (CA), 'Root CA' handles 'Top self-signed anchor stored in OS/Browser Trust Store' (Kept strictly offline inside FIPS 140-3 HSMs; signs Intermediates).

[HI] Public Key Infrastructure (PKI) and Certificate Authorities (CA) में 'Root CA' का कार्य/विवरण 'Top self-signed anchor stored in OS/Browser Trust Store' (Kept strictly offline inside FIPS 140-3 HSMs; signs Intermediates) है।

Q18. Which option accurately describes 'Registration Authority (RA)' in Public Key Infrastructure (PKI) and Certificate Authorities (CA)?

(Public Key Infrastructure (PKI) and Certificate Authorities (CA) के संदर्भ में 'Registration Authority (RA)' की सही विशेषता कौन सी है?)

(A) Top self-signed anchor stored in OS/Browser Trust Store

(B) Authenticates applicant identity & domain control before issuance

(C) Public append-only Merkle logs issuing SCT receipts

(D) Web server attaches CA-signed status inside TLS handshake

Correct Answer: (B)

[EN] 'Registration Authority (RA)' provides 'Authenticates applicant identity & domain control before issuance' — key point: Vets CSR requests; never signs certificates directly.

[HI] 'Registration Authority (RA)' का मुख्य विवरण 'Authenticates applicant identity & domain control before issuance' है (Vets CSR requests; never signs certificates directly)।

Q19. In Public Key Infrastructure (PKI) and Certificate Authorities (CA), identify the correct parameter for the specification: "Web server attaches CA-signed status inside TLS handshake".

(Public Key Infrastructure (PKI) and Certificate Authorities (CA) में "Web server attaches CA-signed status inside TLS handshake" विवरण किस विकल्प के लिए सही है?)

(A) Registration Authority (RA)

(B) Root CA

(C) Certificate Transparency (CT)

(D) OCSP Stapling

Correct Answer: (D)

[EN] 'OCSP Stapling' corresponds to 'Web server attaches CA-signed status inside TLS handshake' (Eliminates CA query latency and protects user browsing privacy).

[HI] 'OCSP Stapling' का संबंध 'Web server attaches CA-signed status inside TLS handshake' (Eliminates CA query latency and protects user browsing privacy) से है।

Q20. Considering Public Key Infrastructure (PKI) and Certificate Authorities (CA), what key behavior defines 'Certificate Transparency (CT)'?

(Public Key Infrastructure (PKI) and Certificate Authorities (CA) में 'Certificate Transparency (CT)' की मुख्य भूमिका या मान क्या है?)

(A) Web server attaches CA-signed status inside TLS handshake

(B) Top self-signed anchor stored in OS/Browser Trust Store

(C) Authenticates applicant identity & domain control before issuance

(D) Public append-only Merkle logs issuing SCT receipts

Correct Answer: (D)

[EN] 'Certificate Transparency (CT)' represents 'Public append-only Merkle logs issuing SCT receipts' (Detects rogue or compromised CA certificate misissuance).

[HI] 'Certificate Transparency (CT)' का अर्थ/मान 'Public append-only Merkle logs issuing SCT receipts' है (Detects rogue or compromised CA certificate misissuance)।

Public Key Infrastructure (PKI) and Certificate Authorities (CA) — Exam FAQs

Q1: Why don't browsers simply store every website's public key directly instead of trusting CAs?

ब्राउज़र CA पर भरोसा करने के बजाय सीधे हर वेबसाइट की पब्लिक की अपने अंदर स्टोर क्यों नहीं कर लेते?

[EN] There are hundreds of millions of websites whose keys rotate every 90 days; pre-installing ~150 Root CAs allows browsers to dynamically verify billions of sites via hierarchical signatures.

[HI] इंटरनेट पर करोड़ों वेबसाइट्स हैं जिनकी कुंजियाँ हर कुछ महीनों में बदलती हैं; केवल ~150 Root CAs को ट्रस्ट स्टोर में रखकर ब्राउज़र हर नई वेबसाइट को स्वतः सत्यापित कर लेता है।

Q2: What is the difference between CRL and OCSP?

CRL और OCSP में मुख्य अंतर क्या है?

[EN] CRL is a periodic downloadable list of all revoked serial numbers (large file, slower updates), whereas OCSP queries the revocation status of one specific certificate in real time (or via server-side OCSP Stapling).

[HI] CRL रद्द सर्टिफिकेट्स की एक बड़ी डाउनलोड योग्य सूची है, जबकि OCSP किसी एक विशिष्ट सर्टिफिकेट की वैधता की तुरंत जांच करता है।

Q3: What is a Wildcard certificate (e.g., *.computersir.in) vs a Multi-Domain SAN certificate?

वाइल्डकार्ड सर्टिफिकेट (*.computersir.in) और मल्टी-डोमेन SAN सर्टिफिकेट में क्या अंतर है?

[EN] A wildcard covers unlimited subdomains at one single level (blog.computersir.in, mail.computersir.in), whereas a Multi-Domain SAN certificate lists explicitly distinct domains (example.com, example.org) inside one cert.

[HI] वाइल्डकार्ड एक ही डोमेन के अनगिनत सब-डोमेन को सुरक्षित करता है, जबकि मल्टी-डोमेन SAN एक ही सर्टिफिकेट में अलग-अलग मुख्य डोमेन नाम शामिल कर सकता है।

Cyber Security