Certificate question
I have setup a new Exchange 2010 server and I am migrating from Exchange 2003. I have an internal domain name of 123.org and an external domain name of abc.org. I have created a certificate request and was attmpting to purchase the cert from Digicert. The
rep at Digicert told me that I could not buy the SSL cert because my internal domain name of 123.org is a registered external domain name of another comapny.
My problem is that I am not sure how to remedy this problem. The rep I was speaking with got in touch with his Exchange cert expert and they directed me to this article
http://support.microsoft.com/kb/940726 and told me to change the internal settings to use the domain name of our external domain name which is abc.org.
Will this work to fix my problem? And will this cause any problems on the internal domain name?
Lastly, would it be best to purchase a wildcard certificate or a SAN certificate. It seems like it would be simpler to manage it it was a wildcard cert. Once the migration is complete I will only have one outward facing Exchange server, so hopefully there
would be no security problems with using the wildcard cert.
Thanks,
Doug
February 9th, 2012 1:34am
You should use the name abc.org as Common Name in your certificate. The name 123.org should be added to the SAN field.
If you use EMC to generate certificate request, you should mark the name abc.org as default.
http://alexxhost.ru
Free Windows Admin Tool Kit Click here and download it now
February 9th, 2012 2:07am
I believe what your saying is DigiCert says your internal domain names matches an already registered external domain name of another company, therefore they wont let you add it to the SAN list? This makes sense and is why you should use internal domain names
like abc.local, and abc.int or the like.
To remedy your problem I think DigiCert was close, you need to just use the external domain name of abc.org on your cert. Use the Exchange 2010 certificate wizard to generate it and the additional SAN names like autodiscover.
You will need to setup an internal DNS entry for mail.abc.org or whatever, that points to your CAS. And also change the internal URLs to match the external URL. On Exchange 2010 Management Console, go to Server Configuration/Client Access and click each
web site under OWA, ECP, OAB and change the internal URL to match the external. Probably also need to modify the SCP record for autodiscover for the cert to work since it wont have your internal server name on it, the command via Exchange Powershell is
Set-ClientAccessServer -Identity <var>CAS_Server_Name</var> -AutodiscoverServiceInternalUri
https://<var>mail</var>.contoso.com/autodiscover/autodiscover.xml -- for CAS server name, use the external URL like mail.abc.org.
Now, none of your clients will ever see the internal URL of the server, so you wont get a certificate issue.
Hope this helps..
February 9th, 2012 10:48am
To add to Adam.
Or you register the domain name you use internally so no one else can get it, but you don't have to publish it on the Internet.
What I am getting a feel for here is that you have not planned out all the aspects of your Exchange 2010 design. This should be done prior to submitting certificate requests. Make sure you understand the CAS namespaces that you are using and
map them out, e.g.
http://technet.microsoft.com/en-us/library/dd351198.aspx
If you have split brain DNS, then you can do what Adam suggests and use the same names internally and externally. You will need to configure ALL URLs and not just AutoD. Again this goes back to namespace design which is 90% of CAS work, the remaining
is 5% implementation and 5% test. Numbers can be changed, but you get the idea :)
Remember to consider activesync, Outlook Anywhere, Autodiscover, EWS, OAB, ECP.........
Cheers, Rhoderick
Free Windows Admin Tool Kit Click here and download it now
February 9th, 2012 11:03am
Hello,
Share with you a nice article:
More on Exchange 2007 and certificates - with real world scenario
http://blogs.technet.com/b/exchange/archive/2007/07/02/3403301.aspx
Thanks,
Simon
February 12th, 2012 12:44pm
Hey guys,
Sorry for the late reply on this, but I have been out of town for a few days.
Thanks for the great replies. It looks like I will go with what Adam states. He hit it right on the nose about the internal domain name matching another companies internet domain name. Because we do not own that domain name Digicert would not issue
us the cert. Had I known back in 2004 that MS would someday make a new Exchange server that would require using an SSL cert for both internal and external security, I probably would have named the internal domain name .local or .internal or something
like that. With that said, it looks simple enough to change the CAS names for internal resolution. As long as no one gets the certificate error then it's all good. I will probably be installing the cert byt the end of this week. I will post my results and
more thanks here when I get it to work.
Thanks again,
Doug
Free Windows Admin Tool Kit Click here and download it now
February 15th, 2012 12:50am
Well, I finally got the server going on Saturday morning and after changing all the internal names to abc.org domain name everything worked just fine all weekend. So, thanks for the input here.
Now I seem to have another problem that just popped up today. The problem is that when I create a new outlook profile on a workstation it tries to connect to mail.abc and not to mail.abc.org. So now I get a certificate error mismatch with the certificate
name. for some reason my DNS server was resolving mail.abc to some ip address on the internet. I have no idea why this is happening, but I came up with a cheap and easy fix. The fix was to create a new zone called mail.abc. In that zone I created a blank A
record with the ip address of my Exchange 2010 server's internal ip address. It seemed to do the trick for now, but I would like to know why this happened in the first place.
Any help would be greatly appreciated.
Doug
BTW, the certificate that it was seeing was a cert registered to Open DNS. We use Open DNS as our external DNS servers.
February 29th, 2012 2:50am