The Advanced Certificate Request window also lets you specify various encryption and certificate options such as cryptographic provider and key size. For IDM, you accept all the default values. When you've completed your selections, click Submit to send your request to the CA. The next screen will inform you that the CA has received your certificate request and that you must wait for a network administrator to issue a certificate. (At this point, you can ask your network administrator to process your request.)
You can skip the next step if you have an enterprise CA, in which case your request for a certificate is automatically processed. But Windows pends all certificate requests for standalone CAs, and IDM has a standalone CA.
Step 3: Process the certificate request and issue a certificate. Few DBAs have the permissions to manage Certificate Authority, especially if the CA is installed on the PDC. In most cases, you have to wait for your network administrator to process the request. But if you have administrator network permissions, you can process the certificate request yourself. First, log in to the server where the CA is installed, and select Start, Programs, Administrative Tools, Certification Authority. In the Microsoft Management Console (MMC) Certification Authority snap-in, expand the Pending Requests section, find the request you just submitted, right-click the request, and select All Tasks, Issue, as Figure 4 shows. To verify success, expand the Issued Certificates section, and look for your certificate.
Step 4: Install the certificate. After getting confirmation of the certificate from your network administrator or issuing the certificate yourself, go again to the CA's Web page (http://tiga-dc-01/certsrv). On the Welcome screen that Figure 1 shows, select the Check on a pending certificate option, and click Next. On the following page, select your certificate in the list box, and click Next. On the Certificate Issued screen (which you'll get almost immediately after completing step 2 if you have an enterprise CA), click the Install this certificate option. The next page will display a confirmation that your certificate has been successfully installed.
Step 5: Verify your certificate. To verify that your machine has the certificate properly installed, right-click the IE icon on your desktop, and select Properties. Select the Content tab, and click Certificates. The certificate you just installed must be in the list for you to enable SSL encryption. Make sure that the Issued To value is your SQL Server's full network address (idmsql.tiga.tld, in this case). Select your certificate, and click View. Make sure that the bottom pane of the window says your certificate status is OK, as Figure 5 shows.
If you're working with a nonclustered installation of SQL Server, you issue the certificate to the server computer by using its full domain name. In this example, the full name of IDM's idmdb1 machine would be idmdb1.tiga.tld. The rest of the procedure is the same. For a clustered SQL Server environment, you need to repeat steps 1 through 5 for each node.
Step 6: Request SSL encryption on the server. After you successfully install certificates on all cluster nodes, go to the node that currently owns the SQL Server service and select Start, Programs, Microsoft SQL Server, Server Network Utility. Select the Force protocol encryption option, as Figure 6 shows, and click OK. This option enables encryption for all incoming connections.
Step 7: Restart the SQL Server service to start SSL encryption. To stop the SQL Server service in a clustered environment, go to any cluster node and select Start, Programs, Administrative Tools, Cluster Administration. Then, right-click SQL Server in the Active Resources section, and select Take Offline, as Figure 7 shows. Wait while SQL Server and all dependent resources (e.g., SQL Server Agent, Microsoft Search) are taken offline. Then, right-click SQL Server again, and click Bring Online. Finally, verify that the SQL Server service has started by trying to connect to it using Query Analyzer. Check the SQL Server error log to verify that the server didn't report any errors when it started.
SSL—Ready to Encrypt
To verify that you've established SSL encryption, monitor the communications between a client and SQL Server by using Network Monitor. For information about installing Network Monitor, see the Microsoft article "HOW TO: Install Network Monitor in Windows 2000" (Q243270, http://support.microsoft.com).
You also need to have the latest service packs installed in your environment. Microsoft has acknowledged that in a Win2K-based cluster, a virtual SQL Server might not start after you configure SSL encryption. The problem is fixed in SQL Server 2000 SP2. If you don't have SP2 installed on your SQL Server and you want to successfully restart your server after you force protocol encryption, you need to be sure that the SQL Server service account is part of the Administrators user group (as it is in this article's example).
You can use steps similar to those I outline in this article to enable SSL encryption for a particular client, but you'll need to use the Client Network Utility instead of the Server Network Utility to enable encryption. For more information about implementing SSL encryption on a client, see the Microsoft article "HOW TO: Enable SSL Encryption for SQL Server 2000 with Certificate Server" (Q276553, http://support.microsoft.com).
Using a clustered environment to support your Internet and e-commerce applications can improve performance and reduce system downtime, but using unencrypted communications can leave security gaps. If you use SSL encryption in your clustered environment, you can close those gaps. I hope the steps in this article will simplify setting up SSL encryption on your system.