Different Domains for App Server

Hi Folks!!

We have Kinetic 2022.1 running good so far locally into our business but lately we have the need to allow access from the internet for the mobile workforce (sales teams mostly). They only travel with a tablet and a mobile phone.

We are looking into using Epicor mobile CRM or web access directly.

Our present issue is that we use a acme.local domain with self-signed certificates but for internet access we would need a public signed certificate with a regular domain acme.com

Has anyone ran Kinetic with more than one domain or FQDN associated? Does someone runs more than one app server using different domains to the same database?

Thanks in advance for any light you can bring to us.

We also have a .local domain internally, but use a .com alias for our Epicor app server. This allowed us to use an SSL certificate from a valid CA instead of self-signed. Our internal DNS has a CNAME (Alias) record pointing to our app server.

So, we use epicor.domain.com instead of appserver.domain.local when accessing any Epicor resources.

On the app server setup, use the DNS Endpoint Identity to reference the .com domain.

image

However, we don’t expose our Epicor app server to the internet, so I can’t comment on that specifically.

1 Like

That’s what I think most people do. Spin up a separate app server altogether for outside access or services in general, separate from your production app server… You can give it a whole different cert and FQDN if I am not mistaken? Both app servers point to the same database. And with using different app servers you can make one (the outside one) use something like Azure AD auth with multifactor or other security enhancements since you can hit it from outside. Microsoft App proxy could work too. @Mark_Wonsil might be able to chime in here. I am novice so take this whole post with a grain of salt…

1 Like

lying top gun GIF

If you have a smart network guy in your poket you can use a network cop type software to generate appropriate cert on the fly at the firewall @EarlGrei did something like that at wci. He has a .local vs a .com and they both work fine with a single appserver

We use wild card cert on our app servers so we can use load balancer so as long as it’s xxx.tld.com it works fine you setup your dns assertion in admin console to match the wildcard cert

2 Likes

I have not tried Azure Application Proxy with the classic client but I have with the Kinetic web client in a small test case and it seemed to work. You create a map of external resources to internal ones. So https://erp.domain.com/instance/ maps to https://erp.domain.local/instance. You can set up multiple maps. Local agents on your network (for redundancy in case a server is down for any reason, and performance by not funneling every request through one queue) will accept calls from the outside and then send responses back. At that time, we were using the self-signed cert, and you upload it to the service so it was considered trusted. But now you can get a Let’s Encrypt cert and deploy it locally without exposing your internal system to the Internet.

As a rule, I prefer to reduce the access surface to internal resources. I would never run an IIS or Exchange server on prem and expose it to the Internet. But that’s me… :person_shrugging:

You may also try something like Tailscale, which is a safer VPN service since it’s not like Exchange or IIS that sits at your perimeter and waits for connections either.

**EDIT: I believe that Microsoft will provide a Cert for the Application Proxy Service for the external address.

2 Likes

I am a novice when it comes to networking and security. I only learn about it when I have issues with Epicor app servers!

I tried app proxy with the classic client on 10.2.500 and it wouldn’t work. @Olga also hopped on and said it was not going to be possible to use something like that with the classic client.

I would believe Olga!

1 Like

it wanted redirect to AAD login screen, AFAIR. It is hardly possible with WCF API calls.

2 Likes

You have a good memory! I hardly remembered what exactly we were trying to do :sweat_smile:

i suggested to try with browser client

1 Like

Yes, and I am glad to see @Mark_Wonsil already did that and that it worked in the limited testing he did!

We plan to try again Olga, when we get our other company on Kinetic.

2 Likes

I didn’t want to put more work into the classic client but if the binding was https instead of NET.tcp, do you think it might have worked? :thinking:

we had ours bound that way, but again, not sure if I had everything else set up correctly for it to work.

I don’t see how it would work. That proxy wanted to redirect to another site so client would be authenticated. REST call in smart client does not expect to receive a web page with login window instead of JSON from server.
Even if you use AAD auth in smart client, all its cookes are left in MSAL dialog where you logged in, and are not available from HTTPClient that is used to make server calls.

Edge agent won’t work either for the same reason.

1 Like

Wow!! such a overwhelming amount of response in such a short time! love EpiUsers! =D

We are setting up an app server in a DMZ so we can expose it to the internet with controlled access to the internal network. Do you guys know license wise how it will behave?

2 Likes

You give it the same Epicor license file as your other app servers.

1 Like