cancel
Showing results for 
Search instead for 
Did you mean: 

SSL Certificate Name and EV External DNS Name

aschnarrs
Level 4
Partner Accredited

All,

We have a single EV 10.04 server and a 3 server Exchange 2013 SP1 CU7 environment.  EV archiving and journaling is running with no issues. I am working on publishing EV for external use within OWA.  I have read through several articles and links regarding how to deploy the webapp.  All seems straight forward until I get to the certificate part.  It would seem that everyone else has the same confusion/question.

On our EVserver we have internal name of evsrv.paper.dom and the DNS alias is “evault” which then points back to evsrv.paper.dom 

Note that “paper.dom” is the internal Windows AD domain and it is not routable from the internet.

The external namespace is abc123paper.com

Question 1 – What does the common name of the SSL Cert need to be?  Does it need to match the EV servername?  Paper.dom is not routable on the internet so here is the problem/question.  Can it be anything that can route back to your EV server from a DNS perspective?

Question 2 – Some articles suggest using a SAN Cert.  Use a common name something like evsrv.paper.com and then have an alternative name for the internal server names.  But I have the same problem.  SSL providers will not let you add any name you want.  It needs to be routable and owned by your business.  I just can’t throw in a evsrv.paper.dom because the paper.dom domain doesn’t exist external.

Question 3 – Could I just use a normal web server certificate with a common name of evsrv.abc123paper.com, install that on the EV server and call it a day or do names need to match?

I have read through “Requesting a SSL Cert” - http://www.symantec.com/business/support/index?page=content&id=HOWTO83452 and it doesn’t say either way that names “must” match.  At least I can’t find it.

 

Thanks for the help in advance.

1 ACCEPTED SOLUTION

Accepted Solutions

BigPhil
Level 5

To answer your questions:

1) The common name of the cert needs to match the external access domain (*.abc123paper.com). Yes, it can be any name that can find its way back to the ev server. You'll need to setup split DNS so internal OWA users can also resolve *.abc123paper.com internally or the mail app wont work for them.

2) As you stated, you cant add a domain name to a 3rd party cert that you dont own or isn't real. No real need to do this though. You can use any cert type you like, be it a wildcard cert for *.abc123paper.com, SAN cert that contains your external access name for EV (i.e. evsrv.abc123paper.com), or just a single name SSL cert with that same name.

3) Yes, that would work just fine. No matter what you do, you have to install the cert on the EV server and then add the 443 port binding to the Default Website.

Once the cert is obtained and installed on the EV (and any reverse proxy you may use, like TMG), your command to install the app for the entire organization would look like this:
 

$Mbx = get-mailbox "mailbox"
New-App -OrganizationApp -DefaultStateForUser:enabled -Url ("http://evsrv.paper.dom/EnterpriseVault/OfficeMailAppManifest.aspx?LegacyMbxDn=" + $Mbx.LegacyExchangeDN + "&BaseURL=https://evsrv.abc123paper.com/EnterpriseVault")

Where "mailbox" is any mailbox enabled for archiving. evsrv could (and probably should) be replaced by the name you use for your vault site alias (found on the vault site properties/general tab).

As a side note, I personally use DigiCert for my 3rd party certs. Their prices, tools, and support are awesome!

View solution in original post

3 REPLIES 3

BigPhil
Level 5

To answer your questions:

1) The common name of the cert needs to match the external access domain (*.abc123paper.com). Yes, it can be any name that can find its way back to the ev server. You'll need to setup split DNS so internal OWA users can also resolve *.abc123paper.com internally or the mail app wont work for them.

2) As you stated, you cant add a domain name to a 3rd party cert that you dont own or isn't real. No real need to do this though. You can use any cert type you like, be it a wildcard cert for *.abc123paper.com, SAN cert that contains your external access name for EV (i.e. evsrv.abc123paper.com), or just a single name SSL cert with that same name.

3) Yes, that would work just fine. No matter what you do, you have to install the cert on the EV server and then add the 443 port binding to the Default Website.

Once the cert is obtained and installed on the EV (and any reverse proxy you may use, like TMG), your command to install the app for the entire organization would look like this:
 

$Mbx = get-mailbox "mailbox"
New-App -OrganizationApp -DefaultStateForUser:enabled -Url ("http://evsrv.paper.dom/EnterpriseVault/OfficeMailAppManifest.aspx?LegacyMbxDn=" + $Mbx.LegacyExchangeDN + "&BaseURL=https://evsrv.abc123paper.com/EnterpriseVault")

Where "mailbox" is any mailbox enabled for archiving. evsrv could (and probably should) be replaced by the name you use for your vault site alias (found on the vault site properties/general tab).

As a side note, I personally use DigiCert for my 3rd party certs. Their prices, tools, and support are awesome!

aschnarrs
Level 4
Partner Accredited

Thanks for the advice.  We went ahead and configured as you suggested and it appears to work.

Now I need to figure out why users keep getting prompted for username/password when clicking on the WebApp from within OWA.  I did confirm that the EV server name and alias is in the trusted listing in IE but that didnt seem to fix the issue.

 

BigPhil
Level 5

Good to hear. As for the other issue, it would be best to start a new thread for that. There are quite a few variable here as to what could cause the authentication prompts. In the new thread, give us all of the details as to your setup, i.e. using any type of reverse proxy, does it happen to internal and external users, etc.