X.509 certificates

TLS uses certificates for authentication. Authentication happens at connection time and is independent of the application or the application protocol.

To see which CICS® access methods support certificates, see Which authentication method can I use with which access method?

Why use certificates?

TLS is a widely adopted security protocol that is used to secure communications over the internet. The primary use case of TLS is encrypting the communication between servers. It can also be used to establish trust between servers when enabling client authentication (sometimes referred to as mutual authentication).

TLS client authentication might not be practical when many clients need to connect to CICS because the creation and administration of certificates can be a significant effort, for example, when certificates expire.

For more information about TLS, see TLS.

How certificates work

TLS client authentication involves making sure that sites with which you communicate are who they claim to be. With TLS, authentication is done by an exchange of certificates, which are blocks of data in a format that is described in ITU-T standard X.509. The X.509 certificates are issued and digitally signed by an external authority, which is known as a certificate authority.

A certificate contains:
  • Two distinguished names, which uniquely identify the issuer (the certificate authority that issued the certificate) and the subject (the individual or organization to whom the certificate was issued). The distinguished names contain several optional components:
    • Common name
    • Organizational unit
    • Organization
    • Locality
    • State or Province
    • Country
  • A digital signature. The signature is created by the certificate authority by using the public-key cryptography technique:
    1. A secure hashing algorithm is used to create a digest of the certificate's contents.
    2. The digest is encrypted with the certificate authority's private key.
    The digital signature assures the receiver that no changes are made to the certificate since it was issued:
    1. The signature is decrypted with the certificate authority's public key.
    2. A new digest of the certificate's contents is made, and compared with the decrypted signature. Any discrepancy indicates that the certificate might have been altered.
  • The subject's domain name. The receiver compares this name with the actual sender of the certificate.
  • The subject's public key.

Certificates are used to authenticate clients to servers, and servers to clients; the mechanism that is used is essentially the same in both cases. However, the server certificate is mandatory - that is, the server must send its certificate to the client - but the client certificate is optional: some clients might not support client certificates; others might not have installed certificates. Servers can decide whether to require client authentication for a connection.

With client certificate authentication, the client is prompted by the server to supply a certificate that the server then validates and associates with a user ID in the user registry. The identity in the certificate must be mapped to a user ID in the user registry. Figure 1 illustrates the exchange.
Figure 1. TLS client authentication flow
TLS client authentication flow
  1. The client makes a request.
  2. During the handshake, the server sends its certificate and other information to the client.
  3. The client validates the server client.
  4. If client (mutual) authentication is required, the client sends its certificate and other information to the server. And the server validates the client certificate.

A client certificate is normally signed by the private key of a certificate authority (CA). To validate the certificate, the server needs to use the public key of the certificate authority. It is also possible that the CA certificate is itself signed by another CA. Such a sequence is called a certification path, and the server must have access to the public keys of all the CA certificates in the path.

Support in CICS for TLS client authentication

CICS can play the role of a server or a client in the client authentication flow. When CICS is acting as a server, the client is prompted by CICS to supply a certificate that CICS validates and associates with a user ID in RACF®. When CICS is acting as a client, the server prompts CICS to supply a certificate that is validated by the server.

You can implement TLS client authentication with CICS in the following ways:
  • CICS Liberty

    CICS Liberty uses Java Secure Sockets Extension (JSSE) as the TLS implementation. JSSE provides a framework and Java implementation that handles the handshake negotiation, including the exchange of certificates. Certificates are stored in a keystore or RACF key ring. For more information on using TLS with CICS Liberty, see Configuring confidentiality and integrity.

  • CICS

    CICS provides TLS support for IPIC requests, web requests, and CICS web services. Certificates are stored in a RACF key ring. For more information about using TLS with different TCP/IP clients, see Data in motion.

  • Application Transparent Transport Layer Security (AT-TLS)

    Application Transparent Transport Layer Security (AT-TLS) is a capability of z/OS® Communications Server. Certificates are stored in a RACF key ring. For more information, see AT-TLS.