It’s important for every environment to run as securely as budgets will allow. And in these times budgets are limited so administrators and IT directors must balance the funds available with the security needs of the organization.

One component of maintaining a secure environment is that of securely sending and receiving email. However problems can occur due to incorrect settings, incompatibilities and sometimes problems with services binding to the wrong Secure Socket Layer (SSL) certificates and external URLs – which will be the focus of this article.

When administrators initially set up Exchange server they will be asked to create a self-signed SSL certificate which will be used to identify the internal NETBIOS of the machine that is used to run the server.

An issue that may result from using the self-signed SSL certificate can be observed during the connection process to an outside URL. An SSL error popup message may show up indicating that the external URL site’s https URL is not the correct site address for the SSL Client/Server socket (connection). For instance, the popup window might say something about the “https” URL, such as https://yourserver(dot)yourcompany(dot)com/, not being the correct name for the SSL Client/Server connection.

Remember that Secure Socket Layer (SSL) was originally developed as a way to secure the internet connections between web browsers and web servers. Developed by Netscape in 1994, the Secure Socket Layer can be used in other applications such as Telnet and FTP.

SSL is an excellent security technology with a number of uses. From a user perspective it is most often seen as a front end to the Hyper Text Transfer Protocol (HTTP) in the form of HTTPS. It can also be used for POP3, SMTP, IMAP, and just about any other well behaved TCP application. It’s very easy for most programmers who are developing network applications from the start to just pull down an SSL implementation and integrate it with their application to provide encryption when communicating across the network via TCP.

And a lot of times, when certificates are needed for Exchange server, some administrators will just use the self-signed certificate that is created during initial setup. An option that administrators should consider is to purchase a certificate from an outside authority, known as a Root Certificate Authority. Certificates can be purchased from such authorities as: Verisign, GlobalSign, Thawte, and others.

But even after installing a valid certificate administrators may find that they are still receiving popup error messages about SSL errors and those error messages still refer to the aforementioned URL as not being a valid name for the SSL Client/Server connection.

It helps to know that all communication in an Exchange server environment is expected to run through SSL encryption. Meaning that communications between Exchange servers is encrypted and that communications between Exchange and Outlook clients is also encrypted. But you may have thought that those communications were supposed to be using RPC and MAPI. That still happens but only for some services.

Other services are using HTTPS. For example when Outlook 2007 is started up it will use an “Autodiscover” service to locate the mailbox for a user on an Exchange server. Normally this service is configured at setup time. The “Autodiscover” service uses SSL encrypted “tunneling” to the Exchange server for its communications.

(Tunneling, or port forwarding, is a way to forward otherwise insecure TCP traffic through SSH. You can secure POP3, SMTP and HTTP connections that would normally be insecure. I have used tunneling when working at remote customer sites and I was behind a firewall but I needed to get access to my own network.)

Getting back to our story, most Client Access Server Role services are bound to the SSL certificate you configured in Internet Information Server for the default website and which are subsequently by Exchange services for the sub sites. In order to correct this situation a reconfiguration will need to be performed that will bind all services to use the newly installed SSL Certificate – pulled down from one of the aforementioned Root Authorities – and to the company’s outside URL web site.

The Exchange information can be changed using cmdlets commands in the Windows PowerShell environment. The Windows PowerShell runtime can invoke these cmdlets from within automation scripts or invoke them through the Windows PowerShell APIs from via software.

The cmdlet that an administrator can invoke is as follows:

Set-WebServicesVirtualDirectory -Identity “(Virtual Directory ID)” -ExternalUrl “Https://(hostname to connect to Exchange server from outside the firewall)/” -InternalUrl “Https://(hostname of Exchange server for connection from inside the firewall)/”

This command will update all of the service addresses such as: OAB, Free/Busy, OOF, GAL.

If you are interested in updating only the Autodiscovery SCP you can use the following CMDLET:

Set-ClientAccessServer -Identity Servername -AutoDiscoverServiceInternalUri https://yourserver(dot)yourcompany(dot)com/

This cmdlet can be used to support the certificate which you purchased earlier and to sidestep Autodiscovery service errors as seen in such Exchange server environments.