Digital certificates overview
In this chapter, we present a high-level view of the purpose of digital certificates and how they might be used.
This chapter includes the following topics:
1.1 Goal
The goal of this chapter is to help you gain a high-level understanding of digital certificates and how they might be used. Specifically, we describe the following topics:
•The need for commendations protection
•Keys, signatures, digests, and certificates
•Certificate Authorities
1.2 Overview
Digital certificates are at the heart of protecting all aspects of data communication, from websites for business and banking to shopping and product development, to social media for interaction and collaboration.
The information explosion, the adoption of cloud computing, and governmental regulations are making digital certificates even more important than ever.
Two parties are involved in the use of certificates (in this book, we refer to digital certificates as certificates). One party uses a certificate to identify itself, the other party must validate it. This process is referred to as a handshake. The protocol that is used is Secure Sockets Layer/Transport Level Security (SSL/TLS). For the handshake process to work, both parties must store the certificates in their own certificate store. The certificate store is also referred as a keystore or a key database.
But where do you obtain the certificates to put in the certificate store for the SSL/TLS protocol?
A certificate authority (CA) issues certificates. There are well-known CAs that sell certificates. There are internal CAs that issue certificates for their own enterprise. All certificates are created by using common standards. That is, no matter which CA sells you the certificate, no matter what CA and on what platform the certificate is created, it can be used by any application on any platform. Therefore, choosing the CA is an independent consideration of the platform on which the certificate is being used.
If you have applications running on z Systems, Linux, and Windows that need certificates to operate and you want to use an internal CA, you do not need to have a CA running on every one of the platforms.
What platform do you want to run your CA? Selecting the platform is based on the following key considerations:
•Security
•Availability
•Scalability
•Functionality
This book describes these topics to give you a high-level understanding of the considerations and options you have to implement an effective way of creating and managing digital certificates with cost and value in mind.
1.3 Primary question
Certificates have one important primary question to answer, as shown in Figure 1-1.
Figure 1-1 Primary question
Before communication starts, anyone or anything (such as a server) must make their identity known to others before proceeding with the communication process.
 
Note: Each party in the communication process is referred to as an entity; however, for the purposes of this overview, we refer to people communicating via mobile phones and notebooks (as shown in Figure 1-1) with Tom and Sally. This scenario can also apply to servers talking to each other or people and servers communicating with each other.
But is your identity really you? It might be someone posing as you.
Secondary questions
Tom might present his identity to Sally, but can she believe this is really Tom? Before we share any messages or transactions with anyone or anything, we must feel more secure about who is involved in the communication and determine whether they can be party to the communication. Three more questions are shown in Figure 1-2 on page 4.
Figure 1-2 Secondary questions
Imagine Tom is making a purchase from Sally. Tom feels more comfortable about making a purchase if these secondary questions are answered before proceeding with the purchase, and has confidence in knowing with whom he is dealing.
The solution to the issues that are raised by our questions are certificates, as shown in Figure 1-3.
Figure 1-3 Digital certificate's role
We can see in Figure 1-3 that if certificates can provide the authentication of people and servers that we want to communicate with, we can proceed with more confidence and an increased level of trust.
Are we okay with this process? Well, not quite. There is another aspect to consider, as shown in Figure 1-4.
Figure 1-4 Can I trust a digital certificate?
In the same way you have concerns about identifying with whom you are communicating, the argument applies to the certificates themselves. We are facing the well-established question of “Quis custodiet ipsos custodes?” or, “Who will guard the guards?”
The solution is to establish a recognized way for people and servers to obtain a certificate that they can trust. The certificate must also provide information to be used to protect the messages and data during the communication process.
 
Note: The certificate does not perform any encryption. The information that is contained within it is used by other software and hardware to perform encryption.

