Certificate selection and requirements

Certificate selection plays a critical role in securing communication between clients and Microsoft Dynamics CRM Server 2011 when using claims authentication. You should have a solid understanding of digital certificates before implementing claims-based authentication.

The following references provide an introduction to certificates and public key infrastructure (PKI) technologies:

Certificates are required for the following in Microsoft Dynamics CRM Server 2011 claims-based authentication.

  • Claims encryption. Claims-based authentication requires a certificate to encrypt claims sent to the relying party. This certificate should be issued by a trusted certification authority (CA) and should be trusted by the computer where you are installing Microsoft Dynamics CRM Server 2011 so it must be located in the local Personal store where the Configure Claims-Based Authentication Wizard is running.

  • SSL (HTTPS) encryption. The certificate for SSL encryption should be valid for host names similar to org.contoso.com, auth.contoso.com, and dev.contoso.com. To satisfy this requirement you can use a single wildcard certificate (*.contoso.com), or a certificate that supports Subject Alternative Names, or individual certificates for each name. Individual certificates for each host name are only valid if you use different servers for each web server role. Multiple IIS bindings, such as a website with two HTTPS or two HTTP bindings, are not supported for running Microsoft Dynamics CRM Server 2011.

Consider the following when selecting a certificate for your configuration.

Wildcard certificate (recommended). A wildcard certificate supports internal and external access requirements for a single domain. For example, *.contoso.com certificate supports the externally accessed domains org1.contoso.com and org2.contoso.com as well as the internally accessed domain internalcrm.contoso.com. Because the external domain name must resolve for internal access, you cannot use the server name for internal access. If you wish, you can use separate Microsoft Dynamics CRM Server 2011 servers for internal and external claims access to allow the server name to be used for internal access.

Subject Alternative Name (SAN) certificate. Use a SAN certificate if you wish to use a different address for your internal domain that does not match your external domain. For example, your internal domain is org.contoso.local and your external domain is org.contoso.com. Be aware that third-party certificate providers typically do not provide certificates for .local domains.

Self-signed certificate. A self-signed certificate should only be used for testing purposes and not in a production deployment. If you use a self-signed certificate, it must be imported into the Trusted Root Certification Authorities store of all Microsoft Dynamics CRM Server 2011 servers and client computers accessing Microsoft Dynamics CRM Server 2011. For information on how to import a certificate, see Help in the Certificates Microsoft Management Console (MMC). See “Creating a self-signed wildcard certificate for a test deployment” below for information on creating a self-signed wildcard certificate.

Important

If you use a certificate that is created by using a custom certificate request, the template that was used must be the Legacy key template. Custom certificate requests created by using the CNG key template are incompatible with Microsoft Dynamics CRM. For more information about custom certificate request templates, see Create a Custom Certificate Request.

The default website certificate

After you have obtained and installed a certificate, the certificate must be bound to the default website before you can use AD FS 2.0.

Bind an SSL certificate to the default website

  1. Open IIS Manager.

  2. In the Connections pane, expand the Sites node in the tree, and then click the Default Web Site.

  3. In the Actions pane, click Bindings.

  4. In the Site Bindings dialog box, click Add.

  5. Under Type, select https.

  6. Under SSL certificate, select your SSL certificate and then click OK.

  7. Click Close.

For more information about adding binding to a site, see Add or Edit Site Binding Dialog Box (https://go.microsoft.com/fwlink/?LinkId=143106)

The Microsoft Dynamics CRM Server 2011 website certificate

When enabling claims-based authentication, the Microsoft Dynamics CRM Server 2011 website must be accessible via HTTPS. You must bind your SSL certificate to the Microsoft Dynamics CRM Server 2011 website.

Bind an SSL certificate to the Microsoft Dynamics CRM Server 2011 website

  1. Open IIS Manager.

  2. In the Connections pane, expand the Sites node in the tree, and then click the Microsoft Dynamics CRM Server 2011 website.

  3. In the Actions pane, click Bindings.

  4. In the Site Bindings dialog box, click Add.

  5. Under Type, select https.

  6. Under SSL certificate, select your SSL certificate.

  7. Under Port, enter a port number other than 443 (for example, 444), and then click OK.

    Note

    Setting the port number to a port other than 443 is not needed if your AD FS server and your Microsoft Dynamics CRM are separate servers.

  8. Click Close.

  9. Add a host record in DNS for internal access to Microsoft Dynamics CRM Server 2011 (for example, internalcrm.contoso.com).

Regarding the AD FS 2.0 token-signing certificate

AD FS 2.0 servers use a token-signing certificate created by the AD FS 2.0 Configuration Wizard to digitally sign all security tokens that they produce. By default, Microsoft Dynamics CRM Server 2011 does not check for the presence or validity of this certificate and does not use AD FS 2.0 token signing. To enable validation and use of the AD FS 2.0 token-signing certificate, see Enabling AD FS 2.0 token signing in the Additional Considerations section at the end of this document.

Creating a self-signed wildcard certificate for a test deployment

You can create a self-signed wildcard certificate using one of the following programs. The certificate created is not publicly trusted and should only be used for testing.

Makecert.exe

You can use Makecert.exe (Certificate Creation Tool) to generate a self-signed wildcard certificate for testing purposes. Makecert.exe is available in the Microsoft Windows Software Development Kit for Windows Server 2008 and .NET Framework 3.5.

The following are the settings used for a wildcard certificate used to create test deployments for this document:

makecert.exe -r -pe -n "CN=*.contoso.com" -b 01/01/2010 -e 01/01/2050 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12

The self-signed certificate created with Makecert.exe is installed in the local computer’s Personal store and is not trusted. To set certificate trust, copy the self-signed certificate (for example *.contoso.com) from the Personal store to the Trusted Root Certification Authorities store. For more information, see Help in the Certificates Microsoft Management Console (MMC).

For more information on Makecert.exe settings, see Makecert.exe (Certificate Creation Tool).

SelfSSL

Download the IIS 6.0 Resource Kit and install the SelfSSL tool. For more information, see: Configuring CCF to Use HTTPS (SSL) on IIS 6.0

See Also

Concepts

Changing the SSL certificate

Send comments about this article to Microsoft.

© 2012 Microsoft Corporation. All rights reserved.