Ralph Scharping
asked on
Exchange 2013 workaround for single domain certificate
Hello,
even though I realize that a multi domain unified communications certificate has been the way to go since Exchange 2007, it has always been possible to also work with a single-domain-certificate. SBS2008 and 2011 did it, and it was could also be done with Exchange Standard in both versions.
I now have my first Exchange 2013 and I am struggeling with this. A certificate is already there and paid for for 5 years, and I would hate to waste it.
This is the setup:
Exchange 2013 on Server 2012 R2 Standard, One DC running Exchange locally (I know it is not recommended).
AD-Domain "company.local", hostname "server.company.local", external domain "remote.company.com". Certificate issued to the external name.
There will be roughly 40 mailboxes on this host. No other servers are involved.
Features required include Outlook Anywhere.
When opening Outlook it connects and syncs fine, then after a rather longer while than I expect, it complains that the certificate, which is valid and issued by a trustworthy CA, was not issued for server.company.local.
I proceeded with the setup the way I always did in 2010 and worked through several of the tutorials including this:
http://www.shudnow.net/2007/08/10/outlook-2007-certificate-error/
which has helped me get 2010 up and running with single domain certificates more than once.
Does anybody know if this can be done at all with 2013 and if so then in what way it works different from 2010?
Thanks,
Ralph
even though I realize that a multi domain unified communications certificate has been the way to go since Exchange 2007, it has always been possible to also work with a single-domain-certificate.
I now have my first Exchange 2013 and I am struggeling with this. A certificate is already there and paid for for 5 years, and I would hate to waste it.
This is the setup:
Exchange 2013 on Server 2012 R2 Standard, One DC running Exchange locally (I know it is not recommended).
AD-Domain "company.local", hostname "server.company.local", external domain "remote.company.com". Certificate issued to the external name.
There will be roughly 40 mailboxes on this host. No other servers are involved.
Features required include Outlook Anywhere.
When opening Outlook it connects and syncs fine, then after a rather longer while than I expect, it complains that the certificate, which is valid and issued by a trustworthy CA, was not issued for server.company.local.
I proceeded with the setup the way I always did in 2010 and worked through several of the tutorials including this:
http://www.shudnow.net/2007/08/10/outlook-2007-certificate-error/
which has helped me get 2010 up and running with single domain certificates more than once.
Does anybody know if this can be done at all with 2013 and if so then in what way it works different from 2010?
Thanks,
Ralph
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
What about external DNS SRV record? For Anywhere clients that are OOF and using public DNS servers to configure Outlook?
ASKER
Haven't gotten that far, yet. So far I am still struggeling with internal clients.
Can you check if External/Internal URLs for all directories is correctly specified at Servers -> Virtual Directories tab?
ASKER
Those are okay, but aren't there some more that are not changeable in the GUI?
Actually in your case only autodiscover, OWA and OAB might cause such problems.
Hm, the only difference between my and your implementation is that I have NLB between client and CAS, which actually has the correct name and cert on it.
In this case I guess there's no workaround (because clients are not using RPC MAPI anymore, they're always using HTTPs, which checks for real and cert host names).
In your case I'd recommend going with new cert, which will include all the hostnames and URLs in SAN (subject alternative name). You will need it sooner or later.
Hm, the only difference between my and your implementation is that I have NLB between client and CAS, which actually has the correct name and cert on it.
In this case I guess there's no workaround (because clients are not using RPC MAPI anymore, they're always using HTTPs, which checks for real and cert host names).
In your case I'd recommend going with new cert, which will include all the hostnames and URLs in SAN (subject alternative name). You will need it sooner or later.
ASKER
Well, turns out it was the autodiscover internal url.
This is the guide that spelled out to me how to check everything:
http://www.mustbegeek.com/configure-external-and-internal-url-in-exchange-2013/
This is the PowerShell-command to set the value needed:
Set-ClientAccessServer -Identity <servername> -AutoDiscoverServiceIntern alUri https://remote.company.com/Autodiscover/Autodiscover.xml
This is the only URL that STILL cannot be set in GUI.
This is the guide that spelled out to me how to check everything:
http://www.mustbegeek.com/configure-external-and-internal-url-in-exchange-2013/
This is the PowerShell-command to set the value needed:
Set-ClientAccessServer -Identity <servername> -AutoDiscoverServiceIntern
This is the only URL that STILL cannot be set in GUI.
ASKER
See specifics in the rest of the thread.
ASKER
thanks for your response. Outlook Anywhere was already configured the way you suggested.
My internal DNS resloves remote.company.com to the CAS-Servers internal IP-address through a regular A-record. I have created a forward lookup zone "remote.company.com" and added an A-record without a hostname pointing to server.company.local
In addition to that I set a SRV-record at company.local\sites\Defaul
The record is _autodiscover priority 0, weight 0, port 443 pointing to remote.company.com
Is there anything else I could have missed?