CompTIA Security SY0-601 Exam: Basics of Public Key Infrastructure

Objective: Given a scenario, implement public key infrastructure.

Topics:
- public key infrastructure (PKI)
- digital certificate
- key management
- certificate authority (CA)
- intermediate CA
- registration authority (RA)
- certificate revocation list (CRL)
- Online Certificate Status Protocol (OCSP)
- certificate signing request (CSR)
- distinguished encoding rules (DER)
- privacy enhanced mail (PEM)
- personal information exchange (PFX)
- stapling
- pinning
- trust model
- key escrow
- certificate chaining

PKI Components
To begin to understand the applications and deployment of a public key infrastructure (PKI), you should understand the various pieces that make up a PKI. A PKI is a vast collection of varying technologies and policies for the creation and use of digital certificates. A PKI encompasses certificate authorities, digital certificates, and a variety of tools, systems, and processes. As previous guides show, digital certificates are a critical component in providing secure systems. For example, “Authentication and Authorization Solutions,” you learned that many implementations of EAP in wireless networks require digital certificates to verify the identity of the client or server. Digital signatures are digitally signed data blocks, and they provide several potential functions but most notably are used for identification and authentication purposes. The requirement for certificates adds complexity. This guide discusses how these certificates are generated and managed.
The basic concepts of public and private keys that you learned about in, “Cryptographic Concepts,” play an important role in PKI. This infrastructure makes use of both types of keys and lays a foundation for binding keys to an identity via a certificate authority (CA). This gives the system a way to securely exchange data over a network using an asymmetric key system. For the most part, this system consists of digital certificates and the CAs that issue the certificates. These certificates identify individuals, systems, and organizations that have been verified as authentic and trustworthy.
Recall that symmetric key cryptography requires a key to be shared. For example, suppose the password to get into the clubhouse is “open sesame.” At some point in time, this key or password needs to be communicated to other participating parties before it can be implemented. PKI provides confidentiality, integrity, and authentication by overcoming this challenge. With PKI, it is not necessary to exchange the password, key, or secret information in advance. This is useful when involved parties have no prior contact or when exchanging a secure key is neither feasible nor secure.

PKI is widely used to provide secure infrastructure for applications and networks, including access control, resources from web browsers, and secure email. PKI protects information by providing the following:
- Identity authentication
- Integrity verification
- Privacy assurance
- Access authorization
- Transaction authorization
- Nonrepudiation support
A public key infrastructure consists of technologies and policies for the creation and use of digital certificates.

Certificate Authority (CA)
Certificate authorities (CAs) are trusted entities and an important concept related to PKI. An organization can use third-party CAs, and it can also establish its own CA, typically for use only within the organization. A CA’s job is to issue certificates, verify the holder of a digital certificate, and ensure that holders of certificates are who they claim to be. A common analogy for a CA is a passport-issuing authority. To obtain a passport, you need the assistance of someone else (for example, a customs office) to verify your identity. Passports are trusted because the issuing authority is trusted.
Registration authorities (RAs) provide authentication to the CA on the validity of a client’s certificate request; in addition, an RA serves as an aggregator of information. For example, a user contacts an RA, which then verifies the user’s identity before issuing the request of the CA to go ahead and issue a digital certificate.
A CA is responsible for issuing certificates. Remember that an RA initially verifies a user’s identity and then passes along to the CA the request to issue a certificate to the user.

CAs follow a chained hierarchy, or certificate chain, when verifying digital certificates, to form what’s known as a chain of trust. Starting with a trust anchor, known as the root CA, certificates are trusted transitively through one or many certificates within the chain. Here is an example of certificate chaining:
The root certificate verifies certificate A.
Certificate A verifies certificate B.
Certificate B verifies certificate C.

This also works in reverse:
Certificate C references certificate B.
Certificate B references certificate A.
Certificate A references the root certificate.

