CHAPTER 10 |
Secure Sockets Layer (SSL) Support
in SIMS
|
|
|
|
|
|
|
|
|
|
| |
The Secure Sockets Layer (SSL) is an open, non-proprietary security protocol. It has been submitted to the W3 Consortium (W3C) Working Group on Security for consideration as a standard security approach for World-Wide Web browsers and servers on the Internet. SSL provides data encryption, server authentication, message integrity, and optional client authentication for a TCP/IP connection.
Using SSL with SIMS ensures security between a mail client and SIMS by encrypting email content sent by the SIMS server to the email client.
A certificate is a nontransferable digital file that contains certain identifying, information. Specifically, a certificate contains the issuer's identity, the receiver's identity, and the public key. The certificate is issued from a third-party whom both parties trust. This third party is known as a Certificate Authority (CA).
A Certificate Authority (CA) can be internal--you create certificates within your organization, or external-- a third party can issue a certificate for you.
Both servers and clients can have certificates. When a server sends a certificate to a client, the process is called server authentication. When a client sends a certificate to a server the process is called client authentication. If you plan on using SSL on your server, you must obtain a server certificate from a valid CA.
Note - At the present time, SIMS only supports server authentication via SSL.
If you are already familiar with SKI, you may wish to skip to "SSL Installation" on page 218 and begin installation.
Solaris Server products that provide SSL service typically use a system called SKI as the means of implementing basic Public-Key Infrastructure (PKI) functionality, for example, key and certificate storage and management. The SKI tools permit the user to create and manage key packages (a cryptographically protected container for an entity's public and private keys), and to create and/or manage X.509 certificates. The following sections present a brief overview of those portions of SKI that will be used to administer server certificates. More information can be found in the SKI man pages whose default installation path is /opt/SUNWski/man.
While not a command that administrators will typically deal with directly, the SKI server, skiserv, is worth mentioning. The SKI server is responsible for providing a server process appropriate access to the key packages that it needs to complete a particular SSL connection. The SKI server will provide to the requesting process access to key packages on the basis of process UID and the IP address upon which the SSL connection is being accepted. In order to gain access to any given key package's private key, the SKI server must be provided with a password to unlock the key package. For server key packages, this is typically done with the
skilogin -h command. If the administrator wishes to start or stop the SKI server, she may do so with the following commands:# su root
# /etc/init.d/skiserv stopand
# /etc/init.d/skiserv start
The keypkg command is used to create and administer a server's key package(s). A server's key package must be created prior to issuing a Certificate Signing Request (CSR).
The skilogin -h command effectively binds a key package to a UID and IP address. That is, when a server process requests a key package, it will be provided on the basis of that process's UID and the IP address upon which an incoming SSL connection is being accepted. When issuing the skilogin command, the administrator must provide the password which will unlock the key package's private key. The skilogin -h command must be issued for each UID and IP binding that the administrator wishes to create.
The skilogout -h command revokes the SKI server's access to a key package. That is, it removes the binding that exists between the key package, UID, and IP address.
The skicert command allows the administrator to view and remove X.509 certificates stored in the SKI repository. Certificates are stored into the repository using the skistore command. The skicert -S command is also useful for examining certificates stored in files, for example, a certificate received from a CA.
The certreq -h command allows the administrator to issue a Certificate Signing Request (CSR) for a server key package associated with a specific UID and IP address binding. Submission of a CSR to a CA will produce an X.509 certificate.
The skistore command can be used to store an X.509 certificate into the SKI repository. Use of this command is typically the final step in the setup and installation of a server certificate.
STOP! Before actually performing the instructions described here, it is very important that you familiarize yourself with all the steps described in this section. It will also help if you review the "SSL Examples" on page 224 before attempting the actual SSL configuration. This section provides the template for the operations you will need to configure SSL for SIMS.
Before a server can use SSL, it must have public and private keys which are used for server authentication, and an X.509 certificate that vouches for its identity. The certificate contains the server's identity (in the form of an X.500 distinguished name, or DN), the server's public key, and the digital signature of the certificate authority, or CA, that issued the certificate. Generally speaking, the administrator of a service secured by SSL will need to accomplish the following steps:
These instructions will guide an administrator through the steps necessary to produce and install a server certificate, signed by either a CA created by the administrator or by a commercial CA, such as VeriSign.
| |
Choose an Appropriate Certificate Authority (CA) |
If a commercial certificate vendor is to be used, for example VeriSign, then skip to "Create the Server Key Package and Register it with SKI Key Server" on page 220. Otherwise, you will need to create an internal root certificate authority (CA) using the following instructions.
| |
Create the UNIX Account for the Internal Root CA |
Create a UNIX account for the user who will act as the Root CA. Standard practice is to locate the Root CA on a machine disconnected from the network and located in a secure area. If you configure a machine in this fashion, you will have to develop a secure methodology for information transfer. An example of this would be Certificate Signing Requests and certificates between the Root CA machine and the server machine. For testing purposes, you may wish to collocate the Root CA with the server, but be aware that this may place the integrity of the Root CA at risk.
For the purposes of these instructions, we shall select skirca as the UNIX user name of the Root CA. If you have not already done so, create a UNIX user with user id of skirca on your system used to create the Root CA.
| |
Create the Internal Root CA Credentials |
Issue the following command:
*** On the Root CA machine:
# su skirca
# /usr/bin/crcaRespond to the queries presented as follows:
| 1. | Distinguished Name: |
| Can be any X.500 distinguished name, but we suggest at minimum that the CN, O, and C attributes be specified, for example: |
| CN=SUPERDUPERCA, O=OURCO, C=US |
| 2. | Directory for Storing Root CA Credentials: |
| Specify the full pathname of the directory into which will be stored a copy of the Root CA credentials, for example: |
| /export/home/skirca/ca-creds |
| 3. | Do you want to store Root CA creds in the naming service[y/n]: |
| Enter y. |
| 4. | Finally, you will be queried for the root user password. This will permit the crca command to store the Root CA credentials into the SKI repository. |
| |
Create the Server Key Package and Register it with SKI Key Server |
Log into the server machine to be secured and issue the following commands:
*** On the server machine:
# su root
# keypkg -Ch
# skilogin -h 0
# skilogin -h <server-uid-number>You will be queried for the server/host DN. This DN should be formed in the following fashion:
CN=<common-name>,OU=<org-unit>,O=<org>,ST=<full-state-or-province-name>,C=<iso-country-code>
For example:
CN=OURCOSERVER, OU=SALES, O=OURCO, ST=CALIFORNIA, C=US
Be sure to specify all of the above listed attributes, in the order specified, as certain commercial certificate vendors, for example, Verisign, require the server DN be specified in this fashion.
The two invocations of the skilogin command will grant access to processes running with the specified UIDs. You will be queried for the password that will unlock the server key package. This is the same password that was used to lock the key package when it was created using the keypkg command. Do not lose this password or future administrative procedures may require the creation of a new server key package and certificate.
<server-uid-number> can be determined with the following command:
# id <server-uid-name>
where <server-uid-name> is the UNIX user name as which the server process is run.
Note: The SIMS message access server imaccessd by default runs as user inetmail, so for the key package to be used by this service, you would determine <server-uid-number> using the following command:
# id inetmail
If SSL is to be used in a Multiple IP Address environment, you will need to bind the key package to multiple IP addresses. For each IP address to which you wish to bind the key package, you will need to issue a command of the form:
*** On the server machine:
# skilogin -h -L <ip-address> <server-uid-number>
| |
Create the Certificate Signing Request |
Once a suitable server key package is available, you should then generate a Certificate Signing Request using the following command sequence:
*** On the server machine:
# su root
# certreq -bh <csr-file>Where <csr-file> is the pathname to a file into which will be written the Certificate Signing Request.
| |
Submit the Certificate Signing Request to the Chosen CA |
If you are using a commercial certificate vendor, present the contents of <csr-file> to the CA using the instructions provided by the certificate vendor, and then proceed to "Install the Server Certificate Produced by the CA" on page 222.
If you are using an internal root CA, as was described in "Create the Internal Root CA Credentials" on page 219, transfer the <csr-file> to the Root CA machine using whatever means are appropriate, and proceed with the following instructions:
*** On the Root CA machine:
# su skirca
# skilogin
# certify -o <server-cert-file> <csr-file>
# skilogoutwhere <server-cert-file> is a pathname to a file that will receive the new certificate.
| |
Install the Server Certificate Produced by the CA |
Assuming that you have received or produced a new certificate and have transferred its contents to the server machine, in a file we'll identify as <server-cert-file>, proceed with the following instructions:
*** On the server machine:
# su root
# skistore -c <server-cert-file> -k <server-dn>where <server-dn> is the DN from the key package that was created in "Create the Server Key Package and Register it with SKI Key Server" on page 220. For example:
# skistore -c ourco.cert -k \
'CN=OURCOSERVER, OU=SALES, O=OURCO, ST=CALIFORNIA, C=US'
| |
Install the Root CA Certificate Provided by the CA |
For SSL server security to function properly, you must install the Root CA certificate of the CA that produced your server certificate. In the general case, this is accomplished in the following fashion:
*** On the server machine:
# su root
# skistore -c <rootca-cert-file> -k <rootca-dn>
# keypkg -Ah <rootca-cert-file>where <rootca-cert-file> contains the certificate of the Root CA that created the server certificate and <rootca-dn> specifies the Root CA's DN. The
<rootca-cert-file> file must be obtained by whatever means are provided by the commercial certificate vendor. Once you have obtained the Root CA certificate, you may determine the DN of the Root CA using the following command:# skicert -S <rootca-cert-file> | egrep "Issuer" | \
awk -F\: 'print {$2}'If you have implemented an internal Root CA, you may log into the Root CA machine as the Root CA user, for example skirca, and obtain the Root CA certificate in the following manner:
*** On the Root CA machine:
# su skirca
# skicert -F -k <rootca-dn> <rootca-cert-file>for example:
# skicert -F -k 'CN=SUPERDUPERCA, O=OURCO, C=US' superduperca.cert
You may then transfer the <rootca-cert-file> to the server machine and install using the skistore/keypkg command sequence specified above.
Note - The SWS 2.1 packages included with SIMS 4.0, install copies of the most common Verisign Root CA certificates in the following directory:
/usr/http/certs
You may use the appropriate <root-ca-file> if your server certificate was produced by Verisign Inc.
After determining the DN of a Verisign Root CA certificate, note that the DN contains a comma in the O=... attribute. Depending upon the command line shell in use by the site administrator, special care must be taken to insure that the DN is correctly specified when using skistore command, for example,
# su root
#skistore -c VerisignCA.cert -k \
'OU=SECURE SERVER CERTIFICATION AUTHORITY, O=RSA DATA SECURITY‚ INC., C=US'
# keypkg -Ah VerisignCA.cert
The SIMS product ships with SSL enabled by default. Once the server credentials are properly installed, no additional administrative steps are necessary.
|
Example of Creation of Externally Signed Server Certificate: |
The following is an example of the steps taken to create a server certificate using an internal local Root CA. This example assumes the following:
|
The user "skirca" has been created as the Root CA UNIX user. |
|
|
The "skirca" home directory is: /export/home/skirca |
|
|
The Root CA is co-located on the machine on which the server certificate will be installed. This simplifies the example but should not be considered secure. |
| 1. | First, create the Root CA credentials... |
| % su skirca % /usr/bin/crca # # Distinguished Name: # Enter Distinguished Name (e.g. "o=SUN, c=US") or q[uit]: CN=SUPERDUPERCA, O=OURCO, C=US # # Directory for Storing RootCA Credentials: # Enter directory pathname under which the key package and certificate will be stored, or q[uit]. Directory name ? /export/home/skirca/rootca-creds keypkg: Generating RSA key pair for user "CN=SUPERDUPERCA, O=OURCO, C=US" \ keypkg: Enter your NEW key package password: <enter root ca key package password> keypkg: Reenter your NEW key package password: <enter root ca key package password> keypkg: Key package generation succeeded certify: Certificates issued:6, certificates available:4 # # Do you want to store RootCA creds in the naming service [y/n]: y # # Storing the RootCA creds in the naming service # You need to enter the root password Password: <enter root UNIX user password> skistore: keypkg /export/home/skirca/rootca-creds/keypkgs/skirca.KEYPKG successfully stored skistore: certificate /export/home/skirca/rootca-creds/certs/skirca.CERT successfully stored skistore: Operation Completed # # The Rootca creds are stored in the naming service |
| 2. | Next, create the server key package... |
| % su root % /usr/bin/keypkg -Ch /usr/bin/keypkg: Enter Distinguished Name of key package owner, or 'q' for 'quit': CN=OURCOSERVER, OU=SALES, O=OURCO, ST=CALIFORNIA, C=US /usr/bin/keypkg: Generating RSA key pair for user "CN=OURCOSERVER, OU=SALES, O=OURCO, ST=CALIFORNIA, C=US" /usr/bin/keypkg: Enter your NEW key package password: <enter host key package password> /usr/bin/keypkg: Reenter your NEW key package password: <enter host key package password> /usr/bin/keypkg: Key package generation succeeded % /usr/bin/skilogin -h 0 /usr/bin/skilogin: Enter host key package password: <enter host key package password> % id inetmail uid=72(inetmail) gid=6(mail) % /usr/bin/skilogin -h 72 /usr/bin/skilogin: Enter host key package password: |
| <enter host key package password> |
| 3. | Next, create the certificate signing request (CSR)... |
| % /usr/bin/certreq -bh /export/home/skirca/ourcoserver.csr % chmod a+r /export/home/skirca/ourcoserver.csr |
| 4. | Next, submit the CSR to the internal root CA... |
| % su skirca % /usr/bin/skilogin /usr/bin/skilogin: Enter your own key package password: <enter root ca key package password> |
% /usr/bin/certify -o /export/home/skirca/ourcoserver.cert /export/home/skirca/ourcoserver.csr /usr/bin/certify: Certificates issued:7, certificates available:3 |
% /usr/bin/skilogout |
| 5. | Next, install the server certificate produced by the internal root CA... |
| % su root |
% /usr/bin/skistore -c /export/home/skirca/ourcoserver.cert -k 'CN=OURCOSERVER, OU=SALES, O=OURCO, ST=CALIFORNIA, C=US' /usr/bin/skistore: certificate /export/home/skirca/ourcoserver.cert successfully stored /usr/bin/skistore: Operation Completed |
| It should now be possible to make connections to the SSL-enabled IMAP and POP ports. |
The following is an example of the steps taken to create a server certificate using an external Root CA. Verisign Inc. is the Root CA used in this example. This example assumes the following:
|
|
A working directory is available. In this example, we'll call it: /export/home/inetmail |
| 1. | First, create the server key package... |
| % su root % /usr/bin/keypkg -Ch /usr/bin/keypkg: Enter Distinguished Name of key package owner, or 'q' for 'quit': CN=OURCOSERVER, OU=SALES, O=OURCO, ST=CALIFORNIA, C=US /usr/bin/keypkg: Generating RSA key pair for user "CN=OURCOSERVER, OU=SALES, O=OURCO, ST=CALIFORNIA, C=US" /usr/bin/keypkg: Enter your NEW key package password: <enter host key package password> /usr/bin/keypkg: Reenter your NEW key package password: <enter host key package password> /usr/bin/keypkg: Key package generation succeeded % /usr/bin/skilogin -h 0 /usr/bin/skilogin: Enter host key package password: <enter host key package password> % id inetmail uid=72(inetmail) gid=6(mail) % /usr/bin/skilogin -h 72 /usr/bin/skilogin: Enter host key package password: <enter host key package password> |
| 2. | Next, create the certificate signing request (CSR)... |
| % /usr/bin/certreq -bh /export/home/inetmail/ourcoserver.csr |
| 3. | Next, submit the CSR to the external Root CA, in this case, Verisign Inc. |
| The CSR is in the file /export/home/inetmail/ourcoserver.csr, and should be submitted to Verisign using the instructions that are provided by the Verisign web site. |
| 4. | Next, install the server certificate produced by the external Root CA. |
| Verisign will email the new server certificate to the email address provided when you submitted the CSR. The message should contain a block of data that looks something like: |
| -----BEGIN CERTIFICATE----- MIIB3DCCAUUCBgUqk4+ncTANBgkqhkiG9w0BAQQFADA0MQswCQYDVQQGEwJVUzEOMAwGA1UEChQFT1VSQ08xFTATBgNVBAMUDFNVUEVSRFVQRVJDQTAeFw05OTA1MTExODM5MTZaFw0wMjA1MTAxODM5MTZaMFgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIFApDQUxJRk9STklBMQ4wDAYDVQQKFAVPVVJDTzEOMAwGA1UECxQFU0FMRVMxFDASBgNVBAMUC09VUkNPU0VSVkVSMHwwDQYJKoZIhvcNAQEBBQADawAwaAJhALJolPnUTIsg1fUNNHddMI0cx+qLbj6MhZ+4a+lufckCvS6yMr6AWiW2luQUUXf+iHG5XRxvOcQXNVGYVHx04c1HkL7JYdwuEz27vH3iPIxB1sCH3J5jXZ2KSPBbf9yAqwIDAQABMA0GCSqGSIb3DQEBBAUAA4GBAHOoo8W80J4btLNTCLyKKa0Mac9T6bv4YlupJQu8TUbCaYSnH4TgyGNCO81CN3E5Wu4MbA2qCxMBJrS8QFiF6163mZSYQ/fY7V9ym7giXe3LtgCrhPWnaNM2qrEu9KHXL/sQc1Y5J0vfq5nL/oRybAzzz8M/ukNY9lM8Vbmt4+dR -----END CERTIFICATE----- |
| Transfer this data to a file called: /export/home/inetmail/ourcoserver.cert Be sure to include the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines. |
| 5. | Next, install the server certificate produced by the external Root CA... |
| % /usr/bin/skistore -c /export/home/inetmail/ourcoserver.cert -k 'CN=OURCOSERVER, OU=SALES, O=OURCO, ST=CALIFORNIA, C=US' /usr/bin/skistore: certificate /export/home/inetmail/ourcoserver.cert successfully stored /usr/bin/skistore: Operation Completed |
| 6. | Next, install the Root CA certificate provided by the external CA... |
| % /usr/bin/skistore -c /usr/http/certs/VerisignCA.cert -k 'OU=SECURE SERVER CERTIFICATION AUTHORITY, O=RSA DATA SECURITY‚ INC., C=US' /usr/bin/skistore: certificate /usr/http/certs/VerisignCA.cert successfully stored /usr/bin/skistore: Operation Completed % /usr/bin/keypkg -Ah /usr/http/certs/VerisignCA.cert /usr/bin/keypkg: Trusted key(s) successfully added |
| It should now be possible to make connections to the SSL-enabled IMAP and POP ports. |
If for some reason you suspect the validity of the server credentials, they may be removed from the SKI repository on the server machine using the following commands:
*** On the server machine:
# su root
# skicert -Reh
# keypkg -DhThis deletes the server certificate and key package from the SKI repository.
It is possible that a Root CA certificate may expire, and that it will be necessary to remove it from the SKI repository on the server machine. This may be accomplished using the following commands.
*** On the server machine:
# su root
# keypkg -Rhs -t <rootca-dn>
# skicert -R -k <rootca-dn>This removes the Root CA public key from the trusted key list in the server's key package and removes the Root CA certificate from the SKI repository.
Because SSL installation must be absolutely perfect, it is sometimes best to simply quit and start from the beginning if you are having any doubts or problems with your initial installation. The following instructions will completely re-initialize the SKI repository on the machine on which they are run. Note that if the following commands are performed, ALL information pertaining to key packages and certificates will be lost, including any information maintained by a local Root CA:
# su root
# /etc/init.d/skiserv stop
# rm -rf /var/fn
# /etc/init.d/skiserv start
Note - Certain information pertaining to printer configuration may be lost as well.