Lesson 5: Implementing a Public Key Infrastructure

Question 1

Digital certificates and public key infrastructure (PKI)

Answer 1

critical to manage identification, authentication, and data confidentiality across most private and public networks. This infrastructure is critical to the security of most data processing systems, so it is important that you be able to apply effective management principles when configuring and supporting these systems.

Everything from encrypted communications within a company’s private network, to the encrypted communications of the global Internet, are wrapped up in public key infrastructures (PKI). The basic building blocks of PKI include digital certificates and certificate authorities.

Public key cryptography solves the problem of distributing encryption keys when you want to communicate securely with others or authenticate a message that you send to others.

The basic problem with public key cryptography is that you may not really know with whom you are communicating. The system is vulnerable to Man-in-the-Middle attacks.

Public Key Infrastructure (PKI) aims to prove that the owners of public keys are who they say they are. Under PKI, anyone issuing public keys should obtain a digital certificate. The validity of the certificate is guaranteed by a certificate authority (CA). The validity of the CA can be established using various models

Question 2

digital certificate

Answer 2

A digital certificate is essentially a wrapper for a subject’s public key. As well as the public key, it contains information about the subject and the certificate’s issuer or guarantor. The certificate is digitally signed to prove that it was issued to the subject by a particular CA. The subject could be a human user (for certificates allowing the signing of messages, for instance) or a computer server (for a web server hosting confidential transactions, for instance).

