Digital certificate management considerations
This chapter provides an overview of topics for you to consider for managing your digital certificate lifecycle.
This chapter includes the following topics:
2.1 Goals
In this chapter, we have the following goals:
•Review the digital certificate lifecycle
•Consider how to manage the digital lifecycle
2.2 Using internal or external certificate authorities
Different aspects must be examined to decide whether to use an internal or external certificate authorities (CA) to create and manage digital certificates. The topics in this section can help you to think about which certificates are better-suited to internal or external certification.
An internal CA is installed and maintained within your enterprise, issuing certificates for the people and servers of your internal IT system.
An external CA is installed and maintained outside of your enterprise and is treated as a third party. Certificates are purchased from a well-known CA.
2.2.1 Costs
Buying digital certificates from a well-known CA creates financial costs. Our research at the time of this writing shows that prices can vary 20 - 1,200 US dollars per SSL certificate for the first year, depending on your requirements and the CA that you choose.
Although it is suggested to use certificates from a well-known CA (for example for external or public-facing web pages), it might not be necessary for internal (or private) IT systems. For internal IT systems or communication among a closed group of entities, a private CA can be used. Issuing certificates from within your organization avoids the costs of purchasing them from an external source.
2.2.2 Scope of use
The choice of choosing an internal or external CA can depend on the scope of use. Public CAs generate digital certificates for the public; that is, for anyone. For internal IT systems, you might want to make sure that only a closed group of entities can access them.
An analogy can be made here between internal and external certification. Next, we consider two items of identification, a passport and a company JOB ID card, as shown in Figure 2-1 on page 21.
Figure 2-1 External and self-certification
The passport is externally validated and issued and provides the carrier with recognized global identity authentication whereas the Job ID card is accepted only within the company it was issued. It is not accepted as global identity authentication as is the passport. However, the passport is accepted as an acceptable identity authentication for the company to issue a job ID card.
2.2.3 Expanding scope of use
The certificates that are issued by internal CAs can expand beyond the organization to which the CA belongs. The internal CA can issue certificates for the organization’s Business Partners, as shown in Figure 2-2 on page 22.
Figure 2-2 Internal CA creating certificates for Business Partners
The Business Partners might need certificates to deal with your organization. If your organization has an internal CA, your Business Partners must we willing to accept your CA certificate into their certificate store. This difference is a subtle change because your internal CA is now dealing with external entities. The effort and administration that is involved must be balanced against the costs and convenience of buying the certificates from a well-known CA.
The CA’s certificate must be in each Business Partners certificate store, which can become a high administration effort as the number of Business Partners increases. Conversely, well-known CA certificates are included in the certificate store.
2.2.4 Compromised certificate considerations
Compromised certificates must be revoked. If a certificate is compromised, the issuing CA must revoke it and a request for a new certificate must be made. The requester can then use the new certificate instead of the compromised certificate.
If an intermediate CA is compromised, the root CA can revoke the intermediate’s certificate. All of the certificates in the intermediate CA’s chain are unusable. The root CA can issue a new certificate to the intermediate CA.
If a well-known company that provides certificates to high-profile clients (such as, financial institutions and major retailers) has its root CA compromised, all of the certificates it issued are unusable. This situation is serious and has visible affect on trading, which can make headline news.
2.3 Digital certificate lifecycle
Digital certificates go through phases. There are key activity points within these phases, which are referred to as the digital certificate lifecycle.
2.3.1 Lifecycle management
The lifecycle of a certificate requires managing. The following points are typical activities within the certificate’s lifecycle:
•Request or Renewal: The initial request for the digital certificate or a renewal when the certificate is to expire.
•Approval: The request is approved or rejected based on the request information.
•Generation and Distribution: The digital certificate is generated with all the required elements and is distributed.
•Usage: The usage period occurs.
•The digital certificate expires and the end of the requested usage period or it might be revoked by an administrator for any valid reason, such as the keys being compromised.
Figure 2-3 shows the lifecycle of a certificate.
Figure 2-3 Digital certificate lifecycle
You can think of a digital certificate as a passport. It is used to prove that you are the person you say that you are and it is coming from a trusted authority: the government. This analogy also can be used to explain a certificate lifecycle. A certificate lifecycle includes the following steps:
1. As with a passport proving your identity, a digital certificate must be requested at a trusted authority (CA).
2. Someone at the authority must prove the request and approve or reject the certificate request.
3. After a certificate request is approved, the certificate can be generated and made available for distribution.
4. The certificate is used to authenticate an entity at a certain IT service or used to secure a communication. (For more information about the various use cases for certificates, see Chapter 1, “Digital certificates overview” on page 1).
5. The expiration date depends on the initial parameters in the certificate request. After a certificate expires, it is no longer usable. Revocation also can stop a certificate from being used even though it did not expire. It is the responsibility of the CA to post the revocation list. Entities accessing the certificate must check to see whether the certificate was revoked before trusting it.
6. After expiration, a certificate must be renewed. After revocation, a new certificate must be reissued.
2.4 Digital certificate lifecycle management considerations
In this section, we describe the areas for you to consider when developing your management strategy and processes.
2.4.1 Manual management risk
The increasing volume of certificates affects how you can choose to manage the lifecycle of certificates. Consider the following points relating to the manual management approach:
•Generation: Increased volume of certificates makes it harder to handle manually because it is time-consuming and requires extra manpower and training to satisfy the increasing demands.
•Distribution of certificates: Each certificate must be individually distributed. It can be more efficient to allow entities to retrieve certificates via download or standard protocols.
•Errors: Manual systems tend to be more error prone and subject to human limitations.
•Expiration: A growing challenge is to track expiration dates and to protect against the consequences of authentication failure because of certificate expiration.
•Responsiveness: Requesters must set the correct expectations that other actions can later depend upon the authentication being there; for example, when introducing new functions or creating an application.
Certificates can be required throughout each stage of the application development, testing, and implementation lifecycle. Delays in the generation can affect subsequent activities. An automated process helps in defining a Service Level Agreement (SLA) for the delivery points of the management cycle.
Automated procedures help resolve many of the issues of manual management.
2.4.2 Request and approval policy
Roles and user autonomy are two considerations to help in defining the request and approval policy.
Roles
Depending on the internal IT security policies, the following questions must be asked:
•Who in an enterprise is allowed to request certificates?
•Who or how many administrators must approve a certificate request?
•Is auto-approval to be allowed, and to what level?
•Is there an audit trail for auto-approval or any other approval process?
The requirements of the various IT security policies can be met by using a public key infrastructure (PKI) and establishing a consistent and accountable workflow for the certificate request and approval process.
User autonomy
You might need to define a structure for user rights management, whereby personal users (such as company employees) can request, revoke, and renew their personal digital certificates. However, they might not be allowed to request server certificates unless they also are server administrators and their job requires them to do so.
2.4.3 Expiration
An issue with certificates is that they expire. If a certificate expires, the authentication process no longer works because the verification of the certificates fails.
The effect of a failed level of authentication often causes disruption to applications or in more extreme circumstances can lead to outages of IT services. For example, authenticating failure in an online business banking application can cause problems that require immediate attention and a high priority resolution.
2.4.4 Revocation
A digital certificate can be revoked for the following reasons:
•Key compromise
•CA compromise
•Affiliation changed
•Superseded
•Cessation of operation
2.5 Accountability
Accountability is key to demonstrate to auditors that certificates are managed across the enterprise in accordance with the enterprise’s defined policies. The accountability is essential to verify that processes that relate to the digital certification lifecycle can be monitored to detect anomalies.
In addition, quantifiable accountability and monitoring can be used to measure and report activity levels that relate to the lifecycle and to use trending to predict activity levels within the lifecycle.
2.6 Public Key Infrastructure
Thus far we reviewed the use of keys and encryption, the role and structure of certificates, and the CA. We also described considerations that we can make to engage the appropriate structure, roles and responsibilities, options, and the potential activities that are involved throughout the enterprise or organization and across different kinds of servers and various operating systems. If we put all this information together into a viable, effective, and trustworthy solution, we have what is referred to as a PKI.
A PKI is based on public key cryptography. The infrastructure can consist of hardware, software, and policies to create, manage, store, distribute, and verify digital certificates.
Managing certificates centrally in a PKI helps you track all the activities that occur during the lifecycle of a certificate; for example, who requested a certificate and who approved it.
2.7 Regulatory demands
The regulatory requirements for digital certificate-related processes vary depending on the following factors:
•Country or government policy
•State within that country
•Type of business or organization:
– Financial
– Healthcare
– Social welfare
– Travel and accommodation
•Online culture and openness
Regulatory recommendations or requirements regarding the use of a PKI to manage digital certificates include the following examples:
•bsi Grundschutz (Germany) recommends the use of PKI for the following use cases:
– Email encryption or signing
– Remote access to company network (VPN) and IPSec
– Authentication to wireless LAN
– Signing code
– Signing XML in web services calls
•HIPAA recommends the use of a PKI as the “most viable technology that will ensure the proper level of protection for healthcare information”.
Several countries are introducing laws or regulations around electronic signatures that require the use of a PKI.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.