A certificate provides the ability to establish a secure session but there are many different certificate issues that can result in an invalid certificate. If you’re planning to take the SY0-501 version of the Security+ exam, you should have a good understanding of implementing a public key infrastructure. A key element in a PKI is a Certificate Authority.
For example, can you answer this question?
Q. A web site is using a certificate. Users have recently been receiving errors from the web site indicating that the web site’s certificate is revoked. Which of the following includes a list of certificates that have been revoked?
A. CRL
B. CA
C. OCSP
D. CSR
More, do you know why the correct answer is correct and the incorrect answers are incorrect? The answer and explanation are available at the end of this post.
Certificate Issues
Before clients use a certificate, they first verify it is valid with some checks. There are many different certificate issues that can result in an invalid certificate. Browsers typically display an error describing the issue and encouraging users not to use the certificate. Applications that detect a certificate issue might display an error using a certificate, but they are typically coded to not use it. Some of the common issues are:
• Expired. The first check is to ensure that it isn’t expired. If the certificate is expired, the computer system typically gives the user an error indicating the certificate is not valid.
• Certificate not trusted. The next check is to see if the certificate was issued by a trusted CA. For example, a Windows system will look in the Trusted Root Certification Authority store and the Intermediate Certification Authorities store. If the system doesn’t have a copy of the CA’s certificate, it will indicate the certificate is not trusted. Users can override this warning, though there are often warnings encouraging users not to continue.
• Improper certificate and key management. Private keys should remain private. They are typically stored in an encrypted format and never shared publicly. If the certificates holding the private keys aren’t managed properly, it can compromise the certificate.
Clients also validate certificates through the CA to ensure they haven’t been revoked. First, they verify that the certificate was issued by a trusted CA. Next, they query the CA to verify the CA hasn’t revoked the certificate. A common method of validating a certificate is by requesting a copy of the CRL, as shown in the figure. The following steps outline the process:
1. The client initiates a session requiring a certificate, such as an HTTPS session.
2. The server responds with a copy of the certificate that includes the public key.
3. The client queries the CA for a copy of the CRL.
4. The CA responds with a copy of the CRL.
Validating a certificate
The client then checks the serial number of the certificate against the list of serial numbers in the CRL. If the certificate is revoked for any reason, the application gives an error message to the user.
CRLs are typically cached after being downloaded the first time. Instead of requesting another copy of the CRL, clients use the cached copy. This generates a lot of traffic between clients and the CA.
Another method of validating a certificate is with the Online Certificate Status Protocol (OCSP). OCSP allows the client to query the CA with the serial number of the certificate. The CA then responds with an answer of “good,” “revoked,” or “unknown.” A response of “unknown” could indicate the certificate is a forgery.
Because OCSP provides a real-time response, it is an excellent example of supporting a common use case of low latency. If a CA revokes a certificate, clients using OCSP will know immediately. In contrast, if clients are using a cached CRL, they will be unaware of the revoked certificate until another copy of the CRL is downloaded.
Over time, authorities realized that OCSP was generating a lot of real-time traffic to the CA because it requires a CA to respond to every request. OCSP stapling solves this problem. The certificate presenter (such as the web server in the figure) obtains a timestamped OCSP response from the CA. Before sending it, the CA signs it with a digital signature. The certificate presenter then appends (or metaphorically staples) a timestamped OCSP response to the certificate during the TLS handshake process. This eliminates the need for clients to query the CA.
Remember this
CAs revoke certificates for several reasons such as when the private key is compromised or the CA is compromised. The certificate revocation list (CRL) includes a list of revoked certificates and is publicly available. An alternative to using a CRL is the Online Certificate Status Protocol (OCSP), which returns answers such as good, revoked, or unknown. OCSP stapling appends a digitally signed OCSP response to a certificate.
Q. A web site is using a certificate. Users have recently been receiving errors from the web site indicating that the web site’s certificate is revoked. Which of the following includes a list of certificates that have been revoked?
A. CRL
B. CA
C. OCSP
D. CSR
Answer is A. A certificate revocation list (CRL) is a list of certificates that a Certificate Authority (CA) has revoked.
The CA stores a database repository of revoked certificates and issues the CRL to anyone who requests it.
The Online Certificate Status Protocol (OCSP) validates trust with certificates, but only returns short responses such as good, unknown, or revoked.
A certificate signing request (CSR) is used to request certificates.
See Chapter 10 of the CompTIA Security+: Get Certified Get Ahead: SY0-501 Study Guide for more information on public key infrastructure components.