Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

1.

The client sends the server information that the server will need to communicate with the client. This information includes the client's SSL version number, encryption settings, and other information. For example, if the client is only authorized to use SSL 3.0, it would communicate this information to the server, and if the server only has an SSL 2.0 version certificate, the connection will be terminated.

2.

The server sends the client the information the client will need to communicate with the server, such as a copy of the server's certificate. If the client is attempting to access a resource that requires client authentication, the server will request the client certificate at this time.

3.

The client uses the server information to authenticate the server. The following information is checked:

Is today's date within the validity date of the certificate?

Is the issuing CA a trusted CA (does the Distinguished Name (DN) of the issuing CA match the DN of a CA on the client's list of trusted CAs)?

Does the issuing CA validate the issuer's digital signature? (The public key from the CA's certificate, found in its list of trusted CAs, is used to validate the CA's digital signature on the server certificate that is presented.)

Does the domain name of the certificate match the domain name of the server? (Validation of this step is not part of the SSL protocol, but can be used to prevent a man-in-the-middle attack because it verifies that the server is on the network address specified by the domain name in the server certificate.)

4.

Authentication can fail and the session can be dropped during any of the tests in step 3. However, if the server cannot be authenticated, the client is warned and, depending on the implementation, the user may be able to accept the certificate even if the authentication process finds a problem with it. The normal browser to web server SSL negotiation process gives the user this option. If the server can be authenticated (or is accepted by the user), the session handshake proceeds.

5.

The client creates the pre-master secret for the session and encrypts it using the server's public key (obtained with the certificate in step 2). The client sends this encrypted pre-master secret to the server.

6.

If the server has requested the client's certificate, the client signs some bit of data only known to the server and the client, and sends that, along with its certificate, to the server.

7.

If required, the server attempts to authenticate the client. It follows a similar process as that outlined in step 3. However, because a user does not monitor the process, an authentication failure cannot be simply accepted, and the session handshake will be terminated. If the client can be authenticated, the session continues.

8.

The server uses its private key to decrypt the pre-master key sent by the client. This pre-master key material generates the master secret.

9.

The client uses the pre-master key material and the same algorithm as the server to generate the master secret.

10.

Client and server use the master secret they have generated (which is the same) to generate the session key. The session key will be used to encrypt the data sent between the server and the client and to verify the integrity of the data.

11.

The client informs the server that all future messages will be encrypted.

12.

The client sends an encrypted message telling the server that the client part of the handshake is done.

13.

The server informs the client that it will encrypt all future messages using the session key.

14.

The server sends an encrypted messages telling the client that the server part of the handshake is done.

15.

The session begins. All data sent between the client and the server is encrypted using the session key. Because each party has its own session key, and this key is identical, each is able to decrypt the messages sent by the other.

1.

Open Internet Services Manager, right-click the web site that the certificate will be used for, and click Properties.

2.

Select the Directory Security tab, as shown in Figure 15-15, select Server Certificate, and click Next.

3.

In the wizard, click Create a new certificate, as shown in Figure 15-16, and click Next.

4.

Click Prepare the request now, but send later, and then click Next. (If the certificate will be supplied by your Enterprise CA, you can choose to submit the request online.)

5.

Accept the name for the certificate (taken from the web site name, as shown in Figure 15-17, or enter a new name). Change the key strength (recommended) and, if necessary, change the CSP, and then click Next.

6.

Enter or accept the organization name and OU and click Next.

7.

Enter the common name, as shown in Figure 15-18 (this should be the FQDN of the web server that will be using the certificate if the web server will be available on the Internet, but it can be the NetBIOS name if the computer will only be available on your intranet), and then click Next.

8.

Enter the city, state, and country information. Click Next.

9.

Browse to a location to save the certificate request file, click Next twice, and click Finish. A certificate request will be saved in a file called certreq.txt. You can view the file in Notepad, as shown in Figure 15-19.

1.

Use Internet Explorer to browse to the CA's web site. For example, if you will do so at the CA console, use http://localhost/certsrv.

2.

Click Request a Certificate.

3.

Click Advanced Certificate Request.

4.

Click Submit a certificate request by using a base-64-encoded CMC or PKCS # 10 file, or submit a renewal request by using a base-64-Encoded PCKS #7 file, as shown in Figure 15-20.

5.

Click Browse for a file to insert and browse to the saved file, then click Read to enter the information in the text box, or instead of using the browse option, open the file in Notepad,select its entire contents, and cut and paste the information in the text box on the screen, as shown in Figure 15-21. When the browse option is selected, the pages accessed must all be identified individually or as part of a trusted site in IE. If the pages are not trusted and you attempt to use the browse option, the browser's security settings will warn that they are preventing the web page from accessing the local disk. You should decide whether you want to follow the instructions to allow this to happen. To do so, you add this site to the trusted sites for the browser.

6.

Use the Certificate Template drop-down list to select Web Server, as shown in Figure 15-22, and then click Submit to submit the request.

7.

If the CA requires the certificate be approved, a warning will be issued. If you have authority, use the CA console to approve the request. You will need to return later using IE to check the pending request and download the certificate.

8.

If the certificate is issued, choose one of the encoding schemes (DER or base 64) and click Next.

9.

Select Download certificate and browse to a location to store the certificate file.

1.

Open the Directory Security page of the web site and click Server Certificate.

2.

Click Process the pending request and install the certificate, as shown in Figure 15-23, and then click Next.

3.

Browse to the certificate file.

4.

Specify the SSL port to use or accept the default 443, and then click Next.

5.

Review the information, click OK, and then click Finish.

1.

From the Directory Security Property page of the web site, click the Edit button.

2.

Click Require secure channel (SSL), as shown in Figure 15-24.

3.

If all clients are capable of using 128-bit encryption, click Require 128-bit encryption.

4.

If you also will require client certificates, click that statement.

5.

Click OK to close the page.