Affichage des articles dont le libellé est Certificates. Afficher tous les articles
Affichage des articles dont le libellé est Certificates. Afficher tous les articles

11 Deploying, Configuring, and Managing SSL Certificates

Client Certificates :
Although Basic, Digest, and Integrated Windows authentication are the most common ways to authenticate users, you can also authenticate users with certificates. In anonymous environments, where many requests go unauthenticated, client certificates are not a good solution. Client certificates require an administrator to have access to the IIS server and to each client that will be connecting to it. This is not feasible in many Internet solutions, in which clients from just about anywhere can be used to attempt a connection. On the other hand, client certificates are the only way to connect to IIS when all other authentication methods—Anonymous, Basic, Integrated, Digest, and Passport— are disabled on the server.

Although the simplest way to authenticate users with certificates is to allow any user with a valid certificate to access the site, this does little to provide security for your organization. By default, your IIS server will trust certificates issued by any trusted root CA, including public CAs that issue user certificates to people you might not want accessing your site.

One-to-one client certificate mapping :
Client certificate mapping has two modes: one-to-one and many-to-one. One-to-one certificate mapping relates a single exported certificate to an Active Directory user account, as shown in Figure 11.4. When Web users present the certificate, they will be authenticated as if they had presented a valid user name and password.

To add one-to-one certificate mappings, first export the user’s certificate. Then perform these steps:
1. View the properties for the Web site, click the Directory Security tab, and click the Edit button in the Secure Communications box.
2. Select the Enable Client Certificate Mapping check box, and then click the Edit button.
3. Click the 1-1 tab, and then click the Add button.
4. Select the exported certificate, and then click Open.
5. Complete the Map Name, Account, and Password boxes, and then click OK.
6. Confirm the password when prompted, and then click OK again.

Many-to-one client certificate mapping :
Many-to-one certificate mapping uses wildcard matching rules that verify whether a client certificate contains specific information, such as the issuer or subject. This mapping does not identify individual client certificates; it accepts all client certificates fulfilling the specific criteria. If a client gets another certificate containing all the same user information, the existing mapping will still work. Certificates do not need to be exported for use in many-to-one mappings.
To add many-to-one certificate mappings, follow this procedure:

1. View the properties for the Web site, and then click the Directory Security tab.
2. Click the Edit button in the Secure Communications box.
3. Select the Enable Client Certificate Mapping check box, and then click the Edit button.
4. Click the Many-1 tab, and then click the Add button.
5. On the General page, type a name for the rule in the Description box. Click Next.
6. On the Rules page, click New to add a rule.
7. In the Edit Rule Element dialog box, click the Certificate Field list to choose either Issuer or Subject. Select Issuer to filter based on the CA that issued the certificate. Choose Subject to filter based on who the certificate was issued to. After completing the rule element, click OK.
8. To add an additional rule, return to step 6.
9. Click Next.
10. On the Mapping page, click Refuse Access to reject logons that match the criteria,or click Accept This Certificate For Logon Authentication to map matching certificates to a user account. If you choose to accept the certificate, complete the Account and Password boxes. Click Finish. If prompted, confirm the password and then click OK.

Certificate trust lists :
You can use the Certificate Trust List Wizard to obtain and manage CTLs. A CTL is a list of trusted CAs for a particular Web site. By configuring your CTL, you can allow client certificates issued by a specific CA but deny client certificates issued from other CAs. CTLs are available only at the Web-site level and are not available for File Transfer Protocol (FTP) sites.
To use the Certificate Trust List Wizard, perform the following steps:
1. View the properties for the Web site, click the Directory Security tab, and then click the Edit button in the Secure Communications box.
2. Select the Enable Certificate Trust List check box.
3. Click the New button to open the Certificate Trust List Wizard, which allows you to select CAs from the local machine authority or an exported certificate file.

Troubleshooting SSL :
Troubleshooting SSL-encrypted connections is difficult because, like IPSec connections, the traffic is encrypted. In some ways, troubleshooting SSL is even more difficult than troubleshooting IPSec because of the wide variety of Web browser clients that need to be able to analyze your public key certificate and establish an HTTPS connection to your Web server. Though the problems are much less frequent than they were in the late 1990s when the use of HTTPS was only beginning to gain popularity, you can run into problems when using a non-Microsoft browser that you would not experience when using Internet Explorer. Because you often have no control over what browser end users use, you might have to isolate the source of the problem to determine which component is not compliant with standards.

The SSL Diagnostic Utility for IIS, available from http://www.microsoft.com/technet /prodtechnol/windowsserver2003/downloads/ssldiags.asp, is helpful for isolating SSLrelated problems. As shown in Figure 11.6, it provides a much more detailed analysis of HTTPS traffic than is possible by capturing SSL traffic by using Network Monitor.