Certification Practice Statement
A certification practice statement (CPS) is a legal document that a CA creates and publishes for the purpose of conveying information to those who depend on the CA’s issued certificates. The information within a CPS provides for the general practices the CA follows in issuing certificates and customer-related information about certificates, responsibilities, and problem management. It is important to understand that these statements are described in the context of operating procedures and system architecture. Certificate policies, on the other hand, indicate the rules that apply to an issued certificate. A CPS includes the following items:
- Identification of the CA
- Types of certificates issued and applicable certificate policies
- Operating procedures for issuing, renewing, and revoking certificates
- Technical and physical security controls that the CA uses

Trust Models
Certificate authorities in a PKI follow several trust models or architectures. The simplest model is the single-CA architecture, in which only one CA exists to issue and maintain certificates. This model might benefit smaller organizations because of its administrative simplicity, but it can present many problems. For example, if the CA fails, no other CA can quickly take its place. Another problem can arise if the private key of the CA becomes compromised; in this scenario, all the issued certificates from that CA would be invalid. A new CA would have to be created, and the new CA would need to reissue all the certificates.
A more common model—and one that reduces the risks inherent with a single CA—is the hierarchical CA trust model. In this model, an initial root CA exists at the top of the hierarchy, and subordinate CAs, or intermediate CAs, reside beneath the root. The subordinate CAs provide redundancy and load balancing in the event that any of the other CAs fail or need to be taken offline. Because of this model, you might hear PKI referred to as a trust hierarchy. An intermediate CA has a certificate that is issued by the trusted root. This certificate is issued so the intermediate CA can issue certificates for others. This results in a trust chain that begins at the trusted root CA, goes through the intermediate, and ends with the SSL certificate issued to a server with which you are interacting.
A root CA differs from subordinate CAs in that the root CA is usually offline. Remember that if the root CA is compromised, the entire architecture is compromised. If a subordinate CA is compromised, however, the root CA can revoke the subordinate CA.
An alternative to this hierarchical model is the cross-certification model, often referred to as a web of trust. In this model, CAs are considered peers to each other. Such a configuration, for example, might exist at a small company that started with a single CA. As the company grew, it continued to implement other single-CA models and then decided that each division of the company needed to communicate with the others. To achieve secure exchange of information across the company, each CA established a peer-to-peer trust relationship with the others. As you might imagine, such a configuration could become difficult to manage over time.
The root CA should be taken offline to reduce the risk of key compromise. It should be made available only to create and revoke certificates for subordinate/intermediate CAs. A compromised root CA compromises the entire system.
A solution to the complexity of a large cross-certification model is to implement a bridge CA model. Remember that, in the cross-certification model, each CA must trust the others. By implementing bridging, however, you can have a single CA, known as the bridge CA, serve as the central point of trust.
Certificates rely on a hierarchical chain of trust. If a CA’s root key is compromised, any keys issued by that CA are compromised as well.

Key Escrow
Key escrow occurs when a CA or another entity maintains a copy of the private key associated with the public key signed by the CA. This scenario allows the CA or escrow agent to have access to all information encrypted using the public key from a user’s certificate and to create digital signatures on behalf of the user. Therefore, key escrow is a sensitive topic in the PKI community. Harmful results might occur if the private key is misused. Because of this issue, key escrow is not a favored PKI solution.
Despite public concerns about escrow for private use, key escrow is often considered a good idea in corporate PKI environments. In most cases, an employee of an organization is bound by the information security policies of that organization (which usually mandate that the organization has a right to access all intellectual property generated by a user and to any data that an employee generates). In addition, key escrow enables an organization to overcome the large problem of forgotten passwords. Instead of revoking and reissuing new keys, an organization can generate a new certificate using the private key stored in escrow.
Key escrow is used for third-party custody of a private key.

Digital Certificate
A digital certificate is a digitally signed block of data that allows public key cryptography to be used for identification purposes. The most common types of certificates are the SSL or TLS certificates used on the Web. Essentially, these certificates ensure secure communications, which occur when a website uses https:// instead of just http:// in the browser address bar, accompanied by a closed padlock.

