Server Authentication communication and Digital Certificates - Overview
Sridhar K Veena 270003WY75 Visits (1211)
Note: Some of the text is used 'as is' from the IBM Redbooks. The information flow and illustration diagrams used are original.
Server Authentication communication and Digital Certificates (in z/OS):
Server Authentication Communication (SSL/TLS Protocol): This requires only the Server to auth
Note: In SSL/TLS Protocol it is also possible to enable Client Authentication, where the Server expects Client to prove its credentials after it has authenticated itself to the Client. This topic is out of scope for this document.
In the z/OS environment, digital certificates are used by Secure Sockets Layer (SSL) and Transport Layer Security (TLS) to authenticate between the client and the server. The certificates contain encryption keys that are used to encrypt the messages of the session setup protocol.
The Digital Certificates are usually issued by recognized certificate companies. They are called as CA Certificates. There are two types of CA Certificates.
Note: A CA certificate can be provided to you by a well-known CA that is in the business of providing certificate services. In addition to being commercially provided, a CA certificate can be created internally by your own company. Such a local root CA would be used to sign and validate other internal certificates.
The Digital Certificates use pair of Private and Public keys to encrypt and decrypt data. Public and private keys exist in pairs. A private key can encrypt a message, but only its associated public key can decrypt. The reverse is also true: anything encrypted with a public key can only be decrypted by the associated private key.
Private keys are never sent over a network. Generally, only one copy of a private key is ever in existence, and it resides within the key repository of that server (or client) that needs to prove its identity. Public keys are freely distributed.
Digital Signing of Certificate:
To digitally sign the certificate, the certificate issuer first generates a unique fixed-length binary value called a message digest based on the certificate contents using a hashing algorithm like SHA1 or SHA2. The exact length of the digest depends on the algorithm. The digest value is unique based on the input data (the certificate contents), but it is also re-creatable, such that another user of the same hashing algorithm and the same input data will generate the exact same value. The message digest is then encrypted using the issuer’s private key, creating the issuer’s digital signature. The hashing algorithm is included in the certificate.
Validation at the Client end on receipt of Digital Certificate from Server:
When a digital certificate is received as proof of identity, the receiver uses the issuer’s public key (found in the issuer's own certificate) to decrypt the message digest. Next, it uses the hashing algorithm specified in the certificate to create its own message digest of the certificate contents. If the newly-generated digest exactly matches the decrypted digest, then the receiver is assured that the certificate was actually signed by the trusted issuer because the issuer's public key successfully decrypted data that was encrypted using its private key, and that the certificate has not been altered since it was issued because the message digests match.
The public key of the issuer must have been placed into the certificate repository of the remote endpoint (Client). In z/OS systems these certificates are uploaded into RACF database or stored in OMVS file systems. As a general rule, public keys are freely distributed. Some are so freely available as to be populated, by default, in certificate repositories from the application or operating system vendor. For example, Windows, Linux and RACF environments already contain certificates with public keys from external vendors such as VeriSign and thawte. Such vendors are referred to as well-known Certificate Authorities, or well-known CAs.