Understanding SSL Architecture

As an administrator, make sure that you read this section thoroughly; it's critical for you to understand how to enable SSL on your GroupWise system. In the following subsection, we're going to give a very simplistic explanation of the pieces of SSL architecture pertinent to understanding how to logically set up SSL encryption in your GroupWise system.

SSL Encryption Using a Symmetric Key Method

The symmetric key method for encrypting data via SSL is one in which the hosts that communicate use the same encryption key. Security of the encrypted data between the two hosts is assured only if the encryption key is secret. In a GroupWise environment there is one scenario in which a symmetric key is used for SSL-izing data. The WebAccess Application to WebAccess Agent communication uses a symmetric key held in the COMMGR.CFG file. The key is editable via ConsoleOne. See Chapter 11, "Installing and Configuring GroupWise WebAccess," for more details about the COMMGR.CFG file.

SSL Encryption Using Public Key Infrastructure (PKI)

SSL uses two types of keys in combination with one another:

• Public keys

• Private keys

These keys allow Internet hosts to encrypt and decrypt data that will be sent to one another. If HostA wants to send encrypted data to HostB, HostA must obtain HostB's public key. Using HostB's public key, HostA encrypts its data to HostB. HostB uses its private key to decrypt the data. The same goes for how HostB sends encrypted data to HostA. HostB uses HostA's public key to encrypt data going to HostA. HostA then decrypts the data using its private key.

A public key must be signed by a certificate authority (CA). After a public key is signed, it is considered a certificate. The private key is still considered a private key, or just the key.

A certificate simply says that the public and private keys of HostA are certified by HostZ. HostZ is considered the certificate authority. HostB makes the decision as to whether to trust the certificate authority. If it does, the certificate for HostA is considered valid. HostB can send data using HostA's public key, with confidence that only HostA knows HostA's private key.

A certificate can also be self-signed, which means that the host that creates the certificate also signs the certificate. A self-signed certificate is generally used for encryption when two hosts have already established a trusted relationship with one another, and they simply need to use public and private keys to encrypt and decrypt data. The GroupWise client and the GroupWise Messenger clients both use self-signed certificates for communicating with their supporting agents.

Public Key Infrastructure and a Novell Environment

With Novell's eDirectory software fully implemented, the pieces of PKI that are relevant to this discussion are already in place. They are listed here:

• The certificate authority: All eDirectory trees version 8.x or better have a certificate authority. Figure 27.1 shows the certificate authority in the WorldWide Widgets tree. The certificate authority (CA) in your Novell eDirectory tree can sign the public keys, which will validate the key.

  Figure 27.1. The certificate authority in an eDirectory tree

  
  
  

• Public Key Generation: With Novell's Certificate Server and Certificate Server snap-ins in place, you can submit a private key. Certificate Server can generate a public key to be used in companion with the private key.