CompTIA Security+ (SY0-801)
PKI and certificates: CA, CSR, CRL vs OCSP, wildcards
A public key infrastructure (PKI) uses certificate authorities (CAs) to sign certificates that bind a public key to a subject's name. You request a certificate with a certificate signing request (CSR) that carries your public key and name, never your private key. Relying parties check revocation through a periodically issued CRL or through an online OCSP query.
Certificates, CAs and self-signed roots
An X.509 certificate is a data structure that binds a public key to a subject. A trusted CA asserts the binding by signing the certificate.
A self-signed certificate is one where the issuer and subject are the same and the signature verifies with the public key inside the certificate. Root CAs use self-signed certificates to start certification paths.
For server names, RFC 9525 says clients check DNS names in the subject alternative name (subjectAltName) extension, in its dNSName entries.
Requesting a certificate: the CSR
RFC 2986 defines a certification request as a distinguished name, a public key and optional attributes, all signed by the entity requesting the certificate. The CA turns it into an X.509 certificate.
Example: an administrator generates a key pair on a web server, then builds a CSR. The CSR carries the server's public key and subject name and is signed with the server's private key. The private key never leaves the server.
Revocation: CRL versus OCSP
A certificate revocation list (CRL) is a time-stamped, CA-signed list of revoked serial numbers. RFC 5280 says a new CRL is issued on a regular schedule, such as hourly, daily or weekly, so a revocation may not reach relying parties until the next CRL.
Online checking reduces that delay. With OCSP (RFC 6960), a client asks a responder about one certificate and gets good, revoked or unknown. A certificate on hold (reason certificateHold) is reported as revoked; RFC 6960 treats hold as a temporary revocation.
Clients can add a nonce to OCSP requests and require the same nonce in the response, which stops an attacker replaying an old response.
Wildcard certificates
A wildcard can only be the whole left-most label, and it matches exactly one label. RFC 9525 says wildcard certificates cover single-label host names in their domain, not multiple levels.
Example: *.dev.example.com covers api.dev.example.com and web.dev.example.com. It does not cover a.b.dev.example.com, and *.example.com does not cover api.dev.example.com.
Where the exam catches people
- Believing a CSR includes the private key: it carries the public key and subject name and is only signed with the private key, which stays with the requester.
- Believing a CRL shows revocations immediately: CRLs are issued on a schedule; OCSP gives current status on each query.
- Believing a certificate on hold returns "unknown" in OCSP: the responder returns "revoked" with reason certificateHold.
- Believing *.example.com covers api.dev.example.com: a wildcard matches one label only.
- Believing a self-signed certificate that verifies with its own key is trustworthy: that check shows only that the certificate was not altered, not who issued it.