1. What is the core problem a certificate authority (CA) solves that plain asymmetric encryption does not?
It makes the encryption mathematically stronger than a self-signed key pair would provide It verifies an identity claim and vouches for the binding between that identity and a public key It generates the private key on behalf of the certificate holder so the key never has to be created locally It stores a backup copy of every private key in case one is lost 2. In the notary analogy from the lesson, what does the CA's signature on a certificate actually represent?
A guarantee that the certificate holder is trustworthy and will not act maliciously A statement that the CA checked the identity claim once and vouches that this public key belongs to that identity Proof that the connection is encrypted end to end with no possibility of interception Confirmation that the private key has been escrowed with the CA for recovery purposes 3. Why does validating a certificate require walking the entire chain of trust rather than just checking the leaf certificate's signature?
Because each certificate in the chain encrypts a different part of the message, so all are needed to decrypt it Because the leaf certificate is only trustworthy if every signature above it, up to a hardcoded root, is also valid Because browsers are required by regulation to check multiple certificates even though one signature would be sufficient Because intermediate CAs rotate their keys frequently, so multiple signatures are needed as a backup in case one key is stale 4. What makes root CA certificates different from every other certificate in a chain of trust?
Root CAs use a stronger encryption algorithm than intermediate or leaf certificates Root CAs are trusted by fiat, hardcoded in advance by the operating system or browser, rather than being vouched for by another CA Root CAs expire faster than intermediate certificates, so they are reissued more often Root CAs are only used internally by organizations and never appear in public HTTPS validation 5. Why is a self-signed certificate not inherently cryptographically broken, even though systems warn about it?
Because self-signed certificates use a weaker key size than CA-issued ones by default Because a self-signed certificate provides identical encryption strength; what it lacks is a trusted third party vouching for the identity claim Because self-signed certificates cannot be revoked once issued Because self-signed certificates do not contain a public key, only a private key reference 6. An interviewer asks: 'If a browser encrypts data using a website's public key, hasn't it already confirmed the website is who it claims to be?' What is the strongest answer?
Yes, because only the real website could have generated that public key in the first place No, encryption and identity verification are separate operations; the certificate's CA signature and chain validation are what prove identity, not the ability to encrypt Yes, because HTTPS would refuse to connect at all if the identity were not already confirmed before encryption starts No, because encryption is never used for identity purposes in any protocol 7. Why is a CA's private key treated as the single most sensitive asset in the entire PKI system, often stored in a hardware security module?
Because losing the key would mean the CA has to reissue certificates for every customer, which is only an operational inconvenience Because whoever holds it can sign a certificate claiming any identity, making a compromise a catastrophic, trust-ending event Because the CA's private key is used to decrypt all HTTPS traffic protected by certificates it issued Because regulations require hardware security modules for any private key regardless of its purpose 
