Digital certificates

 

 

Contents

 

Overview

Digital certificates provide protection against impersonation, because a digital certificate binds a public key to its owner, whether that owner is an individual, a queue manager, or some other entity. Digital certificates are also known as public key certificates, because they give you assurances about the ownership of a public key when you use an asymmetric key scheme. A digital certificate contains the public key for an entity and is a statement that the public key belongs to that entity:

  • When the certificate is for an individual entity, the certificate is called a personal certificate or user certificate.

  • When the certificate is for a Certification Authority, the certificate is called a CA certificate or signer certificate.

If public keys are sent directly by their owner to another entity, there is a risk that the message could be intercepted and the public key substituted by another. This is known as a man in the middle attack. The solution to this problem is to exchange public keys through a trusted third party, giving you a strong assurance that the public key really belongs to the entity with which you are communicating. Instead of sending the public key directly, you ask the trusted third party to incorporate it into a digital certificate. The trusted third party that issues digital certificates is called a Certification Authority (CA), as described in Certification Authorities.

 

What is in a digital certificate

Digital certificates used by WebSphere MQ comply with the X.509 standard, which specifies the information that is required and the format for sending it. X.509 is the Authentication framework part of the X.500 series of standards. X.500 is the OSI Directory Standard.

Digital certificates contain at least the following information about the entity being certified:

  • The owner's public key
  • The owner's Distinguished Name
  • The Distinguished Name of the CA that is issuing the certificate
  • The date from which the certificate is valid
  • The expiry date of the certificate
  • A version number
  • A serial number

When you receive a certificate from a CA, the certificate is signed by the issuing CA with a digital signature. You verify that signature by using a CA certificate, from which you obtain the public key for the CA. You can use the CA public key to validate other certificates issued by that authority. Recipients of the certificate use the CA public key to check the signature.

Digital certificates do not contain the private key. You must keep the private key secret.

 

Certification Authorities

A Certification Authority (CA) is an independent and trusted third party that issues digital certificates to provide you with an assurance that the public key of an entity truly belongs to that entity. The roles of a CA are:

  • On receiving a request for a digital certificate, to verify the identity of the requestor before building, signing and returning the personal certificate
  • To provide the CA's own public key in its CA certificate
  • To publish lists of certificates that are no longer trusted in a Certificate Revocation List (CRL). For more information, refer to Chapter 16, Working with Certificate Revocation Lists

 

Distinguished Names

The Distinguished Name (DN) uniquely identifies an entity in an X.509 certificate. The following attribute types are commonly found in the DN:

CN Common Name
T Title
O Organization name
OU Organizational Unit name
L Locality name
ST (or SP or S) State or Province name
C Country

The X.509 standard defines other attributes that do not usually form part of the DN but can provide optional extensions to the digital certificate.

The X.509 standard provides for a DN to be specified in a string format. For example: 

CN=John Smith, O=IBM, OU=Test, C=GB

The Common Name (CN) can describe an individual user or any other entity, for example a Web server.

The DN can contain multiple OU attributes, but one instance only of each of the other attributes is permitted. The order of the OU entries is significant: the order specifies a hierarchy of Organizational Unit names, with the highest-level unit first.

 

How digital certificates work

You obtain a digital certificate by sending information to a CA. The X.509 standard defines a format for this information, but some CAs have their own format. Certificate requests are usually generated by the certificate management tool the system uses, for example the iKeyman tool on UNIX systems and RACF(R) on z/OS. The information comprises the Distinguished Name and is accompanied by the public key. When the certificate management tool generates the certificate request, it also generates the private key, which keep secure. Never distribute the private key.

When the CA receives the request, the authority verifies the identity before building the certificate and returning it to you as a personal certificate.

 

Obtaining personal certificates

You obtain the personal certificate from a Certification Authority (CA).

When you obtain a certificate from a trusted external CA, you pay for the service. When you are testing the system, or you need only to protect internal messages, you can create self-signed certificates. These are created and signed by the certificate management tool the system uses. Self-signed certificates cannot be used to authenticate certificates from outside the organization.

 

How certificate chains work

When you receive the certificate for another entity, you might need to use a certificate chain to obtain the root CA certificate. The certificate chain, also known as the certification path, is a list of certificates used to authenticate an entity. The chain, or path, begins with the certificate of that entity, and each certificate in the chain is signed by the entity identified by the next certificate in the chain. The chain terminates with a root CA certificate. The root CA certificate is always signed by the CA itself. The signatures of all certificates in the chain must be verified until the root CA certificate is reached.

 

When certificates are no longer valid

Digital certificates are issued for a fixed period and are not valid after their expiry date. Certificates can also become untrustworthy for various reasons, including:

  • The owner has moved to a different organization
  • The private key is no longer secret

A Certification Authority can revoke a certificate that is no longer trusted by publishing it in a Certificate Revocation List (CRL).

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.