Trusted SSL Cert for a .local domain server

I hope I can describe this clearly. I’m trying to get a trusted SSL cert for our Kinetic server, which is on a .local domain. I’m open to any possible solution.

Here’s what I’ve done so far. (names have been changed to protect the innocent)

local domain = abc.local
public domain =

I’ve created a second internal DNS zone for and created an A record for, which points to the IP of our Kinetic server. I can now ping successfully. I have a wild card cert for *, which I applied to IIS.

In the following URL to the Kinetic login, I can replace with and it works and shows a vaild cert now.

The client still shows (in the top right) and if I click the Open Kinetic in Browser it still point to the .local. I think I need to modify the client to use the address, however, I can’t seem to do that.

In the Admin console, under server management it’s listed as, so I thought maybe I needed to add as a new server and create a new Application Server. I was able to add, but I can’t create a new App Server.

That action is only available when the Admin Console is running on the server.

Any pointers would be greatly appercated!

This is defined in the clients sysconfig file, just edit the app server url and it should point to that one.
The sysconfig file is in the deployment path inside the config folder, if you have several sysconfig you can check the shortcut you use to launch the ERP to see which one it is using.

Have you been able to resolve that issue?

We ended up doing what @Jonathan suggested and manually edited the sysconfig file to use the public domain. You change to change 2 values; AppServerURL & HomePageUrl

The one downside is that during every update you have to remember to edit these values again.

1 Like

I just installed 2022.2.7 with a wildcard cert and for us there were two settings I needed to updated. Our wildcard cert is *.[DomainName].com. I don’t install the certs but in IIS I set the host name to [ServerName].[DomainName].com in the https binding, with DNS pointing to the same name. Then in Application Server Configuration the SSL Certificate Subject Name is the selected wildcard cert but the key was then to set the DNS Endpoint Identity to the same [ServerName].[DomainName].com. Make sure to Deploy. Was then able to connect to the App Server in EAC and the client without having to mess around with the .local domain. So instead of EAC trying to connect to the default .LOCAL domain it now connected to the DNS domain.



Update. Found out I did not need to add it to the bindings in IIS, just in the server configuration.

Also, since the value is in the DNS Identity it updates the sysconfig files for the App Server and Home Page URLs to the proper values, no need to manual update after applying updates going forward.


To clarify, are you all able to do this with Single Sign-on, also?

What we need/want to do is

  1. Kinetic 2022+
  2. Our internal domain is .local
  3. Our SSL is issued to .com (necessary for integration)
  4. Use single sign-on (SSO) tied to either AD or Azure AD
  5. Bonus points - ability to use classic client also (preferred; not mandatory)

Have some or all of you accomplished this combination?

We have not got it to work yet.

After help from Epicor support, we accomplished all except #s 4 and 5. I am able to log into 2022.2, from a browser, outside the domain, using Epicor creds (not AD).

I haven’t tried Azure AD yet.

Yes to all, except we are currently using Windows authentication specifically for the classic client. Azure AD when logging in to the Kinetic web UI.

(not exposed to the internet, all connections need to be from the local network or by VPN)

Hmm. I guess I need to specify that we need that also, for integrating with our e-commerce store, for example.

But regardless, my testing has failed before that point anyway. It’s the SSO (AD) step that bombs.

Do you use Azure AD? Edit: I can’t read.


Man I need to read better. Sorry.

Well then I am lost.

Impossibly broad question, but what am I missing?

(And what did Epicor support miss also…? Though in their defense they kind of stopped at, “Oh the network is your problem. Contact a consultant…”)

FYI, the client fails for me with this error:


Did you ensure the SSL cert is installed in the proper store location?

Anything is possible, but if I can get to the same endpoint in a browser, outside the network, would that not imply that it is set up correctly?

Honest question - not sarcasm.

Otherwise, I think it’s in trusted root but I’ll check.

Here’s Microsoft’s recommendations on domain naming.


.local was picked by many but unfortunately not an accepted standard. The recommendation is to use a subdomain of your external domain (or an entirely different domain). It is possible to get a free cert from Let’s Encrypt for your internal network using the recommend subdomain option. (Watch for an upcoming Cloud and Obnoxious article.)

I’ve been able to use Azure AD with the classic client without issues. Heck, that was available in 10.2.300 or so.

While AD is comfortable for many of us, it doesn’t handle non-Windows devices, can’t do conditional access like Azure AD, is a trust-based system, doesn’t register approved applications, MFA costs extra, and doesn’t interact directly with your M365 services if you use them.

I learned from @olga that SSO is ONLY AD. You can assign an arbitrarily large password to force Azure AD login.

1 Like

I’ll do my best to sound intelligent here…

No argument with best practices, but we are already in the bad-practices boat. So before I ask some questions to help me understand this, let me describe where we are at first.


  • Our network was set up decades ago as example.local
    • 300 computers on this network, plus servers, printers, etc.
  • Our emails are on
    • It was on-prem AD (only), but is now a hybrid Azure and on-prem AD sync thing
  • Currently the production Epicor environment is on an example.local server but tied to an address of
    • Not literally, but the point is that it’s
  • We have a public SSL (from GoDaddy) for
  • IIS bindings resolve the difference

All of this works fine in Kinetic 2021.2. But not in 2022+. I am told it is owing to the abandonment of TCP.

So, the subdomain thing you mention. I saw a whiff of that in the MS doc you linked to:


Not sure if this is what you are meaning, but since we already have a subdomain in the Epicor endpoint, where does that leave us?

I don’t touch DNS entries myself, so my experience is nil with that part of it, FYI.

What does your application server configuration look like?

And your .sysconfig file(s)? Specifically the AppServerURL and AuthenticationMode options?

<AppServerURL value="" />
<AuthenticationMode value="Windows" options="Windows|AzureAD|IdentityProvider|Basic" />

Humor me - which ones? Like the ones in C:\Epicor\...\config that are used for a client?

Or some folder somewhere on the server?

Like this - because that’s all we could get to work. But I will try it the way you show.



In our system, the AppServerURL and AuthenticationMode options match on both the client and server side.

Also, do you have your ‘.com’ domain specified in the DNS Endpoint Identity field in Application Server Configuration?


OK, well I have AppServerURL as .local, so I will change that everywhere and give it a whirl.