Trick 1: "A wildcard certificate *.example.com will cover staging.api.example.com." True or False?
FALSE — a wildcard only covers ONE subdomain level.
*.example.com matches: www.example.com, api.example.com, mobile.example.com — any name where the asterisk replaces a single label.
*.example.com does NOT match: staging.api.example.com — because there are two labels before .example.com (staging AND api). A wildcard cannot match multiple labels.
To cover staging.api.example.com, you need either: (1) a SAN certificate that explicitly lists staging.api.example.com, or (2) a separate wildcard *.api.example.com (but this is a different wildcard for a different level).
Exam tip: whenever you see a multi-level subdomain (x.y.example.com) in a wildcard question, the answer is "wildcard cannot cover this."
*.example.com matches: www.example.com, api.example.com, mobile.example.com — any name where the asterisk replaces a single label.
*.example.com does NOT match: staging.api.example.com — because there are two labels before .example.com (staging AND api). A wildcard cannot match multiple labels.
To cover staging.api.example.com, you need either: (1) a SAN certificate that explicitly lists staging.api.example.com, or (2) a separate wildcard *.api.example.com (but this is a different wildcard for a different level).
Exam tip: whenever you see a multi-level subdomain (x.y.example.com) in a wildcard question, the answer is "wildcard cannot cover this."
Trick 2: "An expired certificate means the server is automatically using an invalid/revoked certificate." True or False?
FALSE — expiration and revocation are separate concepts.
A certificate expires naturally when it passes its "Not After" date — this is a planned lifecycle event. An expired certificate means it needs to be renewed, not that anything malicious happened.
Revocation is an out-of-band cancellation before the expiration date — typically because the private key was compromised, the CA issued it in error, or the domain ownership changed. Revocation requires action (CRL, OCSP) and is unplanned.
Both result in browsers rejecting the certificate, but for different reasons:
- Expired: certificate lifecycle ended normally. Solution: renew the certificate.
- Revoked: certificate was canceled early due to a security event. Solution: generate new key pair, request new certificate, investigate why revocation was necessary.
Exam trap: questions sometimes confuse "expired" and "revoked" — they are distinct problems with distinct solutions.
A certificate expires naturally when it passes its "Not After" date — this is a planned lifecycle event. An expired certificate means it needs to be renewed, not that anything malicious happened.
Revocation is an out-of-band cancellation before the expiration date — typically because the private key was compromised, the CA issued it in error, or the domain ownership changed. Revocation requires action (CRL, OCSP) and is unplanned.
Both result in browsers rejecting the certificate, but for different reasons:
- Expired: certificate lifecycle ended normally. Solution: renew the certificate.
- Revoked: certificate was canceled early due to a security event. Solution: generate new key pair, request new certificate, investigate why revocation was necessary.
Exam trap: questions sometimes confuse "expired" and "revoked" — they are distinct problems with distinct solutions.
Trick 3: "The private key is sent to the CA in the CSR so the CA can sign the certificate." True or False?
FALSE — the private key is NEVER sent to the CA. Only the public key is in the CSR.
This is a fundamental PKI principle. The CSR contains: the public key, the identity claims (domain, organization), and is signed with the private key to PROVE you possess it — but the private key value itself is not included.
The CA signs the public key + identity claims = the certificate. The CA never sees, handles, or stores the private key. The private key never leaves the server it was generated on.
Why this matters: if the private key were sent to the CA, you'd have to trust the CA completely with your key — and CA breaches would expose all private keys. The CSR design ensures the CA only vouches for identity, not key custody.
Exam tip: "private key leaves the server" is always wrong in a properly configured PKI. Any answer suggesting the CA receives the private key is incorrect.
This is a fundamental PKI principle. The CSR contains: the public key, the identity claims (domain, organization), and is signed with the private key to PROVE you possess it — but the private key value itself is not included.
The CA signs the public key + identity claims = the certificate. The CA never sees, handles, or stores the private key. The private key never leaves the server it was generated on.
Why this matters: if the private key were sent to the CA, you'd have to trust the CA completely with your key — and CA breaches would expose all private keys. The CSR design ensures the CA only vouches for identity, not key custody.
Exam tip: "private key leaves the server" is always wrong in a properly configured PKI. Any answer suggesting the CA receives the private key is incorrect.
Trick 4: "A self-signed certificate provides the same level of trust as a CA-signed certificate — they use the same encryption strength." True or False?
FALSE — encryption strength and trust are completely different properties.
Encryption strength (key length, algorithm) is technically independent of who signed the certificate. A self-signed 4096-bit RSA certificate encrypts just as strongly as a CA-signed 4096-bit RSA certificate for the TLS session.
The difference is TRUST, not encryption: a CA-signed certificate proves the CA verified the identity claim (this public key belongs to bank.com). A self-signed certificate has no identity verification — anyone can create a self-signed cert claiming to be bank.com, with no one checking that claim.
A man-in-the-middle could present a self-signed cert claiming to be your bank with full 4096-bit encryption — your traffic would be "strongly encrypted" to the attacker, not the bank. The encryption is strong; the identity is unverified.
This is why browsers warn about self-signed certs — not because the encryption is weak, but because the identity is unverified.
Encryption strength (key length, algorithm) is technically independent of who signed the certificate. A self-signed 4096-bit RSA certificate encrypts just as strongly as a CA-signed 4096-bit RSA certificate for the TLS session.
The difference is TRUST, not encryption: a CA-signed certificate proves the CA verified the identity claim (this public key belongs to bank.com). A self-signed certificate has no identity verification — anyone can create a self-signed cert claiming to be bank.com, with no one checking that claim.
A man-in-the-middle could present a self-signed cert claiming to be your bank with full 4096-bit encryption — your traffic would be "strongly encrypted" to the attacker, not the bank. The encryption is strong; the identity is unverified.
This is why browsers warn about self-signed certs — not because the encryption is weak, but because the identity is unverified.
Trick 5: "OCSP is always more secure than CRL because it provides real-time revocation status." True or False?
FALSE — OCSP has a critical vulnerability: soft-fail behavior.
Most browsers implement "soft-fail" OCSP: if the OCSP responder is unreachable (attacker blocks it, responder is down), the browser accepts the certificate anyway rather than blocking all HTTPS connections. An attacker who has stolen a private key and needs to use a certificate that has been revoked can block OCSP traffic — the browser fails open and accepts the revoked certificate.
CRL caching also has soft-fail issues: if the cached CRL is expired and the new CRL can't be downloaded, browsers often accept the certificate.
OCSP Stapling improves on this: the server provides the CA-signed OCSP response directly in the TLS handshake. Even if the CA's OCSP responder is blocked, the stapled response (valid for 24-48 hours) is already present. And OCSP Must-Staple (a certificate extension) tells browsers to REQUIRE a stapled OCSP response — if absent, reject the connection.
For the exam: standard OCSP > CRL for timeliness, but OCSP Stapling > standard OCSP for both timeliness and reliability.
Most browsers implement "soft-fail" OCSP: if the OCSP responder is unreachable (attacker blocks it, responder is down), the browser accepts the certificate anyway rather than blocking all HTTPS connections. An attacker who has stolen a private key and needs to use a certificate that has been revoked can block OCSP traffic — the browser fails open and accepts the revoked certificate.
CRL caching also has soft-fail issues: if the cached CRL is expired and the new CRL can't be downloaded, browsers often accept the certificate.
OCSP Stapling improves on this: the server provides the CA-signed OCSP response directly in the TLS handshake. Even if the CA's OCSP responder is blocked, the stapled response (valid for 24-48 hours) is already present. And OCSP Must-Staple (a certificate extension) tells browsers to REQUIRE a stapled OCSP response — if absent, reject the connection.
For the exam: standard OCSP > CRL for timeliness, but OCSP Stapling > standard OCSP for both timeliness and reliability.
Performance Task: A company with 500 servers is migrating to internal PKI. Currently all internal services (admin portals, APIs, monitoring) use self-signed certificates, generating browser warnings and requiring employees to manually accept them. Design an internal CA deployment that eliminates the warnings and provides proper certificate lifecycle management.
Model Answer:
Architecture — Two-Tier CA Hierarchy:
Root CA: Offline — kept disconnected from all networks except during maintenance windows. Private key generated and stored on an HSM. Root CA certificate exported and distributed, then Root CA goes offline. Used only to sign the Intermediate CA certificate(s).
Intermediate CA(s): Online — this is the operational CA. Connected to the network and issues all end-entity certificates. Private key in an HSM. If the Intermediate CA is compromised, it can be revoked by the offline Root CA without compromising the root of trust.
Trust distribution:
Export the Root CA certificate (public cert only). Deploy it to all company devices via Group Policy (Windows) or MDM (macOS/mobile) — add to the trusted root certificate store. Once distributed, any certificate signed by the Intermediate CA (which is signed by the Root CA) will automatically be trusted by all company devices. Browser warnings disappear immediately for all 500 servers after they replace self-signed certs with Intermediate CA-signed certs.
Certificate issuance for 500 servers:
Options for scale: (1) Manual CSR/issuance for each server (feasible for 500 with automation scripts). (2) ACME protocol (same protocol Let's Encrypt uses) for fully automated certificate issuance/renewal — internal ACME CA servers like Smallstep or Vault PKI. (3) Auto-enrollment via Group Policy for Windows servers.
Lifecycle management:
- Issue certificates with 1-year validity (aligned with compliance requirements)
- Automate renewal 30 days before expiration using ACME or monitoring with alerting
- Implement CRL endpoint or OCSP responder on the Intermediate CA (internal URL)
- Deploy a certificate inventory system: track every cert, expiration, issuing CA, server, responsible team
- Revocation procedure documented: who can authorize revocation, how to submit the revocation request, what downstream notifications are sent
Security controls:
- Dual-control HSM administration for Root CA and Intermediate CA
- Root CA offline except during quarterly maintenance (renewing Intermediate CA certs, signing new subordinate CAs if needed)
- Audit logging of all certificate issuance and revocations
- Alert on any certificate signed by an unauthorized CA (Certificate Transparency-style monitoring for internal namespaces)
Architecture — Two-Tier CA Hierarchy:
Root CA: Offline — kept disconnected from all networks except during maintenance windows. Private key generated and stored on an HSM. Root CA certificate exported and distributed, then Root CA goes offline. Used only to sign the Intermediate CA certificate(s).
Intermediate CA(s): Online — this is the operational CA. Connected to the network and issues all end-entity certificates. Private key in an HSM. If the Intermediate CA is compromised, it can be revoked by the offline Root CA without compromising the root of trust.
Trust distribution:
Export the Root CA certificate (public cert only). Deploy it to all company devices via Group Policy (Windows) or MDM (macOS/mobile) — add to the trusted root certificate store. Once distributed, any certificate signed by the Intermediate CA (which is signed by the Root CA) will automatically be trusted by all company devices. Browser warnings disappear immediately for all 500 servers after they replace self-signed certs with Intermediate CA-signed certs.
Certificate issuance for 500 servers:
Options for scale: (1) Manual CSR/issuance for each server (feasible for 500 with automation scripts). (2) ACME protocol (same protocol Let's Encrypt uses) for fully automated certificate issuance/renewal — internal ACME CA servers like Smallstep or Vault PKI. (3) Auto-enrollment via Group Policy for Windows servers.
Lifecycle management:
- Issue certificates with 1-year validity (aligned with compliance requirements)
- Automate renewal 30 days before expiration using ACME or monitoring with alerting
- Implement CRL endpoint or OCSP responder on the Intermediate CA (internal URL)
- Deploy a certificate inventory system: track every cert, expiration, issuing CA, server, responsible team
- Revocation procedure documented: who can authorize revocation, how to submit the revocation request, what downstream notifications are sent
Security controls:
- Dual-control HSM administration for Root CA and Intermediate CA
- Root CA offline except during quarterly maintenance (renewing Intermediate CA certs, signing new subordinate CAs if needed)
- Audit logging of all certificate issuance and revocations
- Alert on any certificate signed by an unauthorized CA (Certificate Transparency-style monitoring for internal namespaces)