The provision of a certificate is granted through a CA. In Figure 1-5, we see that a CA creates certificates for users.
Figure 1-5 Certificate authority
The typical steps for this process to occur are shown in Figure 1-6.
Figure 1-6 Creating a digital certificate
Although this overview is simplistic, section 1.4, “Behind the scenes” on page 7 describes varying levels of communication protection and what attributes must be met to help answer the questions posed thus far.
1.4 Behind the scenes
In this section, we describe the following topics:
•Security attributes
•Secret key cryptography
•Public key cryptography
•Digital certificates
We describe the basic information for each topic, and present a high-level understanding of how the different parts can work together to form a solution.
Security attributes
Communication includes the following essential security attributes:
•Authenticity: Verification of the validity of a person or server’s claim to identifying who they or it is.
•Integrity: Verification that the message content was not changed or compromised.
•Confidentially: Ensuring that the message can be seen by the intended recipient only.
•Non-repudiation: Assurance that the sender or recipient cannot deny being the source or in receipt of the message.
Without these attributes, we are exposing our communications to a high level of risk and that exposure can result in unwanted consequences.
Therefore, how do we take steps to achieve a level of security that we can have confidence in?
Secret key cryptography
In our example, suppose that Tom wants to send a private message to Sally, who is another member of our group. As shown in Figure 1-7, Tom sends a message by using his mobile phone to Sally, who is using her notebook.
Figure 1-7 Secret key cryptography
They want the message to be private so only they can understand it. The following process occurs:
1. Tom types the message and sends it.
2. The message is encrypted by using a key.
3. When Sally receives the message, it is decrypted by using the same key.
4. Sally reads the original message.
In cryptography, an algorithm or set of algorithms use a key to encrypt the data. There are two parts: the algorithm and the key. These parts are separate from each other, and because they are separate from each other, a new key is required if the key is compromised but the algorithms can remain in place. There is no need to write a new algorithm; instead, use a different key.
In Tom and Sally’s communication, the same key is used to encrypt and decrypt the original message.
The key is a secret between Tom the sender and Sally the receiver. If only Tom and Sally can access the key, consider the following points:
•If Tom uses this particular key to encrypt a message and send it to any other member of the group, the intended recipient does not have the key and cannot decrypt the message and read it.
•If Tom or Sally want to communicate with other members of the group, the following scenarios might occur:
 – Tom creates an individual key for every person and server in the group to communicate with each directly. In this case, he requires another six keys. If everyone in the group chose to communicate with each other by using individual keys, the number of keys would be 6+5+4+3+2+1 = 21. This number increases further if members of the group wanted to form sub groups that had their own keys to secure their communication.
 – Tom and Sally might choose to share the key with others. Those members who had access to the key can encrypt and decrypt messages with each other; however, the privacy level between the original Tom and Sally level now moves to a group level privacy whereby anyone who has access to the key can see the others’ messages.
 
Note: In secret key cryptography, this type of key is called a symmetric key.
Public key cryptography
Public key cryptography consists of the following keys:
•Public key: This key is a key that is made available to the public.
•Private key: This key is kept private to the owner and not made available to the public.
The use of these two keys is known as a paired key approach. The key that is used for encryption is different from the key used for decryption. The public key has a counterpart called the private key. When the keys are created, they are created as a pair. This process is known as asymmetric cryptography, which is different from the secret key that is shown in Figure 1-7 on page 7 that uses a symmetric key (uses the same key for the encryption and decryption).
Asymmetric key pair features the following characteristics:
•An encrypted message can be decrypted only with the other key of the key pair.
•An encrypted message cannot be decrypted with the encryption key that was used to create the encryption.
•Each communication includes a public key and a private key. In our scenario, Tom wants to send a message to Sally by using the asymmetric key pairs. The following steps occur:
 – Tom accesses Sally’s public key to encrypt the message.
 – Sally uses her private key to decrypt the message.
