[SOLVED] Exchange cert warnings... ignore them option!

[TAPtech]

I have a client with an expired SSL cert on their server, they are still using a .local domain on their SBS08 box. In my eyes they are the right client for hosted exchange but they absolutely hate subscriptions of all kind, with a vengeance. Probably the only cost they will spring for is going with a self-signed certificate and installing it on their workstations. They do not access their email outside of their building.

Anyone have a good reason not to do this? They are also inclined to simply ignore the warning. I see how this could leave them vulnerable to a man-in-the-middle type of attack, but unless that man is inside their building it sounds unlikely!

 

[YeOldeStonecat]

Just have the SBS08 box whip up a CSR for a new SSL cert....like remote.myclient.org

 

[YeOldeStonecat]

PM'd you my e-mail addy....shoot me an e-mail.

 

[NYJimbo]

We go through cert renewals every year on all of our cpanel servers. The machines makes a self-signed cert and all the customers have to now accept the new cert. The problem is that a year or so ago some people were not using SSL software and they may now have SSL/Encryption turned on, but now that it is becoming standard in all apps, this self-signed cert thing really screws people up. I have customers calling me now about their phones and ipads failing authentication on imap and smtp and it's a pain in the ass.

 

[YeOldeStonecat]

Yeah...the e-mail clients wanting to autodiscover right away...leads to the errors showing up more, than in prior versions of e-mail clients. Autodiscover is the standard now. And certs, and DNS, need to be correct about it.

 

[TAPtech]

I have gone through that too on my VPS mail server, but I have WHM autodiscover setup to use the VPS mail server name instead of "mail.theirdomain.com" so they aren't getting any errors. And of course the VPS has a proper SSL set up. Also I have SSL communication set as default and is presented in the autoconfig settings. Scary having those plain text emails flying around at coffee shop WiFi locations! I'm concerned for my clients security but also the mail server!

This one is a bit different though as they are getting an error for the server at a .local domain. It's been a while since I've been through Outlook on one of their machines but I believe they are all setup to "use HTTPS if available." I wasn't sure how the whole .local expiration came into play.

 

[TAPtech]

PM'd you my e-mail addy....shoot me an e-mail.

Got your email, as usual, you're the man. Thank you so much!
In the spirit of helping others, I would like to keep this thread going as we all know the .local domain can no longer use a public SSL, and I'm guessing others may be getting questions from break-fix or new clients about these issues.

 

[freedomit]

Check out SSLS.com, you can pickup mega cheap certs

 

[YeOldeStonecat]

This one is a bit different though as they are getting an error for the server at a .local domain. It's been a while since I've been through Outlook on one of their machines but I believe they are all setup to "use HTTPS if available." I wasn't sure how the whole .local expiration came into play.

I used to do the 5x name UCC SSL certs for SBS....but I just do a single name standard SSL cert now. You can get Exchange so that the .local isn't anywhere....create the SSL to something like remote.myclient.org and then go through all the nooks 'n crannies of Exchange and ensure its FQDN names are set to match that (ya know..the HELO on the receive connectors, Exchange Web Service URL, address book URL, couple of other places...some guides can be found where to find all those..I don't know them by heart).

Ensure public DNS record set to resolve that name.
Ensure the firewall supports loopback so that public FQDN can be resolved internally by Outlook clients.

 

[TAPtech]

That's the solution I was looking at after doing some research. Basically how I would setup a new domain, but this one is of course inherited and a bit goofy (oh there are other problems... lots of other problems...)

Except I'll probably do something like local.myclient.com or sitename.myclient.com as that's the scenario.... actually now that I think about it, they may already have a cert for sbs.mycliient.com.... hmmmm must do some digging!

 

[YeOldeStonecat]

You could do something like sbs.myclient.com...utilizing the host name of the server if you want.
Just...since many clients love to remote in, I follow the general convention of "remote.client.com" on SBS setups.
That "local.myclient.com" just seems...awkward. Forget about "local".

You're not setting up a new domain, you're just utilizing their existing public/WWW domain....to alias to the outside interface of SBS...which include Exchanges ports/interfaces. Exchange may run on active directory (.local)..and use it for internal authorization, but it's aliases can always be public FQDNs. Whatever name you choose just has to be setup on all the proper interfaces of Exchange, and be resolvable outside and inside the network (with inside the network..hence the need for the firewall to support loopback).

 

[putz]

That's the solution I was looking at after doing some research. Basically how I would setup a new domain, but this one is of course inherited and a bit goofy (oh there are other problems... lots of other problems...)

Except I'll probably do something like local.myclient.com or sitename.myclient.com as that's the scenario.... actually now that I think about it, they may already have a cert for sbs.mycliient.com.... hmmmm must do some digging!

No need for a new domain setup. You need to modify the Exchange internal and external URI's/URLS to use a public DNS name, example server.mydomain.com. There are a series of Exchange Management Shell commands to modify them, you should be able to find them using google. On your LAN DNS servers, create the matching zone server.mydomain.com and create a blank A record that points to the private IP address of the server. Generate a CSR out of exchange on the SBS box for server.mydomain.com and get a cert from your provider and install it and assign it as the default SMTP and IIS cert. Problem solved. Although autodiscover wont work outside the LAN, you can always manually setup external clients with outlook anywhere.

That will work with anything previous to office 2016. If your customer starts using that then you need a mutli domain or SAN cert with both the server dns name and autodiscover.mydomain.com and you must have DNS records for autodiscover otherwise outlook 2016 cannot setup the account.

 

[TAPtech]

OK, got this one nixed. I need to clear something up here... when I said "new domain setup" I misspoke. I should have said "new server setup" ie, how I would do things with a fresh install and new domain name and everything. I believe that the root of the issue was that the server was presenting itself as SERVERNAME.DOMAIN.LOCAL and giving the existing UCC cert that had that same presentation listed. Well, .local is no longer valid so that part expired. Renewed the cert from their GoDaddy account and made sure that the domain for OWA was in there as a SANs. Not that they really use it! Anyhow, here's the command that got her up and running, and got that SERVERNAME.DOMAIN.LOCAL cert warning error to go away in Outlook:

Set-ClientAccessServer -Identity HostName -AutodiscoverServiceInternalUri https://mail.yourdomain.com/autodiscover/autodiscover.xml

Found from: https://www.digicert.com/ssl-support/redirect-internal-exchange-san-names.htm

 

[YeOldeStonecat]

I still do ".local" on new setups. Microsoft even sets that as standard when you deploy Essentials server. Granted Essentials doesn't have Exchange on it, so none-issue..but by doing what we mentioned above for Exchange..the single name standard cert is fine.

 

[TAPtech]

Thank you all for the help, yet again! Another happy client

Server is a bit grumpy though... guess that just comes with age.

 

[TAPtech]

Ran across this tool today as I had another one of these boxes appear on my radar. Worked GREAT!

https://www.digicert.com/internal-domain-name-tool.htm