CAs issue these certificates, which are signed using the CA’s private key. Most certificates are based on the X.509 standard. Although most certificates follow the X.509 Version 3 hierarchical PKI standard, the PGP key system uses its own certificate format. X.509 certificates to be signed contain the following fields:
- Version Number: This field identifies the version of the X.509 standard that the certificate complies with.
- Serial Number: The CA that creates the certificate is responsible for assigning a unique serial number.
- Signature Algorithm Identifier: This field identifies the cryptographic algorithm used by the CA to sign the certificate. An object identifier (OID) is used. An OID is a hierarchical globally unique identifier for an object.
- Issuer Name: This field identifies the directory name of the entity signing the certificate, which is typically a CA.
- Period of Validity: This field identifies the time frame for which the private key is valid, if the private key has not been compromised. This period is indicated with both a start time and an end time; it can be of any duration, but it is often set to 1 year.
- Subject or owner name: This field is the name of the entity that is identified in the public key associated with the certificate. This name uses the X.500 standard for globally unique naming and is often called the distinguished name (DN) (for example, CN=Sri Puthucode, OU=Sales, O=CompTIA, C=US).
- Subject or Owner’s Public Key: This field includes the public key of the entity named in the certificate, in addition to a cryptographic algorithm identifier and optional key parameters associated with the key.
- Extensions: This field optionally provides methods in X.509 Version 3 certificates to associate additional attributes. This field must not be present in previous versions. Common extensions include specific key usage requirements, such as allowing the public key of the certificate to be used only for certificate signing.
- Signature Value: This value provides the computed digital signature from the signed certificate’s body, used as an input. The signature ensures the validity of the certificate.

You likely have used the most common application of digital certificates: Websites that ask for personal information, especially credit card information, use digital certificates. (Not necessarily all of them use digital certificates, but they should.) The traffic from your computer to the website is secured using Secure Sockets Layer (SSL)/Transport Layer Security(TLS), and the web server uses a digital certificate for the secure exchange of information, as indicated by a small padlock located in the status bar or address bar of most browsers. By clicking this icon, you can view the digital certificate and its details.
Remember the components of an X.509 certificate. You might be required to recognize the contents of a certificate.

The figure below provides an example of a digital certificate that appears when you click the lock icon in the browser address bar.



Details of a digital certificate

Specifically, note that the certificate applies to www.example.org, including any subdomains, and note that this certificate is chained to an intermediary CA’s certificate (DigiCert SHA2 Secure Server CA), which is chained to the root CA’s certificate (DigiCert Global Root CA). Next, note the different fields, many of which are described in the preceding list.

Public and Private Key Usage
Digital certificates and key pairs can be used for various purposes, including privacy and authentication. The security policy of an organization that is using a key or the CA defines the purposes and capabilities for the certificates issued.
To achieve privacy, users need the public key of the individual or entity they want to communicate with securely. This public key is used to encrypt the data that is transmitted, and the corresponding private key is used on the other end to decrypt the message.
You can obtain another’s public key (which is freely available to anyone) and use it to encrypt a message to that person. As a result, that person can use his or her private key, which no one else has, to decrypt the message. The public and private keys are mathematically related.
Authentication is achieved by digitally signing the message being transmitted. To digitally sign a message, the signing entity requires access to the private key.
In short, the key usage extension of the certificate specifies how the private key can be used—either to enable the exchange of sensitive information or to create digital signatures. In addition, the key usage extension can specify that an entity can use the key both for the exchange of sensitive information and for signature purposes.
In some circumstances, dual or multiple key pairs might be used to support distinct and separate services. For example, an individual in a corporate environment might require one key pair just for signing and another just for encrypting messages. Another example is a reorder associate who has one key pair to use for signing and sending encrypted messages and another one that is restricted to ordering equipment worth no more than a specific dollar amount. Multiple key pairs require multiple certificates because the X.509 certificate format does not support multiple keys.