Figure 1-8 shows how public key cryptography handles the events that were shown in Figure 1-7 on page 7.
Figure 1-8 Public key cryptograph
Is this solution acceptable? Does it meet what we stated in “Security attributes” on page 7? No, it does not. It provided a level of confidentiality because the message was encrypted and remained so during its journey until Sally receives it and decrypts it. However, it did not provide sufficient protection for authenticity, integrity, and non-repudiation.
In Figure 1-8, Sally cannot be sure who the sender really is because the sender picked up her public key and used it. Tom did not supply any information that verifies his identity. Therefore, although Sally can decrypt his message and read it, she has no real proof of who sent the message. If Tom wants to prove only that the message is coming from him, he can use another technique: he can digitally sign the message.
Digital signatures
Figure 1-9 shows a different scenario for Tom to send his message to Sally.
Figure 1-9 Digitally signing a message
This process includes the following steps:
1. Tom creates the message to send to Sally.
2. Tom uses an algorithm to hash the message. The hashed output is known as a digest.
3. Tom uses his private key to encrypt the digest to create a signature.
4. The signature is appended to the message and sent to Sally.
5. Sally uses Tom’s public key to decrypt the signature. This decryption reveals the digest that Tom created.
6. Sally also received the original message, so she can use the same hashing process to create a digest.
7. If the message that Sally receives is the same the message that Tom sent, both of the digests should be the same if she uses the same hashing process. This process assures her that the message was not compromised.
This technique improves the situation. The digital signature that was provided by Tom using his private key can prove that the message is from him; otherwise, when Sally used his public key to decrypt the message, it does not work. The matching digests also prove that the message was not altered.
In the scenarios that describe the use of public and private key pairs thus far, the following fundamental questions still must be answered:
•How does Sally get Tom’s public key?
•How does Sally know which algorithms to use to create the hash?
The answer to these questions is the digital certificate. This certificate is the container for the public key and the algorithm. It also indicates the owner of the certificate and other information.
However, the use of a certificate to carry the public key and the algorithm solves the problem partially. The problem moves to the certificate level in that how can Sally know that the certificate really belongs to Tom and that she can trust the content? If Sally cannot trust the issuer of Tom’s certificate, she cannot trust the certificate.
If a certificate is to be trusted, the creator and issuer of the certificate must be trustworthy. It is here that the concept of the CA is important.
1.5 Certificate authorities
The CA can issue digital certificates. The digital certificate must achieve the following goals:
•Verify that the person is who they say they are.
•Verify that the public key belongs to the person being verified.
The CA validates credentials of owner and signs the digital certificate. The CA’s signature validates that the owner is who they say they are and that the public key belongs to them. The CA might also generate the key pair if the person or server has not already done so, as shown in Figure 1-10.
Figure 1-10 CA digital certificate creation and issuance
The CA must be a trusted third party because without this trust, the purpose of the certificate is defeated and we are still left with the issue of not knowing with certainty if the public key belongs to the sender. Figure 1-10 shows the following typical process to issue a certificate:
1. The CA collects and validates credentials from the certificate requester.
2. The CA accepts the request with the public key that was generated by the owner. If the owner wants the CA to generate the keys, it generates the public key and private pair.
3. The CA signs the certificate by hashing the content of the certificate, which includes the requester’s public key to produce a digest followed by encrypting the digest with the CA’s private key.
4. The signed digital certificate is available to the requester for pickup.
The certificate that is issued to the requester contains key fields, such as the owner’s name, public key, issuers name, issuer signature, and the period of validity. There can be other information contained, which might be supplied at request time that can then be included in the certificate, as shown in Figure 1-11.
Figure 1-11 Sample digital certificate format
The amount of detail can vary because there is a demand for more than one type of certificate. That is, certificates can be created for different purposes; for example, email and VPN.
The X.509 standard introduced extensions to digital certificates that cater for the differing requirements but still remain true to the one type of digital certificate.
In our scenario, the following sequence of events now occurs:
1. Tom attaches the certificate to his message, he encrypted it by using his private key.
2. Sally receives the message and accesses the certificate to complete the following tasks:
a. Identify who is the owner of the certificate and message.
b. Check the CA’s signature on the certificate, and continues if she trusts that CA.
c. Use Tom’s public key to decrypt the message.
We have one last matter to address: How can the CA’s identity be represented by its own certificate?
The CA must establish its own identity and credentials by taking the following actions:
1. Generating its own key pair.
2. Protecting its private key so it is not available to entities.
3. Creating its own certificate as being the owner and including its public key.
4. Self-signing the certificate.
The CA is now available to receive requests and to authenticate its requesters.
1.5.1 Other checks for validating a digital certificate
Before going through the decryption and comparison processes, the following checks must be made:
•If the certificate expired.
•If the certificate was revoked.
If the digital certificate expired or was revoked, it is not valid and cannot be trusted.
1.6 Authentication versus authorization
There is a myth that a digital certificate provides a level of authorization. This is not the case.
 
