Key SSL concepts

To authenticate a peer identity, the SSL protocol uses X.509 certificates called digital certificates. Digital certificates are electronic ID cards that are issued by trusted parties and enable a user to verify both the sender and the recipient of the certificate through the use of public-key cryptography.

Public-key cryptography uses two different cryptographic keys: a private key and a public key. Public-key cryptography is also known as asymmetric cryptography, because you can encrypt information with one key and decrypt it with the complement key from a given public-private key pair. Public-private key pairs are simply long strings of data that act as keys to a user encryption scheme. The user keeps the private key in a secure place (for example, encrypted on a computer hard drive) and provides the public key to anyone with whom the user wants to communicate. The private key is used to digitally sign all secure communications sent from the user while the public key is used by the recipient to verify the sender signature.

Public-key cryptography is built on trust: the recipient of a public key needs to have confidence that the key really belongs to the sender and not to an impostor. Digital certificates provide that confidence. For this reason, the IBM Workload Scheduler workstations that share an SSL session must have locally installed repositories for the X.509 certificates that will be exchanged during the SSL session establishment phase to authenticate the session.

A digital certificate is issued by a trusted authority, also called a certificate authority. A signed digital certificate contains:
  • The owner distinguished name
  • The owner public key
  • The certificate authority (issuer) distinguished name
  • The signature of the certificate authority for these fields
A certificate request that is sent to a certificate authority for signing contains:
  • The owner (requester) distinguished name
  • The owner public key
  • The owner signature for these fields
A Certificate Authority (such as, for example, VeriSign or Thawte) is trusted by a client (or a server) application when their root certificate (that is the certificate that contains the Certification Authority signature) is listed in the client (server) trusted Certification Authority lists. The way an application creates its trusted Certification Authority list depends on the SSL implementation. Using OpenSSL, for example, the Trusted Certification Authority List is simply a file containing the concatenated Certificates of all the Certification Authorities that should be trusted. Using the z/OS® Cryptographic Services System SSL, the Trusted Certification Authority List is a proprietary database containing the certificates of the Trusted Certification Authority. The certificate authority verifies this signature with the public key in the digital certificate to ensure that the certificate request was not modified while being sent between the requester and the Certification Authority and that the requester is in possession of the private key that matches the public key in the certificate request.
The Certification Authority is also responsible for some level of identification verification. This can range from very little proof to absolute assurance of the owner identity. A particular kind of certificate is the self-signed digital certificate. It contains:
  • The owner distinguished name
  • The owner public key
  • The owner signature for these fields
A root Certification Authority digital certificate is an example of a self-signed digital certificate. Users can also create their own self-signed digital certificates for testing purposes.
The following example describes in a simplified way how digital certificates are used in establishing an SSL session. In this scenario, Appl1 is a client process that opens an SSL connection with the server application Appl2:
  1. Client Appl1 asks to open an SSL session with server Appl2
  2. Appl2 starts the SSL handshake protocol. It encrypts the information using its private key and sends its certificate with the matching public key to Appl1
  3. Appl1 receives the certificate from Appl2 and verifies that it is signed by a trusted certification authority. If it is Appl1 can optionally extract some information (such as the distinguished name) stored in the certificate and perform additional authentication checks on Appl2
  4. At this point, the server process has been authenticated, and the client process starts its part of the authentication process; that is, Appl1 encrypts the information using its private key and sends the certificate with its public key to Appl2
  5. Appl2 receives the certificate from Appl1 and verifies that it is signed by a trusted certification authority
  6. If the certificate is signed by a trusted Certification Authority, Appl2 can optionally extract some information (such as the distinguished name) stored in the certificate and perform additional authentication checks on Appl1.