Certificate Signing Request
To install a digital certificate, a specific request needs to be generated and submitted to the CA. The applicant applies to the CA for a digital certificate known as a certificate signing request (CSR). Included within the request is the applicant’s public key, along with information about the applicant such as the following:
- Fully qualified domain name
- Legally incorporated name of the company
- Department name
- City, state, and country
- Email address
Before submitting a CSR, the applicant generates a key pair consisting of a public key and a private key. The public key is provided with the request, and the applicant signs the request with the private key. If all is successful, the CA returns a digital certificate that is signed with the CA’s private key.

Certificate Policy
A certificate policy indicates specific uses applied to a digital certificate and other technical details. Not all certificates are created equal. Digital certificates that are issued often follow different practices and procedures and are issued for different purposes. The certificate policy provides the rules that indicate the purpose and use of an assigned digital certificate. For example, one certificate might have a policy indicating its use for electronic data interchange to conduct e-commerce, whereas another certificate might be issued to digitally sign documents.

Remember that a certificate policy identifies the purpose for which a certificate can be used. In addition, other types of information can be included within a certificate policy:
- Legal issues often used to protect the CA
- Mechanisms for how the CA will authenticate users
- Key management requirements
- Instructions for what to do if the private key is compromised
- Lifetime of the certificate
- Certificate enrollment and renewal
- Rules regarding exporting the private key
- Private and public key minimum lengths
The applicant’s public key is submitted along with the CSR.

Certificate Types
Three types of validated TLS certificates exist, each with its own level of trust:
- Domain validation (DV): This type of certificate includes only the domain name. DV certificates can easily be issued, just as a domain name lookup can easily be performed against whois, a database of registered domains. DV certificates are inexpensive and can be acquired quickly, so if trust is important or if a public-facing website is desired, organizations should consider another type of validated certificate.
- Organizational validation (OV): This certificate type provides stronger assurance than a DV certificate as organizations are vetted against official government sources; the OV certificate is therefore a common certificate type for many public-facing websites. Unlike with a DV certificate, OV certificates verification requires a more manual review and verification process; this can take days to process.
- Extended validation (EV): This certificate type provides a high level of trust and security features. EV certificates are easily identified as the business name in the address bar is green. EV certificates are designed to provide assurance against phishing attacks. As the name implies, this certificate type requires a comprehensive validation of the business, which can take up to a couple weeks to acquire.
DV certificates are the quickest and least expensive certificates to acquire. EV certificates can take a couple weeks and are the most expensive, but they also provide the highest level of trust.

You should also be familiar with the following special certificates:
- Wildcard: This certificate provides any number of subdomains for a single registered domain. The name for the certificate thus might look like *.example.com, which would be valid for www.example.com, sub.example.com, and so on.
- SAN: This type of certificate takes advantage of the subject alternate name (SAN) extension. It provides for the use of multiple domain names or even IP addresses within a single certificate. This certificate is also known as a unified communications (UC) certificate.
- Code signing: This type of certificate is required to digitally sign software packages. It provides assurance that the software is authentic and has not been tampered with.
- Self-signed: Self-signed certificates are often used for testing purposes or when trust is not a concern. Certificates are typically signed by another entity or CA. When a web browser recognizes that a certificate is a self-signed certificate, it provides an alert to the user that the connection is not trusted.
- Email: This type of certificate is also known as an S/MIME (Secure/Multipurpose Internet Mail Extensions) certificate. An email certificate is required to digitally sign or encrypt email messages.
- Root signing: A root signing certificate is usually provided by a recognized CA. Organizations with a root signing certificate thus can sign for themselves any number of certificates. These certificates, in turn, are trusted by those outside the organization because web browsers include, by default, many trusted certificates for recognized CAs. For example, an organization that wants to run its own CA in-house, particularly when trust needs to be extended outside the organization, should purchase a root signing certificate.
- User: Known also as a client certificate, a user certificate identifies an individual. Just as a website’s TLS certificate authenticates the website to a particular user, a user certificate can authenticate a user to a remote server. This works much the way a password works.
- Machine/computer: Much like a user certificate, a machine/computer certificate authenticates a client system. This type is primarily used with machine-to-machine communications.
Given a scenario, be able to identify the types of certificates.

