So, do you want to secure Internet/intranet servers and clients in your organization using SSL, but you're confused about your options? This article outlines the benefits of becoming an internal Certification Authority (CA) versus obtaining certificates from an external CA, and explains the process for setting up your own CA server.

SSL is a security protocol that allows you to secure information sent over the network, validate that a message sent to a recipient arrived without tampering, authenticate the server identity to prevent server spoofing, and with SSL 3.0 available in Domino Release 4.6, authenticate the client identity. If you are unfamiliar with SSL concepts, see Hugo Curbelo and Russell Lipton's article "SSL: it's not just for commerce anymore."

The CA is the link that allows clients and servers to communicate. A CA is a person or a group of people who owns the CA certificate and creates and manages server and client certificates. The CA also issues trusted root certificates, which allow clients and servers who have certificates created by different CA's to communicate with one another.

Trusted roots are an important concept to understand when working with SSL. A client and server, or even two servers, can communicate with one another only if the server or client trying to make the connection has a trusted root certificate for the receiving server's certificate. In other words, the client or server trying to make the connection does not necessarily need a certificate stamped by the same CA as the server they are trying to connect to; however, they must have the trusted root certificate for that server's CA.

Let's take ATM machines as an everyday example of this concept. Most banks allow you to use other banks' ATM machines to perform transactions if the bank that you want to use has a network in common with your bank. For instance, if my bank is part of the Cirrus network, I can use my card at any other bank that is also a part of the Cirrus network; my ATM card can communicate with other banks' ATM machines that are also part of the Cirrus network. In this example, the CA is your bank that issues your ATM card and the Cirrus network is the trusted root used by both your bank and other banks.

The SSL certificate concept is similar to the concept of cross-certification in Notes. To allow users and servers to communicate when they have certificates from different organizations, the server or user ID must contain the certificate for the server's organization or organizational unit. Therefore, I may have a certificate issued from the /Lotus certifier, but merged into my ID is a certificate for /Iris. In this example, /Lotus correlates to the CA certificate and /Iris correlates to the trusted root certificate.

Enough on certificates and trusted roots. If you are still unclear on the concepts or need more information, see http://home.netscape.com/eng/ssl3/.

Becoming an internal CA: food for thought
Companies exist, such as Verisign, who are trusted third parties that issue client and server certificates and trusted roots. One of the most important responsibilities of these companies is to verify the person requesting the certificate. Depending on the class of certificate you request, you can be assured that the person to whom a certificate is issued is the same person to whom it is intended. This prevents people from posing as another person and possibly gaining the trust of users. The class of the certificate can vary and is an indicator of the amount of research the external CA completes before issuing a certificate.

You can also set yourself up as an internal CA, which allows you to become the trusted third party within your organization and issue server certificates and trusted roots. Coming soon in Release 4.6.1, you will also be able to issue client certificates using Notes.

Here are some things to think about before deciding to become your own CA:

• Issuing certificates is, in a sense, at no cost after you purchase the Domino and Notes software. External CA's charge a fee to issue new certificates and re-certify expired certificates. The fees can vary according to the certificate class and the company, but typical new server certificates can cost from $250 to $350 per server and upwards of $250 for a yearly renewal. Purchasing additional software that allows you to issue internal certificates is no bargain either. Typical costs for this range from $4,500 to $5,500 annually.
• An internal CA allows you to better control which servers and clients in the organization are certified and the process by which they obtain certificates. You could even set up a workflow application that streamlines the request procedure and integrate it with the process of issuing Domino and Notes server and user IDs.
• In general, issuing new certificates and renewing certificates should be faster using an internal instead of an external CA. The external CA needs time to verify the origin of the request before issuing the certificate. In contrast, the nature of being an internal CA allows for less structure and quicker turn-around time.
• The Notes applications used to set up an internal CA and manage certificates use Notes features, which many administrators are already familiar with. The administrator training for issuing certificates should, therefore, be minimal.

Setting up an internal CA server: the basics
The CA server needs a certificate for both the CA and the server. This means that you will have two key ring files on the CA server machine: one for the CA certificate and one for the server certificate.

