Our users access OWA using a cname record webmail.domain.local Our Outlook use the actual server name servername.domain.local I'm a little confused when it comes to creating the SSL certificate using our existing internal certificate server. When I run through the wizard to generate a certificate request on exchange should I put the actual server name in the OWA URL or the CNAME or since I have a CNAME record do I need both on the certificate and have to generate it some other way? Thank you for any ideas.

Is this server not seen from the internet at all?

No OWA, ActiveSync etc?

If you are using an internal CA, then I would generate a request with both names on it. Use the wizard in Exchange to do that.

Then within Exchange, change all of the URLs to your preferred host name (normally not the server name).

That way the clients will start to use the preferred name, rather than the server's real name.

However it is now very unusual to find anyone using a .local in the SSL certificate. As you cannot get trusted SSL certificates with internal domains on them, and most Exchange servers are exposed to the internet, the best practise is to use the same host name internally and externally, along with a trusted SSL certificate.

Simon.

I agree. We are planning some changes to no longer use a local domain name. I apologize for missing some details, I failed to add that what I really wanted to do was use our internal CA to generate a certificate for internal use of exchange, but I also wanted to use a public CA for outside use and OWA access from remote sites. Is that something I could do, or do I need to go ahead with plans to fix our domain name issue?

You did answer most my problems though, with needing both names on the certificate. Thank you.

• Edited by hunterblackwolf 13 hours 4 minutes ago

You cannot mix the certificates in the way that you want.

Well you can, but adds additional complexity to the environment.

What I would do is have the internal name s(if you must keep them) on a separate site that redirects.

Then use the external name internally and externally (with split DNS for name resolution to the internal IP address).

Wean the users off the use of the internal name.

Simon.

I agree. We are planning some changes to no longer use a local domain name. I apologize for missing some details, I failed to add that what I really wanted to do was use our internal CA to generate a certificate for internal use of exchange, but I also wanted to use a public CA for outside use and OWA access from remote sites. Is that something I could do, or do I need to go ahead with plans to fix our domain name issue?

You did answer most my problems though, with needing both names on the certificate. Thank you.

• Edited by hunterblackwolf Friday, September 04, 2015 6:26 PM

Hi,

Generally, Public CA will not support internal names in the near future. And the third-party certificate authority could not be requested .local namespace.

Therefore, if you want to keep your internal domain name with .local, we can create a mirror of the Public Zone in your internal network which is known as split-brain DNS. Please refer to the following article to configure it:

http://www.msexchange.org/articles-tutorials/exchange-server-2013/management-administration/managing-certificates-exchange-server-2013-part2.html

Then we can set both internal and external URLs for Exchange services to use mail.domain.com (pointed to Exchange 2013 internally and externally) and autodiscover.domain.com (only for Exchange Autodiscover service) for your Exchange environment.

For Exchange certificate, just request a SAN certificate from a trusted third-party CA with mail.domain.com and autodiscover.domain.com.

Regards,