A primary benefit of a PKI is that it allows two people or entities to communicate securely without knowing each other previously. In other words, it allows them to communicate securely through an insecure public medium such as the Internet. If you’re planning to take the SY0-501 exam, you should have a basic understanding of implementing public key infrastructure. This includes using a certificate that provides the ability to establish a secure session.
For example, can you answer this practice test question?
Q. An organization recently updated its security policy. One change is a requirement for all internal web servers to only support HTTPS traffic. However, the organization does not have funds to pay for this. Which of the following is the BEST solution?
A. Create code signing certificates for the web servers.
B. Create one wildcard certificate for all the web servers.
C. Create a public CA and issue certificates from it.
D. Create certificates signed by an internal private CA.
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 Authority
A Certificate Authority (CA) issues, manages, validates, and revokes certificates. In some contexts, you might see a CA referred to as a Certification Authority, but they are the same thing. CAs can be very large, such as Comodo or Symantec, which are public CAs. A CA can also be very small, such as a single service running on a server within a private network.
Public CAs make money by selling certificates. For this to work, the public CA must be trusted. If the CA is trusted, all certificates issued by the CA are trusted.
This is similar to how a driver’s license is trusted. The Department of Motor Vehicles (DMV) issues driver’s licenses after validating a person’s identity. If you want to cash a check, you might present your driver’s license to prove your identity. Businesses trust the DMV, so they trust the driver’s license. On the other hand, if you purchased an ID from Gibson’s Instant IDs, businesses might not trust it.
Although we might trust the DMV, why would a computer trust a CA? The answer is based on the certificate trust path.
Registration and CSRs
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 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. The CSR includes the public key, but not the private key. A CA typically publishes a certificate template showing exactly how to format the CSR.
After receiving the CSR, 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 purchase it.
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.
Certificates use object identifiers (OIDs) to identify specific objects within the certificates and some CAs require OIDs within the CSR for certain items. The OID is a string of numbers separated by dots. OIDs can be used to name almost every object type in certificates.
As an example, while looking at a Google certificate, I noticed a certificate with this OID on the General tab, 1.3.6.1.4.1.11129.2.5.1:
• The first 1 indicates that it is an International Organization for Standardization (ISO) OID.
• 1.3 indicates it is an identified organization.
• 1.3.6.1.4.1 indicates it is using an IANA enterprise number.
• 1.3.6.1.4.1.11129 indicates the organization is Google.
• The additional numbers (2.5.1) are specifically defined within Google’s enterprise.
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.
If the CA is online, meaning it is accessible over a network, it’s possible to submit the CSR using an automated process. However, an organization may choose to keep some CAs offline to protect them from attacks. Offline CAs can only accept CSRs manually.
Revoking Certificates
Normally, certificates expire based on the Valid From and Valid To dates. However, there are some instances when a CA will revoke a certificate before it expires.
For example, if a private key is publicly available, the key pair is compromised. It no longer provides adequate security because the private key is no longer private. Similarly, if the CA itself is compromised through a security breach, certificates issued by the CA may be compromised, so the CA can revoke certificates.
In general, any time a CA does not want anyone to use a certificate, the CA revokes it. Although the most common reasons are due to compromise of a key or the CA, there are others. A CA can use any of the following reasons when revoking a certificate:
• Key compromise
• CA compromise
• Change of affiliation
• Superseded
• Cease of operation
• Certificate hold
CAs use certificate revocation lists (CRLs, pronounced “crill”) to revoke a certificate. The CRL is a version 2 certificate that includes a list of revoked certificates by serial number. For example, the figure shows a copy of a CRL. One of the labs for this chapter shows you how to download and view a CRL.
Q. An organization recently updated its security policy. One change is a requirement for all internal web servers to only support HTTPS traffic. However, the organization does not have funds to pay for this. Which of the following is the BEST solution?
A. Create code signing certificates for the web servers.
B. Create one wildcard certificate for all the web servers.
C. Create a public CA and issue certificates from it.
D. Create certificates signed by an internal private CA.
Answer is D. The best solution is to use certificates signed by an internal private Certificate Authority (CA). This ensures connections use Hypertext Transfer Protocol Secure (HTTPS) instead of HTTP. Even if the organization doesn’t have an internal CA, it is possible to create one on an existing server without incurring any additional costs.
A code signing certificate provides a digital signature for an application or script, not an entire web server.
A wildcard certificate is used for a single domain with multiple subdomains. It is not used for multiple web servers unless they all share the same root domain name, but the scenario doesn’t indicate the web servers share the same root domain name.
You would not create a public CA to support internal private servers. While it is feasible to purchase certificates from a public CA, that would cost money, but the scenario indicates money isn’t available.
See Chapter 10 of the CompTIA Security+: Get Certified Get Ahead: SY0-501 Study Guide for more information on public key infrastructure.
1 thought on “Secure Session Using Certificate”