Sembee Blog

A common complaint in forums for some time has been SSL certificate prompts from Outlook 2007, when running Exchange 2003.
The error is usually along the lines of

"The name on the security certificate is invalid or doesn't match the name of the site."

Often the first response will be connected to RPC over HTTPS, as this is the only part of Exchange 2003 that can use SSL certificates for Outlook connectivity.

However the real cause of this is because of the changes made to Outlook 2007 to accommodate the changes to Exchange 2007 and its move to web services. Web services are used to reduce the dependency on Public Folders.

The specific cause of this is a process known as autodiscover. Anyone who has managed Exchange 2007 will be very familiar with Autodiscover, as it can be a key pain point.

Outlook 2007 will attempt to connect to autodiscover.example.com - where example.com is the part of your email address after the @ sign. It will also attempt to connect to a number  of other URLs if that one fails.
 
If your domain does not have an entry for autodiscover, but does have a wildcard entry in its DNS (which is common) then you may get this issue.

Therefore from a client where you have the problem, attempt to ping 

autodiscover.example.com

Where example.com is your email domain, then repeat with your internal Windows domain.

If it resolves, pinging either autodiscover.example.com, example.com or similar, even if it fails, then you may well be on to the cause. The final test is to bring up a web browser and type in autodiscover.example.com and see what happens.
It is likely that you will get the same SSL certificate prompt that Outlook receives and then it will load another web site completely.

The reason for this is quite simple.
Web hosts will often share the IP address of their server with a number of web sites, could be 100s. However to use SSL, a web site must have a dedicated IP address. Therefore a single web site with that IP address will have SSL support.
By using a wildcard in your DNS (so anythingyoulike.example.com resolves) means that all hosts will resolve to the same IP address.
As SSL cannot share an IP address, and does not see the host name being used, it will connect, and generate the SSL certificate mismatch.

How to resolve? Either remove the wildcard entry on the external DNS or have an entry for autodiscover.example.com put in to your domain with a dummy IP address - 127.0.0.2 for example. This will cause the host name to resolve, but fail to connect. See the single host replacement method on this page for instructions on how to do it: http://www.amset.info/netadmin/split-dns.asp

However if you ever deploy Exchange 2007 or higher then remember to remove it!

Exchange 2003, SSL Certificates, Outlook Exchange 2003, SSL Certificates, Outlook

21st April 2011

An Updated and revised version of this article can be found on our main site here: http://exchange.sembee.info/2007/install/sbs2008ssl.asp

---

In recent months I seem to have spent longer with SBS deployments, rather than Exchange 2007 or 2010. Therefore I have had lots of time to get annoyed with how SBS 2008 works with SSL certificates.

Exchange 2007 is very dependant on SSL certificates, which is something I have posted about in the past. However throw in the customisations to IIS that SBS 2008 makes and it gets much harder.
The SBS team have attempted to simplify the process, but for most people they have actually made it worse.

The major problem with SBS 2008 and SSL certificates is twofold.
1. SBS 2008 presumes that your external DNS provider supports SRV records. Their DNS partners that are pushed in the wizard do of course, but most do not.
SRV records are one of the methods that Outlook 2007 can use for autodiscover. Autodiscover is connected to the availability service. Therefore that means if you are using Outlook Anywhere, without autodiscover working correctly, the client doesn't work.
It can also cause problems internally, but the wizard does actually make the required changes for that.

I can see why the SBS team used the SRV record method, as it allows a standard single name SSL certificate to be used - usually remote.example.com . The wizard then makes the requires changes to Exchange and the domain to allow this method to work correctly. Using a single name SSL certificate keeps the costs down, as anyone who has worked with SBS user will know - getting the typical customer to pay for a certificate can be difficult, particularly when there is a "free" certificate in the product.

The comments in this article from Sean Daniel clearly show the presumption of SRV records use. In my opinion this is a very poor decision from Microsoft, when the wizard could easily automatically enter the additional names that are required and generate the relevant request.
http://sbs.seandaniel.com/2009/02/installing-godaddy-standard-ssl.html

2. The second issue is that SBS 2008 sets up additional web sites and uses them for external traffic. If you install and enable the certificate in the usual way for Exchange 2007, then you break those sites. That causes a mess, which can be resolved, does make extra work.

However, it is possible to get the certificate in place, in a way that is acceptable to both Exchange 2007 and SBS 2008. Whatever you do, DO NOT use IIS to generate and manipulate the certificate.