Before getting started, you'll want to know about the two applications that are included with Release 4.6.

• Certificate Authority (certca.nsf) Lets you create the CA certificate and store it in the key ring file, sign server certificates, and add client certificates to the Public Address Book. If you use Release 4.6, you must create this database using the certca.ntf template that comes with Notes. This application contains all the activities you need to perform as an internal CA.
• Server Certificate Administration (certsrv.nsf) Lets you submit requests to a CA, merge a CA's certificate into the server key ring file as a trusted root, and manage certificates stored in the key ring file. You use this application for either internal or external CA requests. You must use this application when setting up an internal CA, since the CA server must be set up for SSL with a server certificate.

• X.509 is an industry-standard format for SSL certificates. Notes creates server certificates and, if you are using 4.6.1, client certificates using this format. Using a standard format ensures that Domino and other applications can exchange certificates easily.
• PKCS stands for Public-Key Cryptography Standards and is another industry-standard format, but this time for certificate requests. You will notice this acronym in both the Certificate Authority and Server Certificate Administration applications. All it means is that if the CA server understands how to read PKCS format, then it will understand your certificate request. This is important when you submit server certificate requests to an external CA. You need to make sure the external CA understands PKCS format and not some other format, such as PEM (Privacy-Enhanced Mail).

The application in which you complete each step is listed after each bullet.

• Create the Certificate Authority application. [Certificate Authority application]
• Create a CA certificate and merge it into the CA key ring file. [Certificate Authority application]
• Create a server certificate request for the CA server. Note: you will have two key ring files on the CA server. Do not give them the same file name. [Both the Certificate Authority and Server Certificate Administration applications]
• Approve the server certificate request using the CA certificate. [Certificate Authority application]
• Merge the CA certificate as a trusted root into the server certificate key ring file. [Both the Certificate Authority and Server Certificate Administration applications]
• Merge the approved server certificate into the server certificate key ring file. [Both the Certificate Authority and Server Certificate Administration applications]
• Turn on SSL access for the port in the Server document for the CA server. [Public Address Book]

Use the following legend to remember which application you need to be in to perform the task:

Creating the Certificate Authority application

1. Create a database using the certca.ntf template and name it certca.nsf.
2. Give yourself the CAPrivilegedUsers role in the access control list. You can also add the names of other individuals or groups acting as a CA at your organization.

Creating a CA certificate and merging it into the CA key ring file

1. Open the Certificate Authority application.
2. On the opening screen, choose Create Certificate Authority Key Ring & Certificate (step 1).
   
   
   
3. Enter a name for the key ring file and enter a password.
4. Enter the name you want to use for the CA. This is the distinguished name that you will use when issuing certificates, which will appear on the certificates that you sign.
5. Click the Create Certificate Authority Key Ring button.
6. Notes displays a confirmation of the information you just entered. Read the information to make sure that it is correct and click OK.
7. Make a backup copy of the key ring file that was just created and store it in a secure location.

1. Open the Server Certificate Administration application.
2. On the opening screen, choose Create Key Ring (step 1).
   
   
   
3. Enter a key ring name and password. Make sure you give the server key ring file a different name from the CA's key ring file.
4. Enter the components of your server's distinguished name. The common name must be the fully distinguished name of your server, for example, Jspera.lotus.com.
5. Click the Create Key Ring button.
6. Notes displays a confirmation of the information you just entered. Read the information to make sure that it is correct and click OK.
7. Click Create Certificate Request (step 2).
8. Enter the password of the server's key ring file (i.e. the one you entered in step 3 above).
9. Leave Paste into form on CA's site selected.
10. Click Create Certificate Request.
11. The information that appears in this dialog is the certificate in PKCS format. You want to copy this certificate from the Server Certificate Administration application to the Certificate Authority application. Highlight the text in the dialog box and copy it to the clipboard. Click OK.
12. Open the Certificate Authority application and choose Submit Server Certificate Request (1st option under Configuration Utilities).
    
    
    
