Wednesday, February 9, 2011

SBS 2008 Exchange 2007 SAN Certificate Install

SBS 2008 has a built in wizard to install certificates for exchange.  The problem is the wizard only works for a single domain.  This means that Outlook Anywhere will not work using the wizard.  If you try installing a SAN certificate to take advantage of Outlook Anywhere it breaks a few things that will need to be fixed.  

I found the below Guide from Sembee's blog to be helpful for getting things running smooth after the certificate install.

The URLs to use.
The first question is the URLs to use. This seems to where a lot of admins are having problems.
The recommendation I make and use on all of my deployments is as follows:
mail.example.com (this is the common name, the name that your MX records point to will be used for OWA,IMAP/POP3/SMTP and Exchange ActiveSync - plus it is the reverse DNS record on your static IP address)
autodiscover.example.com (self explanatory)
server.example.local (this is the Exchange server's real internal name)
server (this is the Exchange server's NETBIOS name).
"mail.example.com" is the primary name so that it appears on the certificate if a user clicks on it, and ensures that anything external that is connecting to the server without support for SAN/UC certificates.
(SAN is Subject Alternative Name, UC is Unified Communications - they are basically the same thing).
The server name is used internally. If you have UM installed then UM will not use the certificate unless it has the server's real name in its SAN list.
I have seen some people also recommend that example.com (ie nothing in front of the domain) is also included in the list. That is not something I would recommend. In my opinion the root of the domain (example.com) should point to the public web site, not a private resource like OWA. Many people have stopped entering www in front of the domain - look at the number of adverts that do not feature it.
DNS Setup
The next common mistake that is being made is not getting the DNS setup correctly.
Ensure that your network is setup so that the above URLs all resolve INTERNALLY to the Exchange server's INTERNAL IP address. That will mean setting up a split DNS system. I will not go through that here, instead point you to here: http://www.amset.info/netadmin/split-dns.asp
The Certificate Request.
This is where most admins have a breakdown, as the command required is a real pig. Get one character wrong and you will not know until you try and request the certificate. The easy way is to use the wizard that the nice people at Digicert have posted:https://www.digicert.com/easy-csr/exchange2007.htm
You don't have to use them for the certificate, but the script it generates is good for all suppliers. They also have some good explanations on the SAN certificates.
The Certificate Import.
Again another nice Microsoft article that can be shortened to something quite simple.
http://technet.microsoft.com/en-us/library/bb124424.aspx
The command you need for a certificate when it arrives from a commercial supplier?
Import-ExchangeCertificate -Path c:\SSL\result.pfx
URL Changes to Exchange.
The last area that can cause a problem is getting the URLs correct.
Unlike Exchange 2003, where you could address the server by any name that you liked as long as it resolved, Exchange 2007 is a little more picky. Therefore you have to ensure that the URLs are set correctly in the application.
The Full To Do List.
After my waffle above, what do you need to do?
  1. Setup the DNS names that you need to use, both internally and externally.
  2. Generate the request here: https://www.digicert.com/easy-csr/exchange2007.htm
  3. Post the resulting script in to an Exchange Management Shell command.
  4. Use the Certificate Request file with your preferred SSL certificate supplier (such as http://certificatesforexchange.com/  )
  5. When you get the response back, save off the SSL file to the server. If you have used the above site to get the certificate, install the root and intermediate certificate as per the instructions that you have been supplied with.
  6. Use the EMS command to import the Certificate Result file:

    Import-ExchangeCertificate -Path c:\SSL\result.pfx 
    (where the certificate result is in C:\SSL and is called result.pfx)
  7. Run get-exchangecertificate from the shell and you should see your new certificate listed. However you will notice that under "Services" it should be "….." . That is because the certificate is not enabled for any services. 

    Before you can enable the certificate, you need its thumb print. That will be shown in the output of the get-exchangecertificate command that you have already run. It looks like a long series of random characters. Highlight the thumb print and then press enter to copy it.
  8. Restart the Microsoft Exchange Transport Service if the server holds the Hub Transport role and run IISRESET if the server holds the Client Access Role. This will mean the certificate can be enabled immediately. If you cannot do either you will need to wait for Exchange to internally update before you can enable certificate.
  9. To enable the certificate, run the following command:

    Enable-exchangecertificate -thumbprint xxxxxx -services SMTP,IIS,POP,IMAP 

    Run get-exchangecertificate again to confirm the certificate is enabled for the four services. 

    If you are using the UM role, then you should also add UM to the above list. 

    As an alternative, you can run the command for each service as a separate item

    Enable-exchangecertificate -thumbprint xxxxxx -services SMTP

    You can also use PowerGui http://www.powergui.org/ to enable the services for you. With PowerGui you need to do each service one at a time.
  10. Adjust the External URLs in Exchange to match the name of the certificate that you have purchased. You can also change the internal URLs as well (which is what I do) so that the same names work everywhere: 

    In EMC, change: OWA virtual directory, EAS virtual Directory, Outlook Anywhere, OAB virtual directory

    In EMS (where EXCH is the server's real name)

    Web Services
    Set-WebServicesVirtualDirectory -identity "EXCH\EWS (Default Web Site)" -internalurlhttps://mail.example.com/EWS/Exchange.asmx -WindowsAuthentication:$True

    Set-WebServicesVirtualDirectory -identity "EXCH\EWS (Default Web Site)" -externalurlhttps://mail.example.com/EWS/Exchange.asmx -WindowsAuthentication:$True

    Unified Messaging (if installed)Set-UMVirtualDirectory -identity "EXCH\UnifiedMessaging (Default Web Site)" -externalurlhttps://mail.example.com/UnifiedMessaging/Service.asmx  -BasicAuthentication:$True

    If I have missed a URL to change - please drop me a note at the business contact address. However I don't think I have missed any - there are a lot.
  11. Restart the Exchange services on all servers to allow the change to take effect. Outlook users, particularly those on Outlook Anywhere in Outlook 2007 should be asked to restart their session.
If you have changed the external name being used by RPC over HTTPS users on Outlook 2003 then they will have to change the configuration manually.
Once complete, test it using Outlook 2007. Hold down CTRL and right click on the Outlook icon in the system tray. Choose Test Autodiscover and run the tests to see what URLs are being issued.
For external testing, use the https://testexchangeconnectivity.com/ web site from Microsoft.
Hopefully this has explained what needs to be done to get SSL certificates configured correctly on your server, at a cost effective price and with little downtime.
Article Update Information
28th January 2009 - Since the change a few people have reported the certificate cannot be enabled. It would seem that certificate is not immediately available to Exchange after being installed. This wasn't a problem with the previous version of these instructions because most people would have to go and get PowerGui. Therefore I have added a step to ensure the certificate is available immediately.  
26th January 2009 - I have updated the article slightly to include the enable certificate commands, rather than use PowerGui. This provides a complete method without installing anything extra on to your server.

2 comments:

  1. Hello!
    I am very sure that you do NOT need all those Jazz for getting Outlook anywhere up and running.
    One single DNS entry can take care of this, see here:
    http://support.microsoft.com/kb/940881

    ReplyDelete
    Replies
    1. Haha exactly. This is a fine example of what not to do really. The problem we have now from single name certs is that we won't be able to include internal names. This means you have to have a public namespace internally or a private CA setup

      Delete