Client Access Server Security and Secure Socket Layer Certificates
In this post we will review:
– CAS security through digital certificates and how these vary.
– We’ll also review the different SSL certificate types.
– Lastly, we’ll work through the following:
- Create a Certificate Signing Request (CSR)
- Obtain a certificate from a Certification Authority (CA)
- Install the SSL Certificate on the Client Access Server
Up until this point in your Exchange deployment, you may have configured access with the default self-signed certificate. This may be problematic because it doesn’t support all of the access methods (Outlook Anywhere) and isn’t the most secure method of authentication. You may decide to obtain a trusted certificate from a third-party commercial Certification Authority (CA) and install that certificate on the Client Access Server. You do also have the ability to use a PKI certificate through Microsoft Certificate Services which you can setup internally, however, the infrastructure costs and labor may not be worth the trouble.
Managing Authentication
- A digital certificate will authenticate to the client that the server with the certificate is trust-worthy. The server can prove, they are who they say they are.
- In addition, a digital certificate will ensure the data that is exchanged is protected.
- By default, with Exchange 2010, client communications are encrypted using SSL with Outlook Web App, Exchange ActiveSync, and Outlook Anywhere (SSL will not use the Self-Signed Certificates). By default, POP and IMAP aren’t configured to communicate over SSL. You will use the IIS Manager to ensure SSL is enabled on the virtual directory.
Go to the IIS Manager on your mailbox server. Select the server itself, scroll down to Server Certificates. Here you’ll find the Microsoft Exchange Certificate (Issued to itself by itself).
You can double-click on the certificate and check out the properties and see that it’s not trusted.
In IIS, expand Sites and then Default Web Site. If we look at the different sites in IIS, as far as SSL turned on, click on OWA, and then Secure Socket Layer settings, and see if it says “Require SSL”. We can test to see if that works by browsing to localhost in the web browser. An easy way to do this is to click on the “Browse: 443 (https)” link in the Actions pane:
This will open the browser and we’ll be brought to our Outlook Web App. We will have a certificate error. Users will have to install the certificate if they want to get rid of the Red Security Trust Bar in their browser. In this case we will want to install the certificate into the Trusted Certificate Store. Windows cannot validate the certificate, but since we know where the certificate is from we can install it and accept the warning.
Three types of Certificates:
- Self-signed: Signed by the application itself (in our case Exchange 2010) and will allow for OWA and/or ActiveSync functionality but not Outlook Anywhere. *For these to work you have to manually copy them over to the trusted root certificate store of the client computer or mobile device.
- Public Key Infrastructure (PKI): Requires setting up certificate servers and establishing the certificates for communication.
- Trusted Third-Party Certificates: Provided by a CA, these are automatically trusted by clients (unlike the two options above), so the deployment is simplified.
Certificate Types
When you go to purchase a certificate from a CA you’re going to find that different types to purchase.
- Wildcard Certificates: Can represent multiple domain names (for example *.jasoncoltrin.com), however these types of certs provide a less secure method because the wildcard can be used for any sub-domain. Microsoft does not recommend wildcard certs, but to use SAN’s.
- Subject Alternative Name (SAN) or Unified Communications Certificates (UCC) certificates are considered better in this regard because you specifically list out each of the trusted domain names. *It is considered best practice to use as few host names as possible (perhaps as few as three).
The CA Process for Obtaining and Installing Certs
- Take a look at the GoDaddy website for SSL Certificates
- Begin the process of managing a purchased certificate
- We will return to our Exchange Server and use the Exchange Certificate Wizard to obtain a Certificate Signing Request (CSR)
- Use the CSR to complete the GoDaddy certificate process
- Once that certificate is provided (up to 72 hours), we will install it on our Client Access Server
After submitting the encrypted data to GoDaddy, you will see the Subject Alt Names and Primary Domain Name. Your cert will be issued shortly (72hrs), and at that time we will be able to import it. Once the cert is issued, you can download it from GoDaddy. The cert will come down zipped, so unzip it.
Go back to the EMC, You will still see your requests and your self signed cert. Right-click on the SSL Cert and choose Complete Pending Request.
Browse to the downloaded cert (domain.com – not the intermediate cert), click complete, and that’s all there is to it. So we’ve installed it but don’t have any services using it. Right-click on the cert and choose Assign Services to Certificate.
Use SMTP, IIS, click Next, and then Assign.
Do we want to override? Yes.
When we downloaded and unzipped the SSL Certificate, we also received an Intermediate Certificate. The intermediate certificate is used to enhance the security of the root certificate. These are also called a Chained Root Certificates. There are instructions on the GoDaddy site for installing the Intermediate Certificate. It is optional, but you should install the Intermediate certificate if the CA provides you with one, but we will forego that for now. Your CA may or may not issue Intermediate certificates.
In conclusion, in this lesson we discussed the benefits of SSL digital certificates, encouraged SAN certificates, worked through the process of requesting a certificate from the GoDaddy Certificate Authority, and installed and enabled services using that cert on our Exchange Client Access Server.
A large majority of the content provided in my Blog’s Exchange series is derived from J. Peter Bruzzese’ excellent Train Signals Exchange Server 2010 Video Disk Series, as well as my own Exchange 2010 lab. Trainsignal.com is an invaluable source for accurate, easy to understand, IT information and training. http://www.trainsignal.com