Certificate Formats
Certificates can have various file extension types. Some, but not all, extension types are interchangeable. Be sure to determine whether a certificate is binary or Base64 ASCII encoded. 

Summary of Common Certificate Formats:

The most common format and extension for certificates is privacy enhanced mail (PEM), which is mostly associated with Apache web servers. The PEM format is a Base64 ASCII-encoded text file, which makes copying the contents from one document to another simple. A PEM file might contain several certificates and private keys within a single file, although having each component (that is, each certificate and key) as its own file is common. A single certificate includes the header BEGIN CERTIFICATE, preceded and followed by five dashes, and the footer END CERTIFICATE, preceded and followed by five dashes. A single private key includes the header BEGIN ENCRYPTED PRIVATE KEY, preceded and followed by five dashes, and the footer END ENCRYPTED PRIVATE KEY, preceded and followed by five dashes. In addition to the .pem file extension, .crt, .cer, and .key extensions can be used. However, .key is typically used when the file contains only the private key.
Another Base64-encoded certificate format is P7B, also known as PKCS#7. This format uses the .p7b or .p7c file extension, which is commonly supported on the Windows operating system and Java Tomcat. This format includes the header BEGIN PKCS7 and the footer END PKCS7, each of which is preceded and followed by five dashes.
The binary form of a PEM certificate is a distinguished encoding rules (DER) certificate. In addition to the .der extension, .cer and .crt extensions can be used for DER-encoded certificates. DER-encoded certificates are common on Java platforms.
Another binary certificate format is PFX, also known as PKCS#12. Extensions for personal information exchange (PFX)–encoded certificates include .pfx and .p12. This type of certificate is common to the Windows operating system for importing and exporting certificates and private keys. PFX supports a private key, and one or more certificates can be stored within a single binary file.

The table above provides an overview of the certificate formats.
DER and PFX certificates are binary encoded and cannot be edited with a plaintext editor, as the Base64 ASCII–encoded PEM and P7B certificates can.

Certificate Revocation
Digital certificates can be revoked. Revoking a certificate invalidates a certificate before its expiration date. A digital certificate contains a field indicating the date until which the certificate is valid. This date is mandatory, and the validity period can vary from a short period of time up to several years. Revocation can occur for several reasons. For example, a private key might become compromised, the private key might be lost, or the identifying credentials might no longer be valid. Other reasons for revocation include fraudulently obtained certificates or a change in the holder’s status, which could indicate less trustworthiness.

Revoking a certificate is just not enough. The community that trusts this certificate must be notified that the certificate is no longer valid. This is accomplished via either of the following mechanisms:
- CRL: The certificate revocation list (CRL) is a mechanism for distributing certificate revocation information. A CRL is used when verification of the digital certificate takes place to ensure the validity of the digital certificate. A limitation of CRLs is that they must be constantly updated at least every two weeks; otherwise, certificates might be accepted despite having been recently revoked.
- OCSP: Online Certificate Status Protocol (OCSP) is a newer mechanism for identifying revoked certificates. OCSP checks certificate status in real time online instead of relying on the end user to have a current copy of the CRL.

Both OCSP and CRLs are used to verify the status of a certificate. Three basic status levels exist in most PKI solutions: valid, suspended, and revoked. You can check the status of a certificate by going to the CA that issued the certificate or to an agreed-upon directory server that maintains a database indicating the status level for the set of certificates. In most cases, however, the application (such as a web browser) has a function available that initiates a check for certificates.
When a certificate has expired, the client is likely to receive an error message saying that the website cannot be trusted. In some situations, users may not have the correct root certificates installed into their web browsers.

