• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 707
  • Last Modified:

Exchange Certificate Change


I have Exchange 2013 CU3 running on Server 2012 Standard with both CAS and Mailbox roles.  I have on more than one occasion read about hiding the actual netbios host name of the server and keeping it off the public certificate.  One example is this article:  http://exchangeserverpro.com/avoiding-exchange-2013-server-names-ssl-certificates/

Things were running pretty good (save for some ActiveSync issues) but I am nervous about having the host name listed in public DNS so off I go on this effort of changing things over to the generic mail.mydomain.com.  I changed the EHLO on the Send Connector.  I tried to change the EHLO on the five Receive connectors but three of them would not take the change and it appears there is no way to change them.  I believe it was Client Proxy, Default Server, and Default Frontend Server (I only use the default connectors).  I changed my SMTP banner so it won't show there.  DNS records show the generic name.  I re-keyed the certificate at GoDaddy and took off the host name.  All virtual directories were changed to have the same internal and external urls of mail.mydomain.com.  I made changes to internal DNS to make sure mail.mydomain.com and autodiscover.mydomain.com point to the IP of the server.  I also take off the detailed routing information in the headers so the host name would not show there either.

I ran Windows Update and some updates came down including KB2880833.  I rebooted.

I log back in and now I do not have access to the Exchange Power Shell as it does not see the server.  I tried to have it go to mail.mydomain.com and still errors out.  WinRM can't resolve hostname.  I go to https://mail.mydomain.com/ecp or owa and login and get a blank page.  If I substitute the host name I get the red certificate warning and I click to go on and same thing I get the blank page.  Changing the cert has completely demolished this installation.  IMAP, ActiveSync, OutlookAnywhere, and even Outlook connecting up to the server is all failing.  Good thing this is a small installation in the start up phase.

Well we all get desperate so after some troubleshooting and nothing working I tried to delete the virtual directories in the Default Website in IIS and rebuild them manually.  No go...in fact now I am in worse shape and getting the 403 error and no site at all (I did not say this was going to be easy !).

Obviously my first question is where do I go from here ?  Anyone know of a way to rebuild the virtual directories successfully in IIS or other tools ?

My second question is do I forget the plan to try to hide the host name of the server ?  I could re-key the certificate again and put the host name back into it.  I am not keen on this idea but if that's what I have to do to get this working again then that's it.  I do have some decent security with endpoint protection and Malware protection on the mail server itself and behind some Cisco gear.  I know...you can never be secure enough.

The fallback is that I have two images of this server before all the problems.  Both of them might pre-date CU3 but I could always reinstall that to match the schema changes made in Active Directory.  I re-keyed the cert on 1/17 so both images pre-date change as well I could install a new certificate pretty quickly after the re-image.  Any assistance you can give me is much appreciated !  Thank you.
  • 2
2 Solutions
Marshal HubsEmail ConsultantCommented:
Even I faced a similar situation, but I fixed this problem, by carrying out a fresh install on a new server, by moving mailboxes to the new server, and re-purposing and de-commissioning the original server.

I attempted frequently to re-install the CAS role, re-create the EWS virtual directory and always came up against the same trouble. Could not re-create the virtual directory.

One thing which I haven’t tried that may be worth a go for some-one in the same position is to entirely uninstall IIS and the Windows Process Activation Service and then re-install both. From what I have been reading since re-building my server I consider the problem I faced was an orphaned record in the IIS metadata.

For more info on recreating the virtual directories, you can visit http://microsofttoolbox.com/2009/12/how-to-recreate-exchange-virtual-directories/
pizzaman7ConsultantAuthor Commented:
Your link doesn't work by the way.  This is now the second time I have been locked out of my installation with a settings change.  The last time a friend of mine was helping me troubleshoot an OWA issue and he turned off one of the login options....I think it was Integrated Windows login.....and then I could no longer login into ECP.  At the time Powershell was still working and I put in the commands to change the login option back and that did not work.  I used Powershell to delete and re-create some of the virtual directories and still could not log in !

I can appreciate the ease of using a browser to administer your server and using Powershell to control it but I think people are going to miss having the software available as a tool.  There is no way that we should have to resort to going back to a previous state in order to administer your server !

I have an Acronis image from 1/12 and have to cut bait and stop wasting more time on this that probably won't be fruitful.  I will then likely have to re-apply CU3......sigh.........
Simon Butler (Sembee)ConsultantCommented:
You may find that removing the CAS role using Add/Remove programs then reinstalling it might put things back. Your error was removing the virtual directories, because it isn't' possible to rebuild them manually, you have to use the commands.

Changing the SSL certificate shouldn't have been a problem, as long as you use the commands in Exchange to do so, although your logic for doing so seems odd.

You cannot have NETBIOS or internal host names on public SSL certificates any longer. The self signed certificate created by Exchange isn't supported for use with Outlook Anywhere or ActiveSync, so you should have been planning for the deployment of a trusted certificate anyway.

On the receive connectors, you do need to have the real name of the server for the functionality to work correctly. However from a security point of view it doesn't really do much. It will slow down an attacker for about 10 seconds at most, you don't get security by obscurity. In most attacks they don't care about your server names, they just want to compromise an SMTP server. If you are being specifically targeted then there is little you can do - the information can be found out in any number of ways.

pizzaman7ConsultantAuthor Commented:
I might have to try uninstalling the CAS role next time if I find myself in this unfortunate situation.  I used the Exchange 2013 GUI  to change out the certificate so it was done properly but without the netbios name of the server on the certificate nothing worked.  Like I said, could not use the Exchange powershell nor the web browser to ECP.

If the name of the server is not to be on the certificate then I am not sure why GoDaddy approved it.  Everything is running fine right now including Outlook Everywhere.  I have some Active Sync issues to iron out but I don't think they are due to certificate issues.

I restored from image and created another new cert and installed it and save the active sync issues everything is doing good.  Thanks.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now