SSL Certs, internal names, and local domains

U

USMCGrunt

2[H]4U
Joined
Mar 19, 2010
Messages
3,103
So....a couple months from now, SSLs will no longer be issued for local host names. I need some guidance on this....for some reason the whole SSL concept, while simple...makes my head hurt...not sure why...

Anyways, we host an exchange server on our internal AD domain that is server.company.local. Now, from my limited understanding, our SSL cert with a Subject of PublicFQDN will work fine but the SAN listing of servername.company.local is not going to work anymore. If I have the SAN changed to servername.PublicFQDN will this still work? What will I have to do to get it to work properly? The company is also looking into adding a Lync server so...more SSL goodness to configure.
 
Are you asking if you can use the public cert/fqdn internally? If so, yes you can use it for internal traffic to the exchange server. You will need to add a new DNS zone in AD for the public domain, that points to the private IP of the exchange server. That way when internal servers try and access exchange, they get the private IP and hit it directly instead of the public IP (which may not work at all depending on your firewall setup).
 
No, what I'm saying is that SSL certs that contain internal host names, as of Oct 15. will no longer be acceptable, they're being deprecated. Meaning Public CA's will no longer issue SSL certs that contain internal hostnames in the SAN.

Currently, we have an SSL cert for Microsoft Exchange functions that is something like this:

Subject Name: mail.company.org
Subject Alternate Names:
hostname.company.local
hostname
mail.company.org
autodiscover.company.org
rds.company.org

Under the new standards, the first two SANs will no longer be accepted. This will, I imagine, cause authentication issues within the organization. To further complicate things, when the domain was setup....whenever it was done....they made it a .local domain, meaning I can't just register a domain to match my AD domain. I assume there's a way to modify Exchange but I really don't know and I'm not an Exchange guru.
 
I ran into a similar issues, these are my notes below for what i did to over come the .local domain name issue and no longer able to use .local domain in ssl certs. Hope it helps

Exchange 2010 .local domain name in certificate name. Internal Email Clients receiving cert warning. Redirect Internal Names to use a Registered Domain

Internal outlook clients where receiving a certificate warning after removing the .local domain from the cert.

Create a new primary dns zone for ex: domainname.com
Add new A record for mail.domainname.com to point to internal server IP
This way when internal clients try connecting to mail.domainname.com it will know where to point internally to the server IP.

There is also a couple of things that will need to be done in Exchange management shell and Exchange Management Console, in Exchange 2010.
To update your Exchange 2007 or Exchange 2010 server you will need to run the following commands from the Exchange Management Shell and replace the Server running the Client Access Role with your external domain name. These commands update the URL for the Autodiscover service, Exchange Web Services (EWS) and the OWA Web-based Offline Address book respectively.

Before running these commands you will just need to check make sure a DNS record exists mapping the IP Address to the Exchange Client Access (CAS) server.

Note: Each of these commands below should be run on a single line in the Exchange Management Shell (EMS):

Set-ClientAccessServer -Identity HostName -AutodiscoverServiceInternalUri https://mail.yourdomain.com/autodiscover/autodiscover.xml
Set-WebServicesVirtualDirectory -Identity "HostName\EWS (Default Web Site)" -InternalUrl https://mail.yourdomain.com/ews/exchange.asmx
Set-OABVirtualDirectory -Identity "HostName\oab (Default Web Site)" -InternalUrl https://mail.yourdomain.com/oab
Recycle the IIS Application Pools

Next to make these commands take effect you have to tell IIS to push these changes by recycling the application pools.

Open IIS Manager by clicking Start, then enter inetmgr.
Expand the server and expand Application Pools, then right-click on MSExchangeAutodiscoverAppPool, and select Recycle.
 
Why not just force users to leverage the external cert (with matching DNS subdomain, etc.)?
 
PiERiT said:
You need to run some commands in EMS to reconfigure Exchange to use the FQDN. GoDaddy has a good article on what to do:

https://www.godaddy.com/help/reconf...ver-to-use-a-fully-qualified-domain-name-6281
Click to expand...

Junior82 said:
Add new A record for mail.domainname.com to point to internal server IP
Click to expand...