The SSL Diagnostic Utility has the capability to quickly create a self-signed SSL certificate. If you are experiencing problems with a certificate, you can create a self-signed certificate to determine whether the problem occurs with a different certificate. If the problem occurs with your original certificate but not with the certificate generated by the SSL Diagnostic Utility, you know the problem you are experiencing is related to a unique aspect of the original certificate. You can then quickly restore the original certificate to continue troubleshooting.

11 Deploying, Configuring, and Managing SSL Certificates

Renewing SSL Certificates :
Like any other public key certificate, each SSL certificate has a lifetime. At some point in the future, the certificate will expire. You should plan to renew the certificate three to six months prior to the expiration to ensure that there is no period during which the certificate is invalid.

The specific process you use for renewing the certificate will vary. If you are using a certificate issued by a public CA, the CA will provide a renewal process. If you are using a certificate issued by Certificate Services, you can renew the certificate by using Web enrollment, the Certificates snap-in, or the Web Server Certificate Wizard.

Configuring Firewalls :
Applications use a unique port number for SSL-protected communications. As a result,you must change your firewall configuration to allow the encrypted traffic.

There are two approaches to allowing SSL traffic through a firewall. The first approach is to open the firewall to allow all traffic with a designated port. The typical ports that various applications use for SSL are listed in Table 11.2. Although this will allow SSL sessions to be established through the firewall, the firewall will not be able to analyze the contents of the SSL-encrypted packets. As a result, the firewall will be able to use only the origin and destination of the packet to determine whether to let packets through.

11 Deploying, Configuring, and Managing SSL Certificates

Lesson 1: Overview of Secure Sockets Layer (SSL)

SSL was developed by Netscape Communications Corporation in 1994 to secure transactions over the World Wide Web. Soon after, the Internet Engineering Task Force (IETF) began work to develop a standard protocol to provide the same functionality. SSL 3.0 was used as the basis for that work, which is known as the Transport Layer Security (TLS) protocol. The implementation of the SSL/TLS protocol in Windows Server 2003 closely follows the specification defined in RFC 2246, “The TLS Protocol Version 1.0.

How SSL Works :
SSL provides encryption, authentication, and data integrity by using a public key certificate.When the SSL session is established, the server’s public key certificate is used to encrypt and exchange a shared secret between the client and server. This shared secret is then used to encrypt communications for the rest of the session. The following describes the step-by-step procedures for establishing an SSL session:
1. The client requests the public key from the server.
2. The server sends the public key to the client.
3. The client sends the server a session key, encrypting it with the public key.
4. The server decrypts the session key received from the client by using the server’s private key.
The session key can then be used as a shared secret to encrypt and decrypt data exchanged between the client and server.

Comparing SSL with IPSec :
IPSec is commonly used to provide the same services as SSL: authentication, privacy, and message integrity. However, the approach IPSec takes is different from that of SSL. IPSec is implemented by the operating system and is completely transparent to the applications that use IPSec. As a result, IPSec can be used to protect almost any type of network communication. IPSec also provides a flexible authentication scheme. The Microsoft Windows implementation of IPSec allows clients and servers to authenticate each other by using either public key certificates or a shared secret.

SSL, on the other hand, must be implemented by individual applications. Therefore, you cannot use SSL to encrypt all communications between two hosts. Additionally, SSL is less flexible than IPSec because it only supports authentication by means of public key certificates. SSL does provide several distinct advantages, however. Most significantly, SSL is supported by a wide variety of servers and clients, and the maturity of the standard has practically eliminated interoperability problems.

Additionally, SSL allows one-way authentication, while IPSec requires both sides of a connection to authenticate. One-way authentication allows SSL to be used to authenticate the server without placing the burden of registering for a public key certificate on the client. This enables SSL to be used to encrypt communications with public Web sites while protecting the privacy of the end user by not revealing the details of a user certificate to the Web server. Table 11.1 summarizes the differences between SSL and IPSec.
Obtaining SSL Certificates :
To use SSL, the server must have a suitable public key certificate. Additionally, some SSL scenarios allow or require the client to use a public key certificate. SSL is one of the most common uses for public key certificates, and, as a result, you can obtain SSL certificates from a wide variety of places.

Any organization with a computer running Windows Server 2003 can deploy Certificate Services to issue SSL certificates without any additional cost. These certificates are suitable for intranet scenarios, in which both the servers and the clients are controlled by a single organization. These certificates should not be used for communications that cross organizations, however.

As with any public key infrastructure (PKI), SSL certificates can only be trusted if the root certification authority (CA) is trusted. You can use Group Policy objects (GPOs) to add your CA to the list of trusted root CAs on clients on an intranet, but it is much more difficult to configure clients on the public Internet. For this reason, if you do not control the client computers, you should obtain an SSL certificate from a public CA that is trusted by the client applications that will be establishing a connection to your server. If the server is a Web server, your clients will be Web browsers. As shown in Figure 11.1, Microsoft Internet Explorer is configured by default to trust a large number of public CAs.

Google