I’m the server admin for my company and we’ve just moved our Epicor install back in house, I’ve been assigned a task of getting the REST API accessible outside of our network for 3rd party integrators, but have hit a problem with the self signed certificates that were installed when the new ERP was set up
As they’re self signed they won’t work with Azure which is being used by a 3rd party for integration, so I went off and got a real cert
I tried to configure “SNI” in IIS which allows us to use multiple certs on a single binding on the server, but then Epicor won’t start properly (I’ll have to dig up the details from our ERP guy), but I know the task agent wouldn’t start and we couldn’t log in… not great
Is it possible to set Epicor up this way to have the self signed cert for clients to use to connect and also another cert for external REST access? If this isn’t possible how have others done this where having a real cert for REST is required?
Alternatively what are the implications of changing the cert that Epicor uses to this new “real” cert since it would be a different DNS name (local clients currently use one of the https channels to connect to a .local DNS name)
From a security standpoint, many like to segment the on-prem server from the API endpoint. One way to do that is to use something like Azure API Management with virtual networks.
Hi Mark,
I’d actually found that last night after I’d posted this and it sounds like it might work for us (in essence it sounds like the API endpoint is just a reverse proxy for API traffic)
I’ve got the extra details of the error that is thrown when we try and start Epicor with the additional certificate binding:
Sender Information: System.ServiceModel.ServiceHostingEnvironment+HostingManager/60375305
Exception: System.ServiceModel.ServiceActivationException: The service ‘/EpicorERPTest/Ice/BO/UserFile.svc’ cannot be activated due to an exception during compilation. The exception message is: This collection already contains an address with scheme https. There can be at most one address per scheme in this collection. If your service is being hosted in IIS you can fix the problem by setting ‘system.serviceModel/serviceHostingEnvironment/multipleSiteBindingsEnabled’ to true or specifying ‘system.serviceModel/serviceHostingEnvironment/baseAddressPrefixFilters’.
Parameter name: item. —> System.ArgumentException: This collection already contains an address with scheme https. There can be at most one address per scheme in this collection. If your service is being hosted in IIS you can fix the problem by setting ‘system.serviceModel/serviceHostingEnvironment/multipleSiteBindingsEnabled’ to true or specifying ‘system.serviceModel/serviceHostingEnvironment/baseAddressPrefixFilters’.
Parameter name: item
Do you know if it’s supported by Epicor to make changes like this manually in the web.config file, or are we meant to let this be generated by what I assume is the deploy process when you set your server up or make changes?
Appreciate the help regardless, as there isn’t much that Google can tell us which is specific to Epicor
Hi All,
Well we bit the bullet and just outright replaced the certificate and updated the client configuration on our test server to match the new certificate name, so far everything seems to be working without any issues
We’re now just using a single https scheme as suggested rather than using SNI
It will be a case of thorough testing of everything to make sure this hasn’t broken anything (fingers, toes crossed)
