Managing Microsoft Certificate Services and SSL
The focus of the previous chapter was on Web server security. This chapter shows how you can extend Web server security using Microsoft Certificate Services and Secure Sockets Layer (SSL). Certificate Services and SSL provide an extra layer of security that you can add to your Web server.
You use Certificate Services and SSL to protect sensitive information, such as passwords, credit card numbers, or payment information. Certificate Services and SSL protect sensitive information by encrypting the data sent between client browsers and your server. Encryption is the process of encoding information using a mathematical algorithm that makes it difficult for anyone other than the intended recipient to view the original information.
Internet Information Services (IIS) transfers encrypted data to a client browser using the SSL protocol. With SSL, servers and/or clients use certificates to provide proof of identity prior to establishing a secure connection. Once a connection is established, clients and servers use the secure SSL channel to transfer information. This information is encrypted using a technique that the clients and servers can interpret to extract the original information.
On This Page
Understanding SSL
Working with Microsoft Certificate Services
Creating and Installing Certificates
Working with SSL
Managing Site Certificates in the Internet Information Services Snap-In
Understanding SSL
IIS supports SSL version 3.0. SSL 3.0 enables encrypted data transfers between client browsers and Web servers. The sections that follow provide an overview on how SSL works and how it is used.
Using SSL Encryption
As stated previously, encryption is the process of encoding information using a mathematical algorithm that makes it difficult for anyone other than the intended recipient to view the original information. The encryption algorithm uses a mathematical value, called a key, to scramble the data so that it can be recovered only by using the key.
Many techniques are available for encrypting information so that it can be exchanged. Some encryption techniques use a combination of public and private keys—one key can be shared and the other key can't be shared. Some encryption techniques use shared secret keys that are transferred between authenticated systems. SSL uses a technique called public key encryption, which combines private, public, and shared secret (session) keys.
In public key encryption, there are three keys:
- A public key available to any application that requests it
- A private key known only to its owner
- A session key created using public and private key data
IIS uses the public key encryption component in SSL to establish sessions between clients and servers. You should use SSL anytime you want to provide additional protection for data that is transferred between clients and servers. Some specific instances in which you may want to use Certificate Services and SSL are the following:
- When you remotely manage the Web server using the Administration Web site or operator administration pages
- When your World Wide Web site has secure areas that contain sensitive company documents
- When your Web site has pages that collect sensitive personal or financial information from visitors
- When your Web site processes orders for goods or services and you collect credit information from customers
With SSL, users connect to Web pages using a secure Uniform Resource Locator (URL) that begins with
https://. The
https designator tells the browser to try to establish a secure connection with IIS. SSL connections for Web pages are made on port 443 by default, but you can change the port designator as necessary. As you set out to work with SSL, keep in mind that you cannot use host headers with SSL. With SSL, Hypertext Transfer Protocol (HTTP) requests are encrypted, and the host header name within the encrypted request cannot be used to determine the correct site to which a request must be routed.
After the client browser contacts the server using a secure URL, the server sends the browser its public key and server certificate. Next the client and server negotiate the level of encryption to use for the secure communications. The server will always attempt to use the highest level of encryption it supports. Once the encryption level is established, the client browser creates a session key and uses the server's public key to encrypt this information for transmission. Anyone intercepting the message at this point would not be able to read the session key—only the server's private key can decrypt the message.
The IIS server decrypts the message sent by the client using its private key. The SSL session between the client and the server is now established. The session key can be used to encrypt and decrypt data transmitted between the client and server.
To recap, secure SSL sessions are established using the following technique:
- The user's Web browser contacts the server using a secure URL.
- The IIS server sends the browser its public key and server certificate.
- The client and server negotiate the level of encryption to use for the secure communications.
- The client browser encrypts a session key with the server's public key and sends the encrypted data back to the server.
- The IIS Server decrypts the message sent by the client using its private key, and the session is established.
- Both the client and the server use the session key to encrypt and decrypt transmitted data.
Using SSL Certificates
Not reflected in the previous discussion is the way in which SSL uses certificates. You can think of a certificate as an identity card that contains information needed to establish the identity of an application or user over a network. Certificates enable Web servers and users to authenticate one another before establishing a connection. Certificates also contain keys that need to establish SSL sessions between clients and servers.
In most cases, certificates used by IIS, Web browsers, and Certificate Services conform to the X.509 standard. For this reason, they are often referred to as X.509 certificates. Different versions of the X.509 standard have been issued. These versions have been extended from time to time as well. Two types of X.509 certificates are used:
- Client certificates, which contain identifying information about a client
- Server certificates, which contain identifying information about a server
Certificate authorities (CAs) issue both types of certificates. A CA is a trusted agency responsible for confirming the identity of users, organizations, and their servers and then issuing certificates that confirm these identities. Before issuing a client certificate, CAs require you to provide information that identifies you, your organization, and the client application you are using. Before issuing a server certificate, CAs require you to provide information that identifies your organization and the server you are using.
This chapter focuses on server certificates. You have several options when choosing CAs to create your server certificates. If you use Certificate Services, your organization can act as its own CA. When you act as your own CA, you enable SSL on your Web server using the following process:
- Install Certificate Services on a server in the domain and then generate the root CA certificate.
- Generate a certificate request file for each Web site on your server that has a unique name, and then use the certificate request files to create server certificates for your Web sites.
- Install the certificates and then enable SSL on each applicable Web site.
- Your root CA certificate won't be recognized and trusted by client browsers. To get browsers to trust the root CA, the user must install the certificate in the browser's authorities store.
- Initiate SSL connections by using URLs that begin with https://.
You can also use third-party CAs—and there's an advantage here. The third-party authority can vouch for your identity, and dozens of vendors are already configured as trusted CAs in Web browsers. In Microsoft Internet Explorer 5.0, you can obtain a list of trusted authorities by completing the following steps:
- From the Tools menu, select Internet Options. This displays the Internet Options dialog box.
- Click the Content tab and then click Certificates. This displays the Certificates dialog box.
- Click the Trusted Root Certification Authorities tab. You should now see a list of trusted root CAs.
When you use a trusted third-party authority, you enable SSL on your Web server using a different process from when you act as your own root CA. This process is as follows:
- Generate a certificate request file for each Web site on your server that has a unique name.
- Submit the certificate request files to a trusted third-party authority, such as Entrust, Equifax, Valicert, or Verisign. The CA will process the requests and send you back certificates.
- Install the certificates and then enable SSL on each applicable Web site.
- Client browsers initiate SSL sessions using a secure URL beginning with https://.
Regardless of whether you act as your own CA or use a trusted CA, you must still manage the server certificates, and you use Certificate Services to do this. Server certificates can expire or be revoked, if necessary. For example, if your organization is an Internet service provider (ISP) that issues its own certificates, you may want your customers' server certificates to expire on an annual basis. This forces customers to update their certificate information at least once per year to ensure it is current. You may also want to revoke a certificate when a customer cancels service.
Understanding SSL Encryption Strength
The encryption strength of an SSL session is directly proportional to the number of bits in the session key. This means that session keys with a greater number of bits are considerably more difficult to crack and, thus, are more secure.
The two most commonly used encryption levels for SSL sessions are 40-bit and 128-bit. Encryption at the 40-bit level is adequate for most needs, including e-commerce. Encryption at the 128-bit level provides added protection for sensitive personal and financial information. Versions of Microsoft Windows 2000 shipped in the United States are configured with 128-bit encryption. Export versions of Windows 2000 have 40-bit encryption. To upgrade a server from 40-bit encryption to 128-bit encryption, you must install the 128-bit upgrade patch, which is available from Microsoft.
Don't confuse the encryption level for SSL sessions (the strength of the session key expressed as bits) with the encryption level for SSL certificates (the strength of the certificate's public and private keys expressed as bits). Most encryption keys (public and private) have a bit length of 512 or 1024. Domestic U.S. and export versions of most applications and operating systems support encryption keys with a bit length of 512. However, encryption keys with a bit length of 1024 or greater are not supported in the export versions of most applications and operating systems.
When a user attempts to establish an SSL session with your Web server, the user's browser and the server use the bit length of their encryption keys to determine the strongest level of encryption possible. If the encryption keys use 512 bits, the level of encryption is set to 40 bits. If the encryption keys use 1024 bits, the level of encryption is set to 128 bits. Other key bit lengths and encryption levels are available.
Working with Microsoft Certificate Services
Microsoft Certificate Services allows you to issue and revoke digital certificates. These certificates can be used to enable SSL sessions and to authenticate the identity of your intranet, extranet, or Internet Web site.
Understanding Certificate Services
Certificate Services is a Windows service that runs on a designated certificate server. Certificate servers can be configured as one of four types of certification authorities:
- Enterprise root CA An enterprise root CA is the certificate server at the root of the hierarchy for a Windows domain. It is the most trusted CA in the enterprise and must have access to Active Directory service.
- Enterprise subordinate CA An enterprise subordinate CA is a certificate server that will be a member of an existing CA hierarchy. It can issue certificates but must obtain its own CA certificate from the enterprise root CA.
- Stand-alone root CA A stand-alone root CA is the certificate server at the root of a nonenterprise hierarchy. It is the most trusted CA in its hierarchy and doesn't need access to Active Directory service.
- Stand-alone subordinate CA A stand-alone subordinate CA is a certificate server that will be a member of an existing nonenterprise hierarchy. It can issue certificates but must obtain its own CA certificate from the stand-alone root CA in its hierarchy.
Certificate servers don't have to be dedicated to Certificate Services and can be the same servers you use for Web publishing. However, it is a good idea to designate specific servers in your domain that will act as certificate servers and to use these servers only for that purpose. Once you install Certificate Services on a computer, you are limited in what you can and cannot do with the computer. Specifically, you cannot do the following:
- You cannot rename a computer running Certificate Services.
- You cannot change the domain membership of a computer running Certificate Services.
Certificate Services is managed using a Microsoft Management Console snap-in called Certification Authority snap-in, and a Web-based Active Server Page (ASP) application that can be accessed in a standard Web browser. In the snap-in, you have full control over Certificate Services. The Web-based application, on the other hand, is primarily used to retrieve certificate revocation lists (CRLs), to request certificates, and to check on pending certificates.
Figure 6-1 shows the main window of the Certification Authority snap-in. As you can see, there are four nodes under the root authority. These nodes are used as follows:
Note: The label for the root node of the snap-in is set to the name of the CA. In the example, the CA name is Corporate Root CA.
Installing Certificate Services
Installing Certificate Services is a multipart process. First, you must create a folder that Certificate Services can use to store certificates and configuration files. The folder must be stored on the local machine where Certificate Services will be installed. The folder must also be configured with Read permission for the implicit group Everyone. This allows users to access the folder and to install certificates from it. Second, if the server isn't running IIS and you want to be able to retrieve CRLs to request certificates or to check on pending certificates via a browser, you must install IIS on the certificate server.
After you create the certificate folder and install IIS, if necessary, you need to install Certificate Services. To do this, complete the following steps:
- Log on to the certificate server using an account with Administrator privileges, or Domain Administrator privileges if you're creating an enterprise CA.
- Click Start, point to Settings, and then click Control Panel.
- Double-click Add/Remove Programs. This displays the Add/Remove Programs dialog box.
- Start the Windows Components Wizard by clicking Add/Remove Windows Components.
- Select the Certificate Services check box. When prompted to confirm the action, click Yes, and then click Next.
As shown in Figure 6-2, select the CA type. The options are as follows:
Next, as shown in Figure 6-3, enter information to identify the CA and to set the expiration date of the root CA certificate. Provide complete entries for the following fields:
- Next, specify the storage location for the configuration data, database, and log. By default, the certificate database and log are stored in the \%SystemRoot%\System32\CertLog folder. Also, use the Shared Folder field to specify the location of the certificate folder you created earlier, or click Browse to find this folder.
- Click Next. If IIS is running on the certificate server, Windows will need to shut down the related services before continuing. Click OK when prompted to do this. The Windows Components Wizard will begin installing and configuring Certificate Services.
- Click Finish to complete the process. If you installed Certificate Services on a computer running IIS, you can configure these services for Web access (see the section of this chapter titled, "Accessing Certificate Services in a Browser").
Accessing Certificate Services in a Browser
When you install Certificate Services on a computer running IIS, the default (or primary) Web site is updated so that you can perform key certificate tasks via a Web browser. These tasks include
- Retrieving CRLs
- Requesting certificates
- Checking on pending certificates
The structures that make Web-based requests possible are files configured for use in three virtual directories:
- CertSrv Contains files necessary for Web-based access to Certificate Services and is located in \%SystemRoot%\System32\CertSrv by default. This directory is set up as an in-process Internet Server Application Programming Interface (ISAPI) application called CertSrv.
- CertControl Contains files necessary for controlling Certificate Services and is located in \%SystemRoot%\System32\CertSrv\CertControl by default.
- CertEnroll Contains files necessary for controlling Certificate Services and is located in \%SystemRoot%\System32\CertSrv\CertEnroll by default.
If these directories are not available for some reason, you can create virtual directories that map aliases to their physical locations. You do this by completing the following steps:
- Start the Internet Information Services snap-in and then, in the left panel (Console Root), click the plus sign (+) next to the computer you want to work with. If the computer isn't shown, connect to it as discussed in the "Connecting To Other Servers" section of Chapter 2, "Core IIS Administration."
- Right-click the Web site on which you want to link the system directory, point to New, and then select Virtual Directory. This starts the Virtual Directory Creation Wizard. Click Next.
- In the Alias field, type the name you want to use to access the system directory, such as CertSrv.
- The next dialog box lets you set the path to the physical directory where your content is stored. Click Browse to search for the system directory you want to use.
- Click Next and then set access and execute permissions. For CertSrv, CertControl, and CertEnroll, select Read, and then select Scripts Only.
- Click Next and then click Finish. The virtual directory is created and mapped to the system directory you referenced. The CertSrv directory should be configured as an ISAPI application with a starting point that points to its base directory. CertControl and CertEnroll should be a part of an application as well, but these don't need to be configured as separate applications.
Once you've configured Web-based access to Certificate Services, you can access these services by typing the following URL:
http://hostname/certsrv/
where
host name is the DNS or NetBIOS name of the host server, such as ca.microsoft.com or CASrv. Figure 6-4 shows the main page for Certificate Services.
Figure 6-4: Use the Web-based interface to retrieve CA certificates or revocation lists, to request certificates, or to check on pending certificates.
Starting and Stopping Certificate Services
Microsoft Certificate Services runs as a Windows service on the certificate server. You can stop and start this service on a local system by completing the following steps:
- Start the Certification Authority snap-in, then right-click the root node for the CA (Root CA) and point to All Tasks.
- Select Stop Service to stop Certificate Services.
- Select Start Service to start Certificate Services.
You can stop and start services on a remote system by completing the following steps:
- Start the Certification Authority snap-in and then right-click the CA node.
- To display the Certification Authority dialog box, from the shortcut menu, select Retarget Certification Authority.
- As shown in Figure 6-5, select Another Computer, type the name of the computer to which you want to connect, and then click Finish. You can also type the server's Internet Protocol (IP) address or fully qualified domain name (FQDN).
Figure 6-5: You can connect to both local and remote certification authorities.
- In the Certification Authority snap-in, right-click the root node for the CA (Root CA), then point to All Tasks.
- Select Stop Service to stop Certificate Services.
- Select Start Service to start Certificate Services.
Backing Up and Restoring the CA
If your organization publishes its own CA, you should routinely back up the CA information. Backing up the CA information ensures that you can recover critical CA data, including
- CA private key and certificate
- CA configuration information
- CA log and pending request queue
You can perform two types of backups:
- Standard Creates a full copy of certificate logs and pending request queues.
- Incremental Creates a partial copy of certificate logs and pending request queues. This copy contains only the changes since the last standard backup.
In a very large CA implementation, you can perform incremental backups of logs and queues by selecting Perform Incremental Backups. To use incremental backups, you must do the following:
- First perform a standard backup.
- Perform successive incremental backups at later dates.
When you use incremental backups, you must also incrementally restore. To do this, complete the following steps:
- Stop Certificate Services.
- Restore the last standard backup.
- Restore each incremental backup in order.
- Start Certificate Services.
Creating CA Backups
To back up the CA information on your certificate server, complete the following steps:
- Create a folder that Certificate Services can use to store the backup information. This directory must be empty and it should created on the local machine where Certificate Services is installed.
- Start the Certification Authority snap-in, right-click the root node for the CA (Root CA), point to All Tasks, and then select Backup CA. This starts the Certification Authority Backup Wizard.
Note: Certificate Services must be running when you back up the CA. If the service isn't running, you'll see a prompt asking you if you want to start the service. Click OK.
Click Next and then select the items you want to back up, as shown in Figure 6-6. The options are
- If this is an incremental backup, select Perform Incremental Backup.
- Type the file path to the backup folder in the Back Up To This Location field, or click Browse to search for this folder. If you specify a folder that does not already exist, you will be given the option of having it created.
- Click Next. Type and then confirm a password that will be used to protect the private key and CA certificate files.
- Click Next and then click Finish. The wizard creates a backup of the selected data.
Recovering CA Information
If you ever need to recover the CA information, you can do this by completing the following steps:
- The Certificate Services cannot be running when you restore the CA. In the Certification Authority snap-in, right-click the root node for the CA (Root CA), point to All Tasks, and then select Stop Service.
- Right-click the root node a second time, point to All Tasks, and then select Restore CA. This starts the Certification Authority Restore Wizard.
Click Next and then select the items you want to restore, as shown in Figure 6-7. The options are
- Type the file path to the backup folder in the Restore From This Location field, or click Browse to search for this folder. You should always restore the last complete backup before restoring any incremental backups.
- Click Next. Type the password used to protect the CA files and then click Next again.
- Click Finish. The wizard restores the selected data. When the operation is complete, you have the option of starting Certificate Services. Click Yes if this is only a backup to restore. Otherwise, click No, and repeat this process to apply incremental backups as well.
Approving and Declining Pending Certificate Requests
Pending certificate requests are displayed in the Pending Requests node of the Certification Authority snap-in.
You can approve pending requests as follows:
- Start the Certification Authority snap-in and then select the Pending Requests node. You should see a list of pending requests.
- Right-click the request that you want to approve, point to All Tasks, and then select Issue.
- Certificate Services generates a certificate based on the request and places this certificate in the Issued Certificates queue.
- Certificates are valid for one year. After this period, they must be renewed.
You can decline pending certificate requests as follows:
- Start the Certification Authority snap-in and then select the Pending Requests node. You should see a list of pending requests.
- Right-click the request that you want to decline, point to All Tasks, and then select Deny.
- When prompted to confirm the action, select Yes.
- Denied requests are moved to the Failed Requests queue and cannot be restored. The user must resubmit a new request.
Generating Certificates Manually in the Certification Authority Snap-In
Once you've issued a certificate, you can manually create the certificate file that you need to install on the Web site. To do this, complete the following steps:
- Start the Certification Authority snap-in and then select the Issued Certificates node. You should see a list of certificates issued by this root CA.
- Right-click the certificate that you want to generate and select Open. This displays the Certificates dialog box.
- Select the Details tab and then select Copy To File. This starts the Certificate Export Wizard. Click Next.
- Select the Base-64 Encoded X.509 export file format, and then click Next.
- Specify the name of the file you want to export. Be sure to use .cer as the file extension. Click Browse if you want to use the Save As dialog box to set the file location and name.
- Click Next and then click Finish. Click OK after the Certificate Export Wizard confirms that the certificate was successfully exported. You can now install the certificate file on the Web site as described in the section of this chapter titled "Processing Pending Requests and Installing Site Certificates."
Revoking Certificates
Server certificates are valid for one year and can be revoked if necessary. Typically, you revoke a certificate when there is a change in the status of the site or when the customer for whom you issued the certificate cancels the service subscription. To revoke a certificate, complete the following steps:
- Start the Certification Authority snap-in and then select the Issued Certificates node. You should see a list of issued certificates.
- Right-click the certificate that you want to revoke, point to All Tasks, and then select Revoke Certificate. The Certificate Revocation dialog box is displayed.
- As shown in Figure 6-8, use the Reason Code to specify a reason for the revocation, and then click Yes.
- The CA marks the certificate as revoked and moves it to the Revoked Certificates node.
Figure 6-8: Specify the reason you are revoking the certificate.
By default, CAs publish CRLs weekly. You can change this setting through the Revoked Certificates Properties dialog box.
- Start the Certification Authority snap-in and then right-click the Revoked Certificates node.
- Select Properties and then use the Publication Interval fields to set a new interval for publishing the CRL, as shown in Figure 6-9.
- Click OK.
Figure 6-9: Set the schedule for publishing the CRL. By default, the publication interval is one week.
Reviewing and Renewing the Root CA Certificate
The root CA certificate is valid for the period specified when the certificate was created. To view the expiration date or to review the certificate properties, complete the following steps:
- Start the Certification Authority snap-in. Right-click the root node for the CA (Root CA) and then select Properties. This displays the Root CA Properties dialog box.
- Click View Certificate on the General tab.
- As shown in Figure 6-10, use the Certificate dialog box to review the properties of the root CA certificate, including the valid from and to dates.
Figure 6-10: The Certificate dialog box shows the properties of the root CA certificate, including the valid from and to dates.
Usually, the root CA certificate is valid for two years. If you are approaching the end of the two-year period, you should renew the certificate. You should also renew the root CA certificate if one of the following situations exists:
- The signing key is compromised
- A program requires a new signing key to be used with a new certificate
- The current CRL is too big and you want to move some of the information to a new CRL
To renew the root CA certificate, complete the following steps:
- The Certificate services cannot be running when you renew the CA. In the Certification Authority snap-in, right-click the root node for the CA (Root CA), point to All Tasks, and then select Stop Service.
- Right-click the root node for the CA (Root CA) again, point to All Tasks, and then select Renew CA Certificate. This displays the Renew CA Certificate dialog box shown in Figure 6-11.
Figure 6-11: When you renew the root CA certificate, you can generate new public and private keys. Do this if the key has been compromised or a new key is required.
- In the Renew CA Certificate dialog box, select Yes if you want to generate a new public and private key pair. Otherwise, click No.
- Click OK. Certificate Services is restarted automatically and a new certificate is issued.
Creating and Installing Certificates
You have two options for creating and installing certificates. You can use your own Certificate Services to generate your certificates or you can use a trusted third-party authority. When you use Certificate Services, you manage the certificate creation, expiration, and revocation process. When you create certificates through trusted third-party authorities, you let the trusted authority manage the certificate creation, expiration, and revocation process. Either way, the basic tasks you need to perform, create, and install a certificate are as follows:
- Create a certificate request.
- Submit the request to the authority of your choice or to your own root authority.
- When you receive the response from the authority, process the pending request and install the certificate.
- Ensure that SSL is enabled and that secure communications are configured properly.
Creating Certificate Requests
Each Web site hosted on your Web server needs a separate certificate if you want SSL to work properly. The first step in the certificate creation process is to generate a certificate request. You can generate a certificate request by completing the following steps:
- In the Internet Information Services snap-in, right-click the site for which you want to generate the certificate and select Properties.
- From the Directory Security tab, select Server Certificate. This starts the Web Server Certificate Wizard. Click Next.
Note: If you or someone else has already generated a certificate request for the site, you'll see the Pending Certificate Request dialog box, shown in Figure 6-17. You must either process the request or delete the request to continue. See the sections of this chapter titled "Processing Pending Requests and Installing Site Certificates" and "Approving and Declining Pending Certificate Requests" for more information.
- As shown in Figure 6-12, select Create A New Certificate, and then click Next.
Figure 6-12: To create a certificate, select Create A New Certificate.
- Select Prepare The Request Now to prepare a request and manually submit it to an authority, and then click Next.
- Next, as shown in Figure 6-13, you must assign the certificate a name and select a bit length. The name should be descriptive and easy to refer to. The bit length sets the encryption strength of your public and private keys. In most cases, you should choose the highest bit length you are allowed to use.
Figure 6-13: Specify a descriptive name and bit length for the certificate.
Tip If you are outside the United States, you might want to generate a Server Gated Cryptography certificate. If so, select the Server Gated Cryptography (SGC) Certificate check box. Selecting this option does not mean that you'll get issued an SGC certificate automatically. You'll still have to go through an SGC verification process with the trusted authority.
Caution: A high level of encryption might slow down a CPU-intensive application when it is running over SSL. If you use SSL with ASP applications extensively and your Web server demonstrates high CPU utilization, you may want to experiment with different levels of encryption and determine where the acceptable levels of performance are achieved.
- Click Next. You have now created a public and private key pair. These keys are stored locally on the Web server. The final steps are used to create a certificate-signing request (CSR). The information in the request identifies the owner of the key and is displayed on your certificate. The CSR is used only to request the certificate. Certain characters must be excluded from your CSR fields, or your certificate may not work. Do not use any of the following characters:
! @ # $ % ^ * ( ) ~ ? > < & / \
Enter your organization information in the fields provided:
- Organization Sets the legal name of your company, such as Microsoft Corporation
- Organizational Unit Sets the division in your company responsible for the certificate, such as Technology Department
Note: Third-party authorities will use the organization name, the site's common name, and the geographical information you supply to validate your request for a certificate. If you don't enter this information correctly, you won't be issued a certificate.
- Click Next, and enter your Web site's common name. When the certificate will be used on an intranet (or internal network), the common name may be one word, and it can also be the NetBIOS name of the server, such as CorpIntranet. When the certificate will be used on the Internet, the common name must be a valid DNS name, such as www.domain.com. Click Next.
Real World The common name is typically composed of Host + Domain Name, such as www.domain.com or products.domain.com. Certificates are specific to the common name that they have been issued to at the Host level. The common name must be the same as the Web address you will be accessing when connecting to a secure site. For example, a certificate for the domain domain.com will receive a warning if accessing a site named www.domain.com or services.domain.com, as www.domain.com and services.domain.com are different from domain.com. You would need to create a certificate for the correct common name.
As shown in Figure 6-14, enter the geographic information for your company in the fields provided, and then click Next:
- Country/Region Type the country or region for your company.
- State/Province Type the full name of the state or province in which your company is located.
- City/Locality Type the city or locality in which your company is located.
Figure 6-14: Type complete entries for geographic information. Don't use abbreviations for state, province, city, or locality.
Caution: Do not use abbreviations. Some authorities won't accept abbreviated geographic information and you'll have to resubmit your request.
- Next, you need to specify the filename and path for the certificate request file. By default, the filename and path are set to C:\CERTREQ.TXT. Type a new path, or click Browse to select a path and filename using the Save As dialog box.
- Click Next twice and then click Finish to complete the request generation process.
Submitting Certificate Requests to Third-Party Authorities
After you create a CSR, you can submit it to a third-party authority, such as Entrust, Equifax, Valicert, or Verisign. The certificate-signing request is stored as ASCII text in the file you specified in Step 10 under "Creating Certificate Requests." It contains your site's public key and your identification information. When you open this file, you'll find the encrypted contents of the request, such as:
——BEGIN NEW CERTIFICATE REQUEST——
MIXCCDCCAnECAQAwczERMA8GA1UEAxMIZW5nc3ZyMDExEzARBgNVBAsTClRlY2hu
b2xvZ3kxEzARBgNVBAoTCkRvbWFpbi5Db20xEjAQBgNVBAcTCVZhbmNvdXZlcjET
MBEGA3UECBMKV2FzaGluZ3RvbjELMAkGA1UEBhMCVVMwgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBALElbrvIZNRB+gvkdcf9b7tNns24hB2Jgp5BhKi4NXc/twR7
C+GuDnyTqRs+C2AnNHgb9oQkpivqQNKh2+N18bKU3PEZUzXH0pxxjhaiT8aMFJhi
3bFvD+gTCQrw5BWoV9/Ff5Ud3EF5TRQ2WJZ+JluQQewo/mXv5ZnbHsM+aLy3AgMB
AAGgggFTMBoGCisGAQQBgjcNAgMxDBYKNS4wLjIxOTUuMjA1BgorBgEEAYI3AgEO
MScwJTAOBgNVHQ8BAf8EBAMCBPAwEwYDVR0lBAwwCgYIKwYWWQUHAwEwgf0GCisG
AQQBgjcNAgIxge4wgesCAQEeWgBNAGkAYwByAG8AcwBvAGYAdAAgAFIAUwBBACAA
UwBDAGgAYQBuAG4AZQBsACAAQwByAHkAcAB0AG8AZwByAGEAcABoAGkAYwAgAFAA
cgBvAHYAaQBkAGUAcgOBiQBfE24DPqBwFplR15/xZDY8Cugoxbyymtwq/tAPZ6dz
Pr9Zy3MNnkKQbKcsbLR/4t9/tWJIMmrFhZonrx12qBfICoiKUXreSK89OILrLEto
1frm/dycoXHhStSsZdm25vszv827FKKk5bRW/vIIeBqfKnEPJHOnoiG6UScvgA8Q
fgAAAAAVVAAAMA0GCSqGSIb3DQEBBQUAA4GBAFZc6K4S04BMUnR/8Ow3J/MS3TYi
HAvFuxnjGOCefTq8Sakzvq+uazUO3waBqHxZ1f32qGr7karoD+fq8dX27nmh0zpp
RzlDXrxR35mMC/yP/fpLmLb5lsxOt1379PdS4trvWUFkfY93/CkUi+nrQt/uZHY3
N0SThxf73VkfbsE3
——END NEW CERTIFICATE REQUEST—
Most CAs have you submit the certificate request as part of a formal site registration process. In this registration process, you'll be asked to submit the request file in an e-mail or through an online form. When using e-mail, you simply attach the request file to the e-mail and send it. When using an online form, you must copy the entire text of the request—including the BEGIN and END statements—to the clipboard and paste this into the online form. You can use Microsoft Notepad to do this.
After the CA reviews your certificate request, the CA will either approve or decline your request. If the CA approves the request, you will receive an e-mail with the signed certificate attached or a notice to visit a location where you can retrieve the signed certificate. The certificate is an ASCII text file that you can view in Notepad, and it can only be decrypted with the private key you generated previously. As before, the contents of the file are encrypted and include BEGIN and END statements like this:
——BEGIN CERTIFICATE——
MXXCWjCCAgQCEDlpyIenknxBt43eUZ7JF9YwDQYJKoZIhvcNAQEEBQAwgakxFjAU
BgNERAoTDVZlcmlTaWduLCBJbmMxRzBFBgNVBAsTPnd3dy52ZXJpc2lnbi5jb20v
cmVwb3NpdG9yeS9UZXN0Q1BTIEluY29ycC4gQnkgUmVmLiBMaWFiLiBMVEQuMUYw
RAYDVQQLEz1G45IgVmVyaVNpZ24gYXV0aG9yaXplZCB0ZXN0aW5nIG9ubHkuIeev
IGFzc3VyYW5jZXMgKEM345MxOTk3MB4XDTAwMTEwNzAwMDAwMFoXDTAwMTEyMTIz
NTk1OVowczELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEjAQBgNV
BAcUCVZhbmNvdXZlcjETMBEGA1UEChQKRG9tYWluLkNvbTETMBEGA1UECxQKVGVj
aG5vbG9neTERMA8GA1UEAxQIZW5nc3ZyQWEwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBALElbrvIZNRB+gvkdcf9b7tNns24hB2Jgp5BhKi4NXc/twR7C+GuDnyT
qRs+C2AnNHgb9oQkpivqQNKh2+N18bKU3PEZUzXH0prtyhaiT8aMFJhi3bFvD+gT
CQrw5BWoV9/Ff5Ud3EF5TRQ2WJZ+JluQQewo/mXnTZnbHsM+aLy3AgMBAAEwDQYJ
KoZIhvcNAQEEBQADQQCQIrhq5UmsPYzwzKVHIiLDDnkYunbhUpSNaBfUSYdvlAU1
Ic/37OrdN/E1ZmOut0MbCWIXKr0Jk5q8F6Tlbqwe
——END CERTIFICATE—
Save the certificate file to a location that you can access when using the Internet Information Services snap-in. You should use .cer as the file extension. Then process and install the certificate as described in the "Processing Pending Requests and Installing Site Certificates" section of this chapter.
Submitting Certificate Requests to Certificate Services
After you create a certificate-signing request, you can submit it to Certificate Services using the Web-based interface. To do this, complete the following steps:
- The certificate-signing request is stored as ASCII text in the file you specified in Step 10 under "Creating Certificate Requests." Open this file in Notepad and copy the entire text of the request, including the BEGIN and END statements, to the clipboard (press Ctrl+A and then press Ctrl+C).
- You are now ready to submit the request to Certificate Services. Start your Web browser and type in the Certificate Services URL, such as http://ca.microsoft.com/certsrv/. You should see the main page for Certificate Services, as shown in Figure 6-15.
Figure 6-15: When you access the Certificate Services URL, you should see the main page for the Web-based interface. If you don't, you may not have configured Web access correctly.
- Select Request A Certificate and then click Next.
- On the Choose Request Type page, select Advanced Request, and then click Next.
- As shown in Figure 6-16, select the second option on the Advanced Certificate Requests page and then click Next. This option tells Certificate Services that you are going to submit a request that is base64-encoded.
- Paste the request into the Saved Request text box and then click Submit.
- If you've completed this process correctly, the final page shows you that your request has been received and is pending approval by the CA. If there is a problem with the request, you'll see an error page telling you to contact your administrator for further assistance. On the error page, you can click Details to get more information on the error. You may need to re-create the certificate request or go back to ensure that you haven't accidentally inserted additional spacing or characters in the request submission.
Figure 6-16: Use the Advanced Certificate Requests page to choose the type of request you are submitting.
- If you are also the CA, you can use the Certification Authority snap-in to handle the request. See the "Approving and Declining Pending Certificate Requests" section of this chapter.
Once the request has been approved, use the Web-based interface to retrieve the signed certificate. To do this, complete the following steps:
- Start your Web browser and type in the Certificate Services URL, such as http://ca.microsoft.com/certsrv/.
- Under Select A Task, select Check On Pending Certificate, and then click Next.
- You should see a list of pending requests. Requests are listed with a description and a date/time stamp. Select the request for the site you want to work with and then click Next.
Note: If you cannot access the certificate file online, you can have the certificate administrator generate the certificate manually. See the "Generating Certificates Manually in the Certification Authority Snap-In" section of this chapter.
- If a certificate has been issued for the request, you should see a page stating that the certificate you requested was issued to you. On this page, select Base 64 Encoded, and then click Download CA Certificate.
- You should see a File Download dialog box. Select Save This File To Disk and then click OK.
- Use the Save As dialog box to select a save location for the certificate file and then click Save. You should use .cer as the file extension. Then process and install the certificate as described in the "Processing Pending Requests and Installing Site Certificates" section of this chapter.
Tip I recommend placing all certificate files and requests in a common folder on the Web server's local file system. You should safeguard this folder so that only administrators have access.
Processing Pending Requests and Installing Site Certificates
Once you receive the certificate back from the authority, you can install it by completing the following steps:
- In the Internet Information Services snap-in, right-click the site for which you want to generate the certificate and select Properties.
- From the Directory Security tab, select Server Certificate. This starts the Web Server Certificate Wizard. Click Next.
- As shown in Figure 6-17, select Process The Pending Request And Install The Certificate, and then click Next.
- Type the path and filename to the certificate file returned by the authority, or click Browse to search for the file. Click Next to continue.
Figure 6-17: Process the pending request and install the certificate file.
- The next page provides summary information on the certificate. If this is the correct certificate, click Next, and then click Finish to complete the installation process. Otherwise, click Back to choose a different certificate file, and then repeat Steps 4 and 5.
- Configure SSL and manage the certificate as described in the "Working with SSL" and "Managing Site Certificates in the Internet Information Services Snap-In" sections of this chapter.
Deleting Pending Certificate Requests
If you made a mistake in a certificate request that has already been generated, the only way to fix it is to delete the request and then create a new one. You can delete pending certificate requests by completing the following steps:
- In the Internet Information Services snap-in, right-click the site for which you want to generate the certificate and select Properties.
- From the Directory Security tab, select Server Certificate. This starts the Web Server Certificate Wizard. Click Next.
- As shown in Figure 6-18, select Delete The Pending Request, and then click Next.
Figure 6-18: If you or someone else instructs IIS to delete a pending request, you'll need to re-create the certificate request before you can try to install a certificate.
- Click Next and then click Finish. This deletes the request association in IIS but does not remove the actual request file. This file contains your site's public key and should be deleted.
Working with SSL
Installing a site certificate automatically enables SSL so that it can be used, but you may need to change the default settings. You'll need to configure and troubleshoot SSL as necessary.
Configuring SSL Ports
Once you install a certificate on a Web site, you can change the SSL port for the site. The SSL port is used for secure communications with client browsers. To view or change the SSL port, follow these steps:
- In the Internet Information Services snap-in, right-click the site you want to work with, and then select Properties.
- The SSL Port field on the Web Site tab shows the currently configured SSL port (if any).
- As shown in Figure 6-19, change the SSL port by typing a new value in the SSL Port field. Multiple sites can use the same SSL port, provided that the sites are configured to use different IP addresses.
- Click OK.
Figure 6-19: Specify a port value for SSL.
A site can also have multiple SSL identities (meaning the site can answer on different SSL ports). The SSL port configured on the Web Site tab is the one the site responds to by default. All other SSL ports must be specified in the browser request. For example, if you configure SSL for ports 443, 444, and 445, a request for
https://yoursite/ is handled by port 443 automatically, but you must specify the other ports to use them, such as
https://yoursite:445/.
To configure multiple SSL identities for a site, complete these steps:
- In the Internet Information Services snap-in, right-click the Web site you want to manage, and then select Properties.
- On the Web Site tab, click Advanced. The Advanced Multiple Web Site Configuration dialog box is displayed.
As shown in Figure 6-20, use the Multiple SSL Identities For This Web Site panel to manage SSL port settings.
- Click OK, and then click OK again to save your settings.
Adding the CA Certificate to the Client Browser's Root Store
Most root CA certificates issued by third-party CAs are configured as trusted CAs in Web browsers. However, if you are acting as your own CA, your root CA certificate won't be recognized and trusted by client browsers. To get browsers to trust the root CA certificate, the user must install the certificate in the browser's authorities store.
To install the root CA certificate, users need to complete the following steps:
- Connect to your site using a secure URL that begins with https://.
- As shown in Figure 6-21, the user's browser displays a security alert stating that there is a problem with the site's security certificate.
Figure 6-21: A security alert warns that the browser doesn't trust your root CA.
- The alert is displayed because the user hasn't chosen to trust your root CA. At this point, the user can elect to proceed by clicking Yes, to cancel the request by clicking No, or to view the root CA certificate by clicking View Certificate.
- Click View Certificate. This displays the Certificate dialog box.
- The General tab information should state that the CA Root certificate is not trusted. To enable trust, click Install Certificate.
- This starts the Certificate Import Wizard. Click Next.
- Choose Automatically Select The Certificate Store Based On The Type Of Certificate, as shown in Figure 6-22, and then click Next.
- Click Finish. The default options allow the browser to select the certificate store based on the type of certificate.
- Click OK and then click Yes to proceed. The user shouldn't see the security alert again.
Figure 6-22: Select Automatically to select the certificate store.
Confirming that SSL Is Correctly Enabled
Secure connections can only be established when the browser connects to the server using a secure URL beginning with
https://. Browsers display a warning if any embedded content (such as images) on a secure Web page are retrieved using an insecure (
http://) connection. This warning tells users that some of the content on the page is insecure and asks them if they want to continue.
Once you've enabled SSL on your server, you should confirm that SSL is working and that the encryption level is set properly. To confirm that SSL is working in Internet Explorer, complete these steps:
- Access your Web site using a secure URL beginning with https://. A padlock displayed in the bar at the bottom of the Internet Explorer window indicates that an SSL session has been established. If the padlock isn't displayed, the SSL session was not established.
- Right-click anywhere on the Web page and then select Properties. This displays a Properties dialog box, which provides summary information on the Web page.
- Click the Certificates button and then select the Details tab. Scroll down to display details concerning the certificate and the level of encryption used.
To confirm that SSL is working in Netscape Navigator, complete the following steps:
- Access your Web site using a secure URL beginning with https://. The padlock in the lower right corner of the Navigator window should be closed instead of open. This indicates that an SSL session has been established. If the padlock is open, the SSL session was not established.
- Click the padlock icon. This displays the Netscape Personal Security Manager, which also indicates the level of encryption currently being used.
Resolving SSL Problems
If SSL isn't working, ensure that you've installed the server certificate on the correct Web site and that you've enabled SSL on the site. These steps should resolve a server-based SSL problem.
If the encryption level isn't what you expected, you should check to make sure the browser supports the encryption level you are using. If a browser supports 128-bit encryption and the encryption level in use according to the browser's Properties dialog box is 40-bit, the problem is the server certificate. The server certificate must be upgraded to 128-bit encryption.
In Internet Explorer, check encryption support by completing the following steps:
- From the Help menu, select About Internet Explorer.
- The Cipher Strength field shows the level of encryption supported. You must have 128-bit support to establish a 128-bit session.
- Click OK.
- From the Tools menu, select Internet Options. From the Internet Options dialog box, select the Advanced tab.
- Scroll down through the Advanced options until you see the Security heading. Ensure that Use SSL 2.0 and Use SSL 3.0 are selected.
- Click OK.
In Netscape Navigator, check encryption support by completing these steps:
- Click the padlock button on the Navigator's status bar. This displays the Netscape Personal Security Manager, which also indicates the level of encryption currently being used.
- Click the Advanced tab, then select Options. There are three check boxes, all selected by default: Enable SSL Version 2, Enable SSL Version 3, and Enable TLS. Make sure both versions of SSL are selected at a minimum.
- Click Close to save your settings.
Managing Site Certificates in the Internet Information Services Snap-In
Once you've installed a certificate on a Web site, you can use the Internet Information Services snap-in to manage it. Key management tasks are discussed in this section.
Viewing and Modifying Issued Certificates
Certificates contain the identity and geographic information specified in the original certificate request. They also have a number of properties set by the certification authority. These properties describe the certificate, set its authorized uses, and define the site for which the certificate is valid. If needed, you can modify the certificate to do the following:
- Update the friendly name assigned when the certificate was created
- Specify a detailed description of the certificate
- Enable or disable purposes for which the certificate can be used
You can view or modify a site's certificate by completing the following steps:
- In the Internet Information Services snap-in, right-click the Web site you want to manage, and then select Properties.
- On the Directory Security tab, click View Certificate. This displays the Certificate dialog box, shown in Figure 6-23.
Figure 6-23: The Certificate dialog box provides summary information on the site certificate and can be used to modify properties and export the certificate to a file.
To view properties set when the certificate was issued, click the Details tab. Fields on the Details tab include
- Version The X.509 version used in creating the certificate
- Serial Number The unique serial number for the certificate
- Signature Algorithm The encryption algorithm used to create the certificate's signature
- Issuer The issuer of the certificate
- Valid From The date from which the certificate is valid
- Valid To The date after which the certificate expires
- Subject Used to set the subject of the certificate, which typically includes the identification and geographic information
- Public Key The certificate's encrypted public key
- Thumbprint Algorithm The encryption algorithm used to create the certificate's thumbprint
- Thumbprint The encrypted thumbprint of the signature
- Friendly Name The descriptive name assigned to the certificate
- To view or edit a list of purposes for which the certificate can be used, from the Details tab, click Edit Properties. You can then use the Certificate Properties dialog box, shown in Figure 6-24, to view or edit the certificate purposes.
Figure 6-24: Certificate purposes can be modified to meet the needs of your organization.
Renewing, Removing, and Replacing Certificates
Normally, certificates are valid for one year from the date they were issued. This means certificates must be renewed on an annual basis. Certificates can also be removed or replaced as necessary. To renew, remove, or replace a certificate, follow these steps:
- In the Internet Information Services snap-in, right-click the Web site you want to manage, and then select Properties.
- Select the Directory Security tab and then click Server Certificate on the Secure Communications panel. This starts the Web Server Certificate Wizard. Click Next.
- As shown in Figure 6-25, you can now elect to renew, remove, or replace the current certificate. Make your selection and then continue through the remaining wizard dialogs.
Figure 6-25: You can renew, remove, or replace a certificate at any time using the Web Server Certificate Wizard.
Exporting Site Certificates
You can export site certificates to a file, if necessary. To do this, complete the following steps:
- In the Internet Information Services snap-in, right-click the Web site you want to manage, and then select Properties.
- On the Directory Security tab, click View Certificate. This displays the Certificate dialog box, shown previously in Figure 6-23.
- Select the Details tab and then select Copy To File. This starts the Certificate Export Wizard. Click Next.
- As shown in Figure 6-26, you can export the certificate file with or without the associated private key. If you want to export the private key, select the Yes option. Otherwise, select the No option. Click Next.
Figure 6-26: You can export the certificate file with or without the private key. Select an option and then continue by clicking Next.
- The next page lets you choose the export file format. The default format should be adequate, so note the format that will be used, and then click Next.
- If you elected to export the private key, you must now set a password for the certificate file. After you type and then confirm the password in the fields provided, click Next.
- Specify the name of the file you want to export. Click Browse if you want to use the Save As dialog box to set the file location and name.
- Click Next and then click Finish. Click OK to confirm a successful export. Click OK twice more to return to the Internet Information Services snap-in.
Ignoring, Accepting, and Requiring Client Certificates
Client certificates allow users to authenticate themselves through their Web browser. You may want to use client certificates if you have a secure external Web site, such as an extranet. If a Web site accepts or requires client certificates, you can configure client certificate mappings that permit access control to resources based on client certificates. A client certificate mapping can be mapped to a specific Windows account using a one-to-one mapping, or it can be mapped based on rules you specify.
By default, IIS doesn't accept or require client certificates. You can change this behavior. Keep in mind that accepting client certificates isn't the same as requiring client certificates. When a site requires client certificates, the site is secured for access using SSL only and cannot be accessed using standard HTTP. When a site accepts client certificates rather than requires them, the site can use either HTTP or HTTPS for communications.
To configure client certificate usage, follow these steps:
- In the Internet Information Services snap-in, right-click the Web site you want to manage, and then select Properties.
- Select the Directory Security tab and then click Edit on the Secure Communications panel. This displays the Secure Communications dialog box, shown in Figure 6-27.
- If you want to require SSL (and preclude the use of insecure communications), select Require Secure Channel. Optionally, you can also select Require 128-Bit Encryption if your server has a 128-bit encryption installed and enabled.
- On the Client Certificates panel, select the Ignore, Accept, or Require Client Certificates option as necessary.
Note: You can only require client certificates when secure SSL communications are required as well. Because of this, you must check Require Secure Channel when you want to require client certificates.
Figure 6-27: Sites can ignore, accept, or require client certificates.
- If you want to map client certificates to Windows user accounts, select Enable Client Certificate Mapping, and then click Edit. Then use the Account Mappings dialog box to configure certificate mappings.
- If you want to accept client certificates only from specific certification authorities, select Enable Certificate Trust List, and then click New. This starts the Certificate Trust List Wizard, which you can use to specify the root CA certificates that are trusted. Client certificates from trusted root CAs will be accepted. Client certificates from other root CAs will not be accepted.
- Click OK twice.
Requiring SSL for All Communications
In some cases, you'll want to create sites that can only be accessed using secure communications. You can do this by requiring SSL and prohibiting the use of insecure communications. To require SSL for communications with a Web site, follow these steps:
- In the Internet Information Services snap-in, right-click the Web site you want to manage, and then select Properties.
- Select the Directory Security tab and then click Edit on the Secure Communications panel. This displays the Secure Communications dialog box, shown previously in Figure 6-27.
- Select Require Secure Channel if you want to require SSL and preclude the use of insecure communications.
- Optionally, select Require 128-Bit Encryption if your server has a 128-bit encryption installed and enabled.
- Click OK twice.
Source: http://technet.microsoft.com/en-us/library/
How to create a CSR without removing your current certificate in IIS
Currently the Renew option within IIS 5.x/6.x does not work as intended most of the time. Since IIS does not allow your site that is currently running SSL to generate a Certificate Signing Request (CSR) without removing the existing certificate. For most sites this is not a viable option since the SSL portion of your site would be down until the new certificate was put in place. In order to obtain a certificate for your existing web site you will have to do the following.
Note: You may want to print this page for your records. (In IIS Admin)
- Create a Temporary site within IIS.
- Right-Click on the newly created site and click Properties.
- Click the Directory Security tab and then click Server Certificate button.
(Enter Server Certificate Wizard)
- Go through the wizard and enter the exact same information you would/have on your existing certificate.
Note: Common Name examples: www.comodo.com, comodo.com, mail.comodo.com, etc.
- Send us the CSR.
- Install the certificate by proccessing the pending request on the Temporary site created in step 1.
Note: If you're not familiar with installing SSL certificates on IIS, click here for instructions. (On the production website)
- Right-Click on the Production site and click Properties.
- Click the Directory Security tab and then click Server Certificate button.
(Enter Server Certificate Wizard on production website)
- Select Replace the current certificate and click Next.
- Click Next until you are out of the wizard.
Note: A typical site is bound to https on port 443 with a unique IP Address.
- Now delete the Temporary Site AFTER you have installed your certificate. Source: https://support.comodo.com/
CSR Generation: Microsoft IIS 5.x & 6.x
Generating an IIS SSL Certificate Signing Request (CSR) using Microsoft IIS 5.x / 6.x
A CSR is a file containing your IIS SSL certificate application information, including your Public Key. Generate your CSR and then copy and paste the CSR file into the webform in the enrollment process:
Generate keys and Certificate Signing Request:
- Select Administrative Tools
- Start Internet Services Manager
- Open the properties window for the website the CSR is for. You can do this by right clicking on the Default Website and selecting Properties from the menu
- Open Directory Security by right clicking on the Directory Security tab
- Click Server Certificate. The following Wizard will appear:
- Click Create a new certificate and click Next.
Note: If you do not see the above screenshot, you probably already have an SSL Certificate on the website you're using. Please follow these on how to create a CSR without removing the current certificate.
- Select Prepare the request and click Next.
- Provide a name for the certificate, this needs to be easily identifiable if you are working with multiple domains. This is for your records only.
- For Bit length please use 2048 and then Click Next
- Enter Organization and Organization Unit, these are your company name and department respectively. Click Next.
- The Common Name field should be the Fully Qualified Domain Name (FQDN) or the web address for which you plan to use your IIS SSL Certificate, e.g. the area of your site you wish customers to connect to using SSL. For example, an Instant SSL Certificate issued for comodogroup.com will not be valid for secure.comodogroup.com. If the web address to be used for SSL is secure.comodogroup.com, ensure that the common name submitted in the CSR is secure.comodogroup.com. For Wildcard SSL certificate the Common Name must contain at least one asterisks (*) Example: *.comodo.com, *.instantssl.com, etc.
- Click Next once you have entered the common name.
- Enter your Country, State and City, then click Next once this information is entered..
- Enter a filename and location to save your CSR. You will need this CSR to enroll for your IIS SSL Certificate. Click Next.
- Check the details you have entered. If you have made a mistake click Back and amend the details. Be especially sure to check the domain name the Certificate is to be "Issued To". Your IIS SSL Certificate will only work on this domain. Click Next when you are happy the details are absolutely correct.
- When you make your application, make sure you include the CSR in its entirety into the appropriate section of the enrollment form - including
-----BEGIN CERTIFICATE REQUEST-----to-----END CERTIFICATE REQUEST-----
- Click Next
- Confirm your details in the enrollment form
- Finish
To save your private key:
- Go to: Certificates snap in in the MMC
- Select Requests
- Select All tasks
- Select Export
We recommend that you make a note of your password and backup your key as these are known only to you, so if you loose them we can't help! A floppy diskette or other removable media is recommended for your backup files.
Source: https://support.comodo.com/