Digital certificates are based on the X.509 standard approved by the International Telecommunications Union. This standard is incorporated into the Internet Engineering Taskforce’s RFC 5280 (http://tools.ietf.org/html/rfc5280) and several related RFCs.

Question 3

Public Key Infrastructure (PKIX) working group

Answer 3

The Public Key Infrastructure (PKIX) working group manages the development of these standards. RSA also created a set of standards, referred to as Public Key Cryptography Standards (PKCS), to promote the use of public key infrastructure.

Question 4

certificate fields

Answer 4

The certificate fields are expressed as object identifiers (OIDs), using the syntax defined in Abstract System Notation One (ASN.1).

example:
The X.509 standard defines the fields (information) that must be present in the certificate. The standard provides interoperability between different vendors.

Question 5

Certificate extensions

Answer 5

defined for version 3 of the X.509 format, allow extra information to be included about the certificate.

Question 6

extension

Answer 6

An extension consists of:

• Extension ID (extnID)—expressed as an OID.
• Critical—a Boolean (True or False) value indicating whether the extension is critical.
• Value (extnValue)—the string value of the extension.

Public certificates can use standard extensions; that is, an OID defined in the X.509 documentation, which all clients should support. Certificates issued for private use can use private, proprietary, or custom extensions, but may need dedicated or adapted client and server software to interpret them correctly.

Question 7

Key Usage

Answer 7

One of the most important standard extensions is Key Usage. This extension defines the purpose for which a certificate was issued, such as for signing documents or key exchange.

The Extended Key Usage (EKU) field—referred to by Microsoft® as Enhanced Key Usage—is a complementary means of defining usage. Typical values used include Server Authentication, Client Authentication, Code Signing, or Email Protection. The EKU field is more flexible than the Key Usage field, but problems can occur when non-standard or vendor-specific OIDs are used.

An extension can be tagged as critical. This means that the application processing the certificate must be able to interpret the extension correctly; otherwise, the certificate should be rejected. In the case of a Key Usage extension marked as critical, an application should reject the certificate if it cannot resolve the Key Usage value. This prevents a certificate issued for signing a CRL, for example, from being used for signing an email message. If Key Usage is not marked as critical, it effectively serves as a comment, rather than controlling the certificate in any way.

Question 8

Distinguished Encoding Rules (DER)

Answer 8

There are various formats for encoding a certificate as a digital file for exchange between different systems. All certificates use an encoding scheme called Distinguished Encoding Rules (DER) to create a binary representation of the information in the certificate. A DER-encoded binary file can be represented as ASCII characters using Base64 Privacy-enhanced Electronic Mail (PEM) encoding. The file extensions .CER and .CRT are also often used, but these can contain either binary DER or ASCII PEM data.

Question 9

.PFX or .P12 (PKCS #12) certificate format

Answer 9

the .PFX or .P12 (PKCS #12) format allows the export of a certificate along with its private key. This would be used to archive or transport a private key. This type of file format is password-protected. The private key must be marked as exportable.

Question 10

P7B certificate format

Answer 10

implements PKCS #7, which is a means of bundling multiple certificates in the same file. It is typically in ASCII format. This is most often used to deliver a chain of certificates that must be trusted by the processing host. It is associated with the use of S/MIME to encrypt email messages. P7B files do not contain the private key.

Question 11

certificate authority (CA)

Answer 11

the person or body responsible for issuing and guaranteeing certificates. Private CAs can be set up within an organization for internal communications. Most network operating systems, including Windows Server®, have certificate services. For public or business-to-business communications, however, the CA must be trusted by each party. Third-party CA services include Comodo, Digicert, GlobalSign, and Symantec’s family of CA brands (VeriSign, GeoTrust, RapidSSL, and Thawte). The functions of a CA are as follows:

• Provide a range of certificate services useful to the community of users serviced by the CA.
• Ensure the validity of certificates and the identity of those applying for them (registration).
• Establish trust in the CA by users and government and regulatory authorities and enterprises, such as financial institutions.
• Manage the servers (repositories) that store and administer the certificates.
• Perform key and certificate lifecycle management.

Question 12

Registration

Answer 12

the process by which end users create an account with the CA and become authorized to request certificates. The exact processes by which users are authorized and their identity proven are determined by the CA implementation. For example, in a Windows Active Directory® network, users and devices can often auto-enroll with the CA just by authenticating to Active Directory. Commercial CAs might perform a range of tests to ensure that a subject is who he or she claims to be. It is in the CA’s interest to ensure that it only issues certificates to legitimate users or its reputation will suffer.

Note: On a private network (such as a Windows domain), the right to issue certificates of different types must be carefully controlled. The Windows CA supports access permissions for each certificate type so that you can choose which accounts are able to issue them.

Question 13

Certificate Signing Request (CSR)

Answer 13

When a subject wants to obtain a certificate, it completes a Certificate Signing Request (CSR) and submits it to the CA. The CSR is a Base64 ASCII file containing the information that the subject wants to use in the certificate, including its public key. The format of a CSR is based on the PKCS#10 standard.

The CA reviews the certificate and checks that the information is valid. For a web server, this may simply mean verifying that the subject name and FQDN are identical and verifying that the CSR was initiated by the person administratively responsible for the domain, as identified in the domain’s WHOIS records. If the request is accepted, the CA signs the certificate and sends it to the subject.

The registration function may be delegated by the CA to one or more registration authorities (RAs). These entities complete identity checking and submit CSRs on behalf of end users, but they do not actually sign or issue certificates.

Question 14

Certificate policies

Answer 14

define the different uses of certificate types issued by the CA, typically following the framework set out in RFC 2527 (http://www.ietf.org/rfc/rfc2527.txt). As an example of a policy, you could refer to the US federal government’s common policy framework for PKI (https://idmanagement.gov/topics/fpki/).

Different policies will define different levels of secure registration and authentication procedures required to obtain the certificate. A general purpose or low-grade certificate might be available with proof of identity, job role, and signature. A commercial grade certificate might require in-person attendance by the authorized person. A CA will issue many different types of certificates, designed for use in different circumstances.

Question 15

server certificate

Answer 15

A server certificate guarantees the identity of e-commerce sites or any sort of website to which users submit data that should be kept confidential.

Question 16

Domain Validation (DV)

Answer 16

proving the ownership of a particular domain. This may be proved by responding to an email to the authorized domain contact or by publishing a text record to the domain. This process can be highly vulnerable to compromise.

Question 17

Extended Validation (EV)

Answer 17

subjecting to a process that requires more rigorous checks on the subject’s legal identity and control over the domain or software being signed. EV standards are maintained by the CA/Browser forum (https://cabforum.org).

• When creating a web server certificate, it is important that the subject matches the Fully Qualified Domain Name (FQDN) by which the server is accessed, or browsers will reject the certificate. If using multiple certificates for each subdomain is impractical, a single certificate can be issued for use with multiple subdomains in the following ways:
• Subject Alternative Name (SAN)—the subdomains are listed as extensions. If a new subdomain is added, a new certificate must be issued.
• Wildcard domain—the certificate is issued to the parent domain and will be accepted as valid for all subdomains (to a single level). Wildcard certificates cannot be issued with Extended Validation (EV).
• Both these methods can cause problems with legacy browser software and some mobile devices. There is also greater exposure for the servers operating each subdomain should the certificate be compromised. Using separate certificates for each subdomain offers better security.

Question 18

machine certificates

Answer 18

It might be necessary to issue certificates to machines (servers, PCs, smartphones, and tablets), regardless of function. For example, in an Active Directory domain, machine certificates could be issued to Domain Controllers, member servers, or even client workstations. Machines without valid domain-issued certificates could be prevented from accessing network resources. Machine certificates might be issued to network appliances, such as routers, switches, and firewalls.

Question 19

email certificates

Answer 19

An email certificate can be used to sign and encrypt email messages, typically using S/MIME or PGP. The user’s email address must be entered in the Subject Alternative Name (SAN) extension field. On a directory-based local network, such as Windows Active Directory, there may be a need for a wider range of user certificate types. For example, in AD there are user certificate templates for standard users, administrators, smart card logon/users, recovery agent users, and Exchange mail users (with separate templates for signature and encryption). Each certificate template has different key usage definitions.

Question 20

code signing certificates

Answer 20

A code signing certificate is issued to a software publisher, following some sort of identity check and validation process by the CA. The publisher then signs the executables or DLLs that make up the program to guarantee the validity of a software application or browser plug-in. Some types of scripting environments, such as PowerShell®, can also require valid digital signatures.

Question 21

root certificates

Answer 21

The root certificate is the one that identifies the CA itself. The root certificate is self-signed. A root certificate would normally use a key size of at least 2048 bits. Many providers are switching to 4096 bits.

Question 22

self-signed certificates

Answer 22

Any machine, web server, or program code can be deployed with a self-signed certificate. Self-signed certificates will be marked as untrusted by the operating system or browser, but an administrative user can choose to override this.

Question 23

To install a CA hierarchy:

Answer 23

1. Set up the root CA or contract with a third-party vendor to provide root CA services.
2. Create and issue a self-signed root certificate from the root CA.
3. Install subordinate CAs.
4. Sign all necessary subordinate CA certificates using the root certificate.
5. Secure the root CA by taking it offline.
6. Install further levels of issuing CAs according to your trust model design plan.

Question 24

To install a Windows Server 2016 CA hierarchy:

Answer 24

1. Verify that all CA servers in the hierarchy can locate each other by Domain Name System (DNS) name. The CA hierarchy uses DNS naming to publish and locate critical CA information.
2. Install the root CA.

a.

In Server Manager, in the Configure this local server section, select Add roles and features.

b.

In the Add Roles and Features Wizard, on the Before you begin page, select Next.

c.

On the Select installation type page, verify that the Role-based or feature-based installation radio button is selected and select Next.

d.

On the Select destination server page, verify that the correct server is selected and select Next.

e.

On the Select server roles page, in the Roles section, check the Active Directory Certificate Services check box.

f.

In the Add Roles and Features Wizard dialog box that pops up, select Add Features.

g.

Select Next, then on the Select features page, select Next again.

h.

On the Active Directory Certificate Services page, select Next.

i.

On the Select role services page, check the Certification Authority Web Enrollment check box.

j.

In the Add Roles and Features Wizard dialog box that pops up, select Add Features.

k.

Select Next, then on the Confirm installation selections page, check the Restart the destination server automatically if required check box and select Yes.

l.

Select Install. When installation completes, select the Configure Active Directory Certificate Services on the destination server link.

3. Configure the root CA.

a.

In the AD CS Configuration wizard, on the Credentials page, select Next.

b.

On the Role Services page, check the Certification Authority and Certification Authority Web Enrollment check boxes, then select Next.

c.

On the Setup Type page, select the Standalone CA option and select Next.

d.

On the CA Type page, with the Root CA option selected, select Next.

e.

On the Private Key page, with the Create a new private key option selected, select Next.

f.

On the Cryptography for CA page, select Next to accept the default values.

g.

On the CA Name page, in the Common name for this CA text box, enter the CA name. Select Next.

h.

On the Validity Period page, set the validity period (in years) for the certificate. Select Next.

i.

On the CA Database page, select the storage location for the CA database and log. Select Next.

j.

On the Confirmation page, select Configure.

k.

After configuration completes, on the Results page, select Close.

4. Install the root certificate on the subordinate CAs.

a.

Open a web browser and navigate to http:///certsrv where is your server name.

b.

Select the Download a CA certificate, certificate chain, or CRL link.

c.

In the CA certificate list, ensure that your certificate is selected.

d.

In the Encoding method section, select Base 64, then select Download CA certificate.

e.

Save the certificate and then transfer it to the subordinate CA.

f.

On the subordinate CA, double-click the .cer file to open it.

g.

Select Install Certificate.

h.

In the Certificate Import Wizard, on the Welcome to the Certificate Import Wizard page, select Next.

i.

On the Certificate Store page, select Place all certificates in the following store, then select Browse.

j.

In the Select Certificate Store dialog box, select Trusted Root Certification Authorities, then select OK.

k.

Select Next.

l.

On the Completing the Certificate Import Wizard page, select Finish.

m.

In the Security Warning dialog box, select Yes.

n.

In the Certificate Import Wizard dialog box, select OK.

o.

In the Certificate dialog box, select OK.

5. Install and configure the subordinate CAs.

a.

Install the subordinate CA using the Add Roles and Features Wizard in the same manner that you installed the root server.

b.

In the AD CS Configuration wizard, on the CA Type page, select Subordinate CA.

c.

In the AD CS Configuration wizard, on the Certificate Request page, select Send a certificate request to a parent machine and enter the CA name or server name. (If the root CA is offline, save the certificate request as a file, transfer the file to the root CA, then complete the request.)

d.

At the root CA, select Tools→Certification Authority.

e.

Select the CA object and open the Pending Requests folder.

f.

Right-click the request and select All Tasks→Issue.

g.

Start the CA service at the subordinate CA and install the new CA server certificate. (If the root CA is offline, save the certificate as a file and transfer the file to the new subordinate CA.)

Question 25

To secure a Windows Server 2016 CA:

Answer 25

1. In Server Manager, select Tools→Active Directory Sites and Services.
2. Expand Services, then Public Key Services, and select Certificate Templates.
3. Double-click the template you want to secure, and configure security as necessary.

Question 26

To back up a Windows Server 2016 CA:

Answer 26

1. In Server Manager, select Tools→Certification Authority.
2. Select your CA object and select Action→All Tasks→Back up CA.
3. Use the Certification Authority Backup Wizard to back up the CA’s private key, CA certificate, certificate database, log, and request queue.
4. To restore components of the CAs, select your CA object and select Action→All Tasks→Restore CA.
5. Use the Certification Authority Restore Wizard to restore the CA’s private key, CA certificate, certificate database, log, and request queue from the backup location. Note that Certificate Services must be stopped during this process.

Question 27

To enroll a certificate for a Windows Server 2016 web server:

Answer 27

1. Request the certificate.

a.

In Server Manager, select Tools→Internet Information Services (IIS) Manager.

b.

In Internet Information Services (IIS) Manager, select your server object.

c.

In the Server Home pane, in the IIS section, double-click Server Certificates.

d.

From the Actions pane, select Create Certificate Request.

e.

Complete the Request Certificate wizard with all the appropriate information.

2. If the certificate request is saved as a file, transfer the file to the issuing CA and submit it manually. If the CA is not configured to issue certificates automatically, the CA administrator will issue the certificate manually.
3. After the certificate has been issued, install it on the web server. To install a certificate on a web server:

a.

Download and save the certificate.

b.

In Internet Information Services (IIS) Manager, select your server object.

c.

Double-click Server Certificates.

d.

In the Actions pane, select Complete Certificate Request and follow the wizard steps.

e.

Verify that the correct certificate is selected.

f.

Open the certificate and select Install Certificate to import it.

Question 28

Key management refers to the operations at various stages in a key’s lifecycle. A key’s lifecycle may involve the following stages:

Answer 28

• Key generation—creating a secure key pair of the required strength, using the chosen cipher.
• Certificate generation—to identify the public part of a key pair as belonging to a subject (user or computer), the subject submits it for signing by the CA as a digital certificate with the appropriate key usage. At this point, it is critical to verify the identity of the subject requesting the certificate and only issue it if the subject passes identity checks.
• Storage—the user must take steps to store the private key securely, ensuring that unauthorized access and use is prevented. It is also important to ensure that the private key is not lost or damaged.
• Revocation—if a private key is compromised, it can be revoked before it expires.
• Expiration and renewal—a key pair that has not been revoked expires after a certain period. Giving the key or certificate a “shelf-life” increases security. Certificates can be renewed with new key material.

Note: Key management also deals with symmetric secret keys, with the problem of secure distribution being particularly acute.

Key management can be centralized (where one administrator or authority controls the process) or decentralized (where each user is responsible for his or her keys). In very general terms, keys issued to servers and appliances are likely to be managed centrally, while some provision is made for users to be able to request keys dynamically.

Certificate and key management can represent a critical vulnerability if not managed properly. If an attacker can obtain a private key, it puts both data confidentiality and identification/authentication systems at risk. If an attacker gains the ability to create signed certificates that appear to be valid, it will be easy to harvest huge amounts of information from the network as the user and computer accounts he or she sets up will be automatically trusted. Finally, if a key used for encryption is accidentally destroyed, the data encrypted using that key will be inaccessible, unless there is a backup or key recovery mechanism.

Question 29

hardware security module (HSM)

Answer 29

A key or key pair is a pseudo-randomly generated integer of the required size (1024-bit or 2048-bit, for instance), expressed in binary DER or ASCII PEM encoding. Generating integers that are sufficiently random is not a trivial task, and it is possible to make a mistake, leading to a weak key (one that is easier to crack). The process is also CPU-intensive, meaning that it often must be undertaken on dedicated hardware, such as a hardware security module (HSM).

Question 30

key generation & usages

Answer 30

Keys (or certificates) have different usages, as set out in the Certificate Policy Statement. In the case of key pairs used for secure email and communications, a key pair used to encrypt a document (providing confidentiality or digital sealing) should not be used to sign a document (providing authentication and non-repudiation). If the same private key is used for both purposes, and the key is compromised, then both uses of the key are threatened. If a key is used for signing only, it can be destroyed, and a new key issued if the original one is compromised. A key used for encryption cannot be destroyed so easily, as the data encrypted by it has to be recovered first. Consequently, an email user may require multiple key pairs represented by multiple certificates.

The security requirements for key usage will also determine the key’s length. Longer keys are more secure, and critical processes (such as identifying the root CA) should use long keys (4096-bit). Data processing servers are likely to use 2048-bit keys, rather than 1024-bit keys, especially if there is any regulatory compliance involved. Conversely, a certificate issued to a smartphone or tablet or Internet of Things (IoT) device might need to use a shorter key to reduce the amount of CPU processing and power required for each operation using the key.

Question 31

key storage and distribution

Answer 31

Once generated, an asymmetric private key or symmetric secret key must be stored somewhere safe (a repository). If these keys are not appropriately secured, the PKI might appear to be functional, but there is the risk of information exposure (anyone obtaining a private or secret key can use it decrypt a message) or inaccurately attest to the identity of a particular person (a private key could be misused to impersonate a digital signature). Key storage can be either software- or hardware-based. In software-based storage, the key is stored on a server. Security is provided by the operating system ACLs. This is sufficient in some cases, but it would not be considered secure enough for mission-critical key storage. Software-based distribution of keys (or in-band distribution) should take place only over a secured network.

Hardware-based storage and distribution is typically implemented using removable media, a smart card, or at the higher end, a dedicated key storage hardware security module (HSM). A smart card may be a credit card style device, a USB device, or a subscriber identity module (SIM) card (used with smartphones). A smart card may therefore support a variety of interfaces, including a card reader or USB port. The main consideration with media and smart card-based storage is to physically secure the device and to keep the access method (typically protected by a passcode) secure. Another option is to use a Trusted Platform Module (TPM) chip in a PC or laptop to generate, store, and protect key material.

Third-party key management HSM products, such as RSA Certificate Manager, AEP Keyper, or Certicom Trust Infrastructure, offer enterprise key management options. There are a variety of solutions, some combining hardware and software devices and systems. One of the advantages of this type of system is that the process is often automated, meaning that the keys cannot be compromised by human involvement.

HSMs can be implemented in several form factors, including rack-mounted appliances, plug-in PCIe adapter cards, and USB-connected external peripherals.

Question 32

Key Recovery

Answer 32

Key Recovery defines a secure process for backing up keys and/or recovering data encrypted with a lost key. This process might use M-of-N control to prevent unauthorized access to (and use of) the archived keys.

Question 33

Escrow

Answer 33

means that something is held independently. In terms of key management, this refers to archiving a key (or keys) with a third party. This is a useful solution for organizations that don’t have the capability to store keys securely themselves, but it invests a great deal of trust in the third party.

Question 34

M-of-N control

Answer 34

Keys such as the private key of a root CA must be subject to the highest possible technical and procedural access controls. For such a key to be compromised would put the confidentiality and integrity of data processed by hundreds or thousands of systems at risk. Access to such critical encryption keys must be logged and audited and is typically subject to M-of-N control. M-of-N control means that of N number of administrators permitted to access the system, M must be present for access to be granted. M must be greater than 1, and N must be greater than M. For example, when m=2 and n=4, any two of four administrators must be present. Staff authorized to perform key management must be carefully vetted, and due care should be taken if these employees leave the business.

Question 35

revoked key

Answer 35

A revoked key is no longer valid and cannot be “un-revoked” or reinstated.

A certificate may be revoked or suspended by the owner or by the CA for many reasons. For example, the certificate or its private key may have been compromised, the business could have closed, a user could have left the company, a domain name could have been changed, the certificate could have been misused in some way, and so on. These reasons are codified under choices such as Unspecified, Key Compromise, CA Compromise, Superseded, or Cessation of Operation. A suspended key is given the code Certificate Hold.

Question 36

suspended

Answer 36

A suspended key can be re-enabled.

A certificate may be revoked or suspended by the owner or by the CA for many reasons. For example, the certificate or its private key may have been compromised, the business could have closed, a user could have left the company, a domain name could have been changed, the certificate could have been misused in some way, and so on. These reasons are codified under choices such as Unspecified, Key Compromise, CA Compromise, Superseded, or Cessation of Operation. A suspended key is given the code Certificate Hold.

Question 37

certificate and key renewal

Answer 37

Typically, a certificate is renewed before it expires. Where a user is in possession of a valid certificate, less administration is required (in terms of checking identity) than with a request for a new certificate. When you are renewing a certificate, it is possible to use the existing key (referred to specifically as “key renewal”) or generate a new key (the certificate is “re-keyed”). A new key might be generated if the old one was no longer considered long enough or if any compromise of the key was feared.

Question 38

expiration

Answer 38

When a key has expired, it is no longer valid or trusted by users. An expired key can either be archived or destroyed. Destroying the key offers more security, but has the drawback that any data encrypted using the key will be unreadable. Whether a key is archived or destroyed will largely depend on how the key was used. In software terms, a key can be destroyed by overwriting the data (merely deleting the data is not secure). A key stored on hardware can be destroyed by a specified erase procedure or by destroying the device.

Question 39

certificate revocation list (CRL)

Answer 39

CAs must maintain a certificate revocation list (CRL) of all revoked and suspended certificates, which can be distributed throughout the hierarchy. A CRL has the following attributes:

• Publish period—the date and time on which the CRL is published. Most CAs are set up to publish the CRL automatically.
• Distribution point(s)—the location(s) to which the CRL is published.
• Validity period—the period during which the CRL is considered authoritative. This is usually a bit longer than the publish period (for example, if the publish period was every 24 hours, the validity period might be 25 hours).
• Signature—the CRL is signed by the CA to verify its authenticity.

The publish period introduces the problem that a certificate might be revoked but still accepted by clients because an up-to-date CRL has not been published. Another problem is that the CRL Distribution Point (CDP) may not be included as a field in the certificate. A further problem is that the browser (or other application) may not be configured to perform CRL checking, though this now tends to be the case only with legacy browser software.

Question 40

Online Certificate Status Protocol (OCSP) server, referred to as an OCSP responder

Answer 40

Another means of providing up-to-date information is to check the certificate’s status on an Online Certificate Status Protocol (OCSP) server, referred to as an OCSP responder. Rather than return a whole CRL, this just communicates the status of the requested certificate. Details of the OCSP responder service should be published in the certificate.

One of the problems with OCSP is that the job of responding to requests is resource intensive and can place high demands on the issuing CA running the OCSP responder. There is also a privacy issue, as the OCSP responder could be used to monitor and record client browser requests. OCSP stapling resolves these issues by having the SSL/TLS web server periodically obtain a time-stamped OCSP response from the CA. When a client submits an OCSP request, the web server returns the time-stamped response, rather than making the client contact the OCSP responder itself.

Question 41

trust model

Answer 41

Another critical concept in PKI is the idea of the trust model. A trust model shows how users and different CAs are able to trust one another.

Question 42

single CA

Answer 42

In this simple model, a single CA issues certificates to users; users trust certificates issued by that CA and no other. The problem with this approach is that the single CA server is very exposed. If it is compromised, the whole PKI collapses.

Question 43

hierarchical model or intermediate CA model

Answer 43

In the hierarchical model, a single CA (called the root) issues certificates to several intermediate CAs. The intermediate CAs issue certificates to subjects (leaf or end entities). This model has the advantage that different intermediate CAs can be set up with different certificate policies, enabling users to perceive clearly what a particular certificate is designed for. Each leaf certificate can be traced back to the root CA along the certification path. This is also referred to as certificate chaining or a chain of trust. The root’s certificate is self-signed. In the hierarchical model, the root is still a single point of failure. If the root is damaged or compromised, the whole structure collapses. To mitigate against this, however, the root server can be taken offline as most of the regular CA activities are handled by the intermediate CA servers.

Another problem is that there is limited opportunity for cross-certification; that is, to trust the CA of another organization. Two organizations could agree to share a root CA, but this would lead to operational difficulties that could only increase as more organizations join. In practice, most clients are configured to trust multiple root CAs.

Question 44

online CA

Answer 44

An online CA is one that is available to accept and process certificate signing requests, publish certificate revocation lists, and perform other certificate management tasks

Question 45

offline CA

Answer 45

Because of the high risk posed by compromising the root CA, a secure configuration involves making the root an offline CA. This means that it is disconnected from any network and usually kept in a powered-down state. The drawback is that the CRL must be published manually. The root CA will also need to be brought online to add or update intermediate CAs.

Question 46

Certificate pinning

Answer 46

refers to several techniques to ensure that when a client inspects the certificate presented by a server or a code-signed application, it is inspecting the proper certificate. This might be achieved by embedding the certificate data in the application code or by submitting one or more public keys to an HTTP browser via an HTTP header, which is referred to as HTTP Public Key Pinning (HPKP).

Question 47

certificate issues

Answer 47

The most common problem when dealing with certificate issues is that of a client rejecting a server certificate (or slightly less commonly, an authentication server rejecting a client’s certificate).

• If the problem is with an existing certificate that has been working previously, check that the certificate has not expired or been revoked or suspended.
• If the problem is with a new certificate, check that the key usage settings are appropriate for the application. Some clients, such as VPN and email clients, have very specific requirements for key usage configuration. Also check that the subject name is correctly configured and that the client is using the correct address. For example, if a client tries to connect to a server by IP address instead of FQDN, a certificate configured with an FQDN will be rejected.
• If troubleshooting a new certificate that is correctly configured, check that clients have been configured with the appropriate chain of trust. You need to install root and intermediate CA certificates on the client before a leaf certificate can be trusted. Be aware that some client applications might maintain a different certificate store to that of the OS.
• In either case, verify that the time and date settings on the server and client are synchronized. Incorrect date/time settings are a common cause of certificate (and other) problems.

From a security point of view, you must also audit certificate infrastructure to ensure that only valid certificates are being issued and trusted. Review logs of issued certificates periodically. Validate the permissions of users assigned to manage certificate services. Check clients to ensure that only valid root CA certificates are trusted. Make sure clients are checking for revoked or suspended certificates.

Question 48

Pretty Good Privacy (PGP)

Answer 48

popular open standard for encrypting email communications and which can also be used for file and disk encryption. It supports the use of a wide range of encryption algorithms. PGP actually exists in two versions. The PGP Corporation develops a commercial product (now owned by Symantec®). However, PGP has also been ratified as an open Internet standard with the name OpenPGP (RFC 4880). The principal implementation of OpenPGP is Gnu Privacy Guard (GPG), which is available for Linux® and Windows® (gpg4win). The commercial and open versions of PGP are broadly compatible. In OpenPGP, for encrypting messages (symmetric encryption), you can use 3DES, CAST, Blowfish/Twofish, AES, or IDEA. For signing messages and asymmetric encryption, you can use RSA, DSA, or ElGamal. OpenPGP supports MD5, SHA, and RIPEMD cryptographic hash functions.

To use PGP, a user needs to install PGP software (usually available as a plug-in for the popular mail clients). The user then creates his or her own certificate. In order to provide some verification that a certificate is owned by a particular user, PGP operates a web of trust model (essentially users sign one another’s certificates).

The contents of X.509 and PGP certificates are similar. The main difference is that PGP certificates can be signed by multiple users, while X.509 certificates are signed by a single CA. PGP certificates can also store more “friendly” information about the user (though this type of data could be added using attribute extensions to X.509 certificates).

Question 49

To back up user certificates and private keys in Windows Server 2016:

Answer 49

1. As the user, create a custom MMC console containing the Certificates snap-in.
2. In the Certificates console, expand Certificates.
3. Expand the Personal store and select the Certificates folder.
4. Select the certificate you want to back up and select Action→All Tasks→Export.
5. Complete the appropriate steps in the Certificate Export Wizard. For maximum security, use a strong password and export the certificate to a flash drive or other external storage medium. Store the drive in a secure location.

Question 50

To restore a user certificate and private key in Windows Server 2016:

Answer 50

1. Open a Certificates console for the affected user account.
2. Open the Personal store, select the Certificates folder, and select Action→All Tasks→Import.
3. In the Certificate Import Wizard, on the File to Import page, in the File name text box, specify the location of the backup certificate.
4. On the Private key protection page, in the Password text box, enter the password. Check the Mark this key as exportable. This will allow you to back up or transport your keys at a later time check box.

Question 51

To configure key recovery agents in Windows Server 2016:

Answer 51

1. Configure permissions to users or groups that can perform key recovery, and publish the key recovery agent certificate.
2. Issue key recovery agents (KRAs) with key recovery certificates.
3. Enable key archival for the CA, and identify the KRAs with permission to recover the key.
4. Create and publish certificate templates with archiving enabled

Question 52

No matter what type of CA software you use, there are three main steps in revoking certificates:

Answer 52

1. Revoke the certificate itself.
2. Publish the CRL if your CA relies on it.
3. Destroy the revoked certificate if it has been stored as a file. If the certificate was stored on a smart card or other portable storage device, destroy or securely wipe the device.

Question 53

To revoke a certificate in Windows Server 2016:

Answer 53

1. In Server Manager, select Tools→Certification Authority.
2. In Certification Authority, select the Issued Certificates folder.
3. Select the certificate you want to revoke, then select Action→All Tasks→Revoke Certificate.
4. In the Certificate Revocation dialog box, from the Reason code drop-down list, select the reason you’re revoking the certificate.
5. Select Yes to revoke the certificate.
6. Publish the CRL automatically or manually.

• To publish the CRL automatically, wait for the automatic CRL publication interval.
• To publish the CRL manually, in Certification Authority, select the Revoked Certificates folder and select Action→All Tasks→Publish. In the Publish CRL dialog box, select OK to publish the CR

Question 54

To modify the CRL publication schedule in Windows Server 2016:

Answer 54

1. In Certification Authority, right-click the Revoked Certificates folder and select Properties.
2. In the Revoked Certificates Properties dialog box, on the CRL Publishing Parameters tab, set the CRL publication interval as desired.
3. Select OK.
4. Republish the CRL to change the update schedule for clients.