OCSP Stapling
Although OCSP provides for real-time status checking, it requires the CA to respond to every client request to validate a site’s certificate. High-traffic websites burden the CA with these requests because they need to respond to a potentially overwhelming number of certificate validity requests. A mechanism known as OCSP stapling helps reduce this load by allowing the web server to instead “staple” a time-stamped OCSP response as part of the TLS handshake with the client. The web server is then responsible for handling OCSP requests (instead of the CA). The OCSP stapling process involves the following steps:

A TLS-encrypted web server presents its certificate to the CA to check the validity.
The CA responds with the certificate status, including a digitally signed time stamp.
The web server staples the CA’s signed time stamp to the certificate when a client web browser connects.
The client web browser verifies the signed time stamp.
OCSP stapling provides several benefits. First, it improves the performance of the secure connection. Next, privacy concerns are reduced because the end user’s browser does not need to potentially contact a third-party CA to verify the certificates and reveal the browsing history. Finally, reliability is improved. If the client were unable to connect to an overburdened CA, for example, the client would otherwise accept a potentially invalid certificate—or simply end the connection.
Using CRLs is not as efficient as OCSP. The lists need to be frequently updated and are not reliable if they are outdated.
Before a certificate is revoked, it might be suspended. Certificate suspension occurs when a certificate is under investigation to determine whether it should be revoked. This mechanism allows a certificate to stay in place, although it is not valid for any type of use. Users and systems are notified of suspended certificates. New credentials do not need to be retrieved, however; it is only necessary to be notified that current credentials have had a change in status and are temporarily not valid for use.

Pinning
Certificate pinning extends beyond certificate validation (discussed earlier in this guide) to thwart man-in-the-middle attacks. Hashes of public keys for popular web servers are built into applications such as web browsers. A similar (though now deprecated) variation, known as HTTP Public Key Pinning (HPKP), used public key pins, which are essentially hashed values of the public key communicated to the browser client from the server in the HTTP header. After obtaining the server certificate, the client verified the public key against the hash of the public key.

Quiz questions:
1. Your organization has established a hierarchical PKI and deployed several CAs in the process. Which one of the following steps should your organization be sure to take? A. Take the root CA offline. B. Take all subordinate CAs offline. C. Take the root CA online. D. Take all subordinate CAs online with the exception of the intermediates.
2. What type of key goes into key escrow? A. Public B. Shared C. Private D. Session
3. Your organization has developed a custom application that requires a check for the validity of digital certificates even when the Internet is not available. Which of the following meets this requirement? A. CRL B. OCSP C. SAN D. CPS
4. Which of the following types of certificates allows you to digitally sign and encrypt email messages and attachments? A. DER B. PFX C. Self-signed D. S/MIME

Answer 1: A. Best practice is to take the root CA offline to reduce the risk of compromise of the entire PKI; thus, answer C is incorrect. Answer B is incorrect because the subordinate CAs are signed by the root CA and should not be taken offline as they need to manage requests. Although subordinate CAs should be online, Answer D is incorrect as it suggests taking the intermediates offline, which are the same as the subordinates.
Answer 2: C. Confidential secret or private keys go into key escrow. Public keys are known and have no need for escrow, so answer A is incorrect. A shared key or session key (for single use) is a key that performs both encryption and decryption and would not be usable if left in key escrow. Answers B and D are incorrect.
Answer 3: A. CRL provides a mechanism to ensure the validity of digital certificates by using a list that must be updated every two weeks. Answer B is incorrect. While OCSP also checks for certificate validity, it works in real time and requires Internet access. Answer C is incorrect because SAN is a type of certificate that takes advantage of the subject alternate name extension. A CPS is a legal document that a CA creates and publishes, so Answer D is incorrect.
Answer 4: D. S/MIME (Secure/Multipurpose Internet Mail Extensions) is a protocol that allows you to encrypt email messages and attachments and digitally sign them. Answers A and B are incorrect because distinguished encoding rules (DER) and personal information exchange (PFX) are certificate formats/extensions. Answer C is incorrect because self-signed certificates are often used for testing purposes or when trust is not a concern.