If you’re planning on taking the Security+ exam, you should have a basic understanding on how to use a certificate signing request (CSR) when requesting certificates from a CA.
For example, can you answer this question?
Q. You need to submit a CSR to a CA. Which of the following would you do FIRST?
A. Generate a new RSA-based session key.
B. Generate a new RSA-based private key.
C. Generate the CRL.
D. Implement OCSP.
More, do you know why the correct answer is correct and the incorrect answers are incorrect? The answer and explanation is available at the end of this post.
Self-Signed Certificates
It is possible to create a CA and use self-signed certificates. For example, an administrator can use Active Directory Certificate Services (AD CS) on Windows Server to create a CA and issue certificates to company-owned web servers. AD CS is built in to Windows Server products, so this is certainly less expensive than purchasing a certificate from a public CA.
However, certificates issued by this CA will not be trusted by default. If a user connects to this web server and establishes an HTTPS session, the web browser will show an error. Depending on the web browser, it may indicate that the issuer of a certificate (the CA) is not recognized or indicate that the site’s certificate is not trusted. The error is often accompanied with warning icons and other notes encouraging the users not to continue.
This is not acceptable for an e-commerce web site. Imagine if Lisa has her credit card in hand ready to buy a product, and then sees errors indicating trust problems. She very likely won’t continue.
If only employees use this web site, they could ignore the errors and click through to establish the connection. However, this may breed complacency. When they go to a public site and see this same type of error, they may ignore the error and continue.
Instead, an administrator can copy the CA’s root certificate to the user’s computer. Web browsers will then trust the certificate from the company web site, eliminating the errors.
Registration
Users and systems request certificates from a CA using a registration process. In some cases, a user enters information manually into a web site form. In other cases, a user sends a specifically formatted file to the CA. Within a domain, the system handles much of the process automatically.
As an example, imagine I wanted to purchase a certificate for GetCertifiedGetAhead.com for secure HTTPS sessions. I would first create a public and private key pair. Many programs are available to automate this process. For example, OpenSSL is a command-line program that is included in many Linux distributions. It creates key pairs in one command and allows you to export the public key to a file in a second command. Technically, OpenSSL and similar applications create the private key first. However, these applications appear to create both keys at the same time.
I would then put together a certificate signing request (CSR) for the certificate, including the purpose of the certificate and information about the web site, the public key, and me. Most CAs require CSRs to be formatted using the public-key cryptography standards (PKCS) #10 specification.
I then send the CSR to the CA. The CA validates my identity and creates a certificate with the public key. The validation process is different based on the usage of the certificate. In some cases, it includes extensive checking, and in other cases, verification comes from the credit card I use to pay.
I can then register this certificate with my web site along with the private key. Any time someone initiates a secure HTTPS connection, the web site sends the certificate with the public key and the TLS/SSL session creates the session.
In large organizations, a registration authority (RA) can assist the CA by collecting registration information. The RA never issues certificates. Instead, it only assists in the registration process.
Remember this
You typically request certificates using a certificate signing request (CSR). The first step is to create the RSA-based private key, which is used to create the public key. You then include the public key in the CSR and the CA will embed the public key in the certificate.
Q. You need to submit a CSR to a CA. Which of the following would you do FIRST?
A. Generate a new RSA-based session key.
B. Generate a new RSA-based private key.
C. Generate the CRL.
D. Implement OCSP.
Answer is B. You create the RSA-based private key first and then create the matching public key from it, which you include in the certificate signing request (CSR) that you send to the Certificate Authority (CA).
The RSA algorithm technically creates the private key first, but most applications that create the key pair appear to create them at the same time. A session key is a symmetric key, but RSA is an asymmetric algorithm.
The CA generates the certificate revocation list (CRL) to identify revoked certificates.
Online Certificate Status Protocol (OCSP) is an alternative to using CRLs to validate certificates, but it is not required.