Important: A certificate is used only to verify identity. The receiving system can map the identity to authorization credentials, but the certificate does not contain authorization credentials.
1.7 Use of a digital certificate
A common use of digital certificates is between a web browser and a web server, as shown in Figure 1-12.
Figure 1-12 SSL handshake between browser and web server
Paul is using the browser on his phone to access a website. For him to validate that the web server is who it says that it is, a certificate is sent to the browser. The browser has a trusted certificate store. If the issuer or CA of the certificate is known and trusted, the browser and web server exchange information to set up a secure session by using the public and private keys. This process is known as the Secure Sockets Layer (SSL) handshake. If the browser does not find a certificate match, a security alert prompts the user about how to proceed. There are circumstances where some browsers refuse to allow you continue any further.
SSL handshake and SSL protocol clarification
We used the term SSL handshake and not the term SSL protocol. To avoid confusion and misuse of the terms, consider the following points:
•An SSL handshake proves who we are.
•An SSL protocol is the language that we speak to communicate with each other.
1.7.1 Integrating certificates into applications
Suppose that a new business application must communicate with another application. We might want to encrypt the communication through the SSL/TLS protocol, as shown in Figure 1-13. Certificates and CAs are platform-independent. Some of the CAs that are shown might be well-known and trusted, but others might be private CAs within an organization. However, if they all use the SSL/TLS protocol, they can communicate with each other after their identity is proven by the SSL handshake.
Figure 1-13 Cross platform business application
Before implementing a project that requires data communications, the interested parties that are involved with each part of the application must agree on a collection of certificates and keys that are needed to provide secure communication. The agreed collections must allow for the development, testing, and implementation phases of the project. This process most likely involves setting up a collection of keys and certificates into a various stores.
If the applications are large, it is also likely various certificates are required for the individual areas of the application. These certificates require the appropriate keys.
Organizing the collections to make them effective involves the following tasks:
•Identifying the location of the keystore
•Determining which certificates are needed and where they are needed
Stage 1: Identifying the location of the keystore
Examine the application and see how it is configured to identify the best places to store the keys (there might be more than one place). Define which configurations are to be used and determine their location, as shown in Figure 1-14. Each server has its own configuration and contains information or pointers to locations, such as keystores.
Figure 1-14 Configuring where the keystores are to be stored
Stage 2: Determining which certificates are needed and where
Examine all parts of the applications and based on the function and configuration that is identified in Stage 1, store the keys and certificates in the appropriate repositories.
Server authentication
The client starts the communication and attempts to establish communication with the server. The server must identify itself to the client. This process highlights why stage 1 and 2 are important because they ensure that the appropriate certificates are presented and the keys are available. Based on this exchange, the client can validate the server.
Client authentication
Having identified itself to the client, the server might now require that the client identify itself so that the server can validate the client.
1.7.2 Intermediate CAs
CAs can be hierarchical, which is useful for providing granular authentication. For example, an application might feature email, a document repository, and room booking functions. Therefore, these features are sub-applications and might have corresponding CAs to manage the certification for each area. So, our business applications integration can now be much more hierarchical, as shown in Figure 1-15.
Figure 1-15 Intermediate CAs to support business applications
 
Note: The top-level CA is known as the root CA. If the browser trusts the root CA, it automatically trusts any intermediate CA that belongs to the root CA. This configuration is often referred to as the chain of trust.
To help with the structure to make the management and administration of all the CAs easier and consistent, one CA can be the root CA of all the other intermediate CAs. Your structure might not link to all CAs as the others might be owned by an external third party or be on different platforms. The CAs might not be connected but are still part of the application, as shown in Figure 1-16.
Figure 1-16 Easing the management and administration of CAs
The topics that we described in this chapter that relate to certificates and asymmetric keys form the foundations of a Public Key Infrastructure (PKI). For more information, see Chapter 3, “Introducing z/OS PKI Services” on page 27.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset