test

Sun Java System Calendar Server 6.3 Administration Guide

7.1 Configuring SSL for Calendar Server

This section contains instructions for configuring SSL for Calendar Server.

This section contains the following topics:

ProcedureTo Create a Certificate Database

A certificate is required by the gateway to send its public keys to the clients. The certificate contains the gateway's public key, the Distinguished Name associated with the gateway's certificate, the serial number or issue date of the certificate, and the expiration date of the certificate. A certificate is issued by a certification authority (CA), which verifies the identity of the gateway. CA is an authority trusted by one or more users to issue and manage X.509 Public Key Certificates and CARLs or Certification Revocation List (CRL)s. CA is the basic building block of the Public Key Infrastructure (PKI). On the other hand, PKI is a set of policies, processes, server platforms, software and workstations used for the purpose of administering certificates and public-private key pairs, including the ability to issue, maintain, and revoke public key certificates.

The CA inserts its name in every certificate and CRL it generates and digitally signs the certificate with its private key. Once you establish that they trust a CA (directly, or through a certification path), you can trust certificates issued by that CA. You can easily identify certificates issued by that CA by comparing its name. However, its public key can be used to ensure that the certificate is valid.

The CA performs four basic PKI functions:

Your server's certificate and key pair represent your server's identity. They are stored in a certificate database that can be either internal to the server or on an external, removable hardware card (smartcard). An SSL implementation for Calendar Server requires a certificate database. The certificate database must define a Certificate Authority (CA) and certificates for Calendar Server. This section contains conceptual and task information:

Before You Begin

Before you create the certificate database, familiarize yourself with the following:

  1. Log in as or become superuser (root).

  2. Specify the certificate database password in /etc/opt/SUNWics5/config/sslpassword.conf.

    For example:


    # echo "password file entry" 
      /etc/opt/SUNWics5/config/sslpassword.conf

    The format of password file entry in the sslpassword.conf file is as follows:

    Internal (Software) Token:password

    where password is your password.

    Note that the password entry in the sslpassword.conf file must use the format shown above, including the string, Internal (Software) Token:. However, the password entry used with the password file associated with the certutil -fpasswordfile command must use the following simple format:

    password.

  3. Create the certificate database directory. For example:


    # cd /var/opt/SUNWics5
 # mkdir alias

  4. Change to the bin directory and generate the certificate database (cert8.db) and key database (key3.db). For example:


    # cd /opt/SUNWics5/cal/bin
 # ./certutil -N -d /etc/opt/SUNWics5/config
                 -f /mypath/mypassworfile
    Note –

    For this and other times when you must run the certutil utility, follow the examples exactly, or consult the certutil help page to understand the syntax.

    For example, in this case, do not run the utility with the -N option without also specifying the -d /file information.

  5. Generate a default self-signed root Certificate Authority certificate. For example:


    # ./certutil -S -n SampleRootCA -x -t "CTu,CTu,CTu"
 -s "CN=My Sample Root CA, O=sesta.com" -m 25000
 -o /etc/opt/SUNWics5/config/SampleRootCA.crt
 -d /etc/opt/SUNWics5/config
 -f /mypath/mypassworfile -z
 /etc/passwd

  6. Generate a certificate for the host. For example:


    # ./certutil -S -n SampleSSLServerCert -c SampleRootCA 
 -t "u,u,u"
 -s "CN=hostname.sesta.com, O=sesta.com" -m 25001
 -o /etc/opt/SUNWics5/config/SampleSSLServer.crt
 -d /etc/opt/SUNWics5/config 
 -f /mypath/mypassworfile
 -z /etc/passwd

    where hostname.sesta.com is the server host name.

  7. Validate the certificates. For example:


    # ./certutil -V -u V -n SampleRootCA  
    -d /etc/opt/SUNWics5/config
 # ./certutil -V -u V -n SampleSSLServerCert 
   -d /etc/opt/SUNWics5/config

  8. List the certificates. For example:


    # ./certutil -L -d /etc/opt/SUNWics5/config
 # ./certutil -L -n SampleSSLServerCert 
   -d /etc/opt/SUNWics5/config

  9. Use modutil to list the available security modules (secmod.db). For example:


    # ./modutil -list -dbdir /etc/opt/SUNWics5/config

  10. Change the owner of the alias file to icsuser and icsgroup (or the user and group identity under which Calendar Server will run). For example:


    # find /etc/opt/SUNWics5/config -exec chown icsuser {};
 # find /etc/opt/SUNWics5/config -exec chgrp icsgroup {};

7.1.1 Self-signed Certificate

A self-signed certificate is signed with the gateway's own private key. Self-signed certificates are not secure, but they can be used to test applications that require certificates before a signed certificate is available for use. A self-signed certificate uses its own certificate request as a signature rather than the signature of a CA.

There are ten common fields in which six are mandatory and four are optional in creating a self-signed certificate through PKI. The serial number, certificate signature algorithm identifier, certificate issuer name, certificate validity period, public key, and the subject name are the mandatory fields. The optional fields are the version number, two unique identifiers, and the extension. These optional fields appear only in version 2 and 3 certificates.

The mandatory Validity field indicates the dates on which the certificate becomes valid and the date on which the certificate expires. The default value for expiration date provided in the NSS certutils is three months. However, the validity data in a certificate become unreliable before the expiration date arrives. The X.509 CRL mechanism provides a status update for the certificates they have issued and to take care about the certificate expiration dates. Also, CA enforces certificate expiration to one or two years.

