Client authentication

Client authentication provides additional authentication and access control by checking client certificates at the server. This support prevents a client from obtaining a connection without an installation approved certificate.

The server authenticates the client by receiving the client's certificate during the SSL handshake and verifying the certificate is valid. Validation is done by the server the same way the client validates the server's certificate. The client sends a signed certificate to the server. System SSL at the server decrypts the signature (message digest) using the public key of the client certificate issuer found in the server key database file. The server then creates a new message digest using the certificate's Distinguished Names and public key and compares the new message digest with the decrypted one. If they match, the server can be assured the client is authentic. Depending on where the client certificate is stored, up to three different levels of client authentication are available. See the security information for the appropriate server or client for setup details.

Level 1 authentication is performed by System SSL. The client passes an X.509 certificate to the Server as part of the SSL Handshake. To pass authentication, the Certificate Authority (CA) that signed the client certificate must be considered trusted by the server. That is, the certificate for the CA must be in the key ring used by the Server and designated as trusted. Note that the value of this option alone is based on which CAs are considered trusted. If the CA is a public CA and the certificate is in an easily obtained class, anyone can obtain such a certificate. In this case passing level 1 SSL Client Authentication does not provide much additional security unless coupled with the level 2 RACF® support. If the CA is controlled by the enterprise, some level of access control is provided because the client that possesses such a certificate is at least known to the organization.

In addition to the checking done with the first level of client authentication support, level 2 authentication requires that the client certificate is registered with RACF or another SAF-compliant security product and is mapped to a valid z/OS® user ID. The client certificate that is received during the SSL handshake is used to query the security product to verify that the certificate maps to a user ID known to the system before connection negotiation. This level of support provides extra access control at the server and ensures that the user is known to have a valid user ID on the server host. Each server uses the returned user ID in a different way. To see how the user ID is used for a particular server, see the security information for the appropriate server or client. Level 1 authentication occurs before level 2 authentication.

Level 3 authentication provides, in addition to level 1 and level 2 support, the capability to restrict access to the server based on the user ID returned from RACF. In some cases a certificate may be valid and mapped to a user ID but should be valid for only one of several servers. The third level of control uses the SERVAUTH RACF class to restrict access to the server based on client user ID. If the SERVAUTH class is not active or the SERVAUTH profile for the server is not defined, it is assumed level 3 authentication is not requested. If the SERVAUTH class is active and the server profile is defined, a connection is accepted only if the requester's user ID associated with the client certificate is in the profile. Otherwise, the connection is dropped.

Level 1 client authentication is done by SSL using a gskkyman key ring or a RACF key ring. If the client certificate was issued by a well-known Certificate Authority, it is likely the CA certificate is already primed in the gskkyman key ring. The CA certificate is probably also in RACF. However, all CA certificates in RACF initially have a status of NOTRUST. The CA certificate must be set to TRUST and connected to the appropriate RACF key ring. If the certificate issuer (a CA or self-signed) is not part of the list of well-known CAs, the key ring must be primed with the signer certificate of the CA or the self-signed client certificate.

After Level 1 authentication is performed by SSL using either key ring, the certificate is passed to the server which accesses the RACF database for Level 2 and Level 3 authentication.