- How to: Configure Certificates to Enable SSL In IIS
- How to: Map Windows Accounts with Certificates
- How to: Create a Service Principle Name (SPN)
- How to: Configure WCF for NATs and Firewalls
- How to: Create an X.509 Certificate
How to: Configure Certificates to Enable SSL in IIS
Use Secure Sockets Layer (SSL) in Internet Information Services (IIS) to protect the communication channel between your WCF-enabled Web application and the Web client. SSL protects sensitive data on the network from being stolen or modified.
Perform the following steps to configure certificates for SSL communication in IIS.
- Click Start and then click Run.
- In the Run dialog box, type inetmgr and then click OK.
- In the Internet Information Services (IIS) Manager dialog box, expand the (local computer) node, and then expand the Web Sites node.
- Right-click Default Web Site and then click Properties.
- In the Default Web Site Properties dialog box, click the Directory Security tab, and then in the Secure Communications section, click Server Certificate.
- On the Welcome screen of the Web Server Certificate Wizard, click Next to continue.
- On the Server Certificate screen, select the Assign an existing certificate radio button option, and then click Next.
- On the Available Certificates screen, select the certificate you created and installed in the previous step, and then click Next.
- Verify the information on the certificate summary screen, and then click Next.
- Click Finish to complete the certificate installation.
- In the Default Web Site Properties dialog box, click OK.
- For information on installing a server certificate, see Install a Server Certificate (IIS 6.0).
- For a Q&A on deployment considerations, see the Deployment Considerations section of WCF Questions and Answers.
- For deployment guidelines, see the Deployment Considerations section of WCF Security Guidelines.
How to: Map Windows Accounts with Certificates
If you are using certificate authentication, you can map certificates to Windows accounts in order to enable authentication and authorization based on the Windows account.
You can map an X.509 certificate to a Windows account by setting the mapClientCertificateToWindowsAccount property to true. By default, when using the certificate client credential type on bindings, the certificate is not mapped to Windows accounts.
Perform the following steps to map certificates to Windows accounts:
- Decide between the IIS certificate mapping versus Active Directory certificate mapping.
- IIS mapping is useful if you need only a limited number of mappings, or a different mapping on each WCF service.
- Use Active Directory mapping when the account mappings are identical on all IIS servers. Active Directory mapping is easier to maintain than IIS mapping because you only have to create the mapping in one location.
- Configure IIS / Active Directory for mapping the certificates.
- After you have enabled the client certificate mapping feature, set the mapClientCertificateToWindowsAccount property to true as follows:
<serviceBehaviors> <behavior name="MyServiceBehaviorForWebHttp"> <serviceCredentials> <clientCertificate> <authentication mapClientCertificateToWindowsAccount="true" /> </clientCertificate> </serviceCredentials> </behavior> </serviceBehaviors>
- For more information on certificates, see Working with Certificates.
- For more information on mapping certificates to Windows accounts, see Map certificates to user accounts.
- For more information on mapping certificates to Active Directory, see Mapping Client Certificates with Directory Service Mapping.
- For more information on certificate mapping strategies, see Mapping Strategies.
How to: Create a Service Principle Name (SPN)
A service principal name (SPN) is the name by which a client uniquely identifies an instance of a service. The Kerberos authentication service can use an SPN to authenticate a service. When a client wants to connect to a service, it locates an instance of the service, composes an SPN for that instance, connects to the service, and then presents the SPN for the service to authenticate.
To create an SPN for a domain account, run the Setspn tool from a command prompt as shown below:
setspn -A HTTP/webservername domain\customAccountName setspn -A HTTP/webservername.fullyqualifieddomainname domain\customAccountName
The setspn tool creates an SPN for the custom domain account (domain\customAccountName) and associates the account with the HTTP service on the specified Web server. By running the command twice as shown above, you can associate the account with the NetBIOS server name and the fully qualified domain name (FQDN) of the server. This ensures that the SPN is established correctly even if your environment does not consistently use FQDNs.
- For more information on SPNs, see Setspn.exe: Manipulate Service Principal Names for Accounts.
How to: Configure WCF for NATs and Firewalls
Network address translators (NATs) and firewalls can impact the strategy by which your WCF clients and services communicate.
Perform the following steps to determine WCF configuration for a NAT or firewall:
- Determine the addressability of the service and client machines. If the service or the client is behind a NAT and is not directly addressable, use a technology such as Microsoft Teredo to enable communication.
- Determine if there are protocol or port constraints on the service or client machines. For example, port 80 might be open through a firewall while other ports might be blocked.
Once you understand the addressability, protocol, and port constraints on your service and its clients, you can determine service and endpoint configuration. Use the table in the MSDN article Working with NATS and Firewalls to determine the best configuration for your particular scenario.
- For more information on Microsoft Teredo, see Teredo Overview.
- For more information on configuring WCF for NATs and firewalls, see Working with NATS and Firewalls.
How to: Create an X.509 Certificate
You might need to create an X.509 certificate to aid in development and debugging of your WCF service. Temporary certificates are easier to generate and cost less money than a certificate issued by a trusted certificate authority (CA), so they are well suited for a development environment.
To create a temporary X.509 certificate in a development environment, use the Makecert utility. In a production environment, use an X.509 certificate issued by a CA such as VeriSign.
|Do not use temporary development certificates in a production environment because this will open your communication channel to malicious spoofing, sniffing, and tampering.|
- For more information, see How To — Create and Install Temporary Certificates in WCF for Message Security During Development and How To — Create and Install Temporary Certificates in WCF for Transport Security During Development in the How To Index of the WCF Security Guide.
- For more information on creating a certificate, see Certificate Creation Tool.