When a certificate is expired or its validity date is over, it needs to be renewed. Renewal is an act or process of extending the validity of the data binding asserted by a public key certificate by issuing a new certificate. You can validate a certificate using the command:

-V -n certname -b validity-time -u certusage [-e] [-l] [-d certdir]

The following example shows how to use the command to validate a certificate:

certutil -V -n jsmith@netscape.com -b 9803201212Z -u SR -e -l -d certdir.

The Certificate Database Tool shows results similar to the following:

Certificate:'jsmith@netscape.com' is valid.

or

UID=jsmith, E=jsmith@netscape.com, CN=John Smith, O=Netscape Communications Corp., C=US : Expired certificate

or

UID=jsmith, E=jsmith@netscape.com, CN=John Smith, O=Netscape Communications Corp., C=US : Certificate not approved for this operation

ProcedureTo Request and Import a Certificate from a Root Certificate Authority

The following steps tell you how to generate a certificate request, submit it to the Public Key Infrastructure (PKI) Web site, and then import the certificate. These instruction assume you are placing the certificate database under the config directory.

Before You Begin

Both the certificate database and the password file must reside in the same directory. The default shown here is the config directory, but you can choose another directory, in which case, you must configure a different path parameter, as shown in the procedure that follows.

  1. Log in as or become superuser (root).

  2. Move to the bin directory:

    # cd /opt/SUNWics5/cal/bin

  3. Use certutil to generate a Certificate Request based on the Certificate Authority or Public Key Infrastructure (PKI) Web site. For example:


    # ./certutil -R -s "CN=hostname.sesta.com, 
OU=hostname/ SSL Web Server, O=Sesta, 
C=US" -p "408-555-1234" -o hostnameCert.req 
-g 1024  -d /etc/opt/SUNWics5/config 
-f /mypath/mypassworfile  -z /etc/passwd -a

    where “hostname.sesta.com” is the host name.

  4. Request an test certificate for an SSL web server from the Certificate Authority or Public Key Infrastructure (PKI) Web site. Copy and paste the contents from the hostnameCert.req file into the Certificate Request.

    You will be notified by when your certificate is signed and can be picked up.

  5. Copy the Certificate Authority Certificate Chain and SSL server certificate into text files.

  6. Import the Certificate Authority Certificate Chain into the certificate database to establish a Chain of Authority. For example:


    # ./certutil -A -n "GTE CyberTrust Root"
    -t "TCu,TCu,TCuw" 
    -d /etc/opt/SUNWics5/config 
    -a 
    -i /export/wspace/Certificates/CA_Certificate_1.txt
    -f /mypath/mypassworfile
# ./certutil -A -n "Sesta TEST Root CA" 
    -t "TCu,TCu,TCuw" 
    -d /etc/opt/SUNWics5/config 
    -a 
    -i /export/wspace/Certificates/CA_Certificate_2.txt
    -f /mypath/mypassworfile

  7. Import the signed SSL server certificate:


    # ./certutil -A -n "hostname SSL Server Test Cert"
    -t "u,u,u" -d /etc/opt/SUNWics5/config 
    -a 
    -i /export/wspace/Certificates/SSL_Server_Certificate.txt
    -f /mypath/mypassworfile

  8. List the certificates in the certificate database:

    # ./certutil -L -d /etc/opt/SUNWics5/config

  9. Configure the SSL Server Nickname in the ics.conf file to be the signed SSL server certificate, For example: “hostname SSL Server Test Cert”.

    Note The host name for the service.http.calendarhostname and service.http.ssl.sourceurl parameters in the ics.conf file should match the host name on the SSL certificate (in case your system has several aliases). For example: calendar.sesta.com

ProcedureTo Configure SSL Parameters in the ics.conf File

To implement SSL with Calendar Server, you must set specific parameters in the ics.conf file. If any of the parameters listed in the following table are not in the ics.conf file, add them to the file with the value specified. Since the ics.conf is read only at system startup (when start-cal is issued), the new values will not take effect until the Calendar Server is restarted. For a description of these SSL parameters, see E.2.10 Calendar Server SSL Configuration Parameters.

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit one or more of the parameters as shown in the following table:

    Parameter 

    Value 

    encryption.rsa.nssslactivation

    "on"

    encryption.rsa.nssslpersonalityssl

    "SampleSSLServerCert"

    encryption.rsa.nsssltoken

    "internal"

    service.http.tmpdir

    "/var/opt/SUNWics5/tmp"

    service.http.uidir.path

    "html"

    service.http.ssl.cachedir

    "."

    service.http.ssl.cachesize

    "10000"

    local.ssldbpath

    "/etc/opt/SUNWics5/config"

    service.http.ssl.port.enable

    "yes"

    service.http.ssl.port

    "443" (Default SSL port)

    Note –

    Not on port "80", which is the HTTP default port.

    service.http.securesession

    "yes" (Entire session encrypted)

    service.http.ssl.sourceurl

    "https://localhost:port" (Supply the name of your localhost, and the service.http.ssl.port value.)

    service.http.ssl.ssl3.ciphers

    "rsa_red_40_md5,

    rsa_rc2_40_md5,

    rsa_des_sha,

    rsa_rc4_128_md5,

    rsa_3des_sha"

    service.http.ssl.ssl3.sessiontimeout

    "0"

    service.http.sslusessl

    "yes"

  5. Save the file as ics.conf.

  6. Restart Calendar Server for the changes to take effect.

    cal-svr-base/SUNWics5/cal/sbin/start-cal