Preparation Work

To ensure that you work with the common configuration for SBS 2008, some DNS entries need to be made on the internet facing DNS services (usually your DNS provider).
Specifically these are
remote.example.com and autodiscover.example.com

(where example.com is your domain after the @).

These should point to your public static external IP address. If you cannot use a static IP address, then use a dynamic DNS provider to setup a host. Then create a CNAME for each of the above hosts and point them to then dynamic DNS host name.

While you can use another host name instead of remote.example.com, but everything in SBS seems to be orientated towards that name. Therefore I usually also use that host name for the MX records for the server as well, and get the ISP to setup the reverse DNS (aka PTR) record.

Certificate Request Generation and Response Installation

To generate the request, follow my guide elsewhere on this blog: http://blog.sembee.co.uk/archive/2008/05/30/78.aspx
However, add the name "Sites" to the list of domains that you include. That makes the full list:

remote.example.com
autodiscover.example.com
server.domain.local (the server's internal FQDN)
server (the server's NETBIOS name)
sites

When you get the response back from your provider, continue to follow my blog article up to the point about installing the response. DO NOT use the enable-exchangecertificate command.

By using the Exchange Management Shell to do the request you do not put the current self generated certificate at risk, because the request and response doesn't touch it. The certificate is only changed later on in the process.

Activating the Certificate

Now this is where things get different to Exchange 2007 full product installation.
In the SBS Management Console, start the SSL certificate. Select the option to use an existing certificate. Your new UCC certificate with the additional names should be listed. Select it and then complete the wizard. SBS will install the certificate in to the web sites correctly for you.
You should then be able to browse to https ://remote.example.com/remote and use the full feature set.

You can verify the certificate is installed correctly by using the Fix my Network wizard, which shouldn't touch the certificate installation - or by running the SBS Best Practises tool. The link to that is on my list of Exchange resources at http://exbpa.com/

Conclusion

With care, you can deploy a commercial certificate on to SBS server, without breaking any of the functionality of the server. This provides a more professional looking deployment for everyone involved, and no need to tell users to ignore certificate prompts.

Exchange 2007, Small Business Server, SSL Certificates Exchange 2007, SSL Certificates, Small Business Server

SSL certificates with Exchange 2007 continue to be a reoccurring question on forums, and I have recently had some common points continue to come up. 
If you are looking for my guide on SSL certificate requests for Exchange 2007 then it is here: http://blog.sembee.co.uk/archive/2008/05/30/78.aspx

The Self Signed Certificate
As Exchange starts to mature, and installations have been in place for over 12 months, the question of renewing the self signed certificate comes up.
What these people do not seem to realise is that they shouldn't even be using the self signed certificate. It is designed for interim use only and should be replaced with a commercial SAN/UC certificate as soon as possible.

This is Microsoft's official stance on the use of the self signed certificate: http://technet.microsoft.com/en-us/library/bb851554(EXCHG.80).aspx

One of the key lines is this:

"Important:  The self-signed certificate is not supported for use with Outlook Anywhere or Exchange ActiveSync.  "

Therefore if you are using either of those features with a self signed certificate you are actually in an unsupported environment.
The fact that getting the certificate to work for those two features can be tricky at the best of times, makes it even more pointless to continue to try and use self signed certificates.

The main argument for not using a commercial certificate is the cost and the perceived complexity of the certificate acquisition. When Exchange 2007 was first released the first UC/SAN certificates were expensive. However with vendors releasing low cost certificates for US$60/year (http://DomainsForExchange.net/ for example) that has now changed.
As for the perception of complexity for the purchase, I outlined what required in a previous blog posting: http://blog.sembee.co.uk/archive/2008/05/30/78.aspx

SAN/UC Certificates and Outlook Anywhere

The other thing that appears to be catching people out is when using Outlook Anywhere (aka RPC over HTTPS) with SAN/UC certificates.
When you setting up Outlook Anywhere in the client, if you choose to enable the "mutual authentication" option then you cannot use one of the alternative names on the certificate - you must use the primary common name. For most people this shouldn't be a problem, particularly if you follow the recommendation to put the most common name that will be used (the URL used for OWA) in as the common name and the other URLs (auto discover, the server's FQDN and real name) as additional names.
However if you have used SAN/UC certificates to support multiple domains on the same server, then it could cause you a problem.
The answer of course is to disable that option. Outlook Anywhere will continue to work correctly without that option enabled, although users may get authentication prompts. The most likely scenario where you would disable that option is when hosting, so the clients are likely to be off your domain anyway.

SAN/UC Certificates and POP3/SMTP/TLS

Similar to the issue above, to ensure maximum compatibility, the primary name on your certificate should also match your MX record. Therefore what I am recommending is the same URL is used for OWA, Outlook Anywhere and the MX records - usually mail.example.net

Certificate Prompts where the Certificate is Issued to Another Domain Entirely

Another issue I have seen a few reports of is Outlook 2007 generating a certificate prompt, and when you look at the certificate it is issued to someone else.
The cause of this is a combination of a missing URL and a wildcard on your DNS.
If you have not configured a split DNS system on your public domain for internal use, then Outlook 2007 will attempt to connect to autodiscover.example.com as part of its startup process. If you have a wildcard DNS entry on your public DNS (so *.example.com resolves) which resolves to your public web server, AND you do not have autodiscover.example.com defined, then you may get the prompt if your public web server has an SSL certificate protected site on it.

Always define autodiscover.example.com and preferably setup a split DNS system so that you can point autodiscover.example.com to your Exchange server. http://www.amset.info/netadmin/split-dns.asp

Certificates when Using Unified Messaging

You can also run in to problems when you are using Unified Messaging. I have blogged on that subject before: http://blog.sembee.co.uk/archive/2008/06/02/79.aspx

Exchange 2007, MS Exchange Server, SSL Certificates Exchange 2007, MS Exchange Server, SSL Certificates

I hinted in my Exchange 2007 SAN certificate posting (http://blog.sembee.co.uk/archive/2008/05/30/78.aspx) that I had written an article on how to setup Exchange 2007 with a single name certificate. After cleaning it up I have now published the article. However it isn't here, as it contains screenshots which the blog seems to struggle with - you will find it on my company technical site: http://exchange.sembee.info/2007/install/singlenamessl.asp

Do note that if you are using Unified Messaging that you cannot use a single name certificate. Also note the hard requirements of SRV record support at your public DNS provider (ie your domain name registrar) and Outlook 2007 SP1.

amset.info, Exchange 2007, MS Exchange Server, SSL Certificates Exchange 2007, MS Exchange Server, amset.info, SSL Certificates

While researching an article for my main technical site amset.info on how to use a single name SSL certificate with Exchange 2007 (I hinted at that in my blog post from last week http://blog.sembee.co.uk/archive/2008/05/30/78.aspx) I discovered an annoying little quirk that I think deserves a separate blog posting as I think some people may trip over it.
I also mentioned it in the same blog post from last week.

As you may be aware, Exchange 2007 allows you to assign certificates to specific roles and services. It can also generate its own self generated certificates.

The Unified Messaging role requires an SSL certificate. While trying to assign the certificate to the UM role you might find that while the command is accepted, when you query the services enabled on that certificate that UM is not listed.

Furthermore if you remove the certificate that is currently assigned to the UM role, then when you restart the Exchange services, Exchange simply recreates it - a separate certificate from the main certificates used for the other roles (SMTP, OWA, IMAP, POP3 etc).

The reason for this is quite simple. It would appear that UM will not accept a certificate UNLESS it has the server's real name listed. However I haven't quite worked out whether it is just the server's NETBIOS name or the FQDN that is required - as the commercial SAN/UC certificate I used had both.

Therefore the recommendation I would make for a SAN/UC certificate URLs are:

mail.example.com (this is the common name, the name that your MX records point to will be used for OWA, POP3/IMAP/SMTP and 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 (Subject Alternative Name) / UC (Unfied Communications) certificates are available from US$60 (At the time of writing) from http://DomainsForExchange.net/

Exchange 2007, MS Exchange Server, SSL Certificates Exchange 2007, MS Exchange Server, SSL Certificates

21st April 2011

An Updated and revised version of this article can be found on our main site here: http://exchange.sembee.info/2007/install/multiplenamessl.asp

---

Back in January 2007, shortly after the release of Exchange 2007, I wrote an article on how to use single name SSL certificates with Exchange 2007. This was because at the time the preferred SAN/UC certificates were retailing at something like $400 a year.

The market has moved on and you can now pick up the UCC certificates from around $60/year (at the time of writing) from places such as http://certificatesforexchange.com/
Furthermore the process I wrote about in Jan 2007 doesn’t work on Windows 2008 and Outlook Anywhere is not supported outside of the default web site. Therefore its value has become less.

However administrators still seem to be having problems with SSL certificates. A lot of this comes down to the URLs being used. This blog post will try and clear up the confusion and guide you through a quick and easy process to get the certificates, without wanting to poke out your eyes with a spoon. *

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)" -internalurl https://mail.example.com/EWS/Exchange.asmx -WindowsAuthentication:$True
    
    Set-WebServicesVirtualDirectory -identity "EXCH\EWS (Default Web Site)" -externalurl https://mail.example.com/EWS/Exchange.asmx -WindowsAuthentication:$True
    
    Unified Messaging (if installed)
    
    Set-UMVirtualDirectory -identity "EXCH\UnifiedMessaging (Default Web Site)" -externalurl https://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.

Related Posts (added Jan 2009)

Unified Messaging Requires the Server Name in the SSL Certificate
http://blog.sembee.co.uk/archive/2008/06/02/79.aspx

Exchange 2007 with a Single Name SSL Certificate - if you must
http://blog.sembee.co.uk/archive/2008/06/09/80.aspx

More on SSL Certificates with Exchange 2007 - includes details on what is supported
http://blog.sembee.co.uk/archive/2008/10/16/87.aspx

* Credit to fellow Exchange MVP Lee Mackay for that colourful phrase.

Exchange 2007, MS Exchange Server, SSL Certificates Exchange 2007, MS Exchange Server, SSL Certificates

When you are deploying Windows Mobile in to your Exchange environment, you should be using an SSL certificate to secure the deployment.
However the number of SSL certificates that Windows Mobile trusts is much smaller than the number supported by Internet Explorer or Firefox on your desktop. This means one of two things.

1. You need to purchase a certificate from one of that small list.
2. You have to import the SSL certificate in to your device.

For the second option, I have instructions elsewhere: http://www.amset.info/pocketpc/certificates.asp

For the first option, which may be preferable if you are going to deploy a large number of the devices, you need to get a certificate that is issued by one of the roots supported by Windows Mobile.
The root certificates can be easily seen in the device, but the name of the certificate does not always match the name of the company who can issue the certificates. The root certificates have changed hands, companies have merged or simply changed their names.

Therefore what I have done is taken the list of root certificates from a standard emulator image, which is what Microsoft would have supplied the hardware suppliers as their base image and then found who is currently issuing the certificates.
You should check whether the root certificate list I have here is the same as what you have in your device, as there have been reports of some root certificates being removed.

Where it isn't clear who is the current owner of a root, I have put a question mark. Also note that not all providers are using the root certificates to issue NEW certificates - they may be using them for legacy support only. You should note that some issuers are using multiple roots and you may have to ask for a certificate to be issued from a specific root to get Windows Mobile support.

If you are deploying a mixture of Windows Mobile 5 and Windows Mobile 6 devices, then use the list of root certificates on Windows Mobile 5 to ensure maximum compatibility.
If you are tempted by wildcard certificates - remember that Windows Mobile 5 does not support any wildcard certificates.

Windows Mobile 6

Thawte Server CA (Thawte)
Thawte Premium Server CA (Thawte)
Starfield Class 2 Certification Authority (GoDaddy - http://www.certificatesforexchange.com/)
Secure Server Certification Authority (Verisign)
http://www.valicert.com (GoDaddy - http://www.certificatesforexchange.com/)
GTE CyberTrust Global Root (GlobalSign)
GoDaddy Class 2 Certification Authority (GoDaddy - http://www.certificatesforexchange.com/)
GlobalSign Root CA (GlobalSign - was InstantSSL.com)
Geotrust Global CA (Geotrust)
Equifax Secure Certification Authority (Geotrust)
Entrust.net Secure Server Certification Authority (Entrust)
Entrust.net Certification Authority (2048) (Entrust)
Class 3 Public Primary Certification Authority (Verisign)
Class 2 Public Primary Certification Authority (Verisign)
Baltimore CyberTrust Root (Cybertrust?)
AddTrust External CA Root (AddTrust)
AAA Certificate Services (Comodo?)
GTE CyberTrust Root (InstantSSL.com)

Windows Mobile 5

Thawte Server CA (Thawte)
Thawte Premium Server CA (Thawte)
Secure Server Certification Authority (Verisign)
http://www.valicert.com (GoDaddy  - http://www.certificatesforexchange.com/)
GTE CyberTrust Global Root (GlobalSign)
GTE CyberTrust Root (InstantSSL.com)
GlobalSign Root CA (GlobalSign - was InstantSSL.com)
Equifax Secure Certification Authority  (Geotrust)
Entrust.net Secure Server Certification Authority (Entrust)
Entrust.net Certification Authority (2048) (Entrust)
Class 3 Public Primary Certification Authority (Verisign)
Class 2 Public Primary Certification Authority (Verisign)

MS Exchange Server, Windows Mobile, SSL Certificates MS Exchange Server, Windows Mobile, SSL Certificates

10th June 2008
I now consider this post to be completely redudant. As well as the post mentioned below on deploying a SAN/UC certificate, I have now published a further article on using a single name SSL certificate with Exchange 2007 which is not only supported, but also works with Windows 2008 deployments. Obviously a SAN/UC certificate is the preferred method and will provide the most successful deployment, however if you are unable to use anything other than a standard single name certificate then that article will help. The new article is linked from this post: http://blog.sembee.co.uk/archive/2008/06/09/80.aspx

---

30th May 2008
There is a new post elsewhere on this blog that I believe makes this post redudant. As SAN/UC certificates have come down in price it makes more sense to use those rather than the method I have outlined below. Furthermore this process does not work on Windows 2008 and Microsoft do not support Outlook Anywhere outside of the default web site.
To see the updated blog posting click here: http://blog.sembee.co.uk/archive/2008/05/30/78.aspx 

I will leave this post here for reference, but I suggest that you deploy a SAN/UC certificate using the guide I have written above.

---

1st October 2007
I am aware that at least one SSL vendor is sending some customers to this blog posting when asked about deploying their certificates with Exchange 2007. If you have been sent here by a vendor, then you should ask them why they are sending you to a blog rather than assisting you with resolving the problem.

Remember that this is one solution to the problem, and it is not a solution that Microsoft recommend. I have found that it works, but that does not mean it is the ONLY solution.

As of the time of writing this section (1st October 2007) it is still the way that I deploy Exchange 2007 and have found that it works. I constantly review my techniques and will change the article if I believe there is a better way.

---

If you care about network security, you will want to use SSL certificates with your Exchange deployment. SSL certificates could be used with OWA, Outlook Anywhere, ActiveSync and the Autodiscover Service.
However as you will quickly find, SSL Certificates for use with Exchange 2007 is a mess.

When Exchange 2007 is initially installed, the installation wizard creates a self generated SSL certificate for the default web site. While this is fine for initial use, you will quickly want to replace it with a commercial certificate to avoid certificate warnings when users browse to the OWA site and to avoid complications deploying Windows Mobile handhelds.

(I have discussed the reasons to use a commercial SSL certificate on my blog last year: http://blog.sembee.co.uk/archive/2006/03/05/Self-Generated-versus-Commercial-SSL-Certificates.aspx).

With Exchange 2003 it was quite simple to deploy a commercial certificate, simply request and deploy a certificate with your chosen external name. If you wanted the same name to work inside, then you would also configure split DNS (http://www.amset.info/netadmin/split-dns.asp).

If you remove the default certificate with Exchange 2007, it will initially appear to work. If your clients are on Outlook 2003, then most things will work correctly.

However when you introduce Outlook 2007, the complications start.

Outlook 2007 is the first client to support the new web based method of Address Book distribution. Previous versions of Outlook used system folders, part of the public folder structure. Microsoft have made no secret of their desire to kill off public folders and the change in address book distribution is a key step towards that goal.

If you replace the SSL certificate with a certificate that does not match the server's real name, then Outlook 2007 generates a certificate warning when it connects to your server on the LAN. It is expecting the SSL certificate to be on the server's real name.
However best practise for certificates is to use a generic name. You may also be in a position where the server's real name ends in .local.

Therefore you need a certificate that supports the additional name.

On a side issue - you will note that Outlook does not generate a warning message on your self generated certificate, which will not be trusted by the client. It has been confirmed that Outlook does not check the trust status when connecting to Exchange on the internal network.

Then you get the complication of the autodiscover service, which is new for Outlook 2007. That connects to autodiscover.domain.com (where domain.com is the domain name in your email address). Therefore your SSL certificate on host.domain.com will not be accepted because it doesn't match the address being accessed.

If you are fortunate enough to be using the same domain name for your AD domain, as your primary email domain, which is also accessible from outside (domain.com), then you might be thinking at this point to purchase a wildcard certificate - so that *.domain.com would work.
That would be fine, but if you want to support Windows Mobile devices, then you will need to think again, as Windows Mobile does not support wildcard SSL certificates.

Therefore what is the solution?

You could look to purchase an SSL certificate that supports the additional names. However none of the cheap SSL certificate providers (RapidSSL and GoDaddy) issue certificates that allow you to have the additional names. The only certificate that I have found that does is one of the US$600 certificates from Geotrust. Having to pay $600 for a certificate just to secure OWA seems very expensive and is not something that many sites will accept.

Therefore the resolution to this problem I have found is to use multiple web sites.

This isn't as hard as it may sound and I will give you the brief steps here. (More comprehensive instructions will appear on the amset.info web site at some point in the future).

1. Setup Outlook Anywhere as required. This is important as it is the one feature that cannot have its virtual directory recreated using the Exchange Management Shell.
   
2. Add an additional internal IP addresses to your Exchange server's network card. For example, if 192.168.1.1 was the default address for the server, you would add 192.168.1.2 as an additional address. It does not have to be the next address, just as long as it is on the same subnet (192.168.1.x)
   You need additional IP addresses as you cannot use host headers with SSL.
   
3. Adjust the configuration of IIS so that the default IP address is bound to the default web site. This is a change from the "All unassigned" setting.
   
4. Create a new web site in IIS Manager. In this example I will call it External. Set it to use the additional IP address, using the default ports. When asked for the path, use the same as the default (C:\Inetpub\wwwroot). When asked for permissions, select Read and Run Scripts only.
   
5. Open the Exchange Management Shell and run the following commands:
   If you are supporting Exchange 2007 Mailboxes ONLY:
   
   New-OWAVirtualDirectory -OwaVersion:Exchange2007 -Name "owa" -WebSite "External"
   
   If you are also supporting Exchange 2003 mailboxes, then you need to run these additional commands:
   
   New-OwaVirtualDirectory -OwaVersion:"Exchange2003or2000" -Name "Exchange" -WebSite "External" -VirtualDirectoryType:Mailboxes
   
   New-OwaVirtualDirectory -OwaVersion:"Exchange2003or2000" -Name "Public" -WebSite "External" -VirtualDirectoryType:PublicFolders
   
   New-OwaVirtualDirectory -OwaVersion:"Exchange2003or2000" -Name "Exadmin" -WebSite "External" -VirtualDirectoryType:Exadmin
   
   New-OwaVirtualDirectory -OwaVersion:"Exchange2003or2000" -Name "Exchweb" -WebSite "External" -VirtualDirectoryType:Exchweb
   
   For ActiveSync, run the following command:
   
   New-ActiveSyncVirtualDirectory -WebSiteName "External"
   
   When you refresh the configuration in Exchange Management Console, you should see two sets of virtual directories under Server Configuration, Client Access, Outlook Web Access and Exchange ActiveSync.
   
6. To add Outlook Anywhere to the web site, open up IIS Manager. In the default web site, find the /rpc virtual directory. Right click on it and choose All Tasks, Save Configuration to a File… and save the configuration.
   Then on the new web site that you have just created, right click on the root and choose New, Virtual Directory (from file)…
   When prompted select the file that you exported from the default web site.
   
   Important note - any configuration changes to Outlook Anywhere do not appear to be reflected in this exported file, so it is important that any configuration is done before the export/import. If you make any changes to the Outlook Anywhere configuration then the export/import will need to be repeated. Delete the imported virtual directory and replace it with a freshly exported configuration file.
   
7. Once you have created the virtual directories, you can then put an SSL certificate on to the new web site and then point external traffic to that address.
   Internal traffic can also be pointed to the new web site.
   Leave the self generated certificate on the default web site, as Outlook 2007 will continue to connect to it.

Autodiscover Service

For Autodiscover, you actually have two options.

1. Repeat the above process, with a new dedicated web site for autodiscover.
   The command for a new Autodiscover virtual directory is
   
   New-AutodiscoverVirtualDirectory -Websitename Autodiscover -BasicAuthentication:$true -WindowsAuthentication:$true
   
   That web site can then get its own SSL certificate.
   This could be useful if you use two different domains, one for email and one for external facing web services. Autodiscover uses the same domain as your email.
   However if you have multiple domains for email, you will need to use the redirect method.
   
2. Add to the external web site and configure a redirect.

To add the Autodiscover virtual directory to the External web site created in above:

New-AutodiscoverVirtualDirectory -Websitename External -BasicAuthentication:$true -WindowsAuthentication:$true

The redirection configuration is very important to ensure that it works correctly. The redirection method requires port 80 (http) traffic to come in. For internal traffic that is fine, but for external traffic you may want to look at a way of configuring the redirection using a public web site.

At the time of writing, this is Microsoft's article on redirection. It is covered under the section Hosted Environments and the Autodiscover Service, but would also be useful if you have more than one domain, or you use a different domain for email than you do for external facing web services.

http://www.microsoft.com/technet/prodtechnol/exchange/e2k7help/4172728f-bb70-4579-9d5d-fccdd4afcd80.mspx?mfr=true

Conclusion

Your control over the web services of Exchange 2007 provides you with many more options for using SSL than Exchange 2003. Unlike Exchange 2003, with the exception of Outlook Anywhere, these options are provided as part of the product, allowing you to use them with the confidence that they should work as expected and can be managed with other features of Exchange.

Exchange 2007, MS Exchange Server, SSL Certificates Exchange 2007, MS Exchange Server, SSL Certificates

A constant theme on many of the Internet forums is the use of self generated SSL certificates versus purchased SSL certificates, particularly when deploying RPC over HTTPS or Outlook Web Access.
Many people will advocate that using a self generated certificate is fine and will do the job.
This could be a certificate generated from the selfssl.exe tool that is supplied with the IIS Resource Kit, or Microsoft's certificate application.
However I am not one of them, and always deploy Exchange with a purchased certificate.

Use of SSL Certificates
SSL Certificates have two main tasks. 

1. To prove that the server you are accessing is the server that you meant to access.
2. To encrypt the connection between the application being used to access the server, and the server itself.

There are three things that your web browser looks for when accessing a secure site.

• that the name on the certificate matches the address being accessed
• the certificate is issued by someone the browser trusts, or the certificate matches one already installed on the web browser
• the certificate is valid.

If any of those three fail, then you will get a warning message popup.
With self generated certificates, you will get the warning message when you access the server. This is because the certificate hasn't been issued by a trusted authority.
You can get round that warning message by importing the certificate in to the web browser. However that makes a lot of work with deployment, complicates matters and also means that you have to repeat the exercise when the certificates expires.
It also doesn't help when people are accessing your site from a public computer where you cannot install the certificate, such as an internet café or their machine at home.
And that is where self generated certificates start to cause problems.
You can tell your users to ignore the message when connecting to your site, but users have a habit of only hearing what they want to hear. They will hear "ignore the message" but forget the bit "when using our site". In these days of phishing and spoof web sites network administrators need to give out a consistent message - and telling users to ignore a security warning is a very example of failing to do that.
A security warning of any kind looks unprofessional and shows a lack of concern for security.

So what are the alternatives?
The best alternative is to purchase an SSL certificate.
However many administrators think that they need to go to one of the big SSL certificate issuers such as Verisign and pay US$400 or more per year - and that is just for a 40 bit certificate.
That is not the case.
I do my deployments using RapidSSL certificates. They cost US$69 per year and that is for a 128bit certificate. Their root certificate is in most of the popular web browsers so there is no complication there.
If you do need to deploy the certificates to Pocket PC devices, then that can be easily done (see http://www.amset.info/pocketpc/certificates.asp).
You could also certificates from Certificates for Exchange which are trusted by Windows Mobile 5.0 with MSFP and higher. Nothing to install on the devices making deployment easy.
You may also see some "free" SSL certificates around. These should be looked at carefully, paying particular attention to the root certificate support. If the root certificate isn't in the majority of web browsers then you will have the same problem as when issuing your own certificates - prompts and imports.

Do Self Generated Certificates Have a Place?
Yes they do. I use them all the time in lab environments. When I have control over every item accessing the service, then I will use the a self generated certificate and make all of adjustments as required to get it to work correctly. However in a production deployment, they are never used.

Exchange 2003, MS Exchange Server, Why you shouldn't..., Exchange 2007, Networking General, SSL Certificates Exchange 2003, Exchange 2007, MS Exchange Server, Networking General, SSL Certificates, Why you shouldn't...