3

I'm in a pickle with the infamous "The Security certificate has Expired or is not yet valid" message and I know it is due to our (multi domain name certificate; or I think that is called a SAN cert? right?) certificate having expired for our local server dns name:

servername.domainname.local

I see that GoDaddy has renewed our certificate automatically and it would normally seem like a cinch to go import it and hope the "The Security certificate has Expired or is not yet valid" message goes away for ALL internet Outlook clients, but the servername.domainname.local dns isn't on the auto-renewed certificate and instead our external dns name is on it: mail.domainname.md

From what I have been reading I now need to change servername.domainname.local to mail.domainname.md and this made me unfortunately realize I'd have to go and change all Outlook clients manually to point to the new external DNS... which also makes me think that this means that all INTERNAL Outlook clients that exist on the same network as the Exchange servers would then be going to the INTERNET to get their mail and come back in whereas I don't want that. I just want them going straight to the Exchange servers locally.

Does this new "no local domain cert registering" rule mean that mail flow is altered from internal to internal to internal to external to internal for traffic flow between the Outlook clients (2007) ?

If YES, does this mean that I have to go manually touch each Outlook 2007 client and change the server name to alleviate the "The Security certificate has Expired or is not yet valid" message?

Could I simply rerun certain certificate self-signing Powershell scripts I have found and generate a new local cert that will work to get rid of the popup message for the users to temporarily avoid registering a cert with an external DNS name?

If I'm right about needing to change the Exchange server name that all outlook clients refer to for their email, can I use this procedure to change it:

Exchange 2010: Outlook clients refusing to update to new CAS server

I really really hope somebody replies with "something" viable. I can't be the only person who's faced this and everything was just fine before the certificate renewal and the cert internal/external rule changed. I have about 60 demanding users and some just won't tolerate the popup at ALL.

Community
  • 1
OrthoNetAdmin
  • 27
  • 1
  • 2
  • I actual enjoy handling intolerant, demanding users and would be happy to deal with them for a bottle of scotch and 60 .308 rifle rounds... and travel costs, of course. Regarding the technical aspect of your problem, how (or do) you have autodiscovery configured? That's the easiest solution to getting your clients pointed at the right place automagically. – HopelessN00b Dec 02 '14 at 01:21

2 Answers2

0

I think you're conflating the issue more than it deserves. Assuming your cert already has the external name on the certificate and you've imported it and set the proper services for it it's actually fairly simple to tell Outlook clients to look for that cert.

There are three main things you'll want to change, just remember best practices and export these settings first so you can refer to them later if something goes wrong.

More or less you just want to set the InternalURL to be the same as the ExternalURL in the WebServicesVirtualDirectory, OabVirtualDirectory, and ActiveSyncVirtualDirectory.

Also if you haven't already in DNS make sure you have a SVC record for AutoDiscover that points to the external hostname (mainly what causes the warnings for internal clients).

David V
  • 840
  • 1
  • 8
  • 15
  • OK. I have the cert working for the external domains. Thank God and it took me 4 days to learn all this stuff so I'd know what I was doing with the Certs. ALL OF OUR INTERNAL DOMAIN OUTLOOK CLIENTS ARE POINTING TO THE LOCAL DNS SERVER NAME: EXCHANGE2.DOMAIN.LOCAL ... AND ALL OF THE INTERNAL OUTLOOK CLIENTS ARE GETTING THE SECURITY ALERT POPUP. DO I NEED TO CHANGE THE EXCHANGE2.DOMAIN.LOCAL URL IN ALL OUTLOOK CLIENTS (WHICH IT DOESN'T LOOK LIKE IT WILL ALLOW) OR ARE YOU TELLING ME IN MY INTERNAL .LOCAL DNS TO POINT AUTODISCOVER TO EXTERNAL MAIL IP SO IT WILL FIX THIS? – OrthoNetAdmin Dec 04 '14 at 23:34
  • It is best practice to have your internal dns resolve to the external hostname (ie in dns you should have a forward lookup zone for yourexternalname.com and it should have an entry something like mail.yourexternalname.com that resolves to your exchanges server's ip.) And yes you should have a SVC record for _autodiscover that points to mail.yourexternalname.com. – David V Dec 05 '14 at 01:44
0

As per CA/B forum new guideline for depreciation of local domain names in SSL certificates, no CA will issue SSL for local domain name. Also you can not acquire ssl for netBios names and IP address.

Till date idle set up for exchange server access to local network used .local domain name and for external use public domain names for outlookanywhere and owa. Accessing an exchange server on any network requires secure connection.

What action is required for exchange administrator?

Its required to remove .local domain configuration from exchange server. Before you remove it you should do the below.

Option1: Use public domain names to connect exchange on both networks like mail.exahngedomain.tld.

Option2: Add additional sub-domain on exchange server like local.exchangedomain.com, host on local network IP address. Then add/propagate DNS for this hostname on local network. This way you can keep exchange server local access limited to local network.

Do not escape the ssl certificate warnings in outlook connection, else your users will face issue whenever they start outlook.

eric
  • 1