13. Paste the request into the Certificate field on the form. The contact information is unnecessary since you are acting as both the server administrator and the CA.
14. Click Submit Certificate Request and click OK. This pastes the request into the Certificate Authority application.

1. In the Certificate Authority application, in the left hand pane, click Certificate Requests.
   
   
   
2. Open the request you just submitted.
3. Deselect the option to send mail to the administrator, since you are the administrator.
4. You can change the validity period for the certificate if you want. Otherwise, click Approve.
5. Enter the password for the CA's key ring file and click OK. Notes will also ask you for the DNS name of your server. Enter that information and click OK.

1. Open the Certificate Authority application and choose Pick Up Certificate Authority Certificate (last option on the screen).
   
   If necessary, click the Main Menu button on the action bar to display the numbered list of steps.
2. Copy the CA's certificate to the Clipboard and click Done.
   
   A word of caution: copying this certificate to the clipboard is somewhat tricky. Make sure you have only the text selected, without any spaces or margins and make sure you copy the Begin and End tags.
3. Open the Server Certificate Administration application and click Install Trusted Root Certificate Into Key Ring (step 3).
4. Enter the password for the key ring file.
5. Enter a label to use when displaying this trusted root certificate in the server key ring file.
6. Leave Clipboard selected and paste the trusted root certificate into the field provided.
7. Click Merge Trusted Root Certificate into Key Ring.

Merging the approved server certificate into the server certificate key ring file

1. In the Certificate Authority application, in the Certificate Requests view, click the action button at the top of the screen labeled "View Approved Certificate Requests."
   
   
2. Select the approved certificate and copy the PKCS format certificate to the clipboard.
   
   Don't forget -- text only; no spaces or margins.
3. Open the Server Certificate Administration application.
4. Click Install Certificate Into Key Ring.
5. Enter the password for the server key ring file.
6. Leave Clipboard selected and paste the clipboard contents into the field provided.
7. Click Merge Certificate into Key Ring and click OK to approve the merge.

1. Open the Public Address Book and edit the Server document for the CA server.
2. In the Internet Port and Security Configuration section, do the following:
• Make sure the server's key ring file name in the SSL key file field is correct.
• Select Enabled in the SSL port status field under the Web column or any other protocol that you want to use SSL.
• Make sure No is selected in the client certificate field.
• Save your changes.

3. Select the Certificate Authority application and choose File - Database - Properties. On the Basics tab select "Web Access: Require SSL connection."

At this point, browsers can connect to the server using either SSL or another Internet protocol, depending on the protocol they enter for the URL. The Database property setting for the Certificate Authority application ensures that all connections to the Certificate Authority application on the server use SSL. You could also set up the CA server so that all connections to the server require SSL by selecting Redirect to SSL in the TCP/IP port status field in the Server document.

Testing your CA server setup
Now, for the grand finale -- testing to make sure your setup works. I'll give you instructions on using a browser and a Web server to test your setup, but you can just as easily use another protocol and client software. Make sure you turned on SSL for the Web server in the Server document.

From your browser, enter the https:// protocol and the URL for your CA server and append the file name of the Certificate Authority application, for example https://Jspera.lotus.com/certca.nsf. You could also enter http:// instead of https:// and Notes will automatically redirect your URL to https:// since we told Notes to force an SSL connection when Web users try to access this database.

If everything is working correctly, the browser will display a message indicating that you don't have the certificate for the server you want to access. You should accept the certificate in your browser. After you accept the certificate, you get the opening page of the Certificate Authority application.

Here are some things to check if you run into problems.

• Make sure the Default entry in the access control list for the Certificate Authority application is set to Author with Create access. If you are prompted for a name and password when trying to access the database, the default access to the database is probably set to No Access.
• If you get a time-out error when trying to access the server, make sure your server is up and running and that you can ping it successfully.
• If the server is refusing to connect you using SSL, make sure you filled out the information correctly in the Internet Port and Security Configuration section of the Server document. Specifically, make sure SSL is turned on for the protocol you want to use and that you specified the correct name of the server's key ring file.
• Make sure your browser supports SSL and that the option is turned on in your browser.