GoDaddy Tutorial said:
If you haven't already done so, to ensure that internal Autodiscover continues to work, you must create an internal DNS zone for your domain name (for example, autodiscover.coolexample.com) and a MX record that points to your server's internal IP address
Click to expand...
So which is it, an A record or an MX record?

REDYOUCH said:
Why not just force users to leverage the external cert (with matching DNS subdomain, etc.)?
Click to expand...
I'll be honest, I have no idea what you mean or how to go about doing this.


I've already got a DNS zone setup for our internal domain with a record pointing to our mail server....though I don't know if it's pointing to the internal IP of the host or the public, external IP. So it looks like I just need to run the commands in EMS to reconfigure Exchange.
 
USMCGrunt said:
So which is it, an A record or an MX record?

I've already got a DNS zone setup for our internal domain with a record pointing to our mail server....though I don't know if it's pointing to the internal IP of the host or the public, external IP. So it looks like I just need to run the commands in EMS to reconfigure Exchange.
Click to expand...

Generally when you do DNS on your internal stuff, you point to the internal IP of the server.

You can test your DNS by just doing a simple ping to the mail server hostname and see what IP it resolves. If you're using that as your primary DNS server, anyway.

Then on your registrar you can either configure another authoritative DNS server for "domain.com", or just add a new (A) record to have "mail.domain.com" resolve to a listening IP on your edge device and have NAT/ACL to permit traffic in for mail/http, etc.

MX records are used to define which server is the mail server accepting email for the domain. How else would [email protected] know to actually send messages to "mail.domain.com"? You can verify this with an MX lookup (I'm sure you have done this before). The A record would be used for the actual resolution of the FQDN of the mail server, now that messages are being sent to "mail.domain.com" you have to have an A record that defines the IP for resolution.
 
Cmustang87 said:
Generally when you do DNS on your internal stuff, you point to the internal IP of the server.

You can test your DNS by just doing a simple ping to the mail server hostname and see what IP it resolves. If you're using that as your primary DNS server, anyway.

Then on your registrar you can either configure another authoritative DNS server for "domain.com", or just add a new (A) record to have "mail.domain.com" resolve to a listening IP on your edge device and have NAT/ACL to permit traffic in for mail/http, etc.

MX records are used to define which server is the mail server accepting email for the domain. How else would [email protected] know to actually send messages to "mail.domain.com"? You can verify this with an MX lookup (I'm sure you have done this before). The A record would be used for the actual resolution of the FQDN of the mail server, now that messages are being sent to "mail.domain.com" you have to have an A record that defines the IP for resolution.
Click to expand...

Deeper explanation without the clarity that I need, lol. I know what the different types of DNS records do. What I don't know is Microsoft Exchange...even though I'm the person responsible for it's upkeep. I've learned as I've gone along over the years but I mostly don't touch the exchange server because its so fragile and I don't know what I'm doing in that software.

I actually have our internal DNS server pointing to our public IP for mail server resolution and a few other services so that mobile devices can access resources when they are inside or outside the network. I know this doesn't work on higher end equipment like Watchguard's firewalls that only allow a single endpoint when dealing with hairpin NAT but these are small networks with basic SOHO firewall/routers.
 
What I had in my post is all I've ever had to do for about a dozen organizations. As long as you can resolve the FQDN internally (meaning mail.whatever.com resolves to your server), you should be fine to just run those commands and remove the internal names from your cert.
 
PiERiT said:
What I had in my post is all I've ever had to do for about a dozen organizations. As long as you can resolve the FQDN internally (meaning mail.whatever.com resolves to your server), you should be fine to just run those commands and remove the internal names from your cert.
Click to expand...

I understand and the link you posted is great. My question beyond what you provided was that there was conflicting information between what GoDaddy says and what Junior82 said. Just looking for clarification on it.
 
USMCGrunt said:
I understand and the link you posted is great. My question beyond what you provided was that there was conflicting information between what GoDaddy says and what Junior82 said. Just looking for clarification on it.
Click to expand...

Oh, I see. I didn't realize you were quoting the article in your post.

It should be an A record for mail (or whatever you use) and autodiscover. Probable typo in the article. I don't think an internal MX record is ever needed for anything.
 
You must log in or register to reply here.
Back
Top